How to Tell If an AI Vendor Is GDPR Compliant
A practical checklist of the documents and clauses to request, DPA, sub-processor list, data residency, and training terms, before trusting an AI vendor's GDPR claims.
How to Tell If an AI Vendor Is GDPR Compliant
Most AI vendors will say they are GDPR compliant. That phrase alone tells you nothing. Compliance is not a badge a vendor earns once and keeps forever, it is a set of contractual and technical facts you can check: a signed Data Processing Agreement, a disclosed list of sub-processors, a clear answer on where your data is stored and whether it trains their models, and a real process for deleting data on request. If a vendor cannot produce these on request, treat the compliance claim as marketing. This guide covers exactly what to ask for and how to read the answers.
Start with the legal relationship, not the marketing page
Under GDPR, when you send an AI vendor personal data (customer emails, employee records, support transcripts, anything tied to an identifiable person), you are the data controller and the vendor is a data processor. Article 28 of the GDPR requires that this relationship be governed by a written contract, and it specifies exactly what that contract has to cover: the subject matter and duration of processing, the nature and purpose of it, the types of personal data and categories of people involved, and a set of binding obligations on the processor.
This sits inside a broader set of concerns worth understanding on their own terms; for the wider picture beyond GDPR specifically, see our practical guide to AI risks for builders.
That written contract is the Data Processing Agreement (DPA). If a vendor cannot produce one, or tries to fold GDPR terms into a generic terms-of-service page instead of a standalone signed document, that is the first red flag. See Article 28 of the GDPR for the official text of what a compliant processor contract must include.
The document checklist: what to request before you sign
Ask for these five things by name. A vendor that has done the compliance work will have them ready. A vendor that has not will stall, point you to a marketing FAQ, or offer a verbal assurance instead.
1. A signed Data Processing Agreement (DPA)
This should be a standalone document, not a clause buried in the terms of service. Per Article 28, it needs to specify that the processor acts only on your documented instructions, keeps the data confidential, implements appropriate security measures, assists you with data subject requests, deletes or returns data at the end of the engagement, and allows for audits. Read the deletion clause closely: some vendors default to data return only, with deletion an extra request.
2. A current sub-processor list
Almost every AI vendor relies on sub-processors: cloud hosting, the underlying model provider, analytics, customer support tooling. GDPR requires that these sub-processors be disclosed and bound by the same data protection obligations as the primary processor, who remains fully liable for their sub-processor's failures. Ask for the current list and how you get notified before a new one is added. Under general authorization, you should have the right to object to a new sub-processor before it starts touching your data, not just a notification after the fact.
3. A written answer on whether your data trains their models
This is the single most common gap between what an AI vendor's marketing implies and what its contract actually says. "We don't sell your data" is not the same commitment as "we don't train on your data." Ask for the specific contract clause, not a sales rep's verbal assurance, and check whether it applies to all data you send or only certain tiers or plans. If the vendor offers an opt-out toggle in a settings page instead of a contractual guarantee, that toggle can change or reset without notice. We cover how to run this check in more depth in how to check if an AI tool trains on your data.
4. Data residency and cross-border transfer terms
If you need EU customer data to stay in the EU, ask exactly where it is processed and stored, not just where the company is headquartered. A vendor claiming "EU data residency" should be able to name the specific region their infrastructure runs in. If any processing happens outside the EU/EEA, GDPR requires a valid transfer mechanism, most commonly the European Commission's Standard Contractual Clauses (SCCs). Ask which version of the SCCs is in the contract and whether the vendor has done a transfer impact assessment for the destination country, a requirement that grew out of the Schrems II ruling on transfers to the US.
5. A deletion and retention process you can actually trigger
GDPR's right to erasure means a data subject can ask for their personal data to be deleted, and you as the controller need the vendor to be able to honor that request, including from logs, backups, and cached copies, not just the primary database. For AI vendors specifically, ask what happens if the data was used in a fine-tuning run or embedded in a vector store: deleting a database row does not always remove it from a trained model or an index. Get the vendor's retention schedule in writing, including how long logs and backups persist after you delete something upstream. If you are drafting your own privacy policy on top of a vendor stack like this, our guide to writing a privacy policy for an AI app covers how to describe these downstream vendor relationships to your own users.
A quick reference table
What to request | Why it matters | Red flag |
|---|---|---|
Signed DPA | Legally required under Article 28 for any processor relationship | Only a generic ToS, no standalone DPA |
Sub-processor list | Shows who else touches your data and under what terms | Vendor won't disclose or can't produce a current list |
Training-on-data clause | Determines if your data becomes part of their model | Verbal assurance only, no contract language |
Data residency terms | Confirms where data is actually processed and stored | Vague answers about "global infrastructure" |
Deletion process | Confirms erasure requests are technically possible to honor | No answer on logs, backups, or model artifacts |
Questions to ask on a vendor call
If you only have twenty minutes with a sales engineer or vendor security contact, these questions surface the gaps fastest:
Can you send me the signed DPA and the current sub-processor list today, not next week?
Does any part of your infrastructure or your sub-processors sit outside the EU/EEA, and if so, what transfer mechanism covers that?
Is customer data used to train, fine-tune, or evaluate your models, by default or ever?
If I delete a record, does that also remove it from logs, backups, and any fine-tuned model or embedding index?
Who is your data protection officer or GDPR contact, and can I reach them directly if I have questions later?
A vendor with real compliance infrastructure answers these without hesitation, usually with a link to a trust or security page that already has the DPA and sub-processor list posted. A vendor that needs to "check with legal and get back to you" on basic contract terms is telling you those terms are not standardized yet.
Shortcuts vendors take, and how to spot them
A few patterns show up repeatedly when a vendor's GDPR compliance is more claim than practice:
The DPA is a PDF nobody signed. Some vendors post a template DPA on their website but never actually execute it with each customer. Ask for a copy signed for your account specifically, not a generic sample.
"SOC 2 compliant" gets used as a stand-in for GDPR compliant. SOC 2 is a security framework, not a data protection regulation. A vendor can hold a clean SOC 2 report and still lack a proper DPA, sub-processor disclosure, or lawful transfer mechanism. The two are related but not interchangeable.
The sub-processor list is stale. Ask when it was last updated. A list that has not changed in two years for a fast-moving AI product usually means nobody is maintaining it, not that the vendor stopped adding infrastructure partners.
Data residency claims don't match the sub-processor list. A vendor might promise EU hosting for its own servers while quietly routing requests through a US-based model API for the actual AI processing. Cross-check the sub-processor list against the residency claim before you take it at face value.
Where this fits into broader vendor vetting
GDPR compliance is one slice of vetting an AI vendor, not the whole exercise. Security posture, uptime history, and exit terms matter too. For the fuller picture, see how to vet an AI vendor before you hand over data, and if you are past the evaluation stage and into contract terms, how to negotiate a contract with an AI vendor covers the leverage points beyond data protection clauses.
Frequently asked questions
Does every AI vendor need a Data Processing Agreement?
Yes, if they process any personal data on your behalf and you or your customers are subject to GDPR. This applies regardless of where the vendor is headquartered. A vendor processing only fully anonymized, non-personal data is the narrow exception, and few AI tools qualify since inputs often include names, emails, or other identifiers.
What is a data processing agreement with an AI vendor supposed to include?
At minimum, the subject matter and duration of processing, the categories of data and data subjects, the processor's obligations around confidentiality and security, assistance with data subject rights, breach notification, deletion or return of data at the end of the contract, audit rights, and terms governing sub-processors, per Article 28 of the GDPR.
Can a US-based AI vendor be GDPR compliant?
Yes. Location does not exempt a vendor from GDPR if it processes EU residents' personal data. What matters is whether the vendor has a valid transfer mechanism in place, typically Standard Contractual Clauses, along with the standard DPA obligations. Some vendors also offer EU-region hosting specifically to avoid the transfer question altogether.
How do I know if an AI tool is training on my data?
Check the contract, not the marketing copy. Look for an explicit clause stating whether inputs are used for model training, fine-tuning, or evaluation, and whether that is opt-out, opt-in, or excluded entirely. Enterprise or business tiers often exclude training by default while free tiers do not, so confirm which applies to your plan specifically.
What happens to my data if the AI vendor uses sub-processors outside the EU?
The vendor needs a valid legal mechanism for that transfer, most commonly Standard Contractual Clauses, plus in many cases a transfer impact assessment confirming the destination country offers comparable protection. Ask the vendor to name the mechanism and show you the relevant contract language rather than taking a general compliance claim at face value.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
