The GDPR Checklist Before the AI Contract
Request four things before the AI contract: a Data Processing Agreement with Standard Contractual Clauses, a current subprocessor list, certifications like SOC 2 and ISO 27001, and a written training statement. Then ask what separates vendors: retention per endpoint, where abuse detection happens, and incident notification timing. The DPIA, records of processing, and logs remain your responsibility.
Most AI contracts get signed under time pressure: the pilot went well, the business wants to move forward, and the vendor’s paperwork looks professional. That’s exactly when a checklist does the most good. Here are the requirements to set before signing – split into what you should request, what you should ask about, and what you can never hand off. The list is deliberately vendor-neutral: the same requirements apply whether the contract covers a chat service, a developer tool, or an API platform, and it works equally well for a renegotiation as for a new agreement.
The documents to request
Four documents make up the baseline package. If any of them is missing, that’s a reason to pause, not to keep negotiating:
| Document | What it should show |
|---|---|
| DPA with Standard Contractual Clauses | Role allocation, instructions, and a lawful transfer mechanism |
| Current subprocessor list | The whole chain – including hyperscalers, regions, and the change process |
| Certifications: SOC 2, ISO 27001 | Audited information security – ISO 42001 where AI governance is certified |
| Written training statement | That customer data isn't used for model training without explicit consent |
Request dated versions and save them in the procurement file. A subprocessor list with no date is essentially worthless in an audit two years later. Read the list actively, not as a formality: it often shows the chain is longer than the sales pitch implied – a model vendor, a hyperscaler, and sometimes third-tier analytics services. Every link is its own question about region and retention.
The questions that separate vendors
Most serious vendors have the documents above. The differences – and the risks – only show up in the follow-up questions:
- Retention and zero data retention per endpoint. A ZDR promise may apply to some features but not others. Ask per endpoint you actually use, not per product.
- Where abuse detection happens. Many vendors review prompts for abuse – sometimes outside the EU and sometimes with human review. Ask where, by whom, and with what storage.
- Incident notification timing. The standard wording “without undue delay” gives you nothing to plan against. Negotiate a concrete number of hours into a contract addendum – you yourself have 72 hours with the regulator and need a margin.
An example of why the endpoint level matters: a company procures an AI assistant for customer service and settles for the vendor’s “we offer zero data retention.” On review, it turns out ZDR applies to the chat flow – but not to the transcription API that every phone call passes through. The calls have been stored for 30 days outside the EU. A single follow-up question per endpoint would have caught that before the contract was signed. The lesson is general: the closer to your actual calls the question is asked, the more honest the answer gets. And ask for the answers in writing even when they feel obvious in the meeting – that’s the difference between a memory and a record.
Your own responsibility can’t be delegated
However good the vendor is, four obligations remain yours, as controller:
- DPIA – the impact assessment for high-risk processing.
- Records of processing – the AI tool and its subprocessor chain have to go into the Article 30 record.
- Logs – your own traceability over what was submitted and what the system did.
- An AI literacy plan – making sure the people using the tool understand what it may and may not be used for.
The vendor’s documents are input to these points, never a substitute for them. An auditor asks for your assessments, not the vendor’s brochure. These points are also the best defense against shadow AI: an organization that knows which tools may be used for what, and logs how they’re used, catches deviations before they become incidents.
Date the verification – and redo it
Everything above is a snapshot. Terms, subprocessors, and model versions change continuously, so the checklist needs to be run again before go-live and at every model upgrade. Date every verification and keep a version history – that turns the checklist from a one-time ritual into a living safeguard. A practical format is a simple table per vendor with requirement, statement, source, and date – tedious to fill in, invaluable the day someone asks.
Facing an AI contract and want a technical counterpart who’s seen this kind of wording before? At Weapp we work on AI solutions where the contract questions are handled together with the architecture – get in touch and we’ll go through your situation.
Frequently asked questions
What is a Data Processing Agreement, and why isn't the main contract enough?
A Data Processing Agreement (DPA) governs how the vendor may process personal data on your behalf – purpose, instructions, security, and subprocessors. GDPR requires it whenever a vendor processes personal data for you, and for vendors outside the EU, a transfer mechanism like Standard Contractual Clauses is also needed.
Are the vendor's certifications proof of GDPR compliance?
No. SOC 2 and ISO 27001 show audited information security, and ISO 42001 shows AI governance, but none of them is a GDPR certificate. They're necessary pieces of your assessment – your own DPIA and transfer analysis still have to be done.
What's a reasonable incident notification timeframe to require?
You have 72 hours to report a personal-data incident to the regulator, so the vendor's notification has to arrive well before that deadline. Negotiate a concrete number of hours into a contract addendum instead of accepting wording like "without undue delay."
Do we need a DPIA for an AI tool?
If the processing is likely to result in high risk to the data subjects – which AI processing of personal data often does – an impact assessment is mandatory. It's your responsibility as controller and can't be bought from the vendor, even though their documentation is an important input.
What is a record of processing activities?
A record of the organization's personal-data processing activities under Article 30 of GDPR: purposes, categories, recipients, transfers, and retention periods. Every AI tool that processes personal data has to go into it – including the subprocessor chain behind the tool.