The DPA Is a Promise, Not a Control: Reading an AI Vendor Contract for What It Actually Binds

CORE THESIS A Data Processing Addendum is not a technical control — it is a contractual allocation of responsibility for one. It does not stop data from being accessed; it specifies who is accountable when it is, down a subprocessor chain that on a modern AI vendor can run several parties deep and cross into US jurisdiction along the way. The controller stays accountable for the whole chain — for satisfying itself that every link offers sufficient guarantees — even though the processor it contracted with remains liable to it for the subprocessors beneath. Reading an AI DPA well means reading it for three things: what it forbids, who else it lets touch the data, and where it is silent.

Two questions about AI and personal data tend to get most of the attention. The first is what happens to a prompt: an enterprise DPA forbids training but does not guarantee zero retention, and says nothing about who can be compelled to hand the data over. The second is what happens when an organisation trains a model on its own data: self-hosting answers the transfer question and not the lawful-basis or erasure questions. Both lead back to the same underlying subject, and it is one organisations rarely examine directly: the contract itself — the Data Processing Addendum that an organisation signs with an AI vendor, and that it then tends to file away as if signing it were the same as being protected by it.

It is not. And the gap between those two things is where most AI vendor relationships carry risk the controller does not know it is carrying.

A DPA that I reviewed recently makes the point. The vendor was a well-known AI platform; the contract was professionally drafted; the training prohibition was clear; the security commitments were substantial. The organisation’s procurement team had ticked the box: “GDPR-compliant DPA in place.” What no one on the procurement side had read was the subprocessor annex — three pages, near the back, listing the other companies the vendor was permitted to pass the data to. There were eleven of them. Four were US-incorporated. Two provided infrastructure that, as US-controlled entities, was potentially within the scope of US disclosure obligations, including those associated with the CLOUD Act. The training prohibition the procurement team had been so pleased with bound the vendor — and said nothing about what those eleven subprocessors could be compelled to do.

The question this article answers is the one the procurement box-tick skips: when you sign an AI vendor’s DPA, what have you actually bound — and, more importantly, what have you not? The contract is the layer that sits underneath both the prompt question and the training question, and reading it correctly is the discipline that ties the whole subject together.

What a DPA is — and the category error of treating it as protection

Under Article 28 GDPR, whenever a third party processes personal data on a controller’s behalf, a Data Processing Agreement is mandatory, must be in place before any processing begins, and must contain the specific clauses Article 28(3) prescribes.¹ An AI vendor handling personal data for a business customer is, on the enterprise tiers, a processor in exactly this sense, and the DPA is the instrument that makes the arrangement lawful.

But notice what the DPA does. It does not encrypt anything. It does not move a server. It does not prevent a US authority from issuing an order. It is a contract — an allocation of obligations and liabilities between controller and processor. Its protective force is entirely derivative: it works to the extent that the processor performs what it has promised, and to the extent that a court would enforce the promise. This is the category error that “we have a DPA” so often conceals: a DPA is not a control, it is a promise about controls, and the distinction matters most precisely when the promise is hardest to keep — under a legal compulsion the processor cannot lawfully resist.

The most important structural fact about the controller–processor relationship follows directly: the controller does not offload its responsibility by appointing a processor. It remains responsible. Selecting a processor without adequate guarantees, or without a compliant DPA, exposes the controller to enforcement regardless of whether the breach originated with the vendor.² The DPA reallocates contractual liability between the parties; it does not reallocate the controller’s regulatory accountability to the supervisory authority. That accountability stays put.

The subprocessor chain: where the data actually goes

The single most under-read part of an AI vendor’s DPA is the subprocessor provision, and it is where the prompt question and the training question both reappear in concrete form.

