GDPR AI Agent Data Processing Agreement: A Checklist

A data protection officer receives the vendor’s paperwork for a new claims agent (a typical week, not a client). The data processing agreement runs four pages. The sub-processor list has three lines, and one of them says “AI model provider” with no name. The officer’s question is short: who reads our customers’ emails, and who answers for them?

A GDPR data processing agreement (DPA) for an AI agent has to do two jobs. It must carry the eight items that Article 28(3) of the GDPR lists, written for what an agent really does. And it must follow the data down the chain to the hosting provider and the model provider, because every link is another processor (Opinion 22/2024, paragraph 17), and Article 28(4) passes the same obligations down to it. If the model provider is not named, the chain is not documented.

We read the GDPR text, the Commission’s model clauses for controllers and processors, the EDPB’s guidance and three model providers’ public terms on 15 November 2026. This is an engineer’s reading for your DPO and counsel to confirm, not legal advice. A separate Digital Omnibus on data protection is still in negotiation (the Council has adopted its position), so check the articles again before you rely on them. Our companion post covers the seven questions a DPO asks about an agent; this one is the contract view of its second question.

Who is who: controller, processor, sub-processor and the model provider?

The controller decides why and how personal data is processed. The processor processes it on the controller’s behalf. For an agent that reads your customers’ messages, you are the controller and the vendor that builds and runs the agent for you is the processor. Everyone the vendor engages to process that data for you is another processor. The EDPB notes that the GDPR’s definition covers “both the initial processor engaged directly by the controller as well as the processor’s processor, and so on along the processing chain” (Opinion 22/2024, paragraph 17).

So the hosting company is in the chain. So is the model provider. Each prompt it receives can carry the customer’s email.

Each link needs its own paper. Article 28(3) governs your contract with the vendor, and Article 28(4) makes the vendor pass the same obligations down.

Roles follow facts, not labels. Under Article 28(10), a processor that determines the purposes and means of processing “shall be considered to be a controller in respect of that processing”. If a model provider keeps your prompts to improve its own models, it is acting for itself for that use, whatever the contract’s cover page says. The EDPB adds a warning for buyers of standard terms. A vendor drafting the contract does not, by itself, make it a controller. A weaker bargaining position does not justify accepting terms that do not comply with data protection law. The EDPB puts it this way: “The controller must evaluate the terms and in so far as it freely accepts them and makes use of the service, it has also accepted full responsibility for compliance with the GDPR” (Guidelines 07/2020, paragraph 110).

What must a GDPR data processing agreement for an AI agent contain?

Article 28(3) says the contract must set out the subject-matter and duration of the processing, its nature and purpose, the type of personal data and the categories of people, and the controller’s obligations and rights. Then it must stipulate eight things, (a) to (h). The EDPB’s reading is that the contract “should not merely restate the provisions of the GDPR” and should say, in concrete terms, how each requirement will be met (Guidelines 07/2020, paragraph 112). For an agent, the concrete terms look like this.

Article 28(3) ends with one more duty: the processor “shall immediately inform the controller if, in its opinion, an instruction infringes” the GDPR. The EDPB recommends agreeing what happens next, for example a clause on termination if the controller persists with an unlawful instruction (paragraph 149).

Watch the legal-requirement exception in Article 28(3)(a). Its wording decides what the vendor may do without your instruction. Opinion 22/2024 says that the Article’s own wording, “unless required to do so by Union or Member State law to which the processor is subject”, is “highly recommended but not mandatory”. It also says a broader variant such as “unless required to do so by law or binding order of a governmental body” does not release the processor from the GDPR and cannot count as a documented instruction from you.

Where does an agent keep personal data, and what must deletion reach?

An agent can leave copies of personal data in several places. The customer’s message is only the start. The prompt that goes to the model carries retrieved passages and tool results. The answer comes back and is logged. Conversations, run records, a knowledge index and sometimes memory persist after the run, and the model provider may log requests on its side.

An example data path, not a specific product. Article 28(3)(g) asks for deletion of “existing copies”, so the DPA should name each store and who erases it.

Article 28(3)(g) says the processor, at your choice, “deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage”. The EDPB adds that the processor should confirm to you that deletion is complete, within an agreed timescale and in an agreed manner (paragraph 141).

Model providers differ on what they keep. OpenAI’s API documentation lists, endpoint by endpoint, whether data is kept for abuse monitoring (up to 30 days by default) and whether application state stays “until deleted”, as it does for conversations and vector stores. That is why the DPA needs a list of stores, not a general promise to delete “customer data”.

