GDPR Article 28 for AI sales tools: what the partnership reads before signing

In short

1. Article 28 of the GDPR has nine mandatory elements that must appear in any vendor DPA. Most US-built AI tools fudge two of them, and that is where your DPO blocks the deal.
2. The four red flags any senior partner can spot in fifteen minutes: vague sub-processor list, SOC 2 substituted for audit rights, ambiguous training-data clause, breach notification timed in days.
3. A clean DPA can be reviewed in twenty minutes. A bad one costs eight weeks of back-and-forth and usually dies anyway.
4. Read the DPA before the demo. Not after pricing, not after the trial, not when the partnership signs. Day one.
5. SOC 2 is a fine US security report. It is not an Article 28 audit and not a substitute for the controller's audit right under GDPR. Vendors that conflate the two are telling you something about their EU posture.

The DPO sends the email at 10:14 on a Tuesday. Three lines. "Their DPA fails 28(3)(c) on sub-processor flow-through. We can't sign." The senior partner reads it twice, does not know what 28(3)(c) is, but knows the deal that took six weeks of demos is now stalled or dead. So she calls the DPO. The DPO explains it patiently for fifteen minutes. The partner now knows what 28(3)(c) is. She also wishes she had known six weeks ago.

This is the second-most expensive mistake a professional services firm makes when buying AI in 2026. The most expensive is signing the wrong one. The second is running a procurement gate where the partnership and the privacy team only meet on the day the DPA is supposed to come back signed. By then the demo budget is spent, the sales team is invested, and the firm is biased toward saying yes to a contract that should have been killed on day one.

Article 28 of the GDPR is the contract clause that decides whether an AI vendor walks through your firm's data or doesn't. The reading takes twenty minutes if you know what to look for. Most partners never learn what to look for, so they delegate the read to a privacy team that finds the failure six weeks late and a partnership that paid for the demo cycle anyway.

We're going to fix that.

Why Article 28 is on the partner's desk

The standard model in a professional services firm is: legal or privacy reviews the DPA, the partnership signs the master agreement. This works for printer leases and Microsoft 365. It does not work for AI tools that ingest CRM data, conversation logs, identified visitor records, and partner correspondence across every account in the firm's book.

The reason is structural. Your firm is the data controller. You decide what gets processed, why, and on what lawful basis. The vendor is the processor. They do what your contract tells them, no more. If the contract is silent, they are not bound. If it is ambiguous, ambiguity tilts toward them. If your DPO catches the ambiguity at signing, fine. If your DPO catches it eight months in when a former client requests deletion, the firm is the one explaining to the bar association or the sectoral regulator why client data left the EU on a sub-processor whose name appears nowhere in the contract.

The exposure lives at the partnership level, not the privacy-team level. The reading should too. Bar associations have written client confidentiality rules for two centuries and they do not pause for "we delegated the review."

There is a second reason that matters more for the COO than the general counsel. AI sales tools, unlike most SaaS, are continuously processing identified personal data of the people who matter most to the firm: target prospects on dormant accounts, in-flight clients, the partners' own contact networks. A failure here is not a notification email and a regulator letter. It is a conflict-of-interest event, a sectoral regulator review, and in the worst cases a client engagement that ends with a malpractice claim. The cost is firm-level, not department-level, and the partner who approved the vendor is the partner whose name is in the file. (We've written separately about how that partner finds out which prospects are worth the attention in the first place.)

The nine mandatory elements

Article 28(3) of the GDPR lists nine things that must appear in any data processor contract. Most professional services partners have never read the actual list. Here it is, plain language.

1. Subject matter and duration of processing. What data, for how long.
2. Nature and purpose of processing. Why the vendor has it.
3. Type of personal data and categories of data subjects. Whose data.
4. Obligations and rights of the controller. What you can require, what you must do.
5. Processor confidentiality. The vendor's people are bound to keep your data confidential, in writing.
6. Security measures. Encryption, access controls, the standard list, with specifics.
7. Sub-processor authorization. Written prior approval, with a process for change.
8. Assistance with data subject rights. The vendor helps you respond when a person requests access, deletion, or portability.
9. Audit rights. You can audit the processor, or appoint someone to audit on your behalf.

Six of these are uncontroversial. Most vendor DPAs handle the boilerplate adequately, especially the ones that adapted from the EDPB template. The two that vendors most often fake are 7 (sub-processors) and 9 (audit rights). The third where vendors cut corners, though it is not strictly named in 28(3), is the AI-training prohibition, which any clean modern DPA spells out explicitly.

