Your Data Processing Agreement Is Out of Date: 7 Clauses Agent Tooling Broke

On 9 June 2026 Anthropic began retaining prompts and outputs to its covered models for 30 days on every platform where those models are offered, including for organisations holding zero data retention arrangements. No contract was breached. Your data processing agreement simply described a world that a model release had already replaced, and most DPAs signed before 2024 have the same problem.

The short answer

What needs rewriting in an AI-era DPA? Seven clauses: sub-processor identification and notice, retention and deletion, the three separate training permissions, agent tool calls, model version changes, legal hold against erasure, and role allocation across the GDPR and the EU AI Act. Most agreements signed before 2024 address two of the seven.

What your DPA was written to do, and what changed

A data processing agreement is the contract Article 28 of the GDPR requires between a controller and a processor. It fixes the subject matter, duration, purpose, data types, security measures, sub-processing rules, deletion terms and audit rights. A cloud tool with no DPA is a bare infringement, whatever the data volume.

The standard template most companies still use was drafted for a stable piece of software. A vendor ran a fixed application, in a named region, on a sub-processor list that changed once or twice a year.

Three shifts did the damage. Vendors ship model updates that change data handling without changing the contract. Agents call third-party tools at runtime, creating processing paths nobody listed. And employees use consumer AI products where no processor contract exists in the first place.

Article 83(4) puts Article 28 failures in the lower fine tier, capped at €10 million or 2% of global annual turnover, whichever is higher. Across surveyed jurisdictions, aggregate fines reached €7.1 billion by 10 January 2026, with Ireland alone accounting for €4.04 billion.

The same survey recorded an average of 443 notified personal data breaches per day across Europe, a 22% annual increase and the first time daily notifications have passed 400 since 2018. Every one of those notifications tests whether you can name the parties in your processing chain within 72 hours.

This table is an editorial judgement about priority, not a legal opinion.

Clause 1: the sub-processor list you cannot actually produce

Article 28(2) lets a processor engage sub-processors under a general written authorisation, provided it informs you of intended changes and gives you a chance to object. Almost every AI vendor uses that model. OpenAI commits to at least 30 days of advance notice and publishes its current list at a public URL.

That satisfies the letter of the article. It does not satisfy what the European Data Protection Board asked for in October 2024.

In Opinion 22/2024, the EDPB said a controller should have the identity of all processors and sub-processors readily available at all times. Identity means name, address and a contact person, and the requirement applies regardless of the risk level of the processing.

You need the chain to respond to a breach anywhere along it, and to answer a subject access request. The initial processor should push those details to you and keep them current, rather than leaving you to poll a webpage.

My view is that the URL-plus-notice pattern is the weakest common clause in the entire AI vendor stack. If you have never diffed a vendor sub-processor page, you do not have a current list, and a general authorisation does not cure that.

The objection right is thinner than it reads

At most vendors, objecting starts a discussion, and if the discussion fails, your remedy is to terminate the affected service. For a model provider embedded in a production workflow, termination is not a remedy you will use. It is a clause that looks like control and functions as notice.

Where data moves between sub-processors outside the EEA, the board expects a higher level of verification, because Article 28(1) duties sit alongside the Chapter V transfer rules rather than replacing them. The practical detail of that split is covered in the piece on where AI data residency promises hold and where they do not.

Clause 2: retention and deletion that a model release overrode

Anthropic's published policy states that prompts submitted to, and outputs generated by, covered models are retained for 30 days to support safety work. The policy covers every platform where those models are offered. The change took effect on 9 June 2026. It applies through Claude Console, AWS Bedrock, Google Cloud and Microsoft Foundry.

The group it reaches is precisely the group that negotiated hardest. Organisations with zero data retention arrangements had a contractual term saying inputs and outputs were not stored. A model class was designated, and the retention floor moved underneath them.

I do not think the vendor did anything improper here. Safety review of a more capable model class is a defensible reason to keep data for a short window, and it was published rather than buried. The failure is that standard DPAs treat retention as a single static number, negotiated once, with no mechanism for what happens when the vendor's own risk assessment changes.

Two clauses fix most of it. First, require notice before any retention floor increases, with the same window as a sub-processor change. Second, require the vendor to state which categories of data are exempt from the deletion promise, because abuse monitoring and trust-and-safety flagging almost always carry longer retention than the headline figure. A vendor that will not write down its exception list has not measured it.

The wider pattern of vendor terms shifting between contract cycles is set out in the comparison of model provider terms. The commercial half of the same problem sits in the contract clauses a CFO should insist on.

Clause 3: training is three permissions, not one

Most DPAs carry a single line saying the vendor will not use customer data to train its models. That sentence covers one of three distinct activities, and buyers routinely believe it covers all three.

Model training is the obvious one. Service improvement is different: it covers using content to tune retrieval, ranking, safety filters or product features, and it is often carved out separately. Human review for trust and safety is different again, and it is the one with the longest retention tail, because flagged content is usually kept far longer than clean content.

Write them as three lines with three different answers. A vendor that gives you one answer to three questions has either not read its own pipeline or is hoping you will not ask twice.

Why the regulator cares about the training question

In December 2024 the EDPB adopted Opinion 28/2024 on AI models, at the request of the Irish supervisory authority. Two findings matter for contracts.

First, a model trained on personal data is not automatically anonymous. The board set a high threshold, requiring that the likelihood of extracting personal data from the model be insignificant when assessed against all means reasonably likely to be used. Calling a model anonymous is a claim you have to evidence, not a default.

Second, unlawful processing during development can follow the model into deployment. Where a different controller deploys a model built unlawfully, the EDPB expects that deployer to conduct due diligence on how the model was developed.

