Policy, Decision Rights, and the AI Risk Register

An AI policy is often asked to carry the whole framework. It cannot, and understanding its actual job prevents writing a long document that changes nothing.

A policy does three things well. It states which uses are permitted, prohibited, and conditional. It tells people where to go for a decision. And it establishes that someone in the organisation has thought about this, which matters both internally and to an auditor.

It does none of the following. It does not find systems, which is the inventory's job. It does not classify them. It does not make anyone competent. And it does not stop a determined person doing something unwise, particularly if the approved route is slower than the unapproved one.

The most common failure is a policy written as aspiration: we will use AI ethically, responsibly and transparently. Nobody can act on it and nobody can breach it, which makes it unfalsifiable and therefore useless as a control.

The test for every clause: could an employee tell, on Tuesday, whether they are complying with this? If not, rewrite it or delete it.

The core of a usable policy is three explicit lists, written in terms of activities rather than technologies.

Permitted without approval. Drafting internal documents, summarising material you already have access to, generating code in a sandbox, brainstorming. Being generous here is what keeps people inside the policy, and an over-restrictive green list produces shadow use rather than caution.

Prohibited outright. Entering personal data, customer data, credentials or unreleased material into non-approved external tools. Using AI output as the sole basis for a decision about a person's employment, credit, access to services or education. Emotion inference applied to staff or students, which is a prohibited practice under the AI Act rather than a policy preference. Presenting generated content as human-authored where disclosure is required.

Conditional, requiring approval. Anything customer-facing, anything that automates a decision, anything processing personal data at scale, anything a supplier will use to make decisions on your behalf, and any new AI tool entering the organisation.

Anchor each prohibition to its reason. A rule with a stated reason survives an edge case, because someone can reason from it. A bare prohibition gets routed around the moment it is inconvenient.

Most governance friction is not disagreement about the answer. It is that nobody knows who gets to give it.

RACI is the ordinary tool: for each decision, who is Responsible for doing the work, Accountable for the outcome and able to say yes, Consulted before the decision, and Informed after it. Applied to AI, the decisions worth mapping are few and specific.

Approving a new AI tool into the organisation.

Classifying a system's risk tier, and approving reliance on the Article 6(3) derogation.

Approving a system that makes or materially influences decisions about individuals.

Accepting a residual risk that has been identified and not fully mitigated.

Suspending a system in production.

Approving a substantial modification, which can change both the classification and the grandfathering position.

One rule prevents the usual pathology: exactly one Accountable per decision. Two accountable parties is the same as none, and it is how decisions end up escalating to whoever is most senior rather than whoever is best placed.

A further rule worth stating: the accountable party for deploying a system should not be the same person whose targets the system helps hit. That is not a suspicion of bad faith, it is ordinary control design.

New systems should arrive through one door, and the door should be fast for the common case or people will use the window.

A request arrives. The first question is whether the intended use touches individuals or a regulated decision. Where it does not, and no personal data is involved, a lightweight approval by the function owner is enough, with an inventory entry created automatically.

Where it does, the request routes into classification. Anything landing in an Annex III area, or relying on the derogation, goes to the accountable party for that decision with legal input.

The controls attach at the end, proportionate to what the classification found, and the inventory entry is created either way.

The design principle is that the burden should track the consequence. A gate that treats a transcription tool and a credit-scoring model identically will be resented in the first case and rushed in the second.

A generic risk register with AI written at the top misses what is distinctive about these systems. Eight risks that do not appear in ordinary software registers.

Performance disparity: the system works well on average and badly for a subgroup, which averages hide.

Drift: accuracy degrades as the world moves away from the training distribution, silently and without an error.

Automation bias: the human reviewer defers to the system, so the oversight control that mitigates every other risk quietly stops working.

Confident fabrication: generative systems produce fluent, plausible, wrong output, and fluency carries no signal about accuracy.

Provider change: the vendor updates the model and behaviour shifts without a deployment on your side.

Data leakage: input sent to an external system leaves your boundary, and may be retained or used for training.

Proxy discrimination: a variable correlated with a protected characteristic reproduces the effect of using it directly.

Unexplainability: you cannot tell an affected person why, which is both a fairness problem and, in some contexts, a legal one.

The first three are the ones that compound, because each of them degrades your ability to notice the others.

Risk registers accumulate colour-coded scores that nobody acts on. Three practices keep the exercise honest.

