Do You Need a DPA for Your AI Tools?

If your AI tool touches customer names, emails, support tickets, or CVs, GDPR almost certainly requires a Data Processing Agreement with that vendor. The hard part is not knowing that a DPA exists, but knowing when it applies and how to read one that actually protects you.

What a DPA is, in plain terms

A Data Processing Agreement (DPA) is the contract required under Article 28 of the GDPR whenever one organisation (the controller) hands personal data to another organisation (the processor) to handle on its behalf. You are the controller: you decide why and how the data is used. Your AI vendor is the processor: it runs the model, stores the prompts, and executes the task you asked for.

The DPA is what makes that hand-off lawful. Without it, you are transferring personal data to a third party with no binding rules on how they may use it, how long they keep it, or what happens when something goes wrong. Regulators treat a missing DPA as a compliance failure in its own right, separate from any actual data breach.

The key mental shift for AI tools: a chatbot or agent that reads a support inbox is not "just software." The moment it processes an email address or a customer complaint, it becomes a processor of personal data, and Article 28 applies exactly as it would to a cloud CRM or a payroll provider.

When you actually need one

You need a DPA whenever an AI vendor processes personal data on your behalf. In practice that covers most real business use:

• Customer-facing agents that read emails, chats, or tickets containing names and contact details.
• HR and recruitment tools screening CVs or applications (often special-category data).
• Sales and marketing assistants working from CRM records or lead lists.
• Knowledge assistants where employees paste internal documents that mention colleagues, clients, or partners.

You may not need a DPA if the tool only processes fully anonymised data, or purely non-personal content such as public product specifications. But be careful: pseudonymised data (an internal ID that can still be linked back to a person) is still personal data under the GDPR, so the DPA obligation stands.

A useful test: if you would be uncomfortable seeing the input appear in a data-breach headline, there is personal data in the pipeline, and you need the agreement. When you evaluate any AI agent or wider AI workforce platform, treat the DPA as a gating question, not an afterthought.

What to look for in an AI vendor's DPA

Not all DPAs are equal, and AI introduces clauses that generic templates miss. Work through this checklist before signing.

No training on your data. This is the clause that matters most for AI. The agreement should state that your prompts, uploads, and outputs are never used to train or fine-tune the vendor's or any third party's models. Look for explicit "no-training" and zero-retention language, not vague "we respect your privacy" wording.

Retention and deletion. The DPA should say how long prompts and outputs are stored and confirm that data is deleted on request and at contract end. Zero-retention model contracts, where inputs are discarded immediately after the response, are the strongest position.

Sub-processors. Every AI vendor relies on others: model providers, cloud hosting, sometimes search APIs. The DPA must list these sub-processors, commit to equivalent obligations down the chain, and give you notice of changes. If your tool routes prompts to OpenAI, Anthropic, Google, or Mistral, those model providers are sub-processors and belong in the agreement.

Data location and transfers. Check where processing happens. If data leaves the EU, the DPA needs a valid transfer mechanism such as Standard Contractual Clauses. EU data residency and EU model endpoints remove much of this risk before it starts.

Security and breach notification. Expect a description of technical measures and a commitment to notify you of breaches quickly enough to meet your own 72-hour reporting duty.

Audit and records. You should have the right to request evidence of compliance, and the vendor should keep records of processing.

The AI-specific risks a DPA should address

Standard SaaS DPAs were written before generative AI, so a few extra points deserve attention.

The biggest is the model layer itself. Your prompt does not stop at the vendor; it is passed to a large language model that may be operated by a different company entirely. A serious AI DPA makes the model provider's terms transparent and confirms that no-training and retention commitments apply all the way down.

Second is input minimisation. The safest architecture keeps personal data out of the model in the first place. Platforms that mask PII at the gateway, before any prompt reaches a model, shrink the amount of personal data actually processed and make the whole DPA easier to honour. This is a core part of a well-designed knowledge and RAG setup, where documents are retrieved with citations rather than absorbed into a model.

Third is traceability. If a regulator or customer asks what an AI agent did with someone's data, you need an answer. An immutable, append-only audit trail that logs every step, exportable for your records, turns a difficult question into a simple lookup. This matters even more for multi-agent pipelines, where several steps run in sequence and each one may touch personal data.

How AgentWorks approaches this

AgentWorks is built in the Netherlands as an EU-native platform, and the data protection posture reflects that. Personal data is masked at the gateway before any prompt reaches a model, so the amount of personal data actually processed is minimised by design. Model access runs on no-training, zero-retention contracts, and EU data residency is used with EU model endpoints where offered.

Every agent action is recorded in an immutable, append-only audit trail that you can export as CSV or JSON, and state-changing actions can require human-in-the-loop approval. Each agent carries a per-run risk classification, part of an EU AI Act-ready design (readiness depends on your specific use case, not a blanket claim). You can review the full data protection and governance approach before you commit, and a DPA is available on request.

None of this replaces your own assessment. You remain the controller, and you decide whether a given use case is lawful. What a well-built platform does is make the DPA straightforward to sign and easy to live up to. You can see how this fits across everyday chat, connected integrations, and the wider plans.

Summary: Under GDPR Article 28, you need a Data Processing Agreement whenever an AI vendor processes personal data on your behalf, which covers most real business use. The clauses that matter most for AI are no-training and zero-retention commitments, a full sub-processor list including the model provider, EU data location, and an exportable audit trail. Treat the DPA as a gating question before you adopt any AI tool.

Frequently asked questions

Is a DPA legally required for every AI tool?

A DPA is required whenever the AI vendor processes personal data on your behalf, which is the case for most business tools that read emails, tickets, CVs, or CRM records. If a tool only handles fully anonymised or purely non-personal data, you may not need one, but pseudonymised data still counts as personal data and triggers the requirement.

What is the difference between a DPA and a privacy policy?

A privacy policy is a public statement of how an organisation handles data, aimed at individuals. A DPA is a binding contract between you (the controller) and a vendor (the processor) that sets out exactly how that vendor may process the personal data you entrust to it. You cannot rely on a privacy policy in place of a DPA; GDPR Article 28 requires the contract.

What is the single most important clause in an AI DPA?

For AI tools, the no-training and zero-retention commitment is the clause to check first. It confirms that your prompts, uploads, and outputs are not used to train models and are not retained beyond what is needed to return a response. Make sure it also flows down to the underlying model provider, not just the front-end vendor. ===END======SLUG=== eu-ai-act-risk-classification ===META=== title: EU AI Act Risk Classification for AI Agents excerpt: How per-agent risk classes map to the AI Act's tiers, and why being "AI Act-ready" depends on your use case, not a vendor badge. seoTitle: EU AI Act Risk Classification for Agents | AgentWorks seoDescription: A practical guide to EU AI Act risk classification for AI agents: map each agent to the Act's tiers and see why readiness depends on your use case. category: Compliance readTime: 8 min read