AI Governance Operating Model & AIMS Reference Architecture

Imagine every control plane is built. PII is masked. RAG respects permissions. Guardrails block prompt injections. The audit trail writes to immutable storage. Budgets hold. Content is labeled. Quality is measured. The supply chain sits under an AIBOM. The agent sits behind a policy gate. Six months in, an ISO 42001 audit arrives — and there is 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. From nobody having been assigned to maintain or audit them.

This is the final, operating plane. The technical patterns from the earlier chapters 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): owners, a lifecycle, a system registry, policy-as-code, and auto-generated evidence. It delivers the capstone: the full reference architecture of Kovcheg.

The Business Goal

Turn a set of controls into a managed system that survives a specific engineer leaving and passes an audit without a scramble. Business outcomes:

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: Regulator and Drift

ISO/IEC 42001: a certifiable AIMS is a requirement in ~40% of EU enterprise RFPs (2026).

EU AI Act: Art. 9 (Risk Management System), Art. 17 (Quality Management System), Art. 72 (post-market monitoring), Art. 11–12 (documentation and logs).

Organizational drift: without owners and process, controls go stale. ACL lags. The dataset ages. The kill-switch goes untested. This is 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 the underlying planes.

Engineering Stack

AIMS/GRC: ISO 42001-aligned processes; risk and policy trackers.
Registry: MLflow Registry or an internal AI system registry.
Policy-as-code: OPA/Rego as the shared gate language.
Evidence: the audit log, eval reports, AIBOM, and red-team results combined as automatic evidence.

Engineering Implementation

Step 1. An AI System Registry

Every system (Kovcheg RAG, Kovcheg agent) is a record. It carries a risk class, an owner, a lifecycle status, and links to its controls and evidence.

Step 2. RACI Governance

Define who owns the risk, who approves a release, who holds the kill-switch, and who is accountable for evals. A governance board is a process with authority. An owner without the power to block a release is decorative. This is a common failure.

Step 3. Policy-as-Code as One Shared Layer

Consolidate the OPA policies into a single versioned repository. A policy change is a PR, a review, and a new version. Governance itself is under audit.

Step 4. Lifecycle & Gates (State Machine)

dev → risk-classification → security-gate → eval-gate
    → release → post-market monitoring → retire

Every transition is an explicit, observable state, with technical documentation auto-generated from the artifacts. This is not an "if" buried in a CI script. It is an external status.

Step 5. Post-Market Monitoring, Closed Onto the Policies

The drift, incident, and feedback loop updates the registry, the RMS, and the policies themselves. An incident triggers a new red-team case and a new OPA rule. The registry, RMS, and policies are updated from incidents.

Step 6. Kovcheg's Reference Architecture (Capstone)

A full diagram of the control plane: how the individual planes fit together into one request path and one evidence layer. This is the map an audit can walk through end to end.

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. 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. Governance competes with convenience; if the legal path is painful, people route around it.
A registry drifting from reality without auto-discovery of systems.

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.
The output is the "requirement → control → evidence" matrix.

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.

The Capstone Artifact

Assemble Kovcheg's reference architecture: a registry of two systems with risk classes and owners, RACI, a single policy-as-code repository, lifecycle gates in CI, and auto-generated technical documentation. The course's final artifact is the Kovcheg AIMS dossier — one folder an audit can be walked through from: classification, controls, evidence, owners, the incident process.

What's Next

The course delivered the control plane and the operating model on top of it. Next: 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. That is outside this course's enterprise perimeter.

Sources

Every control plane you build will eventually assemble into one operating model — an AIMS plus policy-as-code. The engineering leader who owns governance end to end is the one who decides whether that assembly happens by design on a Tuesday, or by scramble the night before an audit.

Governance Operating Model & AIMS: How to Assemble a Control Plane That Survives Entropy