Do AI deployments usually need one?

They frequently land in the territory it exists for, though whether one is strictly required is a legal judgement on your particular facts. The practical answer is often to do it regardless, because the questions are ones a careful buyer wants answered anyway.

What makes one actually useful rather than performative?

Being written before the design is settled, and having a residual risk section that actually says something. Those two properties are what separate an exercise that changes what gets built from a file that accurately describes what was always going to happen anyway.

When should it be revisited?

When the deployment reaches further than it did, which for AI tools happens quietly. A new connected system or a new use of the output changes what was assessed, and an assessment nobody returns to becomes a record of an arrangement that has moved on.

Glossary

Data protection impact assessment (DPIA)

A structured assessment of privacy risk carried out before higher-risk processing begins, rather than written up once it already has.

In plain terms

Thinking through what could go wrong for the people whose data this is, before you start rather than afterwards. Done in that order it changes the design; done in the other order it produces a file, and the two are hard to tell apart by looking at the file.

Why it matters

Because AI deployments frequently land in exactly the territory this exists for, and they arrive as product decisions rather than processing decisions. A tool reaching across systems, analysing material about people, or informing something that affects them is the shape the requirement was written around, and nothing in a normal purchase process raises it.

How it works

It is done in advance, and that ordering is the requirement rather than a preference. The point is to change what gets built while changing it is still cheap, so an assessment written after deployment has satisfied the form and missed the entire mechanism.

It works by forcing specific questions to have owners and answers. What material is involved, who is affected, what could go wrong for them, what reduces that, and what remains: each has to be written by somebody, which is a very different exercise from a general intention to be careful.

The residual risk section is the one that does work. Naming what remains after mitigation is uncomfortable, which is why it tends to be thin, and it is also the only part that lets somebody senior accept a risk knowingly rather than approving a document that implies there is none.

It is a live document rather than an artefact. A deployment that later reaches further, or feeds a new tool, has changed the thing the assessment described, and an assessment nobody revisits gradually becomes a record of a system that no longer exists.

Whether one is strictly required is a legal judgement and the practical answer is frequently to do it anyway. The questions are the ones a careful buyer would want answered regardless, so the exercise earns its cost even where the obligation is uncertain.

Who writes it changes what it finds, which is worth deciding rather than defaulting. Drafted entirely by the team that wants the deployment, it tends to describe risks that are already mitigated; drafted with somebody who has no stake in the project proceeding, it surfaces the ones nobody had reason to raise.

The same document, two orders

The reason the second column is so common is that it is genuinely easier and does not feel like a compromise. By the time somebody thinks to write the assessment, the deployment has been designed, the risks are therefore known rather than speculative, and describing known risks accurately is a straightforward task that produces a better-written document than the speculative version would have been. Nobody has cut a corner; the exercise has simply lost its only mechanism, which was the ability to change something. That also explains why the residual section thins out in the second column: naming what remains is only comfortable when somebody still has the option of doing something about it, and once the system is running the honest entries read as admissions rather than decisions. For AI deployments the practical trigger is worth stating simply, because the requirement's own language will not prompt anybody in a product meeting: if the tool will hold, reach or produce material about identifiable people, the assessment belongs before the configuration rather than before the launch.

Seen in the wild

Working through what an assistant deployment exposes before staff begin pasting customer material into it.
ChatGPT
Assessing a search deployment that makes material about people reachable from one box.
Glean
Revisiting an assessment after an automation started feeding a system nobody described originally.
Make

Common misconceptions

People assume

It is paperwork to be completed before launch.

In fact

It is a design exercise whose output happens to be a document. Completed after the design is settled it changes nothing, which is the whole difference between satisfying the requirement and doing the thing the requirement asks for.

People assume

A completed one means the deployment is safe.

In fact

It means the risks were considered and somebody accepted what remained. That is a genuine and limited claim, and a deployment can be fully assessed and still carry risk that was named, weighed and knowingly taken.

Questions

Do AI deployments usually need one?: They frequently land in the territory it exists for, though whether one is strictly required is a legal judgement on your particular facts. The practical answer is often to do it regardless, because the questions are ones a careful buyer wants answered anyway.
What makes one actually useful rather than performative?: Being written before the design is settled, and having a residual risk section that actually says something. Those two properties are what separate an exercise that changes what gets built from a file that accurately describes what was always going to happen anyway.
When should it be revisited?: When the deployment reaches further than it did, which for AI tools happens quietly. A new connected system or a new use of the output changes what was assessed, and an assessment nobody returns to becomes a record of an arrangement that has moved on.