GDPR-compliant AI: what changes in the architecture
GDPR-compliant AI can be built. We build it in France, for clients whose legal teams read everything, and the workable systems share one trait: compliance was an architecture input from day one instead of a review at the end. The regulation did not change for AI. What changed is where your data now flows: into prompts, logs, embeddings and third-party model providers, places your existing compliance map has never heard of.
Most "is AI even legal under GDPR" anxiety dissolves once you list the concrete obligations. Five do most of the work in practice: a lawful basis for the processing, a proper contract with your model provider, minimization in what you send and store, deletion that reaches every copy, and residency you can prove. Each one translates directly into design decisions.
GDPR-compliant AI starts with the provider paperwork
Your model provider processes personal data on your behalf, which makes it a processor under Article 28 and makes a data processing agreement mandatory. The points to nail down: a contractual commitment that your data is not used to train models (the enterprise tiers of the major providers offer this; consumer tiers generally do not), the location of processing, the sub-processor list, retention of your inputs, and breach notification. A provider that cannot answer clearly on these points is out, however good the model. This is also the moment to update your records of processing and, for anything touching sensitive data at scale, to run the impact assessment your DPO will ask about anyway.
Prompts and logs are personal data too
Teams secure their database meticulously, then send its contents to a model wrapped in a prompt, logged in full, retained indefinitely. Minimization applies: send the fields the task needs, not the whole customer record. Where the task allows it, pseudonymize identifiers before the model call and rejoin them after. And put a retention policy on your application logs, because the classic leak we find is a debug log that has quietly stored every prompt, in full, since launch. Logs you keep for quality monitoring deserve the same access controls as the source systems they mirror.
Deletion has to reach the embeddings
The right to erasure is where AI architectures quietly fail. When a customer’s data is deleted from the CRM, copies live on: in the vector store that powers retrieval, in caches, in evaluation sets, in exported training files someone built for an experiment. A compliant system keeps the mapping from each source record to every derived artifact, so that one deletion cascades everywhere. Retrofitting that mapping later is miserable; building it in takes about a week. The risk is concrete: deletion that does not delete is one of the recurring findings when GDPR gaps surface in due diligence after a deal closes, and remediation at that point is measured in months.
Residency you can prove
If your contracts or your sector require EU processing, the architecture must make it true end to end: model inference, vector store, logs, backups, monitoring. The options have improved: EU-region processing from major providers, European providers under EU jurisdiction, or open-weight models on your own infrastructure where the requirement is strict, a range of options we compare in self-hosted models versus APIs. What matters for GDPR is that the claim and the infrastructure match. "Our data stays in Europe" while telemetry streams to a US-hosted analytics tool is the kind of gap that surfaces at the worst moment, usually in a client’s security review.
Access control is a GDPR feature as much as a security one
An internal assistant that answers from documents the user has no right to open is a data protection failure with a friendly interface. Purpose limitation and confidentiality require the retrieval layer to enforce the same permissions as the source systems, per query and per user. This is entirely feasible and entirely unforgiving of shortcuts, and it is one of the requirements that separate a serious build from a demo, as we detail in what it takes to build an assistant on company knowledge.
None of the above stops a project. In our experience it adds days to a well-run build, not months, and it turns your DPO from a blocker into a sponsor, because for once the compliance requirements were in the design review instead of arriving after it. If you want an AI system your legal team can sign off on without heroics, that is how we run every custom AI build: with the data flows mapped on the first whiteboard.