DPA for AI: What the Contract Must Cover Beyond Standard

A Data Processing Agreement – DPA – is standard in any cloud procurement. But for AI services, the standard wording is rarely enough. There’s a set of questions that only arise once a language model is involved, and if the contract is silent on them, you have a gap. This page goes beyond the general DPA definition and looks specifically at the AI-specific clauses.

Why standard isn’t enough

A typical DPA governs processing in general: what the processor may do, security requirements, deletion at the end of the contract. That’s necessary but not sufficient for AI, because AI introduces three new behaviors:

• Customer data can be used to train the model.
• Data can be retained for different lengths of time on different endpoints.
• Models get deprecated, sometimes with short notice, forcing a migration.

None of these are captured by a clause written for an ordinary database. They need to go in as explicit addenda.

The four AI addenda to look for

When you read a DPA for an AI service, actively search for these:

1. A training ban without explicit consent. The contract should establish that your data isn’t used for training unless you actively approve it. “Can opt out” is weaker than “prohibited unless consented to.”
2. Retention and ZDR terms per endpoint. Zero data retention on one endpoint doesn’t help if another one stores everything. The terms should be specified per endpoint, not as one sweeping sentence.
3. A carve-out for abuse detection. Nearly every vendor retains some data to detect abuse. It should be clear exactly what the carve-out covers and for how long – otherwise it quietly erodes your retention requirements.
4. An agreed notice period for model deprecation. You need time to revalidate before a model disappears. Without an agreed notice period, a switch can be forced faster than your own review can keep up with.

The role shift on the hyperscaler path

A common mistake is to regulate only the relationship with the model company. If you run AI via a hyperscaler, the picture looks different.

So on the hyperscaler path, the cloud provider’s DPA is the governing document, and the model company ends up as the subprocessor in the chain. Check that both links are covered: that the cloud provider’s contract actually covers your processing, and that the subprocessor is bound by equivalent terms. If only one link is covered, there’s a gap where responsibility can fall through the cracks.

Verification points from an auditor’s perspective

Beyond the addenda, there are a few points that, per the source material, often decide how an audit lands:

• SCC module and UK addendum. The right module of the Standard Contractual Clauses for your specific setup, and a UK addendum if British data is involved.
• Incident notification timing. The standard wording is often too generous. It’s a point worth tightening in an addendum, so you get word in time to act.
• Exportable audit logs. If you can’t pull the logs, you can’t show what happened either. Logs being exportable is the difference between processing you can document and processing you can’t.

How to review the contract in practice

Once the DPA is on the table, it’s easy to drown in text. A couple of concrete techniques make the review manageable. Don’t read through everything linearly – search specifically for the AI-specific clauses first, since that’s where standard templates are usually silent. Search for words like “training,” “retention,” “deprecation,” and “abuse,” and see what the contract actually says, not what you’re hoping it says.

Be especially alert to wording that sounds reassuring but doesn’t actually commit to anything. “We don’t normally use customer data for training” isn’t the same as a ban. “Data is deleted within a reasonable time” isn’t the same as a stated retention period per endpoint. The difference between a soft statement of intent and a binding clause is exactly what an auditor is looking for.

A common pitfall is settling for the vendor’s standard DPA because it looks complete. It covers the general case but rarely the AI addenda – you often have to ask for those separately. Another is regulating only the model company and forgetting that on the hyperscaler path, it’s the cloud provider’s contract that governs. Miss either link and responsibility can fall through the cracks.

Keep the contract alive

AI vendors’ terms change often. So request dated contract versions, so you know exactly which wording applies at any given time, and revalidate the agreement whenever models or terms change. A DPA written a year ago may today govern a service that no longer behaves the way it did when the contract was signed.

Reviewing an AI DPA properly requires understanding both the law and how the service actually works technically. Want a sounding board ahead of an AI procurement? Read about our AI services or get in touch. This page is decision support, not legal advice.