“If you use Fable, Anthropic keeps your data for 30 days.” Jordan Wilson said that on the Everyday AI podcast earlier this year, and it set off a lot of discussion among business AI users who’d never checked what their vendor contracts allowed[1]. For an ordinary software user, thirty days’ retention is a nuisance. For a regulated advice firm putting suitability information, cashflow projections and meeting notes through the tool, it’s a compliance problem with a named regulator attached.
Most firms using AI tools haven’t read the data clauses. They started on a free trial, moved up to a business tier and carried on. This piece covers what those clauses usually say, which ones matter in a regulated firm, and what to check before you sign anything else.
Why AI vendor contracts are now a compliance issue for advice firms
AI tools are now handling data they were never designed for, in volumes and sensitivity that put them firmly inside your UK GDPR obligations and the FCA’s expectations.
A few years ago, an advice firm “using AI” meant a chatbot on the website or a grammar checker in Word. Neither touched client data in any real sense. Now firms put meeting transcripts, fact-finds, cashflow models and draft suitability letters into AI tools. That data is usually personally identifiable, often financially sensitive, and sometimes includes details that count as special category data under UK GDPR.
The contracts behind those tools were mostly written for the general business market, not regulated financial services. Their terms are perfectly normal for a marketing agency or a software company and quite wrong for a firm under FCA oversight.
The four clauses that matter most
Four clauses come up again and again when you read AI vendor terms properly.
Training rights. Many standard-tier contracts let the vendor use your inputs and outputs to improve its models. The wording is usually along the lines of “aggregated, anonymised data may be used to improve service performance”. In practice, client information you paste in, even redacted or paraphrased, may end up as training material. Anonymisation is a process, not a guarantee, and it doesn’t always work.
Retention. Vendors commonly keep conversation data for anything from a few hours to several months, depending on tier and settings. Some keep it until you ask for deletion. The thirty days Wilson mentioned for one major platform isn’t unusual[1]. For a firm with data minimisation duties, open-ended or long retention is a liability.
Sub-processors. Most AI vendors use sub-processors: cloud hosting, monitoring services, safety evaluation tools. The contracts give them wide room to share data with these parties, as long as the sub-processor keeps “equivalent” protections. You’re rarely told who they are, where they are or how long they keep data, which matters for international transfers under UK GDPR.
Where the data is processed. Standard tiers often process data in the vendor’s home jurisdiction, which may be the US. A UK firm sending data there needs a proper transfer mechanism. Many vendors offer one, but often only on request, on the enterprise tier, with the data processing agreement explicitly in place. Signing up in a browser doesn’t put it in place for you.
What Zero Data Retention means and when to ask for it
Zero Data Retention (ZDR) is an enterprise privacy commitment offered by a handful of major AI vendors. Under ZDR, the vendor doesn’t store your inputs or outputs once the request is finished: nothing in their logs, nothing in their training pipeline, nothing kept for safety review in a form linked to your account[1].
ZDR does not change what the model does with your data while it is processing it. It changes what the vendor does with it afterwards, and most vendor explanations bury that distinction.
ZDR isn’t on consumer or standard business tiers. It needs an enterprise contract, usually costs more, and often comes with a separate data processing agreement. If your firm puts identifiable client information through an AI tool without ZDR or an equivalent contractual protection, it’s worth checking hard whether your arrangement meets what UK GDPR expects of a processor.
Asking for ZDR is a reasonable and increasingly normal request. If a vendor can’t offer it, or can’t tell you clearly how long it keeps data, that tells you something.
Sovereign AI versus token-metered services
Digital Applied draws a useful distinction between sovereign AI and token-metered services[2]. It sounds technical, but the question underneath is simple: when you send data to this vendor, where does it go, who can see it, and what rights do you have over it?
Token-metered services are the standard API model. You send a request, the vendor processes it on shared infrastructure, sends back a result and keeps logs for a while. Your data passes through systems you don’t control, on terms you agreed at sign-up. Most AI tools in use today work like this.
Sovereign AI, in the vendor sense, means the model runs on infrastructure you control, or on dedicated infrastructure in a specific jurisdiction, with contractual guarantees that data stays there. Local deployment goes further: the model runs on your own hardware and the vendor data processing question disappears. As one engineering blog puts it, moving AI to local infrastructure turns the compliance question from complex legal contracts into network diagrams you can verify[3]. That’s simpler to audit, although it brings its own requirements around model governance, updates and validation.
For most advice firms, full local deployment isn’t a near-term option. The middle ground is an enterprise contract with explicit data residency and sub-processor controls, which the major vendors will provide today if you ask before you sign.
Five checks before you sign
Most of this can be done by whoever handles data protection in your firm, without specialist legal help. For any enterprise AI contract that will touch client data at scale, I’d still get a solicitor to look at it before signing.
Find the data processing agreement. Every AI vendor covered by GDPR or UK GDPR should offer one. If it isn’t easy to find on their website, ask your account contact. If they can’t produce one, you have your answer.
Read the training clause. Look for wording about using your data to improve models, train systems or develop features. If it’s in the default terms, ask whether you can opt out and which tier that needs.
Get the sub-processor list. Most vendors publish it, often alongside the DPA. Check whether any sub-processors sit outside the UK or EEA and whether the transfer mechanism is named.
Ask about retention directly. Default retention is often buried in documentation that changes without notice. Get the answer in writing, including what happens to retained data when you cancel.
Confirm where processing happens. If it’s outside the UK, confirm the transfer mechanism (adequacy decision, standard contractual clauses or something else) and that it covers how you use the tool.
None of this is unusual compliance work. It’s the same due diligence you’d do on any third-party data processor, applied to a kind of tool that changes quickly and whose defaults are rarely set in the customer’s favour. For a fuller walk-through of contract terms, see how to read an AI vendor contract, and for the wider supplier checks, the AI vendor due diligence checklist.
Vendors are moving slower than regulators
AI governance has moved from internal good practice to a regulatory expectation, and most AI vendors haven’t kept up. MIT Technology Review has reported on the gap between how fast firms are deploying AI tools and how mature the governance around them is[4]. Some vendors have set their default terms to match: permissive unless you ask, restrictive only on request, and only at enterprise prices.
That’s no reason to avoid AI tools. It’s a reason to read what you’re signing before any client data goes in. Start with the DPA and the training clause for the tool your team uses most, because those two answers decide whether the rest of the checks are urgent.
This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.
This article does not constitute legal advice. Data protection obligations vary by circumstance and jurisdiction. Consult a qualified solicitor or data protection adviser for advice specific to your firm.
Sources
[1] Everyday AI, ‘Jordan Wilson commentary on Anthropic data retention terms’, June 2026. [Cited for the thirty-day Anthropic data retention observation and Zero Data Retention framework.]
[2] Digital Applied, ‘Evaluating AI vendor claims: Sovereign AI vs Token-metered services’, 3 July 2026. Available at: https://www.digitalapplied.com/blog/alex-karp-palantir-tokens-weights-alpha-cnbc-2026
[3] Zen van Riel, AI Engineer Blog, ‘Local AI for EU teams under GDPR and the AI Act’, 31 July 2026. Available at: https://zenvanriel.com/ai-engineer-blog/local-ai-for-eu-teams-under-gdpr-and-the-ai-act
[4] MIT Technology Review (2026) ‘Enterprise AI contracts may contain data privacy gaps that present significant reputational and regulatory risks’, MIT Technology Review. [Industry report; no public URL available.]