What is AI governance?

AI governance is the set of policies, roles and review processes an organization uses to decide how AI systems are acquired, built, deployed and monitored. The emphasis belongs on decisions rather than documents: a policy nobody consults is not governance, while a repeatable way of answering whether to use a system, under what conditions, and who is accountable for it, is. It sits above compliance and security rather than beside them. Compliance asks whether you meet an external rule and security asks whether one system is safe, while governance decides which AI gets used at all and sets the conditions.

Why is AI governance a CISO problem?

Because AI decisions are radically decentralised and you own the consequences of the ones you were never consulted on. A developer adds a model to a feature, a business unit buys a tool with AI already inside it, an employee pastes a contract into a chatbot to summarise it. Each is a decision about your risk made by someone who does not carry it. When something then goes wrong, the question from the board, a regulator or a court is always who approved this and on what basis, and without governance there is no answer.

How does maintaining an AI inventory support responsible governance?

An inventory is what makes everything downstream possible, because you cannot tier, gate or monitor a system you do not know exists. It records what each system does, what data it touches and who owns it, which is precisely the input a risk tier and a review gate need. Without one you govern the three systems you know about and miss the thirty you do not. Discovery has to be active rather than announced: procurement records, expense reports, SSO grants to AI apps, and the AI features quietly switched on inside tools you already own.

How should a CISO evaluate an AI vendor?

Put the vendor through the same review gate you apply to anything built in house, against criteria known in advance. Ask what data the system touches, what human oversight exists, what the failure modes are, and specifically what happens if the vendor changes the model underneath you. Establish whether the use makes you the provider or the deployer, because under the EU AI Act the obligations attach to that role. Then give the approval an expiry, because a vendor swapping a model is exactly the change a one-time blessing at launch will never catch.

Do NIST AI RMF, ISO/IEC 42001 and the EU AI Act each do something different?

Yes, and they answer three separate questions. The NIST AI Risk Management Framework supplies the vocabulary for the loop through its govern, map, measure and manage functions. ISO/IEC 42001 turns that loop into a certifiable management system for when you have to prove it to a customer or an auditor. The EU AI Act tells you which uses the law treats as high risk and what your role obliges you to do. Use them as maps rather than as the territory, because a team can produce a complete framework binder and still be unable to say who approved the applicant-screening model.

AI Governance: Deciding What Ships Before It Ships You

AI decisions are being made in your organization whether or not you are in the room, and if you are not, you still own the consequences. Nothing about that is malicious. Someone clicks a toggle that was designed to be clicked.

Governance is how you get back in the room. It is mostly not about models.

What AI governance actually is

AI governance is the set of policies, roles, and review processes your organization uses to decide how AI systems are acquired, built, deployed, and monitored. Read that again with the emphasis where it belongs: it is about decisions, not documents. A policy PDF that nobody consults is not governance. A repeatable way of answering “should we use this, under what conditions, and who is accountable” is.

It helps to separate governance from two neighbours. Compliance asks whether you meet an external rule. Security asks whether a specific system is safe. Governance is the layer above both: it decides which AI gets used at all, sets the conditions, and names who owns the answer. Compliance and security are things governance calls on, not substitutes for it.

Why AI decisions reach you anyway

The reason this is a CISO problem, and not just a legal or data-science one, is that AI decisions are radically decentralised. A developer adds a model to a feature. A business unit buys a tool with AI baked in. An employee pastes a contract into a chatbot to summarise it. Each of those is a decision about your risk, made by someone who does not carry it.

Without governance, three things happen. First, you accumulate risk you never agreed to: systems making decisions about customers, staff, or money that no one assessed. Second, you get shadow AI, the unsanctioned use that grows precisely because the sanctioned path is slow or absent. Third, when something goes wrong, the question from the board, a regulator, or a court is always the same and you cannot answer it: who approved this, and on what basis?

There is a regulatory edge to this now. Under the EU AI Act, obligations attach to your role: building a system (provider) carries different duties from deploying someone else’s (deployer), and high-risk uses carry more of both. You cannot meet an obligation you cannot see, which is why governance starts with knowing what you have. None of this argues for a committee that says no to everything. It argues for a decision you can defend.

