Most teams reach for an AI tool first and ask about GDPR later, usually when a client questionnaire or a works council lands on the desk. That order is backwards, and it is expensive to unwind. "GDPR-compliant" is not a property of the model. It is a property of how you deploy the model: what you feed it, where that data is processed, who you have signed agreements with, and what you can show a regulator if asked.
This is a working checklist, not a legal opinion. Each item is something you can verify before you roll a tool out, and most of them come down to a document you either have or you do not. Work through them in order. If you want the underlying framework in more depth first, our guide to GDPR-compliant AI explains the moving parts, and the comparison of the best GDPR-compliant AI tools applies them to specific vendors.
1. Establish a lawful basis before the first prompt
Every time personal data goes into an AI system, that is processing under Art. 6 GDPR, and processing needs a legal basis. For most business use the basis is legitimate interest (Art. 6(1)(f)) or contract performance (Art. 6(1)(b)). If you are processing special-category data, health records, for example, you also need an Art. 9 condition, which is a much higher bar.
- Name the lawful basis for each category of data you plan to send to the tool.
- Where you rely on legitimate interest, document the balancing test in one paragraph.
- Confirm no special-category data flows in unless you have an Art. 9 condition and the appropriate safeguards.
- Check that the AI use is compatible with the purpose the data was originally collected for.
The common failure here is silent scope creep: a tool bought for drafting marketing copy quietly starts handling customer support transcripts. Write down what the tool is for, and keep it to that.
2. Sign a data processing agreement that reaches the model provider (Art. 28)
When a vendor processes personal data on your behalf, Art. 28 requires a data processing agreement (DPA, or Auftragsverarbeitungsvertrag / AVV in Germany). This is the single most-skipped item, because a signed DPA with the tool vendor feels like enough. It usually is not.
Almost every AI tool is a layer over one or more third-party models. Your prompts are processed by those models, so the agreement chain has to reach them.
- Get a signed DPA with the tool vendor.
- Ask for the sub-processor list in writing, and confirm the model providers behind the tool are on it.
- Confirm each sub-processor is bound by an equivalent agreement, not just named.
- Check the DPA covers deletion, audit rights, and breach notification.
Wysor holds an AVV/DPA with each model provider it routes to, so the chain reaches the actual processor rather than stopping at the wrapper. Ask any vendor to show you the same.
3. Verify where the data is actually processed
EU hosting is not a legal requirement in itself, but processing outside the EU triggers Chapter V transfer obligations, standard contractual clauses, a transfer impact assessment, and the documentation to back them. EU processing removes that whole workload before it starts.
- Confirm the region where requests are processed, in writing, not from a marketing page.
- Ask specifically where the model inference runs, not just where the app is hosted. These are often different.
- If any processing happens outside the EU, confirm the transfer mechanism and file the transfer impact assessment.
Beware the gap between "our servers are in Frankfurt" and "your prompt is sent to a model API in another region". The app can be EU-hosted while inference is not. Wysor runs an EU-hosted pipeline for exactly this reason. For the security-first version of this same check, see our secure AI for business checklist.
4. Confirm no training on your data, and zero data retention
Two separate promises, often confused. "We do not train on your data" says your inputs will not improve the model. "Zero data retention" says your inputs are not kept after the request finishes. You want both in writing, because one without the other still leaves a gap.
- Get a written commitment that customer prompts and uploads are excluded from model training.
- Confirm the retention window. "Zero" is the strong answer; anything longer needs a reason and a deletion process.
- Check the same commitments hold at the sub-processor level, not just the front-end vendor.
- For any knowledge base or document upload, confirm the same no-training and no-retention terms apply to files.
On many consumer plans, prompts feed model improvement by default unless you opt out. A business account should invert that. Wysor operates on zero data retention with no training on customer data, and applies the same terms to knowledge-base uploads (PDF, DOCX, XLSX, PPTX and more).
5. Keep the records the regulator will ask for (Art. 30)
Art. 30 requires records of processing activities. An AI tool is a processing activity like any other, and adding it means updating your register. This is boring and it is also the first thing an auditor checks.
- Add the AI tool to your record of processing activities: purpose, categories of data, recipients, retention.
- List the tool and its sub-processors in your processor register.
- Keep your data protection notices current so data subjects know AI processing is involved.
- Confirm you can honour access, deletion, and objection requests for data that passed through the tool.
If you cannot answer "what does this tool do with personal data" from your own records in five minutes, the records are incomplete.
6. Run a DPIA where the risk warrants it (Art. 35)
A data protection impact assessment is not required for every tool, but it is required where processing is likely to result in a high risk to individuals. Large-scale processing of special-category data, or systematic monitoring, are the usual triggers. Health, legal, and HR use cases often cross the line.
- Screen the use case against the Art. 35 criteria and your supervisory authority's list.
- If a DPIA is needed, run it before deployment, not after.
- Document the risks, the mitigations, and the residual risk you are accepting.
- Review the DPIA when the use case or the tool materially changes.
For a legal or medical use case specifically, the professional-secrecy duties stack on top of GDPR. Using a private, EU-hosted workspace with a full agreement chain helps reduce the risk associated with professional secrecy, but it does not remove your own duty of care.
7. Meet the EU AI Act competence duty (Art. 4)
New for 2026, and widely missed. Art. 4 of the EU AI Act requires providers and deployers of AI systems to ensure a sufficient level of AI literacy among the staff who operate them. This is a duty about people, not technology, and it applies even to low-risk tools.
- Confirm the staff using the tool understand what it does, its limits, and when to check its output.
- Provide brief, role-appropriate training and keep a record that you did.
- Set a rule that a human reviews and releases AI-generated documents before they go out.
- Revisit competence when you add new tools or new use cases.
The review-and-release rule matters in practice. Wysor's document generation drafts letters and reports from notes, and the Scribe turns speech into a structured note, but the user reviews and releases the output. That workflow supports the competence duty rather than working against it.
The short version
If you only keep one thing, keep this: a tool is GDPR-ready for your business when you can produce, on request, the legal basis, the signed DPA reaching the model provider, proof of EU processing, written no-training and zero-retention terms, an up-to-date processing record, a DPIA where the risk warrants it, and evidence that your people are competent to use it. Every item is a document or a verifiable fact, not a matter of trust.
Wysor is built to make that list short to satisfy: multi-model chat (Claude, GPT, Gemini and more) in one private, EU-hosted workspace, an AVV/DPA with each model provider, no training on customer data, and zero data retention, on a free plan, Plus at 19,99 EUR/mo, or Premium at 29,99 EUR/mo, with no enterprise contract required.
FAQ
Is any AI tool truly "GDPR-compliant" out of the box? No. Compliance is a property of how you deploy a tool, not a badge the tool carries. The same product can be compliant in one setup and not in another depending on your legal basis, agreements, and configuration. Treat every vendor claim, including Wysor's, as something to verify against current documentation.
Do I need a DPA if the tool "does not store my data"? Yes. A DPA under Art. 28 is required whenever a vendor processes personal data on your behalf, whether or not it retains that data afterward. Processing includes the moment your prompt is handled. Make sure the agreement chain reaches the model provider, not just the front-end tool.
When is a DPIA actually mandatory? When the processing is likely to result in a high risk to individuals, for example large-scale processing of special-category data such as health information, or systematic monitoring. Screen against Art. 35 and your supervisory authority's published list. When in doubt, running one is cheaper than defending the decision not to.
What is the EU AI Act Art. 4 competence duty, in plain terms? It requires that the people operating an AI system have a sufficient level of AI literacy: they understand what it does, where it fails, and when to check its output. Brief role-appropriate training and a documented human review step usually satisfy it for everyday business tools.
Does EU hosting alone make me compliant? No, but it removes a large category of work. EU processing avoids the Chapter V transfer obligations that non-EU processing triggers. You still need the legal basis, the DPA, the records, and, where relevant, the DPIA. Confirm that model inference runs in the EU, not only that the app is EU-hosted.
