AI governance: decision rights, evidence, and control

AI governance is the allocation of decision rights over AI systems, combined with evidence that those decisions are being followed. Decision rights: who may put a model in front of customers, which data may reach which providers, what testing is required before deployment, who signs off on a high-impact use case. Evidence: registries, evaluation results, audit trails, decision records that prove the answers are enforced rather than aspirational.

Everything else sold under the name, ethics statements, principle posters, steering committees without budgets, is decoration.

I say that as someone who spends much of his working time inside enterprise AI programs, not as a cynic about the subject. Governance done properly is the thing that lets an organization move fast with AI, because engineers stop relitigating the same questions on every project. Governance done as paperwork slows everything down and controls nothing. The difference between the two is the subject of this page, and of the cluster of articles it anchors.

What governance actually is

Strip away the vocabulary and governance answers five questions, in writing, with a named owner for each answer:

1. Which AI systems do we have? An inventory. Most organizations cannot answer this today, which is why shadow AI is discovered in incident reports and expense lines rather than registries.
2. Who may approve what? A model, a data source, a use case, a vendor. Decision rights, explicitly allocated, so approval is a lookup rather than a negotiation.
3. What must be true before deployment? Testing thresholds, security review, data-classification checks, documentation. The pre-deployment gate.
4. What must stay true after deployment? Ongoing evaluation, drift monitoring, audit logging, incident response. The part almost everyone underweights, because deployment is exciting and operation is not.
5. What is the evidence? For every answer above, an artifact a skeptical third party could inspect. Not a slide. An artifact.

Notice what is absent from that list: any statement of values. Values matter, but they enter governance only when translated into a decision right or a control. “We use AI responsibly” governs nothing. “Customer-facing systems must pass the golden eval set at threshold X, and the results are retained for two years” governs something. My deeper treatment of that translation, policy-as-code, model cards, review gates that behave like CI checks, is in AI governance engineers won’t route around.

The artifact set

Governance is built from a small number of concrete artifacts. If a program cannot show you these, it does not matter how mature its committee structure looks.

Artifact	What it proves	Where it lives
System inventory	You know what AI you run	A registry, not a spreadsheet email thread
Approved-model registry	Data-to-model routing is deliberate	Enforced at a gateway, not in a PDF
Model / system cards	Intended use, non-uses, current eval state	Version control, next to the system
Eval gates	Behavior meets thresholds before and after ship	CI and scheduled production runs
Audit trail	Who asked what, which model answered, with what context	Structured logs with retention
Decision records	Why a use case was approved or declined	Lightweight ADR-style documents
Incident path	AI failures have an owner and a process	Your existing incident tooling

Two properties matter more than the list itself. First, each artifact is a byproduct of operating, not a separate reporting exercise; the moment compliance evidence requires archaeology, it decays. Second, each artifact is checkable by someone who distrusts you. That is the standard regulators, auditors, and, frankly, your own future engineers will apply.

The gate thresholds come from somewhere, and that somewhere is risk analysis: deciding which failure modes are expensive enough to prevent and which you will accept. That prioritization discipline is its own topic, covered in AI risk management for engineers, and the evaluation machinery that turns thresholds into pass/fail signals is covered in evaluating AI systems in production.

The regulatory picture, factually

Two reference points dominate the current environment, and it is worth being precise about what each one is.

The EU AI Act is law. It entered into force on 1 August 2024 as Regulation (EU) 2024/1689, the first horizontal AI statute from a major jurisdiction. It is risk-tiered: some practices are prohibited outright, high-risk systems carry substantial obligations (risk management, data governance, logging, human oversight, conformity assessment), and lower-risk systems carry mostly transparency duties. Obligations phase in over several years rather than landing at once, with prohibitions applying first and the bulk of high-risk requirements following in 2026 and 2027. If you sell into or operate in the EU, the artifact set above is not optional; the Act effectively demands documented risk management, logging, and technical documentation for in-scope systems.

The NIST AI Risk Management Framework is not law. Published in January 2023 as a voluntary framework, it organizes AI risk work into four functions, Govern, Map, Measure, Manage, and was extended in 2024 with a generative-AI profile. Its value is vocabulary: it has become the common language US enterprises, auditors, and increasingly regulators use to discuss AI risk. Treat it as a checklist and you will produce paperwork. Treat it as a structure for controls you already need and it earns its keep.