What do Articles 28(2) and 28(4) require for the sub-processor chain?

Five rules matter, and the Commission’s model clauses show what each looks like on paper.

1. Written authorization, specific or general. Under Article 28(2), “the processor shall not engage another processor without prior specific or general written authorisation of the controller”. With a specific authorization you approve each named sub-processor for a stated activity, and silence means no (Opinion 22/2024, paragraph 26). With a general authorization you approve a list at signing and the vendor must tell you of intended additions or replacements, with enough time for you to object. Under general authorization, your silence can be read as authorization (Guidelines 07/2020, paragraph 157), so put a calendar reminder on the notices.

2. The notice is the vendor’s job. The EDPB says the duty to inform “implies that the processor actively indicates or flags such changes toward the controller” (Guidelines 07/2020, paragraph 128). In our reading, a list on a web page works as the list, but a change to it is a notice only if the vendor flags it to you. The same guidelines say that merely publishing changes to standard terms on the processor’s website is not compliant with Article 28 (paragraph 110).

3. The law sets no number of days. Both options in the Commission’s clause 7.7(a) leave the time period blank. The EDPB asks for a reasonable timeframe and for the contract to say what happens after an objection, for example a time frame in which the parties decide whether the processing ends (paragraph 158). One checklist we read gives 30 days as the typical notice. That is a fair negotiating position, but it is market practice, not a rule.

4. The same obligations go down, in substance. Article 28(4) requires “the same data protection obligations” to be imposed on the sub-processor by contract. The Commission’s clause 7.7(b) says “in substance”, and the EDPB agrees that the wording need not be identical (Opinion 22/2024, paragraph 63).

5. The vendor stays liable, and so do you. Article 28(4) says the initial processor “shall remain fully liable to the controller” for a sub-processor’s failures. The EDPB is plain that this does not take you out of the picture. The ultimate responsibility for verifying the guarantees stays with the controller, though the vendor stays liable to you, so you have a contractual claim against it (paragraphs 58 and 64). Toward the people affected, Article 82(4) says each controller or processor responsible for the damage can be held liable for the entire damage, with a right of recourse between them in Article 82(5).

How hard should you check? The EDPB’s answer scales with risk. You may rely on your processor’s information and build on it. Where it “seems incomplete, inaccurate or raises questions”, check further. For high-risk processing you “should increase” the verification (paragraphs 59 and 60).

You are not required to ask for every sub-processing contract. Opinion 22/2024 says to decide case by case and to run sampling checks as part of your audit process (paragraph 69). If you use the Commission’s clauses, clause 7.7(c) gives you the right to ask: “At the controller’s request, the processor shall provide a copy of such a sub-processor agreement and any subsequent amendments”, with business secrets redacted if needed. One more line from the EDPB matters here: contractual clauses “cannot - by themselves - demonstrate that the sufficient guarantees are effectively implemented” (paragraph 71). Ask what the vendor actually does.

The model clauses also include a third-party beneficiary clause (7.7(e)). If the vendor has disappeared or become insolvent, you can terminate the sub-processor’s contract and instruct it to erase or return the data. In our reading, without such a clause your access to the sub-processor depends on the vendor surviving.

What should you ask about the model provider?

The model provider is where the prompt lands, and where DPAs are quietest. These six questions turn “AI model provider” into something you can check. The right column shows how three providers’ public terms read on 15 November 2026. They are other companies’ terms, they differ by plan and endpoint, and they change. Read your vendor’s contract for the route it actually uses.

One more question comes from Opinion 28/2024. It covers a controller that deploys an AI model retaining personal data, when the model was built by someone else. Supervisory authorities “should take into account whether the controller deploying the model conducted an appropriate assessment” that the model was not developed by unlawfully processing personal data. The assessment can be “less or more detailed depending on the risks raised by the processing in the deployment phase”. Ask the vendor what documentation from the model provider it can pass to you for the model your agent uses.

When does Chapter V apply to the model call?

Chapter V applies whenever a transfer to a third country takes place. Article 44 says transfers may take place only if the conditions of the chapter “are complied with by the controller and processor”, and that includes onward transfers. The EDPB treats remote access from a third country as a transfer when the criteria are met (Opinion 22/2024, paragraph 75), so a support engineer outside the EEA who can open logs also matters, not only where the model runs.

