What actually belongs on the register?

Anything specific enough to own. A named system, the way it is used, the outcome that would be bad and the person answerable. General statements about the technology fail that test, which is why they never produce a decision. If a line cannot be assigned to somebody, it is a topic rather than a risk.

How is this different from our existing technology risk work?

Mostly it is not, and treating it as an entirely new discipline wastes the machinery you already have. The additions are output that is confidently wrong, and behaviour that changes underneath you. Adding those two to an existing process is usually better than standing up a parallel one, which tends to be maintained by nobody.

Who should own an entry?

Whoever can actually change the answer. A risk owned by the person who introduced the system but cannot alter how it is used is a name in a column rather than an owner. The test is whether that person could, on their own authority, make the entry go away, and if nobody can, the entry belongs one level up.

How should severity be judged?

By what cannot be undone rather than by what is most likely. Reversibility sorts a register more usefully than probability, because the recoverable failures are absorbed by ordinary work and the irreversible ones are the ones that become a meeting. Sending, paying, deleting and publishing are the usual boundary.

Glossary

AI risk

AI risk is the specific harm a particular system could cause, recorded and owned, which is mostly ordinary risk work plus two things that are genuinely new.

In plain terms

Not a feeling about the technology but a list. This system, used this way, could produce this outcome, and here is who owns that. Most of what appears on such a list is familiar from any technology review. A small part of it is not, and that part is where the attention should go, because the familiar parts already have a process.

Why it matters

Because the general conversation is unownable and the specific one is actionable. Nobody can be accountable for whether AI is risky. Somebody can be accountable for an assistant that drafts customer replies without review, which is a sentence with a system, a use and a consequence in it. Organisations that never make that translation end up with a great deal of anxiety and no decisions.

How it works

Most of the register is ordinary technology risk wearing new clothes, which is genuinely reassuring. Data going somewhere it should not, a supplier failing, an integration with more access than it needs, a cost that scales differently from expected: all of these have established owners and established treatments, and none of them needs a new discipline.

The first genuine addition is that the system produces confident output that can be wrong, and wrong in a way that reads as right. Ordinary software fails visibly. This fails plausibly, which moves the risk from the system to whoever accepted the output, and means the treatment is almost always about the check rather than the component. Assistant documentation in this guide says as much, noting that important outputs should be reviewed and verified.

The second is that behaviour is not fixed. The model behind a product can change, the material it reads can change, and what was true at approval can quietly stop being true without anything in your own estate being touched. That is unusual: most technology risk assessments assume the thing assessed stays the thing assessed, and here the assumption does not hold.

Some of it does not sit in any single system, which is why a register organised strictly per system will miss it. Several teams independently choosing the same provider is a concentration nobody decided on, and the same is true of a model that many separate workflows quietly depend on. Each entry looks proportionate alone; the exposure is in the total, and the total is nobody's line item.

Severity is usually about reversibility rather than probability, which is the most useful reordering available. A wrong draft costs a few minutes. A wrong message that has been sent, a payment made, a record deleted or a customer told something binding cannot be taken back. Sorting a register by what cannot be undone tends to produce a different order from sorting it by what is most likely, and a more useful one.

Sorting a register by what cannot be undone

Ordering a register this way rather than by likelihood tends to reveal that the controls are in the wrong place. Most review effort naturally attaches to the left-hand end, because that is where the volume is and where mistakes are noticed most often, so drafts get checked carefully by people who read them anyway. The right-hand end is where the review is thinnest, partly because those actions are rarer and partly because they are usually the ones automated first, precisely for being repetitive. That combination is the shape of an expensive surprise. The practical reading is not that the left-hand end needs less attention but that a control placed at the right-hand end buys far more than the same control placed anywhere else, and that a register sorted by probability will never say so.

Seen in the wild

Documentation stating the tool is unsuited to work requiring guaranteed accuracy or unsupervised high-risk decisions, which is a supplier naming the risk for you.
ChatGPT
A platform noting that always-on autonomy is earned and supervision precedes trust, which describes a risk that grows with how much you delegate.
Relevance AI
A compliance platform carrying risk assessment and vendor risk alongside control monitoring, which is where a register of this kind usually ends up living.
Vanta

Common misconceptions

People assume

The risk is that the model says something outrageous.

In fact

That is the visible one and rarely the expensive one. Quiet plausible errors accepted into work, an automation acting on a misreading, and access granted more broadly than anybody remembers approving cost more and attract no attention while they are happening. The outrageous output at least announces itself.

People assume

A register written at approval covers it.

In fact

It covers the system as it was. Because the model behind a product can change and the material it reads changes constantly, an assessment has a shelf life in a way that an assessment of ordinary software does not. The date on the register is part of the register, and an undated one is a document about the past.

Telling them apart

AI risk vs AI incident

AI risk

What could happen, recorded before it does.

AI incident

What did happen, and what was done about it.

One is a forecast and the other is a fact. An organisation with incidents and no register is learning the expensive way.

Questions

What actually belongs on the register?: Anything specific enough to own. A named system, the way it is used, the outcome that would be bad and the person answerable. General statements about the technology fail that test, which is why they never produce a decision. If a line cannot be assigned to somebody, it is a topic rather than a risk.
How is this different from our existing technology risk work?: Mostly it is not, and treating it as an entirely new discipline wastes the machinery you already have. The additions are output that is confidently wrong, and behaviour that changes underneath you. Adding those two to an existing process is usually better than standing up a parallel one, which tends to be maintained by nobody.
Who should own an entry?: Whoever can actually change the answer. A risk owned by the person who introduced the system but cannot alter how it is used is a name in a column rather than an owner. The test is whether that person could, on their own authority, make the entry go away, and if nobody can, the entry belongs one level up.
How should severity be judged?: By what cannot be undone rather than by what is most likely. Reversibility sorts a register more usefully than probability, because the recoverable failures are absorbed by ordinary work and the irreversible ones are the ones that become a meeting. Sending, paying, deleting and publishing are the usual boundary.

Key takeaways

A list of specific harms with owners, not a general worry about the technology.
Most of it is ordinary technology risk with established treatments.
Addition one: output that is confidently wrong, so the treatment is the check rather than the component.
Addition two: behaviour changes underneath you, so an assessment has a shelf life.
Sort by what cannot be undone rather than by what is most likely.

Tools that use this

ChatGPT
Documentation naming unsupervised high-risk decisions as outside its shape.
Relevance AI
Autonomy earned rather than assumed, with supervision before trust.
Vanta
Risk assessment and vendor risk carried alongside control monitoring.

Last checked July 2026

All glossary terms