Sub-processors. Almost every AI sales vendor uses sub-processors. OpenAI or Anthropic for inference, AWS or GCP for hosting, an observability stack, an analytics layer, Twilio for messaging, Stripe for billing. Article 28(2) says the vendor must have your written authorization to use any of them. The fake version is a clause that says "Customer hereby authorizes Vendor to use sub-processors listed at vendor.com/subprocessors as updated from time to time." That is not authorization. That is a unilateral notification model dressed up as consent. A clean DPA gives written authorization to a specifically named list and includes a meaningful objection window, typically thirty days, on changes.

Audit rights. Article 28(3)(h) gives the controller the right to audit the processor or appoint a third party to do so. The fake version reads "Audit obligations satisfied by provision of a SOC 2 Type II report on request." SOC 2 is a US security audit framework. It tells you very little about GDPR-specific obligations and nothing about your contractual right to audit. A clean DPA preserves the audit right with a defined notice window, typically forty-five days, and a methodology by mutual agreement. The vendor will rarely be audited in practice. That is not the point. The point is that the right exists in the contract.

AI training. The vendor's marketing page tells you they don't train on customer data. The contract is what binds them. A clean DPA includes an explicit clause prohibiting use of customer data for training, fine-tuning, or evaluation of any AI model, with no exceptions for "aggregated" or "anonymized" data. The fake version is silence, or a clause that prohibits training "of foundation models" but leaves the door open for the vendor's own model fine-tuning, embedding generation, or "service improvement." Read carefully.

Four red flags in any AI vendor DPA

You do not need to be a privacy lawyer to spot these. You need fifteen minutes and a highlighter.

Red flag one: a sub-processor list that is not specifically named. "We use industry-standard sub-processors" is a sentence designed to mean nothing. A real list has names, jurisdictions, functions, and a public URL the partnership can revisit at any time.

Red flag two: SOC 2 substituted for audit rights. SOC 2 is fine on its own merits. SOC 2 in place of an Article 28(3)(h) audit clause is a tell. It usually means the vendor wrote their DPA for the US market and bolted on an EU compliance section under sales pressure.

Red flag three: breach notification timed in days, not hours. GDPR requires controller notification of a breach within seventy-two hours from awareness. The vendor must give you enough lead time to meet that deadline. A clean clause says twenty-four hours from vendor awareness. A weak clause says "without undue delay" with no number, which is the kind of language a US lawyer writes when an EU lawyer has not redlined the document.

Red flag four: a training-data clause that uses the words "aggregated," "anonymized," or "for service improvement." Any of these phrases is a back door. A clean clause says no training, no fine-tuning, no model evaluation, full stop. The vendor either commits to that or they don't, and the contract is where they prove which.

If a vendor's DPA shows two of these four, your DPO will block the deal. If it shows three, the deal should not move forward. If it shows all four, the vendor is treating their DPA as a marketing document and the partnership should walk before the demo cycle starts.

What a clean DPA looks like

Bias warning. We're a vendor too.

Our DPA is public, deliberately, for exactly the reason this article describes: a partner can read it before the demo, the privacy team can sign off in twenty minutes instead of three weeks, and the deal either moves or it doesn't. No NDA gating, no after-trial reveal, no SOC 2 substitution. The clean version of each contested clause:

Sub-processors. A specifically named list at /legal/subprocessor-list/. Three primary entries: Hetzner (hosting, Germany and Finland), Nebius B.V. (inference layer, Netherlands), and an EU-based transactional email provider. Thirty-day advance notice on changes, written right of objection.

Audit rights. Article 28(3)(h) audit right preserved as written. Forty-five days notice, scope limited to GDPR compliance and security controls, methodology by mutual agreement. A SOC 2 report is available on request as supplementary evidence. It does not replace the contractual audit right.

AI training prohibition. "Processor shall not use Customer Personal Data to train, fine-tune, or evaluate any artificial intelligence or machine learning model, whether developed by Processor or any third party. This prohibition applies regardless of aggregation, anonymization, or pseudonymization." That is the clause, more or less verbatim from the published DPA.

Breach notification. Twenty-four hours from awareness. Not "without undue delay." Twenty-four hours, written into the document, full stop.

You don't have to take our word for any of this. The DPA is a public link. So is the sub-processor list. So is the security overview. We made these documents public because the alternative is sending them in PDF after NDA after demo after price negotiation, and watching the deal die six weeks later when the privacy team finds the same thing they would have found on day one.

The 20-minute partner review

Before you book the demo. Not after.

