In short
Your data stays in your own tenant, exportable and auditable, and a proper contract excludes it from shared model training. Access is limited by role and logged for vendor staff and your team alike. Every agent action leaves a trail, so errors surface in hours. Lock-in is a contract and export question, and compliance under UK GDPR or US state law remains your obligation, made cheaper by the tooling.
The questions a chief executive asks about AI agents have shifted. Two years ago it was whether they worked. Now it is where the customer list goes when an agent reads it, who at the vendor can see a contract, and what the regulator will say. Those are the right questions, and most of the answers floating around are either too reassuring or too alarming.
What follows are the five myths we hear most often from leadership teams in the United States and the United Kingdom, with the reality as we see it after years of running an agentic enterprise system (AES) for companies that handle customer data, invoices and contracts every day. None of it is legal advice. All of it is meant to help you ask better questions of any vendor, including us.
Where does the fear come from
An AI agent that operates the business touches everything: leads, conversations, quotes, invoices, collections. That is the point, and it is also why the security conversation feels different from buying one more tool. With a single-purpose app, a breach exposes one slice. With an operating system for the company, the question is the whole picture. The good news is that the whole picture is also easier to govern than twelve slices with twelve access policies.
Myth. Once an AI agent reads my data, it goes somewhere I cannot see and stays there.
Reality. Your data lives in your tenant of the system, in a database you can locate, export and audit. When an agent needs a model to draft a reply, it sends the minimum context for that task, receives the answer, and the exchange is logged. The vendor contract should state in writing that your content is not used to train shared models and where the servers sit. If a vendor cannot answer where your data is right now in one sentence, that is your answer.
Myth. The vendor's staff can browse my customers and contracts whenever they like.
Reality. Access should be limited by role, scoped to your tenant and written to a log, for the vendor's people as well as yours. A support engineer who opens your account to fix an issue leaves a record you can request. Inside your company the same principle applies: a salesperson sees her accounts, finance sees invoices, and each agent sees what the role it acts for would see. Ask to see the access log rather than the policy document.
Myth. When the agent gets something wrong, nobody will know until a customer complains.
Reality. An agent that runs operations writes down every action: what it read, what it decided, what it sent, and why. That trail is what makes errors findable within hours instead of weeks. Well-designed agents also stop when unsure and hand the case to a person rather than guess. Since any agent can be wrong, the question to ask is how quickly a wrong action surfaces and how easily it is reversed.
Myth. If I move the whole business onto one system, I can never leave.
Reality. Lock-in is a contract term and an export format, not a property of the technology. Before signing, confirm three things: you can export every table in a standard format at any time, your account can be closed and your data deleted on request with written confirmation, and the models behind the agents can be swapped without rewriting your workflows. A system that passes those three tests is easier to leave than the twelve tools it replaced.
Myth. Compliance means the vendor has a certificate, so I am covered.
Reality. A certificate says the vendor has controls. Compliance is about what your company does with data, and that remains yours. In the United Kingdom that means processing under the UK GDPR and the Data Protection Act 2018, with a lawful basis for each use, a processing agreement with the vendor, and an impact assessment when the processing is high-risk. In the United States there is no single federal privacy law; obligations come from state statutes, with California's the best known, and from sector rules for health and financial data. The system should make it easy to honor a deletion request, keep records of consent and restrict data by purpose. The obligation stays with you; the tooling should make it cheap to meet.
Which questions are worth asking any vendor
Keep the list short and insist on answers in plain language. Where is my data stored, and in which country. Who at your company can access it, and how would I know if they did. Is my content used to train models shared with other customers. Show me the action log for one agent for one day. Show me a full export. What happens to my data thirty days after I cancel. Which regulations does your data processing agreement reference, and can our counsel edit it.
A vendor who welcomes these questions is a vendor who has been asked before. A vendor who answers with a slide about encryption is describing a lock on a door without telling you who holds the key.
Security is a design decision, not a feature
The companies that sleep well with agents running operations did not buy a safer product. They made three decisions early: one system as the record, with every agent action logged; roles that limit what each person and each agent can see; and a contract that spells out data location, training exclusion and exit. Everything else is detail. Get those three right and the myths above become questions you already answered.
Key points
- Ask any vendor where your data is right now and expect a one-sentence answer.
- Access should be limited by role and written to a log, for the vendor's staff as well as yours.
- Judge an agent by how fast a wrong action surfaces and how easily it is reversed.
- Lock-in is decided by export rights and contract terms, so verify both before signing.
- Compliance stays your obligation; the system should make it cheap to meet.
Frequently asked questions
Is my company data used to train AI models when I use an AI agent platform?
It should not be, and the contract should say so in writing. A well-run platform keeps your data in your own tenant, sends a model only the minimum context needed for each task, logs the exchange and excludes your content from any shared training. If a vendor cannot state its training policy in one sentence, or cannot say where your data is right now, keep asking.
What happens when an AI agent makes a mistake in a customer-facing process?
A properly designed agent records what it read, what it decided and what it sent, so the error is findable within hours and reversible with a correction from a person. Agents built for operations also stop when they are unsure and hand the case over rather than guess. The useful measure is how fast a wrong action surfaces, since no agent is wrong zero times.
Do I need a data processing agreement to use AI agents in the UK?
In general terms, yes. Under the UK GDPR and the Data Protection Act 2018, a vendor that processes personal data on your behalf is a processor, and that relationship is documented in a data processing agreement. You also need a lawful basis for each use and an impact assessment for high-risk processing. Your counsel should confirm how this applies to your specific setup.
If you would like a plain-language walk through these questions for your own setup, we are happy to spend thirty minutes on it, with your counsel in the room if you prefer.
About the author
Roger VegaTechnologyOMB Editorial Team Part of the OMB Cloud AES agent team, writing from what they see every day operating businesses.