The tools are the ones you know. An adequacy decision under Article 45 lets a transfer take place without specific authorization, and Article 46(2)(c) allows standard data protection clauses adopted by the Commission. The EU-US Data Privacy Framework rests on such a decision. The General Court dismissed a challenge to it on 3 September 2025, and Philippe Latombe appealed to the Court of Justice on 31 October 2025. Ask which tool each provider relies on and what the fallback is if it changes.

Three points from Opinion 22/2024 help in the vendor call:

• You decide. “It is up to the controller to decide on whether a transfer of personal data outside of the EEA is possible”, and the processor should not transfer outside your instructions (paragraph 77). The Commission’s clause 7.8(a) says the same. You can forbid transfers or allow them to named countries only.
• You stay responsible. Even when a processor carries out the transfer, the controller “is still subject to duties coming from both Article 44 GDPR and Article 28(1) GDPR” (paragraph 80).
• Documentation travels up. The exporting processor prepares the transfer documentation, and you assess it and must be able to show it to your supervisory authority. You may rely on it and build on it.

Chapter V does not say “EU only”. That is a contract choice you can make, and if you make it, it has to hold at every hop: the model, its logs, its support access.

What records and audit rights should the DPA give you?

Article 28(3)(h) makes the processor give you “all information necessary to demonstrate compliance” and allow audits. The EDPB wants the contract to say how often information flows and in what form, for example by sharing the relevant parts of the processor’s own records (Guidelines 07/2020, paragraph 143). It also keeps the choice of auditor with you, lets you contest an audit’s scope and methodology, and warns against “clearly disproportionate or excessive” fees, which would make the audit rights “purely theoretical” (paragraphs 144 and 145).

Four items belong in the pack you could hand to a regulator:

1. The processor’s record of processing. Article 30(2) requires each processor to keep a record of the categories of processing it carries out for you, its transfers and a general description of its security measures. Under Article 30(4) it must make the record available to the supervisory authority on request. Ask for the extract that concerns you.
2. Your own record. Under Article 30(1)(d) your record lists the categories of recipients, including those in third countries. The sub-processor register feeds it.
3. A retrievable list of recipients. If a person asks you who received their data, the Court of Justice has held that you must give the actual identity of the recipients, with exceptions (case C-154/21, discussed in Opinion 22/2024, paragraph 30). Opinion 22/2024 wants that information “readily available at all times”, whatever the risk of the processing, so you can answer access requests without undue delay (paragraph 31).
4. A breach clause with the right clock. Article 33(2) says the processor notifies the controller “without undue delay”. The 72 hours in Article 33(1) is your clock toward the supervisory authority. The checklist we cited above asks for vendor notice within that same 72-hour window, which is a reasonable thing to negotiate. It is not what the article says. Ask for a fixed number of hours that leaves you time inside your own 72, and for the details your notice needs.

For an agent, add a fifth: the run record. If you must show what the agent did with one person’s data, the vendor’s record of each run should say what came in, which sources and tools it used and which model answered. If a person approves the agent’s actions, the approval belongs in that record too, and we wrote about designing that approval step so an auditor accepts it.

A one-page sub-processor table you can copy

Opinion 22/2024 says the identity information means name, address, contact person and a description of the processing, “including a clear delimitation of responsibilities in case several sub-processors are authorised” (paragraph 22). The vendor should proactively provide it for every processor and sub-processor and keep it up to date at all times (paragraph 32). The fields mirror Annex IV of the Commission’s clauses. A useful register adds the facts an agent raises: what personal data each link receives, where it processes, which transfer tool applies and when you authorized it.

Example only: the names are placeholders. Keep one row per link, including the links behind the vendor’s own vendors.

What each column holds:

Ten questions for the vendor call

1. Who is the controller and who is the processor for this agent, and does any sub-processor use our data for its own purposes?
2. Which document is the instruction set (the approved agent specification), and how is a change recorded?
3. Can we see the full sub-processor list now, with name, address, contact person, what each does, what data it receives and where it processes?
4. Is the model provider on that list by name, and does the route go through any gateway or reseller that is not?
5. How, and how many days in advance, are we told of a change, and what happens if we object?
6. Which obligations did you pass to each sub-processor, and will you give us a copy of the contract if we ask?
7. What does each model provider keep, for how long, and who at the provider can read it?
8. Where is the data processed, including support and logs, and which transfer tool covers each location outside the EEA?
9. List every store the agent writes to, and how and when each is erased at the end of the contract. Will you confirm in writing?
10. What do you give us to answer a regulator: the Article 30(2) extract, run records and audit rights? And how many hours after you learn of a breach will you notify us?

