AI governance is the operating model that decides which AI systems an organisation may build or buy, what controls each one operates under, who is accountable when it goes wrong, and what evidence exists to demonstrate all of that. It is the same kind of thing as data governance — an operating model rather than a document — applied to models and the systems built on them.
It has become urgent for a commercial reason rather than an ethical one. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls, and a follow-on forecast expects 40% of enterprises to demote or decommission autonomous agents by 2027 once governance failures surface in production. Meanwhile McKinsey's State of AI research for 2026 finds 88% of organisations using AI regularly but only 39% reporting EBIT impact at enterprise level.
Cancellation is a governance event before it is a technology one. Organisations are not shutting these systems down because the models are bad; they are shutting them down because nobody can answer for what they do.
What it covers that data governance does not
The two overlap and are not the same. Four things belong specifically to AI governance.
Which systems exist. An inventory of every AI system in the organisation, including the ones bought inside other software and the ones a department started without telling anyone. Shadow AI is the norm rather than the exception, and an inventory that only lists the projects IT knows about is a partial answer to a total question.
What each one is allowed to decide. The boundary between advisory and determinative. A model that scores an application for a human to review is a different regulatory object from one that declines it, and the distinction has to be recorded per system, not assumed.
How behaviour is evaluated over time. Data assets are stable; models are not. The same model with the same prompt behaves differently after an upgrade, and a system that passed acceptance six months ago may not pass today. Continuous evaluation is a governance control, not an engineering nicety.
What evidence exists. For each system: what data trained or grounds it, what it was tested against, what it does in production, and what happened in each incident. This is the material an auditor asks for, and it either exists as a by-product of design or it does not exist at all.
The inventory comes first
Every AI governance programme that works starts here, for the same reason every data governance programme starts with a system inventory: policy written before you know what exists is a document about an imaginary organisation.
The inventory has to include four categories, and the last two are where organisations are surprised.
Systems you built. Usually well known.
Models you host. Including the ones running on somebody's workstation as an experiment that quietly became load-bearing.
AI inside purchased software. Your CRM, your HR platform and your security tooling all contain models now. Their vendors' obligations do not become your defence when a decision affects a customer.
AI used by staff informally. Employees pasting internal material into public chat interfaces. This is a data leakage problem that presents as an AI governance problem, and finding it requires network evidence rather than a survey.
For each entry: owner, purpose, what data it touches, whether it decides or advises, and who is affected. That is the register, and it is the artefact everything else attaches to.
Risk tiers, and why they carry the weight
Not every system needs the same controls, and a programme that treats them equally will either strangle low-risk work or under-control high-risk work. Three tiers are usually enough.
Low risk — internal productivity, no personal data, no decision affecting a person. Light controls: registration in the inventory, a named owner, an acceptable use policy.
Medium risk — touches personal data or informs decisions that affect people, with a human making the final call. Full controls: documented data sources, evaluation before release, monitoring, per-user permission enforcement at retrieval, audit logging.
High risk — determines an outcome for a person: credit, employment, eligibility, access to a service. Everything from medium, plus formal impact assessment, explainability appropriate to the decision, a documented appeal route, and periodic revalidation.
The tiering is what makes the programme survivable. Applying high-risk controls universally produces a process everyone routes around, which is worse than no process because it also hides the systems.
The controls that matter most
Five, ordered by how often their absence causes an actual incident.
Per-user permission enforcement at retrieval time. The single most important control in enterprise AI. When retrieval runs under a shared service account, the vector store becomes a permission-flattening machine: documents from across the organisation sit in one index, and any user who can phrase a question can reach any of it. Enforcement must happen per request, under the requesting user's identity.
Request-level audit. Who asked, what was retrieved, which model and version answered, which tools were called with which arguments, what came back. Cheap to build now, impossible to reconstruct later, and the first thing an auditor asks for.
An evaluation harness. Fifty to a hundred real cases from your own domain, run before every model change. Without it, an upgrade is a gamble taken in production, and models change more often than your system will.
Human oversight that is real. A human approval step that approves 99.8% of cases is not oversight; it is a signature. Design the review so the reviewer has the information and the time to disagree, and measure the disagreement rate — if it is near zero, the control is decorative.
Change control on models. A model version is a configuration item. Which version is in production, when it changed, who approved it, what the evaluation showed. Organisations that manage prompts and model versions casually cannot explain past behaviour, and past behaviour is exactly what gets asked about.
The standards landscape
Two frameworks matter, and they do different jobs.
ISO/IEC 42001 is the management system standard for AI — the certifiable one. It carries 38 AI-specific controls organised under nine control objectives, numbered A.2 to A.10, covering policy, internal organisation, resources, impact assessment, lifecycle, data, information for interested parties, use of AI systems, and third-party relationships. Organisations with an existing ISO 27001 management system typically reach 42001 certification in four to six months, against six to twelve months starting cold, and published cost ranges run $85,000–$150,000 for a 50–200 person organisation and $180,000–$320,000 for mid-market. The detail is in the ISO 42001 audit.
The EU AI Act is law rather than a standard, and applies to Azerbaijani companies serving EU clients. Its timing changed: the Digital Omnibus, adopted as Regulation (EU) 2026/1744, deferred most high-risk obligations from August 2026 to December 2027 and August 2028, while transparency duties and GPAI enforcement began on 2 August 2026. The deadline moved; the obligations did not. See the EU AI Act for Azerbaijani companies.
Locally, Azerbaijan's Innovation and Digital Development Agency has approved an Artificial Intelligence Strategy for 2025–2028 naming data governance as a priority area, and a Digital Development Council held its first meeting on 29 June 2026 with the legislative framework for AI on its agenda.
Where AI governance programmes fail
Writing policy before taking inventory. The same failure as in data governance, with the same result.
Governing models and ignoring data. An AI system cannot be governed more tightly than the assets underneath it. If nobody can say which of four customer tables is authoritative, no amount of model documentation fixes the output.
Treating it as an ethics exercise. Principles documents are cheap and change nothing. The controls above are what an auditor asks about, and none of them are ethical positions.
One committee for everything. A single approval body for all AI becomes a queue, and a queue produces shadow deployments. Tier the risk and delegate the low tier.
Deferring audit logging. The one decision that cannot be corrected later. The record either exists from the start or the incident is unexplainable.
Key points
- AI governance decides which systems may exist, under what controls, with what evidence. It is an operating model, not a principles document.
- Start with an inventory that includes AI inside purchased software and informal staff use — not just the projects IT knows about.
- Tier by risk. Universal high-risk controls produce a process everyone bypasses, which hides systems rather than governing them.
- Per-user permission enforcement at retrieval is the control whose absence causes the most serious real incidents.
- Human oversight that approves 99.8% of cases is a signature, not a control. Measure the disagreement rate.
- ISO/IEC 42001 is the certifiable management system; the EU AI Act is law with deferred but unchanged obligations.
We advise on AI governance and implement the controls that make it evidenceable — see AI policy and governance. Related reading: what is AI orchestration and the ISO 42001 audit.