Assess against a concrete failure, not a category. Not the risk of bias but this system ranks candidates over fifty lower and we have not checked. A named failure can be tested; a category can only be scored.

Record who bears the harm. Most risk registers implicitly score harm to the organisation, which systematically underweights risks whose cost falls on customers, applicants or the public. Add a column for it, because the AI Act's concern is fundamental rights of natural persons, not corporate exposure, and a register that only tracks the latter will not surface what a regulator asks about.

Make every mitigation testable. A human reviews the output is not a mitigation; it is a hope. A mitigation states who reviews, against what criteria, with what override authority, and how you would know if they stopped doing it meaningfully. The override rate is the natural indicator: a reviewer who overrides nothing over months is either working with a perfect system or not reviewing.

And record accepted risks explicitly, with the name of whoever accepted them. An unmitigated risk that someone consciously accepted is a governance decision. The same risk unrecorded is an oversight failure, and the difference is entirely in the documentation.

Human oversight is the mitigation most frequently written down and least frequently designed, and the AI Act treats it as a requirement rather than a gesture. Article 14 requires high-risk systems to be built so they can be effectively overseen, and Article 26 requires deployers to assign oversight to people with the necessary competence, training and authority.

Four conditions have to hold, and failing any one makes the control decorative.

Capability: the reviewer can actually tell whether the output is right, which requires domain expertise the system does not supply, plus enough information about how the system reached its answer.

Authority: overriding is permitted and not career-limiting. If disagreeing with the model requires justifying yourself and agreeing does not, the control is asymmetric by design.

Time: the throughput expectation allows genuine review. Assigning oversight of four hundred decisions a day to one person is a decision not to have oversight.

Incentive: the reviewer is not measured on throughput alone, since that measures agreement with the system.

Instrument this. Track the override rate, sample overridden and non-overridden decisions, and treat a rate near zero as a finding rather than a success.

Governance is tested when something goes wrong, and the arrangements that hold are the ones decided in advance.

Define what counts as an AI incident before you have one. A system produced output that caused or could have caused harm; a system was used outside its approved purpose; a provider disclosed a material change or defect; personal data reached a system it should not have; a system's performance degraded materially; or an affected person challenged a decision.

Set a route that works at eleven at night: who is called, who can suspend a system, and what happens if the owner is unreachable. Name the fallback, because incidents do not respect availability.

Know the reporting obligations in advance. Providers of high-risk systems must report serious incidents to market surveillance authorities within defined timeframes, and where personal data is involved the GDPR breach clock may run in parallel on its own, shorter schedule. Working out which regime applies during an incident is how deadlines get missed.

And run the postmortem into the register. An incident that does not change a control, a classification or a training module has been survived rather than learned from.

Many frameworks create an AI governance committee as their first act. Sometimes this helps and often it becomes the place decisions go to wait.

A committee is the right instrument for a narrow set of things: approving the framework itself, deciding genuinely contested cases where reasonable people disagree, accepting significant residual risk on behalf of the organisation, and reviewing the aggregate picture periodically.

It is the wrong instrument for routine approvals. If every new tool requires a monthly meeting, the effective policy is that nobody adopts tools through the official route.

The arrangement that works is delegated authority with escalation: named individuals hold decision rights for defined categories, and the committee sees the exceptions plus a standing report. That keeps the common path fast and reserves collective attention for cases that need it.

Composition matters more than size. The functions that have to be present are the business owner of the affected decision, someone who understands the technology, someone who understands the legal position, and someone who represents the interests of the people the systems are used on. That last seat is the one usually missing, and its absence is why frameworks tend to optimise for organisational exposure rather than for the fundamental rights the Act is concerned with.

Everything above scales down. For a small organisation the whole layer is a few pages and a handful of named people.

The policy is two pages with the three lists.

Decision rights are a short table, and one person may hold several roles, provided the separation between deploying a system and benefiting from it is preserved where it matters.

The risk register covers only the systems that touch individuals. Systems assessed as minimal risk get an inventory entry and nothing more.

The committee is a standing item in an existing management meeting, not a new forum.

The escalation route is two names and a phone number.

What does not scale down is the recording. A small organisation can make decisions in a conversation, but the reasoning still has to be written somewhere, because the person who will need it has not joined yet. That is the same conclusion the inventory reached, and it is the through-line of this whole cursus: the artefacts are lightweight, and the discipline of writing down why is not optional at any size.