How AI governance works, to the depth you need

You do not need to run the review yourself. You need to be able to reason about the machinery, which is smaller than the frameworks make it look: an inventory, a way to tier risk, a gate with an owner, and a link to monitoring.

  new AI use case
  (build, buy, or a feature someone already turned on)
        |
        v
  inventory it  -->  risk tier  -->  review gate  -->  decision
  (you cannot        (minimal /      (named owner,     |- approve
   govern the         elevated /      clear criteria)   |- approve with conditions
   invisible)         prohibited)                       |- reject
        |                                                  |
        +---------------- monitor in production <----------+

Inventory first. Every governable AI use begins as a known one. An inventory that captures what the system does, what data it touches, and who owns it is the unglamorous foundation. Skip it and everything downstream is theatre.

Tier the risk. Not every use deserves the same scrutiny. A tool that drafts internal meeting notes is not a model that screens job applicants. A short triage, minimal versus elevated versus prohibited, sends the rare high-stakes cases to a real review and lets the routine ones through fast. The fast lane is what keeps people from going around you.

Gate with an owner. The review is a decision point with named accountability and criteria known in advance: what data, what oversight, what failure modes, what happens if the vendor changes the model underneath you. The output is not just yes or no but approve, approve with conditions, or reject, and the conditions are written down.

Then hand off to monitoring. Approval is a moment; risk is continuous. An approved system still drifts, gets abused, or quietly changes behaviour, which is why governance closes the loop into AI observability rather than ending at the gate.

The frameworks map onto exactly this. The NIST AI Risk Management Framework gives you the functions (govern, map, measure, manage) as a vocabulary for the loop above. ISO/IEC 42001 turns it into a certifiable management system when you need to prove it to a customer or auditor. The EU AI Act tells you which uses the law treats as high-risk. Use them as maps, not as the territory: adopting a framework is not the same as making decisions.

Where AI governance goes wrong

AI governance fails in a handful of predictable ways, and each one becomes an incident or an audit finding on your desk.

Governance as a document, not a decision. A policy is written, filed, and never consulted. Nothing actually gets reviewed. The fix is a lightweight gate people genuinely have to pass, not a longer PDF.
The committee that only says no. Review becomes so slow or absolute that teams route around it, and you have manufactured your own shadow AI. A fast lane for low-risk uses is not a weakness; it is what keeps the high-risk cases coming to you.
No inventory. You govern the three systems you know about and miss the thirty you do not. Discovery has to be active: procurement records, expense reports, SSO grants to AI apps, and the AI features quietly switched on inside tools you already own.
One-time approval. A system is blessed at launch and never looked at again, even as the vendor swaps the model or the use expands. Approval needs an expiry and a trigger for re-review, especially when the life cycle moves under it.
Governance with no security teeth. It lives entirely in legal or in a data-science team, and no one asks the security questions until after go-live. The controls belong in the decision, not bolted on afterwards.
Framework cosplay. A team maps everything to NIST or ISO, produces a binder, and still cannot tell you who approved the applicant-screening model. The artefact is not the accountability.

Questions to ask about AI governance

You will not sit in every review. You do not need to. A short list, put to your teams and your vendors, separates governance that decides from governance that merely documents:

Do we have an inventory of the AI systems and AI-enabled features actually in use, and how did we find them?
Who approves a new AI use case, against what criteria, and where is that decision recorded?
How do we tier risk, so a low-stakes tool is not treated like a decision that affects people’s livelihoods, and vice versa?
Is there a fast path to yes for low-risk uses, or are we quietly training people to route around us?
When an approved system changes, the vendor swaps the model, or the use expands, what triggers a re-review?
How does an approved system get monitored in production, and who sees the results?
For each significant use, are we the provider or the deployer, and what does that make us responsible for?

If those get crisp answers, you have governance that owns the decision. If they get shrugs, you own the risk and someone else made the call.

AI governance is not the paperwork that slows a launch. It is the difference between choosing your risk and inheriting it.