Most organisations already run data protection impact assessments. The AI impact assessment is the same instrument pointed at a different object: instead of asking what happens to a person's data, it asks what happens to a person because of a system's output. Run them together where personal data is involved — the overlap is large and the reviewers are the same people.
Screen before you assess
A full assessment on every model is unsustainable and produces box-ticking. A short screening set filters most systems out in minutes:
- Does the output influence a decision about an identifiable person?
- Could a wrong output cause legal, financial, physical or reputational harm?
- Does it process personal data, special category data, or children's data?
- Is the system used in a domain the applicable regime treats as high risk?
- Can the affected person tell that AI was involved, and contest the outcome?
The sections that carry weight
- Purpose and necessity. What decision this improves, and what the alternative was. Assessments that skip this read as post-hoc justification.
- Data provenance. Where training and fine-tuning data came from, what lawful basis covers it, and what the licence permits.
- Performance and failure. Measured accuracy on the population it will serve, and what a failure looks like in production — not in the benchmark.
- Bias and disparate impact. Tested across the groups the system actually touches, with the test recorded.
- Explainability and contestability. What the affected person can be told, and how they challenge an outcome.
- Human oversight. Who reviews, what they see, what they can change, and whether they have the time to do it.
- Residual risk and sign-off. What remains, and who accepted it.
Make it a gate, not a form
The assessment has to sit at a point in the lifecycle where its findings can still change something — before procurement commits, before the model is embedded, before launch is announced. An assessment completed the week before go-live records a decision that was already made.
Keep it alive
Models drift, use cases expand, and vendors change their underlying models without asking. Re-assess on a trigger — a new use case, a material model update, a performance drop, a complaint — rather than on an annual cycle that will always lag the estate.