Four Questions That Tell You How Risky an Automation Is

Risk assessments for software usually ask what a tool is. That is the wrong question, and it produces the familiar outcome where the chatbot that drafts internal meeting notes gets the same scrutiny as the one that issues refunds, because both of them are "AI".

Ask what it does instead. Four questions will separate them, and you can answer all four about any automation in your business in about ninety seconds.

How much does it decide on its own?

There is a long way between suggesting and acting. A tool that drafts a reply for a person to send is in a different category from one that sends the reply, which is in a different category again from one that sends the reply at three in the morning with nobody watching.

The distinction that matters is not how clever it is. It is whether a human stands between the decision and the consequence, and whether that human is actually reading or has learned to click approve.

What data does it touch?

Nothing personal at all, ordinary internal business data, personal data about identifiable people, or the special categories that carry extra obligations everywhere.

Most teams answer this too optimistically on the first pass. The automation that summarises support tickets does touch personal data, because support tickets are full of it. The one that reads your calendar knows who you meet. Answer it by looking at what actually flows through the thing, not at what it was designed for.

What happens if it is wrong?

Trivial, inconvenient, costly, or serious. Be concrete: a wrongly tagged ticket is trivial, a wrongly chased invoice annoys a client, a wrongly cancelled order costs money, a wrongly sent message about somebody's account is a different kind of day entirely.

The useful discipline here is to describe the actual worst realistic outcome in one sentence, out loud, to somebody else. Vague answers hide in a dropdown. They do not survive being said.

Can it be undone?

Instantly, with effort, or not at all. Sending something to a customer is not reversible. Deleting a record might be, depending on your backups, and "depending on your backups" means you should go and check rather than assume.

What the four answers do together

They give you a tier, and the tier is what tells you which controls are actually required rather than which ones sound responsible.

At the bottom, a named owner is enough. Higher up you want a human reviewing outputs and an audit log of what it did. Higher still you want a way to stop it immediately and, if it is talking to people outside the company, you want those people to know they are dealing with an automation.

One rule prevents most of the gaming: a workflow is scored by its riskiest step, not its average one. A nine-step process where eight steps are harmless and one sends an email to a customer is a customer-facing automation. Averaging is how a sensible-looking assessment ends up protecting nothing.

abi. Governance scores agents on exactly these four axes from what the process itself says they do, and lists the controls the tier calls for. It is a structured self-assessment, not legal advice, and it does not certify compliance. The register shows how many required controls you have actually evidenced beside how many are required, because a tick that means "declared" and a tick that means "in place" should never look the same.

Do it once for everything you run

The reason to score everything rather than the scary-looking ones is that intuition sorts badly. People assume the customer-facing chatbot is the risk, and it usually is not, because somebody was nervous about it and put review steps everywhere. The risk is more often the quiet internal automation that has been acting unattended on live data since last spring and was never nervous-making enough to review.

Score them all, then spend your attention on the three that come out highest. Three real controls beat a policy document nobody reads, and you can have them in place by the end of the week.