Your AI vendor's terms allow them to train on your client data. Did you know?
Most AI platforms include broad data use rights buried in their terms of service. If you're passing client data through those platforms, you may have already breached your own client agreements — and your clients don't know either.
Here is a question most founders have never thought to ask: have you read the data use terms of the AI tools your business uses?
Not the privacy policy. Not the cookie notice. The actual terms that govern what the AI vendor can do with the data you put into their system when you use it.
If you haven't, the answer is almost certainly not what you'd want it to be. And if any of that data belongs to your clients, you have a problem — potentially a serious one — that started the moment you first used the tool.
The problem most founders haven't noticed
The business model of AI platforms depends on data. The better the data, the better the model. The better the model, the more valuable the product. This creates a structural incentive — baked into almost every major AI vendor's terms — to retain broad rights over the content users feed into their systems.
These rights typically appear in two forms:
- Licence grants: A clause granting the vendor a broad, often sublicensable, royalty-free licence to use your inputs to improve, train, or fine-tune their models. The scope varies enormously — some are narrow (only for operating the service), some are extremely broad.
- Retention rights: Clauses specifying how long your inputs are retained, whether they can be associated with other data, and under what conditions they might be reviewed by human employees for quality and safety reasons.
The important thing to understand is this: the terms vary significantly by product, by pricing tier, by API versus consumer access, and often by region. And they change — sometimes without prominent notice. What the terms said when you first signed up may not be what they say now.
What the terms actually say — in plain English
Without naming specific current versions of any platform's terms (they change, and citing a specific version here could become misleading), here is the landscape of what you'll typically find:
Consumer / free tier products tend to have the broadest data use rights. If you're using a free tier of an AI tool to process business data — including client information — the vendor almost certainly has the right to use that data to improve their models. This is not small print. It is the mechanism by which free products are made financially viable.
Business / enterprise tier products often have more restricted terms, sometimes with explicit opt-outs from model training. But "more restricted" is not the same as "restricted." Many enterprise tiers still include licence grants that go beyond what you'd want if you read them carefully. And the opt-out for model training, where it exists, often requires a specific setting to be enabled — one that isn't on by default.
API access typically has different terms than the consumer product. In many cases, API terms are more restrictive about data use — but again, this varies and you need to check the specific version applicable to your agreement, not general assumptions.
The common thread: almost no UK SME has actually read these terms, compared them against what data they're putting through the platform, and assessed whether that use is compatible with their obligations to their own clients.
The chain reaction of liability
When you pass client data through an AI platform whose terms allow model training on that data, a chain reaction of potential liability begins:
Step 1: You receive client data under a contract that typically includes confidentiality obligations and data protection warranties. The client's implicit assumption — often their explicit assumption — is that their data stays within your business and any sub-processors you've explicitly authorised.
Step 2: You feed that data into an AI tool. Under the vendor's terms, the vendor now has a licence to use that data. Whether or not they exercise it, you have granted a right that your client did not authorise you to grant.
Step 3: You have potentially breached: your client contract (confidentiality and data handling obligations), UK GDPR (lawful basis — the client's data was not provided with consent or under a contract basis that covers third-party AI training), and any DPA you have with the client (which almost certainly doesn't name this AI vendor as a sub-processor).
Step 4: The client discovers this — through press coverage of the vendor's practices, a DSAR they submit, their own legal due diligence, or simply asking you. They have a legitimate complaint even if no harm has materialised yet.
This is not theoretical. The digital marketing agency case study on our homepage is a real example of exactly this pattern. Four AI vendors had model training clauses. The client contracts said nothing about it. The clients did not know. The paper trail was completely inconsistent with what was actually happening.
The DPA gap — why this is also a GDPR issue
Under UK GDPR, if you share personal data with a third party who processes it on your behalf, that third party is a data processor. You are required to have a Data Processing Agreement (DPA) with them — a contract that specifies what data is being processed, for what purpose, under what instructions, with what security measures, and what happens to it when the relationship ends.
Most businesses do not have a DPA with their AI vendors. They have terms of service — which are not the same thing. A ToS is a commercial agreement. A DPA is a specific legal instrument required by Article 28 of UK GDPR, with specific required clauses.
But the more fundamental problem is the processor classification itself. If your AI vendor's terms allow them to use your inputs for their own model training — a purpose that benefits the vendor, not you — they may not be acting as a processor at all. They may be acting as a controller. And that means the entire GDPR framework you've tried to apply (or haven't tried to apply) is built on the wrong foundation.
A processor processes data solely on the controller's instructions, for the controller's purposes. The moment the vendor uses that data for their own independent purpose — improving their model, training their system — they cease to be a processor and become (at least jointly) a controller. At that point, they need their own lawful basis for processing the data. And the question is whether you, as the original controller, had the authority to transfer the data to them in a context that allows that.
In almost every case where a business is passing client personal data to AI tools without telling their clients, the answer is no.
What your client contracts likely say about AI
Read your client contracts and search for any of the following: AI, artificial intelligence, machine learning, automated processing, sub-processor, third party processing.
In most contracts written before 2023, you will find nothing. AI simply wasn't contemplated. In contracts written in 2023-2024, you might find a general confidentiality clause and a data protection schedule — but the data protection schedule almost certainly doesn't name your AI tools or contemplate the training data question.
The absence of specific language is not protection. Confidentiality clauses typically cover all client information, full stop. "We will not disclose your confidential information to third parties" does not have a carve-out for AI vendors. Passing client data to an AI platform — regardless of what the platform does with it — may already constitute a breach of a standard confidentiality clause.
Your clients' lawyers, if they ever look at this, will make exactly this argument.
How to fix it — the three-part solution
There is no single fix because the problem sits at three levels: vendor terms, internal documentation, and client contracts. Each needs to be addressed.
1. Vendor terms audit
For every AI tool that handles client data, read the current data use terms carefully. Specifically look for: model training rights, licence grants over user inputs, human review provisions, data retention periods, and what controls you have. If the vendor offers a business tier with restricted training rights, assess whether switching is warranted. If there's an opt-out, ensure it's properly activated.
2. DPAs and sub-processor documentation
For any AI vendor that processes personal data on your behalf — even if they're also using it for their own purposes — you need to be operating under a proper DPA or enterprise agreement with equivalent protections. These are not always easy to obtain from major vendors, but enterprise agreements often include data processing terms. Document which vendors you've assessed, what their classification is (processor vs. controller), and why.
3. Client contract updates
Your client contracts need to reflect how you actually work. This means: adding AI use provisions to your service agreements, updating confidentiality clauses to include appropriate carve-outs for sub-processors you've properly assessed, ensuring your data protection schedules name or describe the AI tools used, and — depending on what your clients' data is and how it's used — potentially obtaining explicit consent or updated contractual authority for AI processing.
For existing clients, this typically means a contract amendment or addendum. For new clients, it means building these provisions into your standard terms from the start.
What to do now
Start with an honest inventory. Write down every AI tool your business uses. For each one, note whether any client personal data flows through it. If yes, find and read the data use section of the current terms — not the privacy policy, the actual usage and data rights provisions in the terms of service or enterprise agreement.
You will probably find things that concern you. That is the point. Finding them now, when you can fix the contracts and vendor arrangements proactively, is vastly preferable to finding them through a client complaint, a DSAR, or an ICO inquiry.
The businesses we see this affecting most acutely: agencies of all kinds (marketing, PR, legal, HR, consulting) who handle large volumes of client information; SaaS companies whose AI features process end-user data; professional services firms who use AI for research, drafting, or analysis on client matters; and any business that has embedded AI deeply into client delivery without updating its contracts.
If you want someone to go through your specific vendor terms, assess your exposure, and tell you exactly what your contracts need to say, that is exactly what we do.
The six lawful bases — which one your AI process actually uses
If your vendor is a joint controller, you need your own lawful basis. Here is how to identify it.
Read article Free resourceThe AI Compliance Checklist
12 questions — including whether you've checked your vendor DPAs. Most founders haven't.
Take the checklistWant your vendor terms and client contracts reviewed?
Book a free 30-minute session. We'll tell you exactly what your AI vendor terms allow and what your contracts need to say to protect your client relationships.