<- Back

DPA for AI Tools: Checklist for Businesses

Compliance & Data Protection

Image

Dominik Keller

Image

A Data Processing Agreement (DPA) is a contract required under Art. 28 GDPR between you and a service provider that processes personal data on your behalf. For AI tools, it is particularly sensitive because your data runs through a model. This checklist shows what you should look out for in the DPA for AI providers before you sign.

A Data Processing Agreement sounds like the kind of document you sign once and then never look at again. With classic SaaS tools, that may well be true. With AI tools, this is a costly mistake – because here, the provider doesn't just process your data, in case of doubt, they run it through a model that was trained somewhere, whose behavior can change, and whose sub-processor chain is often longer than it appears at first glance.

Here is a checklist you should go through with every AI provider before you sign – for self-assessment or to check off in the next compliance round.

Legally, the DPA is not a nice-to-have: under Art. 28 GDPR, it is mandatory as soon as a service provider processes personal data on your behalf, and Art. 28 para. 3 prescribes the mandatory content. If it is missing or incomplete, fines of up to 10 million euros or 2% of global annual turnover loom (Art. 83 para. 4 GDPR).

Key Takeaways

  • A DPA under Art. 28 GDPR is mandatory as soon as a service provider processes personal data on your behalf – including for AI tools.

  • Three points are critical with AI: training usage, sub-processor chains, and deletion periods.

  • If a third country is involved, the DPA is not enough: standard contractual clauses and a documented case-by-case assessment are also required.

  • In 2024, the EDPB clarified that a model trained with personal data is not automatically considered anonymous.

The Checklist

  • Is the server location of the data processing explicitly stated?
    Not “distributed worldwide” or “subject to availability”, but a specific country or region. For GDPR purposes, this should be the EU.

  • Are all sub-processors listed?
    An AI gateway that itself accesses OpenAI, Anthropic, or other model providers automatically has a sub-processor chain. This must be fully and currently documented – not “available on request”.

  • Is there a policy on using your data for model training?
    This is the key difference between AI tools and classic software: could your prompts end up in the training dataset of the next model update? A good DPA explicitly rules this out instead of leaving it open.

  • Are deletion periods clearly defined?
    How long are prompts and responses stored, for what purpose, and how are they deleted afterwards? “As needed” is not a deletion period.

  • Is it regulated what happens at the end of the contract?
    Will your data then be deleted or exported? And within what timeframe?

  • Are there standard contractual clauses if sub-processors are located outside the EU?
    If the provider itself is based in the EU but forwards model requests to US providers, SCCs are also required for this part of the processing.

  • Are technical and organizational measures (TOMs) documented?
    Encryption, access controls, logging – a reputable DPA refers to a concrete TOM document, not to general security promises.

  • Is an obligation to report data protection incidents contractually fixed?
    And within what timeframe must the provider inform you if something goes wrong?

Why this is more critical with AI tools than with normal software

The European Data Protection Board explicitly addressed this point in its EDPB Opinion 28/2024 on AI models: the anonymity of a model trained with personal data is not automatically given, but is always a case-by-case assessment. For the DPA, this means: the promise "we do not train on your data" belongs in writing in the contract, not in the product description. Why technical redaction before the model call is the more robust protection is shown in Redact personal data.

With a classic accounting tool, it is relatively clear what happens to your data: stored, processed, displayed. With an AI tool, the chain is longer and more confusing. A prompt can run through several systems – gateway, model API, possibly the provider's logging and monitoring tools – and at each station, a new question arises: who is processing what here, and on what legal basis?

This is exactly why AI providers warrant a second, closer look at the DPA than you might give to a project management tool.

How kontinent.ai solves this

At kontinent.ai, the DPA is not a PDF attached as an afterthought, but was designed with these questions in mind from the start: EU server location, fully documented sub-processors, no use of your data for model training, clear deletion periods. The goal is that your legal department can go through the checklist above in a single conversation, without leaving you with open points to clarify afterwards.

If the provider processes outside the EU, the third-country regime under Art. 44–49 GDPR also applies. The three practical ways to solve this for OpenAI, Claude, and Gemini are described in Using OpenAI, Claude, and Gemini in Europe – without GDPR risk. How the AI Act affects things alongside this is clarified in the AI Act Checklist for Gateways.

Frequently Asked Questions

Do I need a separate DPA for every AI tool?

Yes, for every provider that processes personal data on your behalf, a separate DPA under Art. 28 GDPR is required.

Is a DPA sufficient if the provider uses servers in the US?

No, in that case, standard contractual clauses (SCCs) or another recognized transfer basis are additionally required, plus an assessment of the level of protection in the destination country.

What happens if a provider does not offer a DPA?

Then the tool should not be used for processing personal data – this is a clear knock-out criterion, regardless of how good the product is otherwise.

How often should existing DPAs be reviewed?

At least once a year, and additionally whenever the provider's list of sub-processors changes or new functions (e.g., new models) are added.

What must legally be included in a DPA?

Art. 28 para. 3 GDPR prescribes minimum contents: subject matter and duration of processing, nature and purpose, categories of data subjects, obligations and rights of the controller, binding instructions, confidentiality, technical and organizational measures, regulations on sub-processors, support obligations, and deletion or return of data after the end of the contract.

Sources

As of: August 27, 2026 · kontinent.ai. Information according to Art. 28 and 83 GDPR; not legal advice.