Data processing agreements for AI services: what to check

If you use a cloud AI service and enter personal data into it, you often have a processing relationship (Auftragsverarbeitung), and Art. 28 GDPR requires a contract with fixed minimum content for it. Five points matter most in that contract: subject matter and instructions, sub-processors, processing location, deletion, and whether the provider uses your inputs for training. This article describes the topic in general terms and does not replace a review. Whether a contract is sufficient in your case is for your data protection officer or a lawyer to clarify.

When a contract is needed

The German data protection conference (Datenschutzkonferenz, DSK) writes in its guidance of 6 May 2024 that where an organisation uses an external provider’s AI application for its own purposes, for example as a cloud solution, the provider acts “as an extended arm on behalf of the controller” (our translation). There is then often a processing relationship under Art. 28 et seq. GDPR, and an agreement under Art. 28(3) GDPR has to be concluded.

The word “often” matters. The DSK also mentions joint controllership under Art. 26 GDPR, where two bodies jointly decide on purposes and means. And under Art. 28(10) GDPR, a processor that infringes the Regulation by determining the purposes and means of processing is considered a controller in respect of that processing. The roles are settled by the actual service, not by the title of the contract.

Where names and other personal details turn up in your daily work, the articles on recording meetings and on meeting minutes with AI give examples. With a consumer account at a chat service, there is generally no contract between your business and the provider, so it is not suitable for business data.

What Art. 28(3) requires in the contract

The contract has to set out the subject matter and duration of the processing, its nature and purpose, the type of data, the categories of data subjects, and the controller’s obligations and rights. Added to this are the processor’s duties listed in paragraph 3. The contract must be in writing, and an electronic format is enough (paragraph 9). It may be based wholly or partly on standard contractual clauses (paragraphs 6 to 8).

If the provider considers an instruction unlawful, it must inform you immediately. That is also in paragraph 3.

Sub-processors

Under Art. 28(2) GDPR, the provider may not engage another processor without your prior specific or general written authorisation. With a general authorisation, it must inform you of any intended change, and you can object. Under paragraph 4, the same data protection obligations are imposed on the sub-processor, and the first processor remains liable to you for the sub-processor’s failures.

The European Data Protection Board (EDPB) adopted an opinion on this on 7 October 2024. It concludes that you should have the identity of all processors and sub-processors (name, address, contact person) available at all times, regardless of the risk of the processing. The provider should supply this information proactively and keep it up to date. The decision whether to engage a particular sub-processor, and the responsibility for it, remain with you. The extent of your verification depends on the measures and the risk, and for high-risk processing it should increase.

With AI services, a hosting partner or a model provider may also be involved. Art. 28 does not say whether that is so. Ask, rather than assume.

Processing location

The instruction under Art. 28(3)(a) expressly covers transfers to a third country. The DSK points out that with open systems run as a cloud service, transfers to third countries are common, and Chapter V of the GDPR then has to be considered. It regards technically closed systems as preferable from a data protection point of view.

The EDPB states that your duty to verify sufficient guarantees also applies to transfers between two sub-processors, in addition to the requirements of Art. 44 GDPR. The provider, as exporter, prepares the documentation, and you assess it and can build on it.

One clause in the contract deserves a close look: “unless required by law or a binding order of a governmental body”. The EDPB considers this wording permissible within contractual freedom but identifies several problems. For data leaving the EEA, it regards the wording alone as unlikely to be sufficient. It “highly recommends” the wording “unless required by Union or Member State law”, but does not make it mandatory.

Deletion

After the services end, the provider must delete or return all personal data at your choice, unless there is a legal duty to store them (Art. 28(3)(g)). Whether that includes copies in backups is not stated there, so the question belongs in the contract. For AI applications, the DSK gives a point on the right to erasure under Art. 17 GDPR that is also useful for your questions to the provider: some applications can create a personal link by combining different data. On deletion, care must therefore be taken that restoring the personal link is permanently impossible. Merely suppressing outputs with downstream filters is not generally deletion.

Ask specifically what happens to input history, logs and backup copies, and after what period.

Use of inputs for training

The DSK asks you to check whether input and output data are used for training, whether you are informed about it and whether the use can be excluded. If exclusion is not possible and personal data are affected, that purpose needs its own legal basis. According to the DSK, applications that do not use input and output data for training are preferable. As an example of privacy-friendly default settings, it names switching off training on inputs and input history when an account for your staff is set up.

My reading, not legal advice: under Art. 28(3)(a), the provider may process only on your documented instructions. If it uses your inputs for its own training purposes, it decides on the purpose itself in that respect, and Art. 28(10) comes into play. That is why the question belongs in the contract, with a clear answer. How this is to be classified legally is for your data protection officer to assess.

Questions to put to the provider

1. What role do you take in the processing, and where does the contract say so?
2. Do you use inputs and outputs to train or improve your models? Can that be excluded by contract, and is it off by default?
3. Which sub-processors are involved (name, address, contact person, task), and how do you inform us of changes?
4. Where are data stored and processed, and can they be accessed from outside the EEA?
5. On what basis do transfers to third countries take place, and what documents do you provide for them?
6. What happens to input history, logs and backups at the end of the contract, and after what period?
7. How do you support us with requests from data subjects and in the event of a data breach?
8. Which security evidence can we see, and are audits possible on site or by report?

Status and limits

I read the wording of Art. 28 in the Official Journal text (OJ L 119 of 4 May 2016). On 19 November 2025 the Commission proposed amending parts of the GDPR (Digital Omnibus, COM(2025) 837). Status as of November 2026: according to a law firm article, the Council set its negotiating position on 21 October 2026, and Parliament is expected to set its own only in February 2027. Nothing has been adopted, and until then the GDPR applies unchanged. Contracts, roles and individual cases are for your data protection officer, and for a lawyer in a dispute.

What you can do now

1. List the AI services your business uses or wants to use, and note which personal data would go into them.
2. Ask the provider for its data processing agreement and its list of sub-processors, and put both in front of your data protection officer.
3. Send the provider the list of questions and file the answers with the contract.
4. Set up your staff’s accounts so that training on inputs and input history are off, as far as the service allows.