Nobody sets out to break data protection law with an AI feature. It happens in the plumbing — in places that look like implementation detail and are actually processing decisions.
What follows is the engineering map, not legal advice. Your DPO owns the assessment; these are the places where the software makes the assessment harder or easier.
Personal data goes into prompts
The most common one, and the least visible.
To make an answer useful you give the model context: the customer's account, their history, the ticket. That is personal data, and sending it to a model provider is processing it — with all that follows about lawful basis, purpose limitation and international transfer.
The quiet part is that it is rarely deliberate. Someone adds a field to improve answer quality, which is a good engineering instinct, and the scope of what leaves your systems changes without anyone recording that it did.
The control is unglamorous: know exactly what goes into a prompt, keep it to what the answer needs, and treat any change to that set as a change to your processing rather than a tweak.
Data accumulates in logs
Logging is how you debug and how you meet the evidence obligations above. It is also how personal data ends up in six places nobody is thinking about: application logs, model provider logs, error tracking, analytics, backups, and whatever the observability tool retains.
Each has its own retention, its own access list, and its own geography. A retention policy that says ninety days is a statement about the database, not about the error tracker that kept the full request payload.
Then a deletion request arrives. Erasure means everywhere, and "everywhere" turns out to be a list nobody has written down.
Retention has no natural stopping point
Storage is cheap and deleting things feels like losing something. So conversation histories, embeddings and audit records accumulate indefinitely because nobody chose an end date.
Two specifics worth knowing. Embeddings — the numeric representations used to make search work — are derived from your source text and are not anonymous simply because they are unreadable to a human. And a model provider's own retention window applies to what you sent them, independently of your policy.
Article 32 in engineering terms
The security obligation asks for measures appropriate to the risk. Translated:
Access control that survives a mistake. Rules in the database itself, not only in the application, so that one bad query does not return everyone's records. This is the row-level security question, and it is the single highest-consequence one.
Encryption in transit and at rest, which is largely a solved problem and worth confirming rather than assuming.
The ability to restore. Backups that have been tested by restoring them. Untested backups are a belief.
The ability to detect. If someone accessed data they should not have, would anything have recorded it?
Automated decisions
If an AI feature makes or materially shapes a decision about someone — credit, eligibility, pricing, prioritisation — there are additional obligations around transparency and human involvement.
The engineering consequence is that "the model decided" cannot be the whole story. You need the inputs, the version, the output and the record of any human step, which is the same evidence layer the previous section described. Build it once and it serves both purposes.
The map
Draw the data flow for one AI feature: where personal data enters, everywhere it travels, everywhere it rests, how long each place keeps it, and who can read each one.
Most teams have never drawn this, and drawing it takes an afternoon. It is usually the afternoon that finds the problem. For regulated and compliance-heavy firms we design that flow deliberately from the start; where it already exists and nobody has mapped it, a Reality Check maps it in a week.
This is the part we do — the crossing from a demo to a system that survives production.