Modern AI platforms do not run on a single company’s infrastructure. They sit on layered cloud hosting, use third-party infrastructure for compute, route through content-delivery and observability services, and increasingly call other models as components. Each of those is a subprocessor — a party the primary processor engages to process personal data in turn. Article 28 regulates this strictly. A processor may not engage a subprocessor without the controller’s prior authorisation, whether specific or general; under a general authorisation, the processor must inform the controller in advance of any intended addition or replacement of a subprocessor, giving the controller the opportunity to object.³ And critically: the same data protection obligations that bind the primary processor must be passed down, by contract, to every subprocessor in the chain.⁴

The accountability structure the EDPB set out in its Opinion 22/2024 is the part practitioners most often get wrong. If a subprocessor fails to meet its obligations, the initial processor remains liable to the controller — so the controller can make a contractual claim against the processor it actually contracted with, rather than having to pursue a subprocessor four links down with which it has no direct relationship.⁵ But — and this is the sting — the EDPB is equally clear that the ultimate responsibility for the performance of the chain rests with the controller. The controller must satisfy itself that not only the processor but every subprocessor genuinely offers sufficient guarantees; it may discharge this by requiring the processor to contract appropriately and to monitor the chain, but it cannot discharge it by not looking.⁶ The controller is also entitled, under the standard SCC machinery and Article 28(3)(h), to request copies of the subprocessing contracts.⁷

Translate that back to the eleven-subprocessor annex. The controller who signed it had, in law, authorised processing of its personal data by all eleven, accepted responsibility for satisfying itself that all eleven offered sufficient guarantees, and taken on the obligation to track changes to the list. What it had actually done was not read the list. The training prohibition it relied on was a promise by the primary vendor; it told the controller nothing about whether a US-incorporated infrastructure subprocessor could be compelled, under the CLOUD Act, to surrender data the vendor had passed to it.

The transfer layer: a DPA does not move jurisdiction

Article 28 governs the controller–processor relationship; it does not, on its own, legitimise international transfers.⁸ That is a separate regime — Chapter V GDPR, Articles 44 and following — and on an AI vendor with US-incorporated parties in the chain, it is unavoidable.

The mechanisms are well established and each has a precise scope. For transfers to a US organisation that is certified under the EU–US Data Privacy Framework (DPF) for the relevant categories of data, the DPF currently serves as the Article 45 adequacy basis, so Standard Contractual Clauses are not needed for that specific transfer route — but the certification must actually cover the data and service in question, not merely exist.⁹ For US processors not DPF-certified, the standard route is the Commission’s 2021 Standard Contractual Clauses (SCCs) — for most controller-to-processor SaaS relationships, Module 2 — plus, since Schrems II, a Transfer Impact Assessment evaluating whether the destination country’s law undermines the protection the SCCs promise.¹⁰ The DPA must document which transfer mechanism applies to each processor and subprocessor established outside the EEA.¹¹

Here is where the contractual layer meets the architectural one. The TIA is the document that should force the question at the heart of every transfer assessment — who can be compelled to hand the data over? — and a defensible TIA points to genuine technical safeguards: customer-held encryption key sovereignty, a customer-held pseudonymisation domain, an auditable ability to deny access. A TIA that recites “data stored in the EU” and “vendor is DPF-certified” without examining the subprocessor chain’s jurisdictional exposure and the cryptographic and pseudonymisation architecture is not a TIA that has done its work; it is a box-tick that names a mechanism without testing whether the mechanism survives contact with US compulsion law. The DPF reduces the SCC paperwork; it does not abolish the underlying reality that a US-incorporated subprocessor remains within reach of US authorities, a point that no adequacy decision has yet been able to make disappear and that successive challenges keep alive.

