What Is a Data Protection Impact Assessment? DPIA Explained

Impact assessments are valuable when they happen before design decisions are locked and worthless when they are written afterwards to satisfy a process. For AI systems they also need to ask questions that conventional privacy assessments were not built for, which is why templates designed around databases produce assessments that miss the actual risks. This explainer covers both problems. It complements ai privacy impact assessment checklist and what is data residency, and reflects FISTA Solutions' approach in AI enablement delivery. This article is general guidance, not legal advice.

When is one required?

Typically when processing is large scale, involves automated decision-making with significant effects on people, uses new technology, involves systematic monitoring, or handles sensitive categories of data.

AI deployments frequently satisfy several of these at once. That makes the assessment a normal part of the design process rather than an exception triggered by unusual projects, and organisations that treat it as exceptional tend to skip it for systems that needed it.

Trigger	Typical AI relevance
Large-scale processing	Very common
Automated decisions with legal effect	Common in eligibility and screening
New technology	Generally applicable
Systematic monitoring	Common in operations and support
Sensitive categories	Common in health, HR, finance
Vulnerable individuals	Common in public services

What must it cover?

The processing and its purpose, whether it is necessary and proportionate to that purpose, the risks to individuals, and the measures that address them. That structure is standard.

What differs for AI is the content: training data provenance, what flows to a model at inference, what is retained in logs and traces, how deletion is honoured, and what inference risks the model itself carries.

What do conventional templates miss?

Training data provenance, first. Where did the data come from, on what basis, and does its use for training fall within that basis. Many organisations cannot answer this for models they have already fine-tuned.

Then the extraction risks — model inversion and membership inference — which have no analogue in database processing. Then residency, because inference is processing. Then derived data in vector indexes. Then observability, which captures full inputs and outputs and is almost never assessed. See what is model inversion.

Why are deletion rights harder here?

Because training distributes data through model weights rather than storing it as records. A deletion request cannot be satisfied by removing a row; it requires retraining or an argument about why the model does not contain the person's data in a retrievable sense.

That difficulty is a strong argument for architectures that keep personal data in retrieval rather than in training, and the assessment is where that choice should be examined — before the training run, not after the request arrives.

How is it kept useful?

By running it early enough to change the design. An assessment that identifies a residency problem before regions are chosen saves a rebuild; the same finding after launch produces an exception register entry.

The other discipline is proportionality: a short focused assessment on a genuinely low-risk system, and a substantial one where the risks are real. Uniform depth produces either wasted effort or insufficient scrutiny, usually both in different places.

When should it be revisited?

On material change: new data categories, a new purpose, a model change that alters what is processed, a new jurisdiction, or a shift from assisting a human decision to making one. That last change is the most consequential and the most likely to happen gradually without anyone marking it.

What should you do first?

Check whether your existing AI systems have assessments and whether those assessments mention training data, vector indexes, or traces. Where they do not, the assessment was written against a template that did not fit, and the gaps it missed are still there.

Who should be involved?

The people who will build it, the data protection function, and someone who understands the business purpose well enough to argue about necessity. An assessment written by compliance alone describes what the system is supposed to do; one written by engineering alone misses the legal questions.

The most useful conversations in these assessments are usually about proportionality — whether the purpose genuinely requires the data being proposed — and those need a business voice in the room rather than a form to fill in.

What makes an assessment credible later?

Evidence that alternatives were considered and that the mitigations described were actually implemented. An assessment listing controls that never shipped is worse than none, because it demonstrates that the organisation knew the risk and did not address it.

Linking each stated mitigation to where it lives in the system, and checking those at launch, is what converts the document from an intention into a record.

How FISTA Solutions helps

FISTA Solutions runs privacy assessments early enough to change architecture, covers AI-specific questions including training provenance, extraction risk, derived data, and observability capture, and designs for deletion by keeping personal data in retrieval rather than in weights, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies across 12+ countries.

To assess AI privacy risk against the right questions, message FISTA on WhatsApp, or read ai privacy impact assessment checklist.