What's the single most important thing to check in an AI vendor's DPA?

Whether the content you send the tool, your prompts and any data in them, is used to train the vendor's models. This isn't always spelled out clearly in a DPA itself and sometimes lives in a separate terms of service or a toggle in account settings, so it's worth confirming directly rather than assuming the DPA covers it. This is general guidance, not legal advice.

Is a vendor's DPA a legally binding document on its own?

A DPA is typically a contract, or part of one, and where it's properly executed it is legally binding between the parties. Whether a specific DPA satisfies the requirements that apply to your processing, such as GDPR's Article 28, and whether it's been properly incorporated into your agreement with the vendor, is a legal question for your own counsel to confirm, not something to assume from the document's title.

Does having a published DPA mean a vendor is GDPR compliant?

No. A DPA covers the processor's obligations regarding data it processes on your behalf; it doesn't by itself establish that your own processing has a lawful basis, that you've met your transparency obligations to data subjects, or that every other GDPR requirement is satisfied. A DPA is one piece of a compliant deployment, not the whole of it.

Data protection

Blog/What to look for in an AI vendor's data processing agreement

For AI assistants

What to look for in an AI vendor's data processing agreement

By Samuel Seidel · Published September 9, 2026 · 8 min read

Most people click past the DPA link the same way they click past terms of service, and most of the time that's fine, until it isn't. Below is what's actually worth reading in one of these documents before you connect an AI tool to anything that matters, framed as a guide for evaluating any vendor's DPA, not a pitch for ours. Not legal advice; a DPA is a legal document and its adequacy for your situation is a question for counsel.

Start with whether a DPA exists at all

Some AI tools, particularly smaller or newer ones, don't have a published DPA at all, or only offer one on request for enterprise customers. If a vendor processes personal data on your behalf and can't produce a DPA, that's worth treating as a real signal, not a formality to chase down later. A vendor that's thought about this has usually published the document, or at minimum has one ready to send within a day of being asked.

The subprocessor list

A DPA that names the vendor and stops there is missing the part that usually matters most: what other companies touch your data downstream. Cloud hosting, model providers, analytics, support tooling, each of these can be a subprocessor, and a DPA worth having lists them by name instead of pointing at an undefined "our subprocessors." Check whether the list is current, whether there's a process for the vendor notifying you of changes, and whether you'd actually have a chance to object before a new one is added.

Data location

Look for where the data is actually processed and stored, not just where the company is headquartered or where its marketing says its "EU region" is. A DPA should state this specifically enough to be useful, a named region or data center location, not a vague reference to "industry-standard infrastructure." If the answer is unclear or the DPA is silent on it, that's a question to put to the vendor directly rather than infer.

Deletion terms

Read for what happens to your data after you stop using the tool or delete an account: how long it persists, whether that includes backups, and whether deletion is something you have to request or happens automatically on a defined schedule. Vague language here, "data will be deleted in accordance with our retention policy," without stating what that policy actually is, is a gap worth pushing on before you rely on the tool for anything sensitive.

Whether your prompts train the vendor's models

This is the one most specific to AI tools and the one most likely to be buried outside the DPA itself, in a separate terms of service, a FAQ, or an account setting you have to find and toggle. Ask directly: does content sent to this tool get used to train or fine-tune the vendor's models, and is that opt-out, opt-in, or not offered as a choice at all. For any tool handling customer data, confidential business information, or anything under an NDA, this answer needs to be a clear no, or a clear and controllable opt-out, before the tool is safe to use for that data.

Breach notification terms

Check what the DPA commits the vendor to if there's a security incident involving your data: whether it commits to notifying you at all, within what timeframe, and with what level of detail. This matters practically because your own breach-notification obligations, to regulators or to affected individuals, typically run on a clock that starts when you become aware of an incident, and a vendor that's slow or vague about notifying you puts your own compliance timeline at risk before you've even had a chance to respond.

A worked example, read critically

GPUwerk's own Article 28 DPA is public and covers the areas above: it names the current sub-processor situation (published separately at /legal/sub-processors), states that the underlying infrastructure is single-tenant hardware in EU-Central operated by PRINT IT! SE, and addresses deletion and breach terms. It's a reasonable example of the shape a DPA should have, not a claim that it's a flawless or lawyer-perfected document, GPUwerk's legal pages, this one included, have not been reviewed by outside counsel, and that's disclosed directly on the page itself. Read it the same critical way this guide suggests reading any vendor's DPA, and raise anything unclear with us directly rather than assuming it's been resolved.

The checklist

Does a DPA exist, and is it easy to find without asking sales for it?
Does it name actual subprocessors by name, rather than referencing a policy?
Does it state a specific data location, not a vague region claim?
Are deletion terms concrete: a timeframe, and whether backups are included?
Is it clear, in the DPA or elsewhere, whether your content trains the vendor's models?
Does it commit to a breach notification timeframe you can actually plan around?

None of this substitutes for having someone with legal training review the document against your specific processing before you sign anything that matters. Treat this checklist as what to read for, not as the review itself.