“If you use Fable, Anthropic keeps your data for 30 days.” That observation, from Jordan Wilson on the Everyday AI podcast earlier this year, prompted a wave of discussion among enterprise AI users who had not, until that moment, thought to check what their vendor contracts actually permitted[1]. For a general SaaS user, thirty-day data retention is inconvenient. For a regulated financial advice firm processing client suitability information, cashflow projections, and meeting notes, it is a compliance problem with a named regulator attached to it.
Most firms using AI tools in their workflow have not read the data clauses. They signed up on a free trial, upgraded to a business tier, and kept going. This article is about what those clauses typically contain, which provisions matter most in a regulated context, and what to do before you sign anything else.
Why vendor contracts have become a compliance concern for advice firms
The short answer is that AI tools are now handling data they were never designed to handle, in quantities and sensitivities that put them squarely inside your GDPR obligations and FCA expectations.
A few years ago, an advice firm using an AI tool typically meant a chatbot on the website or a grammar checker in Word. Neither touched client data in a meaningful sense. Today, firms are feeding meeting transcripts, fact-finds, cashflow models, and draft suitability letters into AI tools. That data is often personally identifiable, often sensitive in the financial sense, and in some cases contains details that would qualify as special category data under UK GDPR.
The contracts governing those tools were frequently written for the general enterprise market, not for regulated financial services. They contain provisions that are entirely standard for a marketing agency or a software company, and entirely inappropriate for a firm subject to FCA oversight and UK GDPR.
What the contracts typically permit that you may not have noticed
There are four clauses that come up repeatedly when you read AI vendor terms carefully.
Training data rights. Many standard-tier contracts permit the vendor to use your inputs and outputs to improve their models. The language is usually something like “aggregated, anonymised data may be used to improve service performance.” In practice, this means client information you paste into the tool, even redacted or paraphrased, may become training material. Anonymisation is not a guarantee; it is a process that fails more often than vendors acknowledge.
Data retention periods. Vendors commonly retain conversation data for periods ranging from a few hours to several months, depending on tier and settings. Some retain it indefinitely unless you actively request deletion. The thirty-day figure flagged by Wilson for one major platform is not unusual[1]. For a firm with data minimisation obligations, undefined or extended retention is a liability.
Sub-processor chains. Most AI vendors use sub-processors: cloud infrastructure providers, monitoring services, safety evaluation tools. Their contracts give them broad latitude to share data with these parties, subject to the sub-processor maintaining “equivalent” protections. You are rarely told who those sub-processors are, where they are located, or what their retention practices look like. For international data transfers under UK GDPR, that matters.
Jurisdiction of processing. Standard-tier contracts often process data in the vendor’s primary jurisdiction, which may be the United States. For UK firms, data transferred to the US requires an appropriate transfer mechanism. Many vendors offer this, but only if you ask, only on their enterprise tier, and only if the data processing agreement is explicitly invoked. Signing up via a browser does not invoke it automatically.
What Zero Data Retention actually means and when to ask for it
Zero Data Retention, or ZDR, is an enterprise-grade privacy guarantee offered by a handful of major AI vendors. Under ZDR, the vendor does not store your inputs or outputs after the API call completes: nothing hits their logs, nothing enters their training pipeline, and nothing is retained for safety review in a form linked to your account[1].
ZDR does not change what the model does with your data during inference. It changes what the vendor does with it afterwards. The distinction matters, and most vendor explanations bury it.
ZDR is not available on consumer or standard business tiers. It requires an enterprise contract, typically costs more, and often requires a separate data processing agreement signed alongside the main contract. If your firm is processing identifiable client information through an AI tool and you do not have ZDR or an equivalent contractual protection, you are almost certainly operating outside what your DPA requires of data processors.
Asking for ZDR is a reasonable and increasingly standard request. If a vendor cannot offer it, or cannot tell you clearly what their data retention practices are, that is informative.
The ‘sovereign AI’ distinction and what it means in practice
One framework that has become useful for evaluating vendor claims is the distinction between sovereign AI and token-metered services[2]. The label sounds technical but the underlying question is simple: when you send data to this vendor, where does it go, who can see it, and what are your rights over it?
Token-metered services are the standard API model: you send a query, the vendor processes it on shared infrastructure, returns a result, and retains logs for some period. Your data passes through infrastructure you do not control, governed by terms you agreed to at sign-up. Most AI tools in current use are token-metered.
Sovereign AI, in the vendor’s sense, refers to arrangements where the model runs on infrastructure you control, or on dedicated infrastructure within a specific jurisdiction, with contractual guarantees about data not leaving that environment. Local deployment takes this further: the model runs on your own hardware, which removes the vendor data processing question entirely. One practical note here is that moving AI inference to local infrastructure does shift the compliance question from complex legal contracts to verifiable network diagrams[3]. That is genuinely simpler to audit, though it introduces different requirements around model governance, update management, and system validation.
For most advice firms, full local deployment is not a near-term option. The middle ground is enterprise contracts with explicit data residency and sub-processor controls. That is achievable today with the major vendors if you ask for it before you sign.
What to check before you commit
This is a practical checklist. Most of it can be done by whoever handles your firm’s data protection work, without specialist legal input, though I would recommend getting a solicitor’s view before signing any enterprise AI contract that will touch client data at scale.
First, locate the data processing agreement. Every AI vendor subject to GDPR or UK GDPR should offer a DPA. If you cannot find it easily on their website, ask your account contact. If they cannot produce one, that answers the question.
Second, check the training data clause specifically. Look for language about using your data to improve models, train systems, or develop new features. If it is present in the default terms, ask whether it can be opted out of and what tier that requires.
Third, identify the sub-processor list. Most vendors publish this, often in the same section as the DPA. Check whether any sub-processors are located outside the UK or EEA, and whether the transfer mechanism is named explicitly.
Fourth, ask directly about data retention periods. Default retention periods are often buried in documentation that changes without notice. Get the answer in writing, including what happens to retained data when you cancel.
Fifth, confirm the jurisdiction of processing. If your data is being processed outside the UK, confirm the transfer mechanism (adequacy decision, standard contractual clauses, or otherwise) and whether it covers your use case.
None of this is exotic compliance work. It is the same due diligence you would apply to any third-party data processor, applied to a category of tool that moves quickly and where the defaults are almost never set in the client’s favour.
The gap that matters right now
The honest position is that AI governance has moved from internal best practice to a regulatory obligation, and most AI vendors have not moved at the same pace. There is a meaningful gap between the speed at which firms are deploying AI tools and the maturity of the governance frameworks that should surround them[4]. Vendors know this, and a number of them have structured their default terms accordingly: permissive by default, restrictive only on request, and only at enterprise pricing.
That is not a reason to avoid AI tools. It is a reason to read what you are signing before client data enters the system.
If your firm is working through which AI tools are appropriate for regulated use and what contractual protections you should be asking for, a discovery call with Cordrey Consulting is a reasonable place to start.
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.]