Article 25 of the GDPR asks for data protection "by design and by default." It is one of those phrases that sounds like a poster in an office kitchen until you try to build a real AI system and discover that the poster was describing a set of engineering decisions you already got wrong. This paper is about making those decisions on purpose.

The principles that bite hardest

A working language-model deployment collides with a handful of GDPR principles more than the rest. Purpose limitation and data minimisation, from Article 5, are in constant tension with the machine-learning instinct to hoard data because it might be useful. Lawful basis, from Article 6, has to be settled before you process a single record, and for most internal tools that means a documented legitimate-interest assessment. Special-category data, from Article 9, is the landmine: health, biometric, political and similar data is prohibited to process unless a specific exception applies, and it has a way of turning up in document sets nobody screened.

None of this is exotic. It is the ordinary GDPR you already know, applied to a system that happens to read everything you feed it and remember more than you expect.

The erasure problem is real, and most vendors are vague about it

Article 17, the right to be forgotten, is where AI architecture stops being a formality. Deleting a person's record from a database is a solved problem. Deleting their data from a model that was trained on it, or from the vector embeddings a retrieval system built out of their documents, is not. The information is smeared across weights and numbers in a way you cannot simply drop a row from.

When you ask any AI vendor how erasure works, listen for specifics. What happens to the embeddings derived from a deleted document? How long until it ages out of backups? Does a fine-tuned model retain it? If the answer is a shrug or a slogan, the erasure story is not real. The EDPB's Opinion 28/2024 makes clear this is not a theoretical worry: the Board stated that a model trained on personal data cannot, in every case, be assumed anonymous, and that anonymity has to be assessed rather than declared.

A practical erasure test for any AI system you are evaluating. Delete a document, then ask the system a question that only that document could answer. If it still answers, the data was not really erased, it was merely hidden from the file list. A defensible design propagates deletion through conversations, documents, embeddings, any fine-tunes and backups, and logs that it did.

Why architecture, not paperwork, decides this

You can write the finest data protection impact assessment in the world, as Article 35 often requires for high-risk AI, and it will not save you if the underlying system cannot honour a deletion request or keeps sending personal data somewhere it should not go. The document describes the system. It does not fix it.

This is the quiet argument for building the boundary in early. When the model, the index and the logs all sit inside your own network, the mitigations section of your DPIA gets dramatically shorter, because whole categories of risk are absent rather than managed. No third-party processor for the inference step. No international transfer to assess against the shifting backdrop of adequacy decisions. No sub-processor chain that changes when a vendor signs a new supplier. The EDPB's guidance spends pages on how to handle these risks in a cloud setting. Removing the cloud from the sensitive path removes the pages.

A design checklist worth keeping

If you take one thing from this paper, make it a set of questions to ask at design time rather than audit time. Where does personal data physically go when a prompt is submitted? Who, human or corporate, can technically read it along the way? Can a deletion request be honoured completely and demonstrably? Is special-category data filtered before it reaches the model? Is there an immutable log of what the system did with whom? A deployment that can answer those cleanly is one where by-design was more than a slogan.

This paper is general information, not legal advice. The GDPR interacts with the AI Act, sector law and national rules in ways your data protection officer and counsel need to map for your circumstances. The engineering point stands on its own, though. Compliance you can prove starts with architecture you chose deliberately.