DPAs with AI vendors: training use, sub-processors and deletion

This guide is for a company buying an AI tool, or an API, that will see personal data in prompts, files or outputs. The usual DPA questions still apply (see Do you need a DPA? and Reviewing a vendor's DPA); this guide covers the points particular to AI vendors.

Training on your data

The first question is whether the vendor uses your inputs or outputs to train or improve its models. The answer is often in the terms of service or a data usage policy rather than in the DPA, so read them all. If the vendor does train on your data, it is acting as a controller for that use, not as your processor (see Who is really the processor?), and calling it a processor in the DPA does not change that.

Ask for an express prohibition on training, or an opt-in that you control, and check what it covers. A prohibition limited to "customer content" may leave out outputs, uploaded files or feedback (ratings and corrections), which a vendor's terms may treat separately. The clause should name inputs, outputs, files and feedback.

Model providers as sub-processors

Many AI tools do not run their own models: they send your prompts to a model provider's API. That provider is a sub-processor, and the rules on sub-processors apply in full. It must be on the vendor's sub-processor list, with the region where it processes the data, and the vendor's own obligations must flow down to it (Article 28(4)). The flow-down is often the model provider's own business terms; check them for the same points as this guide.

Check whether the vendor can switch model providers, or route requests between several. Many can, sometimes by a change of configuration that the customer does not see. A switch to a new provider is the engagement of a new sub-processor, so the DPA should make it trigger the sub-processor notice and your right to object (Article 28(2)).

Retention of prompts and outputs

Ask how long prompts, outputs and logs are kept, by the vendor and by its model provider, including any retention for abuse monitoring, which may apply at the model provider even when the vendor itself keeps nothing. Ask whether a zero-retention option exists, and on what conditions.

Logs are personal data too when they contain names or account details, and a vendor may keep them longer than the prompts. The retention terms should cover logs by name.

Deletion and "unlearning"

Deleting data from a database is routine, and Article 28(3), point (g), requires it at the end of the service. Removing the influence of data from a model that has already been trained on it is a different matter: in practice, it is not possible on request. Once data has been used for training, deleting the stored copy does not reach the model. That is why the prohibition on training, above, is the real protection.

Ask for deletion of everything stored at the end of the service, within a fixed time: prompts, outputs, uploaded files and embeddings (the numerical representations of your documents that many tools keep for search and retrieval). Ask for a written confirmation, and for the deletion to reach the model provider.

Transfers to US model providers

Where the model provider is in the United States, check whether it is certified under the EU-US Data Privacy Framework; the Framework's website keeps the list. If it is certified, the adequacy decision covers the transfer to it. If it is not, the Standard Contractual Clauses and a transfer impact assessment are needed, as for any other transfer (see International transfers and our guide on EU data transfers after the Data Privacy Framework).

Ask where processing happens, at the vendor and at the model provider, and whether an EU region can be chosen. A vendor may store data in the EU while its model calls go to the US.

Sources: GDPR, Regulation (EU) 2016/679, EUR-Lex; Data Privacy Framework program; Commission Implementing Decision (EU) 2021/914 (Standard Contractual Clauses), EUR-Lex.

Access by the vendor's staff

Check when the vendor's people can read your prompts and outputs, for example for support when you raise a ticket, or for safety review when a prompt is flagged. Ask under what controls this happens (who may look, on what trigger and with whose approval), and that each access is logged. A vendor that does not train on your data may still have people reading it; the DPA should say when.

The EU AI Act sits alongside, not inside, the DPA

The EU AI Act has its own roles: the provider, who develops an AI system or has it developed and places it on the market, and the deployer, who uses it. These are not the GDPR's roles of controller and processor, and the two sets answer different questions: an AI vendor can be the provider and your processor at once, while you are the deployer and the controller.

A deployer's duties (for example, under Article 26 for high-risk AI systems) are handled in the main contract and in your own processes, not in the DPA. The DPA governs the processing of personal data on your behalf. For the dates on which the AI Act's duties apply, see our EU AI Act timeline.

Source: EU AI Act, Regulation (EU) 2024/1689, EUR-Lex.

California: automated decisions

The CCPA regulations on automated decision-making technology apply from 2027. If the tool is used to make significant decisions about people, the business using it has notice, access and opt-out duties, and it will need the vendor's help to meet them: for example, information about how the tool reaches its outputs, and a way to act on an opt-out. The contract should support those duties. Ask the vendor what it can provide, and write it into the contract.

Source: CCPA Regulations, effective 1 January 2026 (CPPA).

What to ask before signing

• Do you use our inputs, outputs, files or feedback to train or improve any model? Will you put a prohibition, or an opt-in that we control, in writing?
• Which model providers process our data, in which regions, and on what terms?
• Can you switch or add model providers, and will a switch trigger the sub-processor notice and our right to object?
• How long are prompts, outputs and logs kept, by you and by the model provider, including for abuse monitoring? Is there a zero-retention option?
• At the end of the service, will you delete prompts, outputs, files and embeddings within a fixed time, and confirm it in writing?
• Is the model provider certified under the EU-US Data Privacy Framework? If not, are the Standard Contractual Clauses in place, with a transfer impact assessment?
• Where does processing happen, and can we choose an EU region?
• When can your staff read our prompts, under what controls, and is each access logged?
• Which of our duties as deployer under the AI Act does the main contract support?
• If we use the tool for significant decisions about people, how will you support our notice, access and opt-out duties under the CCPA regulations?

Questions people ask

If the vendor deletes our data, is it also removed from the model? Not if the model has already been trained on it. Deleting stored prompts, outputs, files and embeddings is routine; removing data's influence from a trained model is not, in practice, possible on request. That is why the prohibition on training is the real protection.

Is the model provider behind an AI tool a sub-processor? Yes, when the tool sends your data to the provider's API. It must be on the vendor's sub-processor list, with its region, and a switch to another provider should trigger the sub-processor notice.

Does the DPA need to cover the EU AI Act? No. The AI Act's roles (provider and deployer) are not the GDPR's roles (controller and processor). A deployer's duties are handled in the main contract and in your own processes.

Is a zero-retention option enough on its own? It addresses how long prompts and outputs are kept. It does not settle training use, staff access or transfers, which need their own terms.

Update log

• 29 October 2026: first published.