AI governance that people will actually follow

What is AI governance?

AI governance is the set of decisions, owners and evidence that let an organisation say what AI it runs, who is accountable for each system, what data those systems touch, and what happens when one behaves badly. It is a management problem before it is a technology or legal one.

Three artefacts do most of the real work, and an organisation that has them can answer a regulator, a customer and an incident:

1. An AI system inventory. Every AI system, internal and third-party, with its purpose and risk tier.
2. A data-flow map per system. What goes in, where it is stored, who can reach it, whether the provider trains on it.
3. A named accountable owner per system. A person, not a committee.

An organisation with a forty-page AI policy and none of those three cannot answer any of them. That inversion — policy first, inventory never — is the most common way AI governance programmes fail while appearing to succeed.

How do NIST AI RMF, ISO/IEC 42001 and the EU AI Act relate?

They answer different questions. NIST AI RMF tells you how to structure a programme. ISO/IEC 42001 lets you certify that the programme exists and operates. The EU AI Act tells you what you are legally obliged to do. They are complementary, not alternatives — and none of them can be started without an inventory.

NIST AI Risk Management Framework

A voluntary US framework built around four functions. Govern establishes the culture, roles and accountability. Map establishes context and identifies risks in each system. Measure analyses and tracks them. Manage acts on them by priority. If you are starting from nothing, this is the most practical shape to adopt, because Map forces the inventory work that everything else depends on.

ISO/IEC 42001

The certifiable AI management system standard. Its value is external: it converts “we take AI seriously” into something a customer’s procurement team or an auditor can verify. If your buyers have started sending AI questionnaires, this is the answer you are being asked for.

EU AI Act

Risk-tiered regulation with obligations phasing in over several years, reaching general-purpose AI models and high-risk systems. Practices deemed unacceptable are prohibited outright; high-risk systems carry substantial documentation, oversight and quality-management duties; limited-risk uses mostly carry transparency obligations. Your first task is classification, and classification is impossible without — again — an inventory. Given how the timelines phase in, confirm the current position with counsel rather than with a blog post, including this one.

OWASP Top 10 for LLM Applications

Not a governance framework, but worth naming here because teams often reach for it as one. It is an engineering test plan. Use it to decide what to test; use the frameworks above to decide who is accountable for the result.

Why does AI governance fail?

Because the approved route is slower than going around it. Every week added to an approval process is a week in which people find something that works today. Governance that loses to a browser tab is not governance — it is documentation.

The design goal is therefore uncomfortable but simple: make the sanctioned path genuinely faster than the unsanctioned one. Concretely, that means:

• Tiered review. A low-risk internal summarisation use case should not go through the same gate as a customer-facing decisioning system. Most requests should clear in days on a self-service path with a lightweight questionnaire.
• Pre-approved patterns. Publish two or three blessed architectures. Anything matching one is approved by default; only novel shapes need review.
• Evidence collected automatically. If compliance depends on someone remembering to update a spreadsheet, you do not have evidence. Pull it from the platform.
• One page people will read. Which tools are approved, what data may never be entered, what needs review, who to ask. Everything longer is written for auditors, not for staff — keep that version separately and do not pretend it is the policy.

Design the approved route to be genuinely faster than the unapproved one, and most of the problem solves itself.

Robin Johns, Worldwide AI SME, Cato Networks

How to build an AI governance programme

Inventory first, then tier by risk, then assign owners, then write the minimum policy that covers what you found. Reverse that order and you will produce rules for an organisation you do not have.

1. Inventory. Discover third-party AI usage on the network (see shadow AI) and canvass engineering for internal projects. Expect the list to be several times longer than anyone predicted.
2. Tier by risk. Score on data sensitivity, autonomy, external exposure and consequence of error. Three tiers is plenty; five is a committee’s way of avoiding a decision.
3. Assign accountable owners. One named person per system. Shared ownership is the absence of ownership.
4. Map data flows for everything above the lowest tier.
5. Write the one-pager, and separately the auditor-facing standard.
6. Instrument enforcement in the toolchain — access policy, DLP, logging — so the control is technical rather than aspirational.
7. Review on change, not on calendar. Model version changes, new tool grants and new data sources are the events that matter; an annual review will miss all three.

What the board actually needs to know

Four things: what AI we run, what could go wrong, who is accountable, and what we would do on a bad day. Boards do not need model architecture; they need decision, accountability and exposure.

• Exposure. How many AI systems, in which tiers, touching what classes of data.
• Accountability. Named owners, and where the approval authority sits.
• Worst credible day. A specific scenario with a specific consequence, not a risk-register colour.
• Trajectory. Whether sanctioned usage is growing faster than unsanctioned usage. That single ratio tells a board more about AI risk than any maturity score.

Frequently asked questions