AI Risk Management Without a Risk Department

Search for an AI risk framework and you will find documents written for organisations with a chief risk officer. They will ask you to nominate a model owner, a validation function, and a second line of defence. In a thirty-person business those are all the same person, usually you, and filling in the template produces something technically complete and practically useless. The underlying questions are still worth answering. The structure around them is not.

The four that actually happen

Forget the taxonomy in the frameworks. In practice, four things go wrong, and none of them are exotic.

Risk	What it costs you
Wrong output reaches a customer	A correction, a refund, or a reputation
Data goes somewhere it should not	A privacy obligation you did not plan for
A tool becomes unavailable	Work stops for however long it lasts
Nobody can explain a decision	A bad afternoon with a client or auditor

These are ordinary business failures with AI as the mechanism. Which is good news, because the responses are also ordinary and you already know most of them from other parts of the business.

The page that replaces the framework

Here is the whole artefact. One line per AI use, four columns.

Where it is used. The tool and the process it touches.

What it does. In plain language, the way you would explain it to a new employee.

Who owns it. A name, not a department.

What would make you stop it. The specific observable event, which is the column everybody leaves blank and the one that matters most. We set out how to write it in defining your stop condition.

Add a short note on what data may go into AI tools, and an incident log recording what went wrong and what changed. That is it. Most businesses can complete this in an afternoon, and it does the work a twenty-page policy pretends to do.

Rank by consequence, not by likelihood

Formal risk work multiplies probability by impact and produces a score. That is sensible when you have hundreds of risks and need to sort them. With six AI uses it is theatre.

Ask a simpler question instead: if this went wrong in the worst plausible way, could we absorb it? Anything you could absorb, use freely and stop worrying about. Anything you could not, put a human in front of it. That single distinction does more real risk reduction than any scoring exercise, and it takes about ten minutes per use rather than a workshop.

Controls you already understand

Every control that matters here is one you use elsewhere in the business. Limit who can do what. Keep a record of what happened. Have someone check the consequential things before they leave the building. Know how to stop it.

For agents specifically, that translates into narrow accounts, short permission lists, and logs somebody reads, which we laid out in three boxes to put an agent in. Nothing about AI requires a new category of control. It requires applying the ones you have to a thing that produces output faster than a person and looks equally confident whether it is right or wrong.

Know when to get formal

The one-page version has a shelf life, and three specific things end it.

A customer asks for evidence of your AI governance during procurement. You start selling AI-enabled services rather than using AI internally. Or you enter a sector with specific rules, in which case the proper frameworks genuinely apply and AI governance for regulated industries is the right place to start.

Until one of those happens, more structure is cost without return. And in my experience businesses get this wrong in that direction more often than the other: they buy a policy template, file it, and never build the inventory that would have actually helped.

The version that fails

Worth naming, because it looks like success. A business downloads a comprehensive AI policy, adapts the names, circulates it once, and files it. Everyone has technically read it. Nobody could tell you which AI tools the business uses.

That is worse than doing nothing, because it manufactures confidence. The test of whether your AI risk management is real is not whether a document exists. It is whether someone can list your AI uses and name who owns each one, without looking. That is a lower bar than any framework sets and a much better predictor, and it is the same gap behind businesses using AI without managing it.

Frequently Asked Questions

What is AI risk management?

Knowing what could go wrong with the AI your business uses, deciding which of those things you are willing to live with, and having a plan for the rest. That is the whole discipline. Large organisations wrap it in frameworks, committees, and documentation because they have thousands of systems and regulators asking questions. A thirty-person business has perhaps six AI uses and needs about a page. The thinking is the same, the paperwork should not be.

Why do the standard frameworks not fit?

Because they were written for organisations with a risk function, and they assume roles you do not have. Read one and it will ask you to nominate a risk owner, a model owner, a validation team, and a second line of defence. In a small business those are all the same person, usually the owner, and pretending otherwise produces a document that is technically complete and practically useless. Take the questions those frameworks ask and skip the structure they impose.

What are the risks that actually happen?

In practice, four. Something wrong reaches a customer and you have to correct it publicly. Personal information ends up somewhere it should not be. A tool everyone depends on becomes unavailable. And nobody can explain how a decision was made when someone asks. Notice that none of these are exotic AI failures. They are ordinary business failures with AI as the mechanism, which is why the responses are also ordinary.

How much documentation do we need?

Roughly one page. A list of where AI is used, what each use does, who owns it, and what would make you stop it. Add a short note on what data may go into AI tools, and a log of incidents and what you changed afterwards. That is enough to answer a customer questionnaire, enough to govern the business, and short enough that it stays current. A twenty-page policy that nobody reads is worse than a one-page one that everybody has seen.

When should this get more formal?

When something external forces it. A customer asks for evidence of your AI governance in a procurement process. You start selling AI-enabled services rather than just using AI internally. You enter a regulated sector or handle a category of data with specific rules. Any of those is a signal to invest in real structure. Doing it before then is a cost with no return, and the businesses that get this wrong usually get it wrong in that direction rather than by being too casual.