You Cannot Select an AI Control Until Governance Tells You What You Are Protecting
Control selection is downstream of classification, and classification is a governance output. Where that chain is missing, what looks like a control framework is really just a control list.
IBM's Cost of a Data Breach Report 2026 found that 68% of the organisations studied lacked AI governance to manage AI or detect shadow AI, up from 63% the year before. Among organisations that suffered an AI-related breach, 92% lacked proper AI access controls.
Over the same period, the share of organisations reporting a breach involving an AI model or application rose from 13% to 21%. Governance coverage declined while exposure increased. Those two lines move in opposite directions, and the gap between them is the subject of this piece.
The access control number is usually read as a security finding. It is more useful to read as a governance one. Access controls for an AI system are not selected in a vacuum. They follow from a decision about what the system is, what it touches, and what it is permitted to do, and that decision is a governance output. When it has not been made, the controls that would have followed from it do not exist either. The first number is the cause and the second is the symptom.
The second number is usually read as a security finding. It is more useful to read as a governance one. Access controls for an AI system are not selected in a vacuum. They follow from a decision about what the system is, what it touches, and what it is permitted to do, and that decision is a governance output. When it has not been made, the controls that would have followed from it do not exist either. The first number is the cause and the second is the symptom.
Which is the argument of this piece, stated more precisely: control selection is a function of classification, classification is an output of governance, and a control framework built without governance upstream of it is arbitrary. Not necessarily wrong. Arbitrary. Which is a distinct and harder problem to remediate.
The two answers
Ask a control owner why a particular AI control applies to a particular AI system, and you get one of two answers.
The good answer: because this system was classified as high impact under our AI impact assessment, and policy requires mandatory human review, retention of decision rationale, and quarterly bias testing for that tier.
The common answer: because it is on the AI control list.
The second answer is diagnosable from the outside. The symptom is a control set applied uniformly, the same evidence demanded of a document tagging model and a creditworthiness model, because without a classification, uniformity is the only defensible-looking option available.
The frameworks already sequence this
All three major frameworks put classification upstream of control selection, and none of them let you start at the controls.
ISO/IEC 42001 requires the Statement of Applicability to be justified by the risk and impact assessments that precede it. Justification has to come from somewhere.
NIST's AI RMF makes GOVERN foundational to the other three functions, and locates risk tolerance there. Without a stated tolerance, MEASURE has no reference point. You can compute a fairness metric, but you cannot say whether the number is acceptable, because acceptability is a governance output rather than a statistical one.
The EU AI Act is not a management system standard, but it does the same thing legally. Obligations attach to systems by classification. An organisation that has not classified its systems has not simply missed a control. It does not know which body of obligations it is subject to.
Three sentences, three frameworks, same sequence. The dependency is structural, not a matter of good practice.
What classification actually decides
"Governance drives controls" remains abstract until you see the fan-out. From a single impact classification, the following are typically determined:
- Whether human oversight is advisory or mandatory, and whether the human can override or merely observe
- What must be logged, and for how long
- Whether affected individuals must be told an AI system was involved, and whether they get a route to contest
- Testing depth and cadence, from annual review to continuous monitoring against pre-committed thresholds
- Who approves deployment, and at what seniority residual risk can be accepted
- What contractual terms are required from a third-party provider
- Whether the system can be deployed at all
That last item is the one most control frameworks omit. A governance function with no mechanism to say no is not governing; it is documenting. The auditable question is whether any AI proposal has ever been declined or materially constrained, and where the record of that decision lives.
The same IBM research suggests this is getting harder, not easier. Strict approval processes for AI deployments were the most commonly reported governance control, but their use fell from 45% to 38% year on year. The mechanism most directly capable of declining a deployment is the one being applied least often over time.
Three failure patterns
Missing governance shows up in three recognisable shapes.
The uniform control set. Every AI system gets the same twelve controls. This looks rigorous and is usually the opposite. High-impact systems are controlled to whatever level the organisation could afford to apply universally, while trivial systems absorb effort that should have gone elsewhere. Test for it by pulling two systems at opposite ends of the impact range and comparing their evidence packs. If they are identical, classification is driving nothing.
The orphaned classification. An impact assessment exists, was completed thoroughly, produces a rating, and is referenced by nothing downstream. The rating is absent from the control documentation and the monitoring configuration, and it does not determine approval routing. Test for it by taking a classification output and tracing it forward: which specific control exists because of that rating?
Shadow AI. A governance process exists and works well for systems that enter through it. The problem is what does not: AI features switched on inside SaaS platforms the organisation already licenses, capabilities added to existing tools by vendor updates, and models built by business teams who do not conceive of what they have done as an AI system. No classification happens because no trigger fires.
The third is the most common and the least visible, because the governance artefacts for the systems in scope all look excellent. It is also the pattern the IBM figures describe. Security incidents involving shadow AI more than doubled to 43% of incidents, from 20% the year before, and those incidents carried higher average breach costs than the year before. The organisations most exposed were not the ones with bad governance. They were the ones whose governance had a population problem.
Why the sequence cannot be reversed
The natural objection is pragmatic. Governance frameworks take a year to stand up, and there are models in production now. Surely applying sensible controls immediately beats waiting?
Applying controls immediately is correct. But two things do not survive being retrofitted.
Risk tolerance. It has to be set before the results are in, or it is not a tolerance; it is a rationalisation. An organisation that measures a model's subgroup performance gap and then decides what gap is acceptable has, whatever the paperwork says, deemed the observed gap acceptable. Governance's contribution here is temporal: committing to a threshold while the answer is still unknown. That commitment cannot be recovered later.
Accountability. Assigning an owner to a model after an incident produces a scapegoat. Assigning one beforehand produces a decision-maker who held authority and, critically, the standing to have refused. ISO 42001 places roles, responsibilities, and authorities in leadership ahead of planning for this reason.
So the sequence is not reversible, but it is compressible. A defensible minimum is smaller than most programmes assume: a definition of what counts as an AI system in your context, a register built from an independent population rather than self-declaration, an impact classification scheme with three or four tiers, a stated tolerance per tier, named accountable owners, and a forum with authority to decline. The full management system can follow.
Note the second item. A register built by asking teams to declare their AI systems will reproduce exactly the population problem that produces the shadow AI pattern. Independent sources, expense data, identity provider logs, egress traffic, procurement records, and code repositories generate a population you did not have to be told about.
What this means in the audit
One testable proposition: pick a control and walk it backwards.
Choose any AI-specific control the organisation claims to operate. Ask which classification triggered it. Ask to see the assessment that produced the classification. Ask who approved the risk tolerance that set the control's threshold. Ask what would have happened had the assessment come out one tier higher.
Where that chain is intact, you have a control framework. Where it breaks, you have a control list: a different artefact wearing similar clothes.
One last figure, measured by IBM for the first time this year. Only 19% of organisations reported any coordination between their governance and security teams. Classification sits with one, control implementation sits with the other, and in four organisations out of five, nobody owns the join. That is where the chain usually breaks, and it is not a documentation problem.