If that sounds like an over-cautious reading of what a contract can and cannot do, the largest GDPR fine ever issued exists to settle the argument. On 22 May 2023 the Irish Data Protection Commission, acting on a binding Article 65 decision of the EDPB, fined Meta Platforms Ireland €1.2 billion for transferring EU users’ personal data to the United States in breach of Article 46(1) GDPR.¹² The decisive finding is the one every controller relying on a US AI vendor should read twice: Meta had transferred the data on the basis of the European Commission’s Standard Contractual Clauses and had layered on extensive supplementary measures — internal policies, encryption of data in transit, a documented practice of challenging government access requests — and the DPC and EDPB held that all of it, together, was still not enough to compensate for the deficiencies in US surveillance law that the CJEU had identified in Schrems II.¹³ The contract was real. The supplementary measures were real. They did not move the jurisdiction, and so they did not move the risk. Meta was ordered not only to pay but to suspend further transfers and repatriate the data to the EU — orders Meta is appealing, and whose practical bite it has so far avoided by moving to the EU–US Data Privacy Framework after the framework was adopted in July 2023.¹⁴ That after-the-fact escape route does not soften the finding: at the moment the fine was assessed, a signed SCC plus extensive safeguards was held insufficient, and that is the holding that matters for anyone relying on contract alone today. This does not mean every current US transfer is unlawful — a transfer to a DPF-certified recipient rests on a different and currently valid basis. It means the transfer mechanism and the recipient’s certification status must be assessed for the surface you actually use, not assumed from a signature. (For scale: the €746 million penalty against Amazon in Luxembourg — historically the second-largest GDPR fine, though a Luxembourg court annulled it on procedural grounds in March 2026 and sent it back to the regulator — was not close.) The lesson transfers directly to a DPA with a US AI vendor: a signature and a folder of safeguards is exactly what Meta had. What it lacked was an architecture in which the data was beyond the reach of US compulsion — and that lack is what the fine was for.

Reading a DPA for what it does not say

The practical skill is reading an AI vendor’s DPA on three axes at once. The first two are what it contains; the third — the one that separates a real review from a procurement formality — is what it omits.

Axis one — what it forbids. Does it exclude use of customer data for training the vendor’s foundation models, in clear terms, across the surfaces you actually use? (A brand’s enterprise and consumer tiers can differ entirely on this.) Does it govern retention — and if zero retention is being assumed, is ZDR written in for the specific surface, or merely inferred from the DPA’s existence?

Axis two — who else it lets touch the data. Read the subprocessor annex, every entry. For each: where is it incorporated, what does it process, and is it in a third country? Under what authorisation model can the vendor change the list, and what is your objection right and window? Is the obligation to flow down the same protections to every subprocessor stated, or merely gestured at?

Axis three — where it is silent. This is the analytical heart of the review. A DPA can be excellent on training and retention and say nothing about the transfer architecture — no transfer mechanism named per subprocessor, no TIA referenced, no acknowledgement of US compulsion law, no key-sovereignty or pseudonymisation commitment. Silence is not absence of risk; it is unallocated risk, and unallocated risk on an Article 28 contract defaults to the controller, because the controller is where regulatory accountability ultimately rests. The question to ask of every silence is the question that runs through the whole subject: does this gap leave personal data reachable by someone who is not bound not to reach it?

A five-question close, runnable on any AI DPA in fifteen minutes:

One: Does it forbid training on our data, on the surfaces we use — verifiably, not by reputation? Two: Is retention governed, and is any zero-retention claim written for the actual surface? Three: Have I read every subprocessor, and do I know which are in third countries? Four: Is a transfer mechanism named for each non-EEA processor and subprocessor, and is there a TIA that tests it against compulsion law — not just against “EU storage”? Five: What does the contract not address — and where does that unaddressed risk land? (It lands on us.)

If question five has no answer, the review has not happened yet.

A review only earns its keep if each “no” triggers a fixed action rather than a note. So pair each question with its remedy:

If training is not verifiably excluded for your surface — do not deploy on that surface; require the exclusion in writing for the exact tier, or move to one that has it. If retention is ungoverned, or zero-retention is assumed but unwritten — write your own retention rule into the contract, and strike any internal claim of “zero-retention” that the contract does not actually support. If you have not read every subprocessor, or cannot tell which are in third countries — withhold sign-off until the annex is read line by line and each entry is tagged by jurisdiction; an unread annex is an unsigned-off DPA. If a non-EEA processor or subprocessor has no named transfer mechanism, or the TIA only recites “EU storage” — send it back for a per-party mechanism and a TIA that tests against compulsion law, and where the data is sensitive, require a genuine technical safeguard (customer-held encryption keys, a customer-held pseudonymisation domain) rather than a paper assurance. For whatever the contract does not address — assign that residual risk to a named owner on your side, because unallocated risk does not stay unallocated; it defaults silently to the controller.

These five remedies are the difference between a DPA you have filed and a DPA you have actually brought under control.

A stress test: the subprocessor you never approved

Run the contract through a failure it is actually likely to suffer. The DPA is signed, the subprocessor annex has been read, every entry has a named transfer mechanism, the TIA is defensible. Six months later the vendor sends a routine notice under the general-authorisation clause: it is adding a new subprocessor — a US-incorporated analytics provider — to the list, effective in thirty days. The notice lands in a shared inbox during a busy week. No one objects, because no one reads it in time. On day thirty-one, EU personal data is flowing to a new US party that no one on the controller’s side ever assessed.

Nothing here was a breach of contract. The vendor did exactly what the DPA permitted: general authorisation means it may change the list, subject only to advance notice and the controller’s opportunity to object — an opportunity that is worthless if no one is watching the inbox.³ And yet the controller is now in precisely the position the Meta decision punishes: personal data in the hands of a US-reachable party, with no fresh transfer assessment, on the controller’s own regulatory account. The processor’s liability for the chain does not rescue the controller here, because the EDPB has been explicit that ultimate responsibility for the performance of the chain rests with the controller — the processor’s residual liability is a contractual backstop, not a transfer of accountability.⁵

This is the stress test that exposes what a DPA really is. The contract did not fail; the monitoring failed, and the contract was never a monitoring control to begin with — it was a promise that allocated who is accountable when monitoring lapses. The defensible posture is therefore operational, not contractual: a named owner for subprocessor notices, a standing rule that any new third-country subprocessor triggers a TIA refresh before the objection window closes, and a default of objecting-pending-review rather than silence-as-consent. The signature bought the right to object. Only a process turns that right into a control.

The takeaway

SUMMARY FOR DECISION-MAKERS A DPA is a contractual promise about controls, not a control — it allocates responsibility for protection, it does not perform it, and the controller’s regulatory accountability stays with the controller no matter how long the processor chain. The subprocessor annex is the document that tells you where your data actually goes; on an AI vendor it can run several parties deep and cross into US jurisdiction, and you have authorised — and taken responsibility for — every party on it whether you read the list or not. Read every AI DPA on three axes: what it forbids, who else it lets touch the data, and — decisively — where it is silent, because silence on the transfer architecture is unallocated risk that defaults to you.

A DPA is not, by itself, an operational control — it does not, on its own, protect data. It says who is responsible for protecting it — and the answer, at the end of every chain, includes the controller. Treating the signature as the protection is the single most common and most expensive misreading of Article 28 in AI procurement.

The subprocessor annex is where the abstractions become a list of named companies in named jurisdictions. The training prohibition you signed binds the vendor; the four US subprocessors three pages later are bound by their own obligations and reachable by their own authorities, and that is a separate question the prohibition never touched.

Read for the silences. A contract that is strong on training and mute on transfers has not solved the transfer problem — it has left it unallocated, and unallocated risk on an Article 28 contract has a default owner. The one question worth carrying through every AI vendor contract: who can reach the data, and are they bound not to? Everything else is paperwork arranged around that one answer.

Glossary of abbreviations

Legal notice: This article serves general information purposes and does not constitute legal advice. For a legally sound assessment in a specific case, consultation with a specialised data protection lawyer is recommended. As of: June 2026.