A surprising number of AI products ship without a Data Protection Impact Assessment (DPIA) or a Data Processing Agreement (DPA). The reason is almost never malice or recklessness. It is that someone — frequently legal counsel — looked at the regulatory text, decided the strict obligation did not clearly apply, and concluded the documents were optional. Technically, sometimes, they are right.
They are also, in our experience, making a mistake. Not a legal mistake — an engineering one. Because the DPIA and the DPA, treated correctly, are not compliance paperwork that happens to involve your system. They are design artifacts that force your team to answer questions you cannot afford to leave unanswered, and they do it before the answers are expensive to discover.
This is the argument we make to clients who have been told they can skip them: keep them, not for the regulator, but for yourselves.
The DPIA is a threat model wearing a compliance costume
Strip the legal framing from a Data Protection Impact Assessment and look at what it actually asks you to produce. It asks you to write down, explicitly:
- What personal data you collect, and why each field is necessary. This is data minimisation, enforced with a pen. Most teams discover fields they collect "just in case" that no feature actually uses.
- How that data flows — where it enters, where it travels, where it rests, who can touch it, and where it leaves. This is a data flow diagram. If you have ever tried to reason about privacy without one, you know it is like debugging without a stack trace.
- What could go wrong, and how badly. Re-identification, leakage, secondary use, model memorisation. This is a threat model, in the security sense, scoped to the people your system affects.
- What you will do about each risk, and who owns it. This is a mitigation register with accountability attached.
Read that list as an engineer rather than a lawyer and the disguise falls away. A DPIA is a structured threat-modelling exercise that produces exactly the artifacts a serious team should want before writing production code — and almost never produces on its own, because nothing forces the discipline. The regulation is just the thing that finally makes you sit down and do it.
For AI products this is sharper still, because your threat model includes failure modes that classical software does not have. A model can memorise and leak its training data. A retrieval pipeline can expose the contents of its index. "What could go wrong" is a longer and stranger list when the system learns. The DPIA is where you write that list down while you can still design around it.
The DPA is an interface contract for your data supply chain
The Data Processing Agreement gets dismissed even faster — it looks like boilerplate, a thing your vendors send and you sign. But consider what it actually pins down: for every party that touches personal data on your behalf, what they are allowed to do with it, what they must not do, how they protect it, how long they keep it, and what happens when the relationship ends.
That is not boilerplate. That is the interface contract for your data supply chain.
Modern AI products are assembled from other people's systems: a model API, a vector database, an annotation vendor, an analytics provider, a fine-tuning service. Each one is a party processing your users' data. Without a DPA, you have integrated a dependency with no specification — you do not actually know whether your inference provider trains on your prompts, how long your annotation vendor retains the data you sent them, or whether deletion on your side propagates to theirs.
A DPA forces those questions to have written answers. And the questions are exactly the ones an engineer integrating a third-party service should be asking anyway: what does this dependency do with what I give it, and what are its guarantees? The DPA is the place those guarantees become explicit and enforceable instead of assumed.
How to make both documents pull their weight
The failure mode is real: a DPIA can decay into a 40-page document nobody reads, and a DPA into a signed PDF nobody enforces. The fix is to treat them as living engineering artifacts, not one-time filings. The lightweight version we use with clients:
- Write the DPIA when you design the feature, not after. It is a threat-modelling session with a template, run while the design is still cheap to change. Its output is a data flow diagram and a risk register that live next to your architecture docs.
- Keep it short and specific. One page of real data flows beats forty pages of generic risk language. If a stated mitigation cannot be pointed at in the code or the infrastructure, it does not count.
- Make the DPA a checklist for every data-touching dependency. Before you integrate a vendor, you should be able to answer, in writing: what data they receive, whether they may train on it, their retention period, and how deletion propagates. No answers, no integration.
- Re-run both when the system changes materially. A new data source, a new model, a new processor — each is a trigger to revisit the assessment. The documents track reality or they are worthless.
Done this way, the DPIA and DPA stop being a tax and start being leverage. They surface the "just in case" data you can stop collecting, the vendor that quietly trains on your prompts, the retention window nobody set, the deletion path that does not actually delete. Every one of those is a privacy risk and an engineering defect, found on paper before it becomes an incident in production.
So when your lawyer says you can skip them, they may be answering the question they were asked: are we strictly required to? That is the wrong question. The right one is whether you can afford to ship a system whose data flows, risks, and dependencies have never been written down. For anything handling data that matters, the answer is no — regardless of what the statute compels.
Reseni Labs is an independent research lab working at the intersection of privacy engineering, security research, and AI governance. We help teams turn governance artifacts like DPIAs and DPAs into engineering tools that actually reduce risk. If you are building AI that handles data that matters, get in touch.