How to build AI governance that works in practice

Organisations rarely fail to govern AI because nobody has written a policy. More often, the policy exists but the operating model underneath it is unclear.

A team wants to use an AI product. Who decides whether it needs review? Procurement asks the supplier some questions. Privacy performs a data assessment. Security reviews the integration. Legal looks at terms. Someone records the tool in a spreadsheet. Six months later the supplier changes its model and nobody is sure whether the original decision still holds.

The purpose of an AI governance operating model is to turn those fragmented activities into one coherent decision process.

NIST's AI Risk Management Framework provides a useful high-level structure through four functions — Govern, Map, Measure and Manage. ISO/IEC 42001 provides an organisational management-system structure for establishing, implementing, maintaining and continually improving AI management. The EU AI Act adds specific legal requirements for systems and actors within its scope. These are different instruments, but operationally they converge on a familiar need: responsibilities, context, risk, evidence, controls and lifecycle management. NIST AI RMF Core; ISO/IEC 42001.

1. Start with an AI inventory — but do not stop there

You cannot govern what you do not know exists. The first practical control is therefore a register of AI systems and AI-enabled capabilities.

But an inventory that contains only product name, owner and status quickly becomes administrative rather than useful. Capture enough context to support a governance decision:

• business purpose and intended users;
• business owner and technical/service owner;
• provider, underlying model and important third parties where known;
• whether the organisation is developing, providing, deploying or simply consuming the capability;
• data categories and data flows;
• people or decisions affected;
• degree of autonomy and human involvement;
• jurisdictions and sectors in scope;
• lifecycle state and last governance review.

The inventory is the spine of the governance system. It should point to decisions and evidence rather than become another spreadsheet that has to be reconciled later.

2. Put governance at the point where a use case enters

The strongest time to govern AI is before the organisation has committed itself operationally.

Create a simple intake route for new AI use cases, new AI suppliers and material changes to existing AI. The initial questions should establish context, not attempt to perform the entire assessment.

Those answers determine what happens next.

3. Use risk-based routing rather than one questionnaire for everything

A common failure mode is applying the same review burden to every AI use case. That produces long forms, governance fatigue and incentives to avoid declaring AI at all.

Instead, define routing rules. A low-impact internal productivity use case may require only basic ownership, security, privacy and acceptable-use checks. A consequential system involving sensitive data, vulnerable people, automated decisions, significant autonomy or regulated activity should trigger deeper review.

The EU AI Act is explicitly risk-based. NIST likewise expects risk management to be contextual. Good internal governance should reflect that principle even when a particular legal classification does not apply.

4. Assign decision rights, not just responsibilities

Many governance documents identify who is “responsible” without saying who can actually decide.

For each review lane, define:

• who may approve normal use;
• who must review privacy, security, legal, procurement, model risk or other specialist issues;
• who can accept a residual risk;
• what requires escalation;
• who can impose conditions;
• who can suspend or withdraw approval.

The human decision should be visible in the record. AI can assist triage, summarisation or evidence checking, but high-consequence governance decisions should not disappear into an automated score.

5. Define the evidence behind every important claim

This is where governance becomes assurance rather than administration.

If a use-case owner says “human oversight is in place”, what would demonstrate that? Perhaps a procedure, role description, interface design, training record, sampled decision log or evidence that overrides actually occur.

If a supplier says “customer data is not used for model training”, what supports that? Contract language, a supplier privacy statement, technical configuration, due-diligence response or some combination?

The correct evidence depends on the claim and risk. But the principle should be consistent:

That structure is valuable whether the organisation is working toward ISO/IEC 42001, responding to customer due diligence, preparing for regulatory obligations or simply trying to make better internal decisions.

6. Separate fact, rule and judgement

A mature governance system should distinguish three things:

1. Fact: what is true about the system — for example, personal data is processed or a third-party model is used.
2. Rule: what that fact triggers — for example, privacy review or a particular control requirement.
3. Judgement: whether the evidence and residual risk are acceptable.

Facts and deterministic rules can often be automated safely. Judgement may require a human reviewer, especially where context, proportionality or risk acceptance is involved.