What does the Wise Agents DPA cover?

Here is how our DPA reads against that list. The trust page sets it out in plain words: you are the controller and we are your processor, and the DPA says so before any data moves. It makes the eight Article 28(3) commitments, from documented instructions to audits. Sub-processors are used only with your authorization, you are told of a change in advance and can object, and we stay fully liable for them.

The platform’s sub-processor list is public. It shows what each one does, what it receives and where, with the date it was last checked (11 November 2026).

The platform is hosted in Nuremberg, Germany. Each deployment names its model providers, and the model route is named per deployment in your contract. The security annex is the nine layers on that page, and the DPA’s transfer annex names the legal basis for each sub-processor outside the EU. The DPIA support pack is available on request, before you sign. Every run is recorded step by step, including which model answered and who approved, and deleting an agent erases its conversations, runs, files, knowledge, credentials, memory and keys, with a receipt for each step.

It is the document set we would want to receive if we were the DPO. If a vendor’s set is missing a row from the table above, ask for it before the first real file reaches the agent.

Bring one process. In 45 minutes you get a first view of its risk class, the controls it needs and whether an agent is the right tool at all. Book a scoping call.

Questions

Do I need a data processing agreement with an AI agent vendor?

Yes, whenever the vendor processes personal data on your behalf. Article 28(3) says processing by a processor shall be governed by a contract that is binding on the processor and sets out the subject-matter, duration, nature, purpose, types of data and categories of people.

Is the model provider a sub-processor?

Usually, yes. When the vendor sends personal data to a model provider to run the agent on your behalf, that provider is another processor in the chain, and Article 28(2) and 28(4) apply to it. If it also uses the data for its own purposes, it takes a controller's role for that use under Article 28(10).

Can the vendor add a sub-processor without asking me?

Not without your authorization. With a specific authorization you approve each one first. With a general authorization the vendor must tell you of intended changes and give you the opportunity to object (Article 28(2)). The number of days is set in the contract, not in the law.

Can personal data go to a model provider outside the EU?

Yes, if the conditions of Chapter V are met, such as an adequacy decision (Article 45) or standard contractual clauses (Article 46). You decide whether transfers are allowed in your documented instructions, and you stay responsible for them even when the vendor makes them.

Do I have to read the vendor's contracts with its sub-processors?

Not as a routine. The EDPB says a controller has no duty to systematically ask for them and should decide case by case, with more checking for high-risk processing. If your DPA uses the Commission's model clauses, clause 7.7(c) lets you request a copy, with business secrets redacted.

Sources

1. eur-lex.europa.eueur-lex.europa.eu/eli/reg/2016/679/oj
2. eur-lex.europa.eueur-lex.europa.eu/eli/dec_impl/2021/915/oj
3. www.edpb.europa.euwww.edpb.europa.eu/system/files/2023-10/edpb_guidelines_202007_controllerprocessor_final_en.pdf
4. www.edpb.europa.euwww.edpb.europa.eu/system/files/2024-10/edpb_opinion_202422_relianceonprocessors-sub-processors_en.pdf
5. www.edpb.europa.euwww.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf
6. gdpr-info.eugdpr-info.eu/art-30-gdpr/
7. gdpr-info.eugdpr-info.eu/art-33-gdpr/
8. gdpr-info.eugdpr-info.eu/art-45-gdpr/
9. gdpr-info.eugdpr-info.eu/art-46-gdpr/
10. gdpr-info.eugdpr-info.eu/art-82-gdpr/
11. platform.openai.complatform.openai.com/docs/guides/your-data
12. openai.comopenai.com/index/introducing-data-residency-in-europe/
13. privacy.claude.comprivacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data
14. learn.microsoft.comlearn.microsoft.com/en-us/legal/cognitive-services/openai/data-privacy
15. www.wilmerhale.comwww.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law-blog/20251201-european-court-of-justice-to-review-challenge-to-eu-us-data-privacy-framework
16. www.teamazing.comwww.teamazing.com/blog/eu-ai-chat-dpa-checklist/
17. www.addleshawgoddard.comwww.addleshawgoddard.com/en/insights/insights-briefings/2026/data-protection/eu-digital-omnibus-european-council-adopts-its-position/

Read on or before 15 November 2026. Not legal advice: your counsel and data protection officer decide.

Written by

The Wise Agents team

Engineers who build and run AI agents for regulated companies. We read every article we cite on the day we state, and say what your counsel or DPO must confirm.

About us →