ISO/IEC 42001, published in late 2023, adds a certifiable management-system standard in the same territory. My honest read: the frameworks converge on the same artifact set. An organization that builds the registry, the gates, the logs, and the decision records can map that evidence onto whichever framework a customer or regulator asks about. An organization that starts from the framework text usually builds documents instead of controls.

How governance, integrity, risk, and evaluation fit together

These four words get used interchangeably, and they should not be. The relationship is a stack:

Governance   — who decides, and what evidence proves enforcement
Risk         — which failures are worth money to prevent
Integrity    — the engineering property: system behaves as specified,
               within bounds, observably, under adverse conditions
Evaluation   — the measurement machinery that tests the property

Integrity is the property you are actually trying to achieve; I define it carefully in the AI integrity engineering framework, and the formal version, a reference model connecting the layers for enterprise use, is in the AI Integrity Reference Model whitepaper. Risk analysis decides where integrity investment goes first. Evaluation measures whether you are getting it. Governance wraps the whole thing in decision rights and evidence so the answers survive personnel changes, audits, and incidents.

The practical consequence: you cannot buy governance as a product, because three of the four layers are engineering work on your own systems. Vendors sell useful components, gateways, eval harnesses, logging. The decision rights and the accountability are yours.

One more relationship worth naming. Governance is also the thing that makes AI adoption scale beyond pilots. Most enterprise AI initiatives stall not on model quality but on unanswered questions: whose data, whose risk, whose budget, whose accountability. A governance structure that answers those questions once, in writing, is what separates organizations that ship from organizations that demo. That argument is developed in the enterprise AI adoption framework.

Where governance programs fail

The failure modes are consistent enough to list.

Committee theater. A governance board that reviews slide decks monthly but owns no gateway, no CI gate, and no budget. Engineers learn the board approves whatever is presented confidently, and route around it.

Policy without enforcement points. A rule that exists only in a document is a suggestion. Every real rule needs a place in the request path or the delivery pipeline where it can say no.

Inventory decay. The registry was accurate at launch. Eighteen months later, half the AI in the building entered through SaaS features nobody classified as AI. Inventory is an ongoing operational process, not a one-time census.

Evidence archaeology. Compliance evidence assembled quarterly by hand. Within a year the assembly costs more than the controls, and leadership starts asking why governance is so expensive. Evidence must be a byproduct of normal operation or it will be cut.

Severity inversion. Heavy process applied uniformly, so an internal document summarizer faces the same review as a customer-facing decision system. Uniform friction teaches teams that the process is unserious. Tiering by impact is not a concession; it is the design.

Where to go deeper

The cluster this page anchors, organized as reading paths.

If you are standing up a governance program:

1. AI governance engineers won’t route around — the artifact set in implementation detail: policy-as-code, model cards, audit trails, NIST AI RMF functions mapped to engineering work.
2. AI risk management for engineers, not auditors — how to decide which controls matter first, without drowning in risk-register ceremony.
3. An enterprise AI adoption framework that survives contact — where governance sits inside the broader adoption problem.

If you are building or operating the systems being governed:

1. What is AI integrity? An engineering framework — the property governance exists to protect, defined precisely.
2. Evaluating AI systems in production — the measurement layer: eval gates, golden sets, drift detection.

If you need the formal treatment:

• The AI Integrity Reference Model whitepaper — the layered model connecting integrity, evaluation, and governance, written for architecture review and audit contexts.

The longer view

Every technology that matters eventually acquires a governance discipline. Finance got double-entry bookkeeping and audit. Aviation got airworthiness directives. Software got change management, and then, when documents proved too slow, CI/CD, which is change governance expressed as engineering.

AI is partway through the same transition, and the organizations getting it right are not the ones with the longest principle documents. They are the ones treating AI as infrastructure: inventoried, gated, logged, owned. Frameworks and statutes will keep changing; the EU AI Act will be amended, NIST will publish new profiles. The underlying requirement, decision rights plus evidence, will not. Build for that, and the frameworks become a mapping exercise instead of a crisis.