High risk is a classification, not an adjective

In the last few months I have heard “we’re treating all of it as high risk” from several engineering leaders, delivered in the tone of someone reporting a conservative and therefore safe decision.

It is neither. It is an expensive way to end up with weaker controls than the team had before, and it usually comes packaged with its mirror image somewhere else in the same organisation: a system that plainly carries obligations, running quietly, described by whoever owns it as “just internal tooling”.

My position: “high risk” is a classification that attaches to a specific system with a defined purpose and boundary. Used as an adjective it does no work, and worse, it substitutes for the thing that would actually help, which is a boring inventory nobody wants to own.

I am not a lawyer and none of this is legal advice. What follows is an engineering argument about what the classification implies for how you build and what you will be asked to produce.

Why the blanket answer makes you weaker

Say you decide everything gets the full treatment. Every service, every assistant, every internal script that calls a model.

Three things happen, reliably.

Controls get diluted to whatever is affordable across the whole estate. If the logging requirement has to apply to four hundred systems, it becomes a checkbox somebody ticks rather than a record somebody can produce on demand. The strength of a control is set by the weakest place you apply it, because that is the standard you have to write it down as.

Attention gets flattened. If everything is high risk, nothing is, and the two systems that genuinely need architectural attention receive the same review slot as the internal dashboard.

And the register stops being informative. A list where every row says the same thing cannot be used to decide anything, which means the first question an auditor asks after seeing it is the one you cannot answer: which of these actually does the thing you are worried about.

Blanket high risk

Every system gets the label. Controls dilute to the cheapest common denominator, attention flattens, and the register carries no information.

The internal tooling dodge

Anything without an external user is assumed out of scope. The assumption is about who uses it, not what it decides, which is the wrong axis.

Policy without inventory

A written position on AI governance, no enumeration of where AI actually sits. The policy is unfalsifiable and therefore untestable.

Inventory first

An enumerated list of systems with purpose, boundary, decision effect and owner. Classification becomes a per-row judgement rather than a mood.

The dodge on the other side

The mirror failure is more common and less discussed. It sounds like this: “that’s internal, so it’s out of scope.”

The relevant axis is not whether a human outside the company touches the interface. It is what the system’s output determines, and about whom. A tool used by twelve internal staff that ranks candidates, scores applications, allocates access or flags employees for review is deciding things about people, and the fact that the interface is internal changes nothing about the effect.

The same reasoning applies to the “it’s only a recommendation, a human decides” defence. That defence is worth exactly as much as the human’s actual ability to overrule it. If the human sees a score, has forty seconds, and disagrees with the system twice a year, describing that as human oversight is a claim about your process that your process cannot support. It is also a claim somebody will eventually test by asking for the override rate, which is a number you should know before they ask.

Where the code question actually sits

Engineering leaders reach for a specific edge case, so let me address it directly: does using a coding assistant make our development pipeline a high-risk system?

Almost certainly not in itself. The assistant is a tool used to build software, in the same way an IDE is. That is a different question from whether the software it helps build carries obligations.

But there is a consequence people miss. If the assistant contributes code to a system that is classified, then the obligations that attach to that system now cover an artefact whose origin you may not have recorded. The traceability question follows the artefact into the system, not the tool that produced it. Six months from now, asked how a particular decision path came to be, “an assistant wrote it and a person approved it” is only an answer if you can show which, when, against what specification, and reviewed by whom.

There is a notable gap here worth naming: generated images have native provenance attribution mechanisms, and there is no documented equivalent for generated code. Whatever record you have of code origin is one you built yourself, out of your own pipeline’s events. Nobody hands it to you.

System, not featureThe unit of classification is a system with an intended purpose and a boundary. Name it in one sentence.

What it determinesThe output's effect on a person or an entitlement. Not the interface, not the audience.

Where the output landsWhich downstream decision consumes it. This is how internal tools acquire scope.

Override realityHow often a human actually disagrees with it. If nobody knows, the oversight claim is untested.

Named ownerOne person who answers for it, not a committee and not a team mailbox.

Start with the inventory, because you cannot classify what you cannot list

The uncomfortable finding in most organisations is not that a system is misclassified. It is that nobody can produce the list.

Model calls appear inside services that predate the current governance conversation. A team added an assistant to a workflow eight months ago as an experiment and it became load-bearing. A vendor product shipped an AI feature in a minor release and switched it on by default, and the contract review that would have caught it happened two years before the feature existed.

So the first move is enumeration, and it is genuinely dull work: find every call to a model provider, every vendor feature flagged as AI, every internal tool doing scoring or ranking. Attach the five fields above to each. Then classify, and expect the argument, because that is where a real position gets formed.

Do that and the blanket answer becomes unnecessary. You will find that most of the estate is genuinely low stakes, two or three systems need serious attention, and the argument you were having about “treating all of it as high risk” was standing in for the fact that nobody had counted.

Enforcement of the EU AI Act began on 2 August 2026. The organisations I would worry about are not the ones with a contested classification. They are the ones who still cannot produce the list.

Where this breaks down

Conservatism is not irrational when the classification is contested. If a system sits genuinely near a boundary, applying stronger controls than strictly required is a reasonable hedge, and I have written as though over-application is always waste. It is not. My objection is to applying the label to everything, which is a different thing from applying it generously where there is real doubt.

An inventory decays the moment you finish it. A list built by hand this quarter is wrong next quarter, because someone adds a model call on a Tuesday. Anyone recommending an inventory owes you the maintenance question, and my honest position is that a manual inventory is a starting artefact that must become a derived one, and most organisations never make that transition.

The strongest objection is that classification is a legal determination and engineers should not be leading it. That is fair. What I am arguing for is the engineering input that a legal determination requires: purpose, boundary, effect, owner. Those are facts about your systems, and no lawyer can produce them for you. But if this piece reads as an invitation to self-classify without counsel, I have written it badly.

Override rate can be measured and still mislead. A low override rate might mean the system is accurate rather than that oversight is theatre. I have used it as a warning sign and it is only a prompt to look closer, not a finding.

And there is a real cost to enumeration that I have waved past. Finding every model call across a large estate is weeks of work by people who have other commitments, and the deliverable is a spreadsheet. Selling that internally is hard, and I do not have a shortcut. Attaching it to a specific question somebody senior has already asked is the only approach I have seen work.

The takeaway

“High risk” is a classification with a subject, a boundary and consequences. Used as an adjective, it produces two failures at once: controls diluted across an estate that mostly does not need them, and quiet systems that do carry obligations sitting outside the conversation because the interface is internal.

The prerequisite for every serious version of this discussion is a list, with five fields per row, that no organisation I have encountered can produce on request.

If you take one thing into next week: ask for the list of systems in your organisation that call a model, and note how long it takes to get an answer. The delay is the finding.