Open three tabs: the vendor's DPA, the sub-processor list, the security overview. If any of the three is gated behind NDA, that is your answer about how serious the vendor is about EU compliance, and you can close the tabs. Move on.

If all three are public, read in this order.

Sub-processor list first. Count the names. Count the EU-incorporated names. Count the US-incorporated names. If the inference layer (the LLM provider) is US-based, this is a Schrems II conversation. Decide whether you want to have it now, or eight weeks into procurement.

DPA second. Search the document for four phrases: "aggregated," "anonymized," "without undue delay," "SOC 2." If any of them appears as the operative language for sub-processors, training, breach notification, or audit, the vendor's DPA is bolted-on. Send it to your DPO with the four hits flagged and a one-line note: "review these clauses specifically." Your DPO will know what to do with that.

Security overview third. Look for hosting location, encryption at rest and in transit, access controls, and the incident response process. (Ours is at /legal/security-overview/ and runs eight pages.) Twenty pages is not a virtue. Eight pages with the right answers is.

If the three documents pass, book the demo. If they don't, don't. The product can be excellent and the contract can still kill the deal. In professional services in 2026 the contract usually does, and the firms that read first save the demo budget for vendors that have a chance.

One uncomfortable truth about SOC 2

SOC 2 is a US-based security audit standard run by the AICPA. It examines internal controls at a service organization across five trust principles: security, availability, processing integrity, confidentiality, and privacy. A SOC 2 Type II report is a serious document and a real investment by the vendor. Most US-built SaaS companies have one because their US enterprise buyers ask for it, and asking for it is reasonable.

The trouble is that SOC 2 is not a GDPR audit, not a data protection audit, and not a substitute for the controller's audit right under Article 28(3)(h). The frameworks overlap on some security controls and diverge on most data protection ones. Lawful basis, sub-processor management, data subject rights, cross-border transfer mechanisms, retention specifics: these are GDPR-native concepts and SOC 2 does not test them.

Most US AI vendors lead with the SOC 2 report in compliance conversations because it is the most rigorous compliance investment they have made. The investment is real. The applicability to your firm's GDPR posture is partial.

A vendor whose DPA satisfies Article 28 and who also has SOC 2 is excellent, and you should sign with them. A vendor whose DPA fails Article 28 but who has SOC 2 is still a vendor whose DPA fails Article 28. When the vendor sends the SOC 2 report and stops responding to the follow-up questions about specific DPA clauses, that is the signal. The DPA is the binding document. The SOC 2 is the report.

Read the DPA on Tuesday. The deal closes on Friday, or it doesn't and the partner saved the firm six weeks. Both outcomes are wins.

Frequently asked questions

Isn't reviewing the DPA the DPO's job, not mine?

Yes, until the deal is signed. The DPO drafts and reviews, the partnership signs the master agreement. When something breaks eight months in, the call goes to the partner who approved the relationship. In professional services the bar association does not write to the privacy team. Reading the DPA once before signing is the cheapest firm-level insurance available, and it usually takes twenty minutes.

What if the vendor's DPA is 'based on the EDPB template'?

Good signal, not a free pass. EDPB-template DPAs are usually solid on the structural elements but vendors customize the sub-processor section and the audit clause heavily, which is exactly where the failures hide. The template does not save you from a unilateral sub-processor flow-through clause the vendor inserted on page nine. Read the customizations, not the boilerplate.

How is a DPA different from a standard NDA?

An NDA prevents disclosure. A DPA defines processing. The NDA covers a conversation, the DPA covers everything the vendor does with your data: who they let touch it, on what lawful basis, for how long, with what security, with what audit right, and what happens when you leave. The NDA is a one-page document. The DPA is the relationship contract, and most professional services firms misweight the two.

Can we just sign the vendor's DPA and add an addendum to fix the clauses we don't like?

Sometimes. If the DPA fails on one specific clause, a negotiated addendum can fix it. If it fails on three or four, you are rewriting the contract piece by piece, which usually means the vendor was not built for the European professional services buyer in the first place. The cleaner path is to ask the vendor to amend the DPA itself for all customers, or to pick a vendor whose default DPA already passes.

The vendor said they will send the DPA after the trial. Is that acceptable?

No. The trial is processing your data. A trial without a signed DPA is a controller-processor relationship operating on no written contract, which is itself an Article 28 violation. Get the DPA before any data touches the vendor's system, even in a sandbox. If the vendor refuses to share the document pre-trial, that is a signal about the rest of the commercial relationship and you should treat it as one.