This separation also makes the governance record explainable. A reviewer can see not just the outcome, but why a control applied and what evidence supported the conclusion.

7. Make supplier AI a first-class governance pathway

Most organisations will buy far more AI than they build. Third-party governance therefore cannot be an appendix.

For supplied AI, capture evidence on the provider, underlying model where relevant, hosting and data routing, use of customer data, security, testing, model changes, incident handling, output/IP terms, subcontractors and exit arrangements.

The objective is not to demand information the supplier genuinely cannot disclose. It is to know which assurances are evidenced, which are contractual, which remain unknown, and what the organisation has decided to accept.

8. Design human oversight for the actual decision

Human oversight should be proportionate to the consequence and autonomy of the AI system.

For a low-impact drafting assistant, oversight may simply mean the employee remains responsible for checking output before use. For a system influencing employment, healthcare, credit, safety or other consequential decisions, the oversight design needs to be much more explicit.

For high-risk systems within its scope, the EU AI Act requires human oversight measures that enable people to understand relevant capabilities and limitations, detect anomalies, avoid over-reliance, interpret outputs and, where appropriate, disregard or override the system. EU Artificial Intelligence Act, Article 14.

9. Give reviewers exceptions, not paperwork

A governance board should not spend its scarce time rereading 40 answers that are complete, low-risk and supported by evidence.

Surface what actually needs human attention:

• Blocker: the case should not proceed yet.
• Material review: specialist judgement is required.
• Condition: the case may proceed subject to an explicit action.
• Information gap: a required fact or evidence item is missing.
• Observation: useful context that does not currently prevent approval.

This is more efficient and often more defensible than a single opaque risk score. The reviewer sees the problem, the reason it matters and the evidence available.

10. Treat approval as a living baseline

An AI approval should not become a dead PDF.

Define material-change triggers such as:

• new purpose or user group;
• new or more sensitive data;
• change in model or provider;
• meaningful increase in autonomy;
• new jurisdiction or regulated activity;
• performance deterioration or drift;
• significant incident or complaint;
• new regulatory obligation;
• change to the human-oversight design.

A trigger should lead to targeted reassessment rather than automatically restarting every governance activity from zero.

11. Govern once, map across frameworks

Organisations operating across the UK, EU, US and India should resist building a separate operational truth for each framework.

Maintain one factual and evidential record for the AI system. Then map that record to applicable legal requirements, standards, internal policies and customer-assurance needs.

This does not mean the frameworks are equivalent. They are not. It means the same fact — for example, how human oversight operates — should not have to be rediscovered four times.

ISO/IEC 42001 is particularly useful at organisational level because it specifies requirements for an AI management system and continual improvement. NIST provides a flexible risk-management structure. The EU AI Act imposes legal obligations where its scope and classifications apply. UK and Indian organisations also need to consider sector, data-protection and other applicable requirements rather than treating “AI governance” as a single statute.

12. Measure whether governance is working

Do not judge the programme by how many policies exist. Better measures include:

• percentage of known AI systems with an accountable owner;
• time from use-case submission to governance decision;
• number and age of unresolved blockers;
• evidence completeness for higher-risk systems;
• percentage of material changes that triggered review;
• supplier evidence gaps;
• incidents and repeated control failures;
• training completion for people with specific governance roles.

These measures tell you whether governance is becoming operational rather than merely documented.

A minimum viable operating model

If an organisation is starting today, the first version does not need to be complicated:

Build that path, test it on real use cases, and improve it from the friction you observe. Add deeper sector and jurisdiction requirements where they genuinely apply.

The objective is straightforward: every material AI system should have an owner, a reasoned governance decision, evidence behind that decision and a mechanism for revisiting it when reality changes.

Primary sources

• NIST — AI RMF Core: Govern, Map, Measure, Manage
• ISO — ISO/IEC 42001:2023 AI management systems
• European Union — Regulation (EU) 2024/1689 (Artificial Intelligence Act)
• UK Government — A pro-innovation approach to AI regulation
• NITI Aayog — Responsible AI for All

This article provides general governance information, not legal advice or a determination of which laws or standards apply to a particular organisation or AI system.