Your AI risk register is a list, not a plan. Here is what organisations are missing.

Key points

• Most organisations using AI have a risk register, but few have a written plan for what to do the moment an AI tool causes a real problem.
• AI failures often surface as a wrong recommendation or a flawed summary, not as a classic data breach, which means they can be missed or misrouted.
• Without named ownership and "pause authority" (the formal right to suspend a system), accountability during an incident belongs to no one.
• Investigators can't reconstruct what an AI did if logs and output records were never required in the first place.
• Security teams already handle vulnerability registers and vendor risk lists; they need the same operational discipline applied to AI.

Something has gone wrong with the AI tool. A ticket is open. A business analyst is asking whether this is a security incident or a vendor problem or just "something the AI did."

Everyone wants to know the same thing: who has the authority to turn this thing off?

That question, first explored in depth by CSO Online, is the one most AI governance programmes can't yet answer. Our AI governance coverage, running since 28 May 2026, keeps returning to the same structural gap: committees form, policies get written, and boards get briefed, yet the moment a real event occurs the distance between "we documented this risk" and "we know what to do right now" becomes very plain.

A risk register is visibility. Not a response.

Why does this matter for ordinary employees and customers?

AI tools are now embedded in the work that affects people directly. A hospital's AI assistant could quietly produce an unreliable clinical summary. A fraud-detection model at a bank could misclassify a legitimate transaction. A security tool monitoring for intrusions could miss a real attack because its recommendations drifted after an update the organisation never fully reviewed.

None of those events look like a traditional breach. They look like operational noise, right up until they cause real harm. Without an agreed way to report and escalate an AI failure, teams lose time arguing about ownership while the impact continues.

What is actually missing from most AI governance programmes?

Three things tend to be absent when an event occurs.

First: evidence. Incident response depends entirely on logs and records. If an organisation never required the AI system to retain prompt histories or output records, investigators have nothing to work with. Security leaders should insist on evidence requirements before any high-risk AI tool goes into production. Monitoring should be proportional to risk, but if a system matters enough to influence real decisions, it matters enough to leave a trail.

Second: clear ownership. Typically a business unit funds the AI tool, a data team configures it, and a vendor built it. Nobody's fully accountable after launch. Ownership must be named, and it must include decision rights, not just a title in a spreadsheet. Accountability without authority is just a label.

Third: pause authority. Someone needs the explicit, documented right to suspend or roll back an AI system when the risk becomes too great. If that person and that process aren't agreed before deployment, the organisation will be forced to work it out under pressure.

Should every AI failure trigger a full incident response?

No. A confusing chatbot answer doesn't require the same response as a data-exposure event, but both need a path for review. A practical AI response playbook doesn't need to be long. It needs to cover how employees report a concern, who investigates, what evidence is preserved, and when the executive team is told. It should be lighter for a low-risk internal chatbot and considerably stricter for AI used in healthcare, regulated decisions or security operations.

Security teams already know how to build this structure. They do it for vulnerabilities and for third-party risks. AI incidents need the same discipline, adapted for failures that may not announce themselves the way a breach does. The register names the risk. The playbook is what you actually use.