The Italian Garante fined OpenAI €15 million on 20 December 2024, on grounds including the absence of an appropriate legal basis for training data and failure to notify a breach. OpenAI said it would appeal and called the penalty disproportionate.

The practical consequence is that a training clause is no longer only about your own data. It is also about whether you can show you checked what the model in front of you was built from.

Clause 4: agent tooling walks off the paper

This is the clause that did not exist to be written badly.

An agent decides at runtime which tools to call. A single task can hit a search API, a code execution sandbox, a document store and a third-party connector. Each of those calls can move personal data to a party that appears on no sub-processor list, because the vendor did not choose it. The agent did, inside your tenant, in response to your prompt.

Who is the processor when a tool is called at runtime

You instructed the processing, so you remain the controller and you carry the accountability. What moves is your ability to enumerate the chain, which is exactly the capability Opinion 22/2024 says you must have available at all times.

The security half of that gap is set out in the analysis of MCP server supply chain risk, and the credential half in the piece on agent identity and non-human access.

Three provisions carry most of the weight. Define an allow list of tools an agent may call in scope of the agreement, and make additions require the same notice as a sub-processor change. State explicitly whether a tool call that transmits personal data is treated as sub-processing under the agreement, because ambiguity here defaults against the controller. And require the vendor to log tool invocations in a form you can export, since you cannot demonstrate a chain you cannot reconstruct.

Contract for the mechanism and the log, not for the inventory.

Clauses 5, 6 and 7: versions, legal hold and who you are under the AI Act

Model version change notice

Vendors change default models, deprecate versions and shift inference regions on their own schedule. A pre-2024 DPA has no hook for any of that. For regulated workloads, ask for advance notice of a default model change and the right to pin a version for a defined period. Expect resistance and a price, because pinning has a real cost to the vendor.

Legal hold against the right to erasure

In May 2025 a US court ordered OpenAI to preserve output log data that would otherwise have been deleted, in the New York Times copyright litigation. OpenAI publicly objected on privacy grounds and challenged the order, and the preservation obligation was substantially narrowed by a further order in October 2025.

The episode proved that a deletion promise in your DPA can be suspended by a court in the vendor's jurisdiction, in litigation you are not party to. Your contract should require prompt notice when that happens, to the extent the vendor is legally permitted to give it, and a statement of which data categories are affected. Silence here means you learn from the press.

Role allocation now spans two regulations

Since 2 August 2026, the EU AI Act's provider and deployer obligations are enforceable. Article 25 is the clause to read. A deployer, distributor or importer becomes a provider of a high-risk AI system in three cases. It puts its own name on the system, makes a substantial modification, or changes the intended purpose so that the system becomes high-risk.

Fine-tuning, rebranding an assistant, or pointing a general-purpose system at a hiring decision can each move you across the line, and provider obligations are materially heavier than deployer obligations. Your DPA allocates controller and processor roles. It almost certainly says nothing about who is the provider, which means the question gets answered by default rather than by agreement. The disclosure obligations attached to the deployer side are set out in the EU AI Act transparency checklist.

The processor contract that does not exist at all

Every clause above assumes a contract. For consumer AI use inside a company, there is no contract to amend.

A survey of 500 employed US adults was fielded on 8 July 2026 for Kolmogorov Law through the Pollfish platform. In it, 38% said they had entered at least one type of work information into a personal AI account their employer does not control. The breakdown is the part that should worry a privacy lead: 23% had pasted internal emails, memos or documents, and 11.4% contracts or legal documents.

Treat those figures as directional. It is a self-reported, non-probability panel of US workers, commissioned by a law firm, with a stated margin of error of 4.4 points.

The awareness gap is the actionable finding. 64.4% of the survey sample did not know that entering work information into a personal AI account can, in some circumstances, break the law. You cannot draft your way out of that. Blocking helps, an approved alternative helps more, and the cost of the failure mode is quantified in the breakdown of what a shadow AI breach costs.

Where this argument is weakest

Three honest objections, in descending order of strength.

Rewriting a DPA changes nothing you can measure

This is the strongest objection and I only partly disagree. A better sub-processor clause does not stop a sub-processor from being added. It gives you notice and a paper trail. The clauses that carry real operational weight are the log export in clause 4 and the retention exception list in clause 2, because both produce evidence you can check.

The law may move before your amendment lands

On 19 November 2025 the European Commission published the Digital Omnibus package. It proposes GDPR amendments including a defined legitimate interest route for AI training, paired with enhanced transparency and an unconditional right to object. It is a proposal, not law, and the legislative process can change it substantially. Anyone rewriting contracts today should assume the training clause may need revisiting once that lands.

Vendor leverage is real and asymmetric

The advice above assumes you can negotiate. Below a certain contract value you cannot, and the vendor's published addendum is the deal. In that case the useful work is not drafting. It is selecting: choose the vendor whose standard terms are closest to what you need, document why, and record the residual risk. Pretending you negotiated something you accepted is worse than accepting it openly.

None of this is legal advice, and the clause priorities above are an operator's ranking rather than counsel's. Two of the sources here are vendor-published policy pages, which are authoritative for what a vendor commits to and not for whether it complies.

Frequently asked questions

Where to start this week

Pick your three highest-volume AI vendors and do two things.

First, produce the sub-processor list on demand. Name, address and contact point for every entity in the chain, exported today, dated, and stored somewhere an auditor can reach. If you cannot assemble it in an afternoon, that gap is the finding and it outranks every drafting question in this post.

Second, send one email per vendor asking three questions. What is your retention floor, and which categories are exempt from it? Do you commit to notice before a default model version changes? Does a tool call made by an agent count as sub-processing under our agreement? Log the answers verbatim. The vendors that answer precisely have measured their own pipeline. The ones that answer with reassurance have told you where to look next.

Related reading