Most AI risk registers fail in one of two directions. Either they are a data-protection document that never mentions model behaviour, or they are an engineering document full of drift metrics that a DPO cannot map to a legal obligation. The result is two teams maintaining two artefacts describing the same system, neither of which is complete.
One register can serve both, provided it is structured around a shared unit: the specific harm, to a specific person, from a specific system, with a named owner and evidence that a control exists.
Why the two audiences diverge
A DPO reasons in terms of obligations: lawful basis, data-subject rights, necessity and proportionality, transfer mechanisms, and — under the EU AI Act — risk classification and the duties that attach to it. An internal auditor reasons in terms of control effectiveness: does a control exist, is it operating, and where is the evidence.
Engineers reason in terms of failure modes: hallucination rates, retrieval quality, prompt injection, drift, latency. These are not competing views; they are the same risk described at different altitudes. The register's job is to hold all three in one row.
The row structure
One row per risk, per system. Fields that earn their place:
| Field | Serves | Note |
|---|---|---|
| System and purpose | All | The specific deployment, not "AI". Purpose drives AI Act classification. |
| AI Act risk class | DPO | Prohibited / high-risk / limited / minimal, with the reasoning. |
| Personal data categories | DPO | Include inputs, outputs, prompts, logs and embeddings. |
| Lawful basis | DPO | Plus the Art. 22 position on automated decision-making. |
| Harm description | All | Concrete: who is harmed and how. Not "model inaccuracy". |
| Likelihood / impact | Auditor | Use the organisation's existing scale. Do not invent a new one. |
| Controls | Auditor | Preventive and detective, stated separately. |
| Evidence | Auditor | A link to an artefact — eval run, log query, sign-off — not a claim. |
| Owner | All | A named person. Not a team, not a function. |
| Residual risk and acceptance | All | Who accepted it, when, and until when. |
The discipline that makes it work: every control cites evidence that can be produced on demand. A control without a retrievable artefact is an intention.
Describe harms, not model properties
"The model may hallucinate" is not a risk entry. It has no subject, no consequence, and no threshold. Compare:
Weak: The model may produce inaccurate output.
Usable: The claims assistant may summarise a policy exclusion incorrectly, causing a valid claim to be declined. Affects claimants. Detected by sampled review of declines; prevented by requiring adviser confirmation before any decline is issued. Evidence: weekly sampling report, decline-confirmation audit log.
The second version is simultaneously a GDPR fairness concern, an AI Act high-risk consideration, and an operational control an auditor can test. That is the whole trick — one description, three readings.
Risks worth having on every AI register
- Incorrect output acted on automatically. The core harm in most deployments. Control: policy-driven human review thresholds.
- Unlawful or excessive personal data in prompts. Users paste more than they should. Control: input classification, redaction at the boundary, retention limits.
- Prompt injection via retrieved content. Untrusted documents instructing the model. Control: privilege separation, output constraints, no unattended action on retrieved instructions.
- Training or inference on data without a basis. Control: contractual no-training terms, verified in the provider agreement.
- Third-country access to plaintext. Control: flow-level residency and key custody decisions, documented in a transfer impact assessment.
- Silent quality drift. Provider updates a model behind a stable endpoint. Control: pinned versions, continuous sampled scoring, alerting.
- Discriminatory outcomes across protected groups. Control: segmented evaluation, not just aggregate accuracy.
- Inability to explain a decision. Directly implicates data-subject rights. Control: decision logging with retrieved context retained.
Keeping it current
A register reviewed annually is a historical document. Tie updates to events that already happen:
- Model or prompt version change — re-check the affected rows before release.
- New data category or new user population — re-assess the classification.
- Eval score crossing a threshold — raises or reopens a row automatically.
- Incident — the post-mortem updates the register as a matter of course.
Where possible, generate the volatile fields from systems rather than maintaining them by hand. Current eval scores, model version, and retention settings can all be pulled. Hand-maintained numbers go stale within a quarter, and a stale register is worse than none because it manufactures false assurance.
Common questions
Is this the same as a DPIA?
No, but they share inputs. A DPIA is a point-in-time assessment for a specific processing operation under GDPR Article 35. The register is a living inventory across systems. A well-maintained register makes each new DPIA substantially faster to produce.
How does the EU AI Act change what we record?
It adds an explicit classification step and, for high-risk systems, duties around risk management, data governance, logging, human oversight, accuracy and robustness. Practically, it means recording purpose precisely, since classification follows use rather than technology. Obligations phase in through 2026 and 2027, so recording your class and reasoning now is cheap insurance.
Who should own the register?
Second line — risk or compliance — should own the structure and the review cadence. Engineering owns the evidence. Splitting it the other way produces either an unmaintained document or one nobody can audit.
How granular should systems be?
One entry per deployed use case, not per model. The same model serving two workflows carries different risks in each, because purpose and population differ.
The short version
Write harms, not model properties. Give every control a retrievable artefact. Record the AI Act class and the reasoning behind it. Regenerate the volatile fields automatically, and hang updates off events that already occur. Do that and one register serves the DPO, the auditor, and the engineers — which is the only version anyone actually maintains.