Do you need a DPIA before deploying AI?

Almost always yes when personal data is involved. Article 35 of the UK GDPR and the EU GDPR requires a data protection impact assessment where processing is likely to result in a high risk to individuals, particularly where new technologies are used, and the ICO's AI guidance is blunt that AI deployments will meet that threshold in the vast majority of cases. The practical question is therefore not whether a DPIA is needed but whether one can honestly be completed for the deployment being proposed.

The question matters in 2026 because AI is moving at speed into HR, customer service, casework and clinical and legal support, all of which run on personal data. When something goes wrong, the DPIA is the first document a regulator asks for, and its absence is a finding in itself.

When does the law require a DPIA?

Before processing begins, whenever the processing is likely to result in a high risk to the rights and freedoms of individuals, particularly where new technologies are involved. That is the Article 35 test in both UK GDPR and EU GDPR. The assessment must describe the processing, judge its necessity and proportionality, assess the risks to the people whose data is involved and set out the mitigations. It is a decision record rather than a form: it exists so the organisation can show it understood the risk before it accepted it.

Why does AI almost always cross the threshold?

Because AI deployments stack the risk factors rather than presenting one. They are innovative technology, which Article 35 itself flags. They frequently involve profiling or evaluation of individuals. And they often touch special category data, sometimes by design and sometimes because staff paste in whatever the day's work contains. The ICO's AI guidance draws the blunt conclusion that AI deployments will trigger the requirement in the vast majority of cases, so the sensible operating assumption for any AI project handling personal data is that a DPIA is required, and the real work is doing it honestly.

What should an AI DPIA actually contain?

Four things separate a competent AI DPIA from a template exercise.

• The real data flows: where the prompt goes, where the embeddings live, what the vendor retains, for how long, and who can see it.
• Necessity and proportionality: whether the purpose could be achieved with less data, shorter retention or less exposure.
• The lawful basis for the processing, a question with enough depth to deserve its own analysis.
• Mitigations that change the risk, not mitigations that merely describe it.

The first item decides whether the rest can be written at all. A DPIA that cannot trace the data cannot assess the risk to it.

Why can a cloud AI DPIA rarely be completed honestly?

Because the data-flow section demands answers the deployer often cannot obtain. Where exactly does the prompt travel, which sub-processors touch it, what is retained for service improvement, who inside the vendor can access it, and what changes when the service updates its models. For a multi-tenant cloud service the honest answers are frequently unknown, contractually variable or impossible to verify. A DPIA whose data-flow section rests on vendor assurances is not an assessment of risk, it is a transfer of risk on paper, and the accountability for the processing stays with the controller regardless of what the assurance says.

What changes on operator-owned infrastructure?

The hardest section becomes the shortest. On a sovereign deployment the prompt goes to a machine the organisation owns, the embeddings live in a store the organisation controls, and the vendor retains nothing because nothing leaves. A zero-egress perimeter makes that claim checkable rather than contractual. On Mickai, a Sovereign Intelligence Operating System that runs offline on operator-owned hardware, the data-flow answer is short, stable and verifiable. That does not make the DPIA disappear, because necessity, proportionality and the risks of the processing itself still need honest work. It makes the DPIA completable, which for many cloud deployments it is not.

How do you evidence the DPIA after deployment?

A DPIA describes intended processing, and regulators ask about actual processing. The gap between the two is where organisations get hurt, because an assessment that no longer matches reality protects nobody. On operator-owned infrastructure every AI action can be sealed to an audit ledger, so the organisation can compare what the DPIA said against what the system actually did, and evidence the comparison. That also serves the review duty: a DPIA is a living document, revisited when the processing changes, and a sealed usage record is the cleanest way of knowing that it has.

“A DPIA that cannot say where the data goes is not an assessment, it is an assumption.”

How we keep the data-flow answer short enough to assess is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Do I need a DPIA before letting staff use ChatGPT at work?

Where staff will put personal data into the service, yes, and the assessment must cover what the service retains and who can access it. Many organisations complete this honestly by concluding that personal data should not enter the service at all, and scoping the permitted use accordingly.

Can I deploy the AI first and write the DPIA afterwards?

No. Article 35 requires the assessment before the processing begins, because its purpose is to shape the decision, not to document it. A retrofitted DPIA tells a regulator that the risk judgement was never made at the time it mattered.

Who should be involved in writing an AI DPIA?

The controller owns it, and where a data protection officer is appointed their advice must be sought. In practice a competent AI DPIA also needs the system owner, the security team and the business owner of the process, because the data-flow and mitigation sections cannot be written accurately from the privacy office alone.

What if the DPIA shows a high risk we cannot mitigate?

The GDPR requires consultation with the supervisory authority before processing where a high residual risk remains. In practice an unmitigable finding in the data-flow section is an architecture finding: if the risk is where the data goes, the mitigation is infrastructure the organisation controls, not more assurance wording.

Does the DPIA need redoing when the vendor changes the model?

A DPIA must be revisited when the processing changes materially, and a model change in a cloud service can alter behaviour, retention and sub-processing beneath an unchanged interface. Deployments that pin and control model versions on their own hardware change on their own schedule, which keeps the assessment stable.