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 cannot 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 wants to know whether this is a security problem, a vendor problem, a privacy problem, or just "something the AI did."

Everyone is asking the same question: 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 cannot yet answer.

Organisations have spent the past two years building risk registers, which are documents that list known risks, rank how serious each one is, and assign an owner on paper. Boards have been briefed. Policies have been written. Committees have formed. And yet the moment a real AI event happens, the gap between "we documented this risk" and "we know what to do right now" becomes very plain.

A risk register is visibility. It is not a response.

Why does this matter for ordinary employees and customers?

It matters because AI tools are now embedded in the work that affects people directly. An AI assistant used inside a hospital could quietly produce an unreliable summary. A fraud-detection model at a bank could misclassify a legitimate transaction. A security tool that monitors for intrusions could fail to flag a real attack because its recommendations drifted after a software update the organisation never fully reviewed.

None of those events look like a traditional breach, where criminals break into a system and steal data. They look like operational noise, right up until they cause real harm.

If the organisation has no agreed way to report, investigate and escalate an AI failure, teams lose time arguing about ownership while the impact continues.

Three things tend to be missing from AI governance programmes when events occur.

First: evidence. Incident response, the structured process security teams use to investigate and contain a problem, depends entirely on logs and records. If an organisation never required the AI system to retain prompt histories, output records, and model version information, investigators have nothing to work with. Security leaders should insist on evidence requirements before any high-risk AI tool goes into production.

Second: clear ownership. In most organisations, a business unit funds the AI tool, a data team configures it, IT hosts it, and a vendor built it. Nobody is fully accountable after launch. Ownership must be named, and it must include decision rights, not just a title in a spreadsheet.

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 are not agreed before deployment, the organisation will be forced to work it out under pressure, which is the worst possible time.

A practical AI response playbook does not need to be long. It needs to say how employees report a concern, who investigates, what evidence is preserved, when legal and privacy teams join, and who tells the executive team. It should be lighter for a low-risk internal chatbot and considerably stricter for AI tools used in healthcare, finance, regulated decisions, or security operations.

Security teams already know how to build this kind of structure. They do it for vulnerabilities, for third-party risks, for data breaches. AI incidents need the same discipline, adapted for failures that may not announce themselves the way a breach does.