GDPR Architecture Wizard
Which data protection architecture fits your AI project?
Answer six short questions about your AI project. The wizard shows a concrete architecture recommendation (e.g. EU cloud is enough vs. on-premise recommended) plus additional guidance on automated decisions, impact assessments, and the EU AI Act provider trap – derived from our own researched articles on GDPR and the EU AI Act.
The GDPR Architecture Wizard derives a concrete data protection architecture recommendation plus additional GDPR and EU AI Act guidance for an AI project from six inputs on data sensitivity, provider location, automated decisions, processing scale, and role.
Your project
Your assessment
Architecture recommendation
A US provider is possible, but needs extra safeguards
A US provider without an EU region is currently usable via the EU-US Data Privacy Framework (DPF), but it's less robust: actively check the provider's DPF certification status, sign a data processing agreement – and have a plan B in case this legal basis ends up in court like Safe Harbor and Privacy Shield before it.
Additional guidance
None of the additional questions triggered further guidance.
Regardless of the result: the AI literacy duty already applies
Art. 4 of the EU AI Act has required every company using AI to ensure sufficient AI literacy among staff since February 2, 2025 – regardless of risk or role, enforceable from August 3, 2026. A structured internal training is enough, but it's frequently overlooked.
Want to carry these architecture questions straight into a project?
How this wizard works
- The architecture recommendation follows from data sensitivity × provider location: uncritical data barely needs architectural safeguards, sensitive data points toward self-hosted models, normal data allows cloud solutions with the right safeguards.
- The GDPR guidance (Art. 22, DPIA) is derived directly from our article "GDPR and AI" – including the CJEU SCHUFA ruling on automated decisions.
- The two EU AI Act items (provider trap, transparency duty) plus the always-shown AI literacy duty are derived directly from our article "The EU AI Act".
- All guidance is shown independently of the architecture recommendation – a self-hosted model, for example, does not exempt you from the DPIA duty for extensive processing.
This wizard does not replace legal advice. It offers an orientation based on publicly documented core principles of GDPR and the EU AI Act – the concrete assessment always depends on the individual case and should be reviewed with a lawyer or data protection officer, especially on the points flagged here (Art. 22, DPIA, provider role).
Frequently asked questions about the wizard
Does this wizard replace a legal review?
No. The wizard offers a well-grounded first orientation based on publicly documented GDPR and EU AI Act principles, but it is not legal advice. For automated decisions (Art. 22), the DPIA duty, or the provider role under the EU AI Act, the concrete implementation should always be reviewed by a lawyer – it depends on the individual case.
Why not a 0–100 score like your other check tools?
Because data protection architecture isn't a scale from bad to good, but a choice between different architectures that each fit a different situation. A single score would suggest there's one "best" answer for everyone – in reality, the right architecture depends on data sensitivity and the chosen provider. Hence a decision tree instead of a score.
Where do the legal statements in this tool come from?
From our two own, researched insights articles "GDPR and AI" and "The EU AI Act" – including primary sources like the CJEU SCHUFA ruling (C-634/21) and EDPB opinions. None of the statements shown here are newly invented; the full reasoning, including sources, is in the two articles.
What do I do with the result?
Use it as a checklist for a conversation with your data protection officer or lawyer, or as a starting point for an architecture discussion with us if you're building a custom application. If the wizard shows several flags at once (e.g. sensitive data plus the provider trap), that conversation is especially worth having early in the project.