What is AI governance?

AI governance is not a document or a committee. It is a working system that sits across the organisation and decides what AI is allowed to do. This guide sets out what it covers, who does the work and how it runs, and points to the more detailed guides for each part.

Why organisations govern AI

Three things push organisations to govern AI deliberately rather than leave it to each team.

The first is spread. AI no longer arrives only as a project with a budget and a sponsor. It arrives inside the CRM, the office suite, the help desk and the developer’s editor, often switched on by a vendor update. Most organisations that run a proper inventory find far more AI than they expected, and a good share of it was never approved by anyone.

The second is consequence. AI systems now draft letters to customers, score applications, summarise case files, write code and, increasingly, take actions on their own. When one of those goes wrong it goes wrong at volume, and the people affected rarely see the system that made the call.

The third is scrutiny. Regulators, customers, insurers and auditors now ask direct questions about AI. The EU AI Act sets obligations by risk level. Privacy laws in the EU, the UK, Australia, California and elsewhere reach automated decisions about people. Enterprise customers send AI due-diligence questionnaires as a routine part of procurement. Each of those readers expects a considered answer backed by records.

What AI governance covers

Good AI governance covers the whole life of an AI system, from the moment someone proposes it to the moment it is retired. The work falls into six parts.

Inventory. A current register of every AI system and agent the organisation builds, buys or uses, with its purpose, provider, model, data, owner and where it stands between proposed and retired. Nothing else works without it, because you cannot assess, control or report on a system nobody has written down. The AI system register guide covers what to record, and finding shadow AI covers the systems nobody told you about.

Intake and approval. A front door for new AI use, so a proposal is reviewed before it goes live rather than discovered after. Intake asks why the system is needed, what it will do, whose data it touches and who it affects, and routes the higher-risk proposals to a committee.

Assessment. A structured look at what each system could do to people and to the organisation. A risk assessment starts from the system and works outward. An impact assessment starts from the people affected and works inward. Both should produce specific controls with owners, held in a risk register.

Policy. The written rules. An acceptable use policy tells staff what they may and may not do with AI. Further policies cover risk assessment, data, incident response and transparency. The governance policies guide covers the full set.

Enforcement and monitoring. Rules that only live in documents are hopes. Enforcement puts them where the AI runs, through guardrails that allow, redact or block traffic, usually at an AI gateway. Monitoring watches what systems actually do in production, including drift, cost, errors and security findings, and raises alerts when something crosses a limit.

Assurance and reporting. The ability to show the work. That means records that stand up to scrutiny, incident handling, board reporting, audit readiness and answers to customer questionnaires.

Around those six parts sit the supporting disciplines that make them work. These are staff training and AI literacy, vendor risk management and security testing.

Who does AI governance

AI governance fails most often because everyone assumes someone else owns it. A working structure names people at four levels.

The board sets the organisation’s appetite for AI risk and holds management to account. It does not run governance, but it should receive a regular report and be able to ask pointed questions.

An accountable executive owns AI governance overall. In some organisations that is the chief risk officer, in others the chief technology, data or information officer. What matters is that one named person answers for the whole, and that accountability is not delegated to a vendor or a consultant.

A governance committee makes the cross-cutting decisions. It approves higher-risk use, sets policy, resolves disputes between teams and reviews incidents. Its membership usually spans technology, risk, legal, privacy, security and the business units that use AI most.

System owners answer for individual AI systems. Each system has a designated business owner who decides how it is used, an executive who is accountable for it and a technical contact who knows how it works. Owners keep the system’s register record current, take part in assessments and act on findings.

Supporting functions do much of the detailed work. Privacy reviews data use and disclosures. Security tests systems and handles attacks. Procurement runs vendor due diligence. Internal audit tests whether the whole thing works. The framework guide sets out a RACI across these roles, and who should build your AI governance weighs doing it yourself against bringing in help.

How AI governance runs day to day

On paper, governance is a set of policies. In practice it is a rhythm of recurring work, most of it triggered by change rather than by the calendar.

A team proposes a new AI tool. Intake captures what it is and why, and the risk its answers point to routes it either to a quick approval or to the committee. Once approved, it goes on the register with an owner. Registration triggers a risk assessment. The assessment produces controls, some of which become guardrail rules at the gateway and some of which become monitoring limits.

Then the world moves. The vendor ships a new model version. The data the system reads changes. A business unit starts using the tool for a purpose nobody assessed. Each of those is a change to the system’s register record, and each should trigger a fresh look at the assessment, the controls and the guardrails. A calendar review every year is a useful backstop, but if it is the only trigger, the assessment will describe a system that no longer exists.

Meanwhile monitoring watches production. A spike in blocked prompts, an agent calling a tool it never declared or spend running ahead of budget all raise alerts for a person to decide on. When something goes seriously wrong, the incident process takes over, and its findings feed back into the assessment and the controls.

Every quarter, the accountable executive reports to the board on the footprint, the material risks, incidents and where the programme stands. Once a year, internal audit or an external assessor tests it.

The frameworks that shape AI governance

No single framework defines AI governance, but a handful set the shape most organisations follow. ISO/IEC 42001 is the international management system standard for AI, built on the same structure as ISO 27001, and it can be certified. The NIST AI Risk Management Framework organises the work into Govern, Map, Measure and Manage and is voluntary. The EU AI Act is law, with obligations that depend on whether a system is prohibited, high-risk, subject to transparency rules or minimal risk.

National frameworks fill in local expectations. The UK sets cross-sector principles for regulators to apply. Singapore publishes a Model AI Governance Framework and a framework for agentic AI. Canada’s federal government applies the Directive on Automated Decision-Making. Japan publishes AI Guidelines for Business, Korea has passed an AI Basic Act and Australia publishes the Guidance for AI Adoption. In the United States, specific uses fall under laws such as Colorado’s automated decision-making law (SB 26-189) and New York City Local Law 144.

The frameworks agree on far more than they differ. Each expects an inventory, named accountability, risk assessment proportionate to the stakes, human oversight, transparency to the people affected, monitoring and records. An organisation that builds those once can map them to each framework that applies, which is the subject of measuring governance against a framework.

Signs that governance is working

A few tests separate working governance from governance on paper.

• Someone can produce a complete list of the organisation’s AI, including AI features in purchased software, within a day.
• Every system on that list has a named owner who knows they are the owner.
• New AI use goes through intake before it goes live, not after.
• Assessments are rerun when a system changes, not only when a review date comes round.
• At least some rules are enforced on live AI traffic, not only written in a policy.
• Incidents are recorded, and their findings change something.
• The board receives a report it can act on.

If several of those fail, a maturity assessment is a quick way to see which areas need work first.

Where Aicura fits

Aicura is an AI governance platform built around the change-driven rhythm described above. Discovery scans connected sources such as device management, code repositories, cloud accounts and your IT asset database, and surfaces AI in use that nobody has registered, for a person to add, link or ignore. A material change to a system’s register record saves a new version and re-runs the assessments that depend on it, so the assessment keeps describing the system that actually runs.

From there, guardrails turn your rules into signed rule sets that gateways in your environment enforce on live traffic, and monitoring, alerts and board reports run on the same record. Aicura supports and guides the work. The decisions, and the accountability for them, stay with your people.

A note on this page

This guide is general information about AI governance. It is not legal advice and it does not tell you which obligations apply to your organisation. For that, read the primary sources on the framework pages and take your own professional advice.