Chapter 10AI Governance course

Chapter 10. Governance Operating Model & AIMS: operating model and reference architecture (capstone)

Imagine every plane from earlier chapters is built: PII is masked, RAG knows the permissions, guardrails are in place, the audit trail is written, budgets hold, content is labeled, quality is measured, the supply chain sits under an AIBOM, the agent sits behind a policy gate. And six months in, an ISO 42001 audit arrives — and there's nothing to prove, because ACL sync silently broke in March, the golden dataset hasn't been refreshed since launch, the kill-switch has never been tested, and the credit module formally has no owner. The technical controls went stale, not from an attack but from nobody having been assigned to maintain or audit them.

This is the final, and most underrated, plane. The technical patterns from chapters 1–9 degrade without an operating model — not from attack, but from entropy. This chapter assembles them into an AI Management System (AIMS per ISO/IEC 42001): with owners, a lifecycle, a system registry, policy-as-code, and auto-generated evidence. And it delivers the capstone: the full reference architecture of Kovcheg.

The customer's business goal

Turn a set of controls into a managed system that survives a specific engineer leaving and passes an audit without a scramble. Promises to the business:

Every AI system has an owner, a risk class, and a lifecycle.
Governance is expressed as code and is itself versioned and audited.
Compliance evidence is generated automatically from live planes.

Driver: threat or regulator

ISO/IEC 42001: a certifiable AIMS is a requirement in ~40% of EU enterprise RFPs (2026).
EU AI Act: Art. 9 (RMS), Art. 17 (quality management), Art. 72 (post-market monitoring), Art. 11–12 (documentation/logs).
Organizational drift: without owners and process, controls go stale (ACL lags, the dataset ages, the kill-switch goes untested) — a silent failure of governance.

Architectural pattern

AIMS + Policy-as-Code Control Plane — an operating model layered over the control plane: policies are code and CI/CD gates; every AI system lives in a registry with roles and a lifecycle; compliance evidence is generated automatically from the artifacts of chapters 1–9.

Engineering stack & providers

AIMS/GRC: ISO 42001-aligned processes; risk/policy trackers.
Registry: MLflow Registry / an internal AI system registry.
Policy-as-code: OPA/Rego as the shared gate language (ch. 2, 3, 6, 9).
Evidence: the audit log (ch. 4) + eval reports (ch. 7) + AIBOM (ch. 8) + red-team results (ch. 3, 9) as automatic evidence.

Engineering implementation

### Step 1. An AI system registry

Every system (Kovcheg RAG, Kovcheg agent) is a record: risk class (ch. 6), owner, lifecycle status, links to its controls and evidence.

### Step 2. RACI governance

Who owns the risk, who approves a release, who holds the kill-switch, who's accountable for evals. A governance board is a process with authority, not a rubber-stamp meeting. An owner without the power to block a release is decorative (a common failure).

### Step 3. Policy-as-code as one shared layer

The OPA policies from chapters 2/3/6/9 are consolidated into a single versioned repository. A policy change is a PR + review + a new version. Governance itself is under audit.

### Step 4. Lifecycle & gates (state machine)

dev → risk-classification (ch.6) → security-gate (ch.3,8) → eval-gate (ch.7)
    → release → post-market monitoring (ch.7,8) → retire

Every transition is an explicit, observable state, with technical documentation auto-generated from the artifacts. Not an "if" in a CI script — an external status (the CLAUDE.md principle).

### Step 5. Post-market monitoring, closed onto the policies

The drift/incident/feedback loop (ch. 7–8) updates the registry, the RMS, and the policies themselves. An incident → a new red-team case + a new OPA rule. The system learns.

### Step 6. Kovcheg's reference architecture (capstone)

A full diagram of the control plane: how planes 1–9 fit together into one request path and one evidence layer. This is the map from _index.md, taken to the level an audit can walk through.

Where it breaks

Governance theater at a new level. A registry and a board exist, but the policies aren't enforced in production — the same "PDF vs. control plane" gap from ch. 0, again. The only cure is policy-as-code plus automatic evidence, not screenshots for the audit.
An owner with no authority — the role exists, but they can't block a release. A decoration.
An AIMS without automatic evidence turns back into a manual scramble for artifacts before an audit date — the same entropy, with a folder attached.
Over-governance. A process too heavy kills velocity → teams drift into Shadow AI (ch. 8). Governance competes with convenience; if the legal path is painful, people route around it.
A registry drifting from reality without auto-discovery of systems (the same AIBOM principle, ch. 8).

Standards and mapping

ISO/IEC 42001: the whole standard (AIMS, Annex A).
EU AI Act: Art. 9 (RMS), Art. 17 (QMS), Art. 72 (post-market), Art. 11–12.
NIST AI RMF: Govern (at the center).
Summary: the "requirement → control (chapter) → evidence (artifact)" matrix.

Lab and artifact (capstone)

Assemble Kovcheg's reference architecture: a registry of two systems with risk classes and owners, RACI, a single policy-as-code repository (policies from chapters 2/3/6/9), lifecycle gates in CI, auto-generated technical documentation from the artifacts of chapters 1–9. The course's final artifact — the Kovcheg AIMS dossier: one folder an audit can be walked through from: classification, controls, evidence, owners, the incident process. This is the course's capstone defense.

Maturity checklist

L1: an AI system registry and assigned owners exist.
L2: policy-as-code gates in CI, a lifecycle with statuses, automatic evidence from audit/eval/AIBOM.
L3: a certifiable AIMS, post-market monitoring closed onto the policies, a compliance matrix with live evidence, governance itself versioned and audited, auto-discovery of systems.

What's next

The course delivered the control plane and the operating model on top of it. The next horizon is cross-organizational governance: provenance and trust between agents from different companies, verifiable credentials for AI agents, industry codes of practice layered on top of the AI Act. But that's already past the enterprise perimeter this course started from — a separate conversation.

Sources

[ISO 42001 guide 2026 (Konfirmity)](https://www.konfirmity.com/blog/iso-42001)
[ISO 42001 vs NIST AI RMF vs EU AI Act (EC-Council)](https://www.eccouncil.org/cybersecurity-exchange/responsible-ai-governance/eu-ai-act-nist-ai-rmf-and-iso-iec-42001-a-plain-english-comparison/)
[Global AI Governance Comparison 2026 (GAICC)](https://gaicc.org/blog/ai-governance-comparison-eu-ai-act-nist-iso-42001/)

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this control plane on real code and a working artifact.

Cursor Rules as Governance: Keeping Standards When the Team Vibe-CodesRules as governance: holding the quality bar when the team vibe-codes.
The Skill That Onboards Other SkillsGovernance over the component lifecycle.
Google A2A Over Git: Production-Ready Agent Transport Across OrganizationsA2A over Git: cross-org agent transport — the 'what's next' horizon.

Putting AI into production under regulatory risk?

Designing the control plane for your system: privacy, access, guardrails, audit, EU AI Act / ISO 42001 compliance — as working architecture, not a policy PDF.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →