AI governance learning path, one stage at a time.

AI governance engineering applies engineering practice (systems thinking, product thinking and code) to the governance of AI. Start here, and learn what separates it from AI safety, MLOps and compliance.

Every control in the stack answers one of three questions: what AI is running, what it is allowed to do, and what evidence proves it. Learn to hold all three in production.

The thing being governed changed shape, from models you call to agents that act, and the market named the role before the profession named itself. Read why the discipline is forming now.

The eight values and six principles the thesis commits to, each paired with the anti-pattern it rejects. This is the value grammar the rest of the path builds on.

The reference architecture: five layers that answer the three questions, with evidence produced at the bottom and assurance closing at the top. Learn to read the stack before you build in it.

The analyst describes the system from the outside and files the description; the engineer reads the running system and ships the control that changes what it does. Know which side of the line each task sits on.

Python is the cross-cutting skill under every workflow: enough to glue systems together, script an intake, or run an eval harness. You do not need to be a software engineer, but you do need to read and write it.

Version control and CI/CD are where governance rules become gates: a merge blocked or allowed, with a logged reason. Learn the pipeline the controls fire in.

Reading regulation and standards well enough to build the control that meets them, parsing an AI Act article or an ISO/IEC 42001 control without mistaking it for legal advice. This is translation, not law.

Enough of how models and agents work (context, tools, autonomy) to see where a control has to fire. The agent shift is what makes runtime identity and scope non-optional.

Every system enters through an intake that classifies it by risk tier, regulatory exposure and autonomy, then routes it to the controls its class requires. Build intake as form-plus-code, not a questionnaire.

The runtime-aware inventory of every model, service and agent (each with an owner, a declared scope, a status and a kill switch), fed by the deployment pipeline, not typed into a spreadsheet.

Transparency artefacts as build outputs: an AIBOM for what an AI system is made of, and model and data cards as control evidence. Generate them, do not hand-write them.

The AI you do not know about is the AI you cannot govern. Discovery finds unregistered models and agents in production and feeds them back into the registry.

Express governance rules as executable policy that evaluates in CI/CD and at admission. OPA/Rego is the most common engine; the output is a structured allow/deny verdict tied to a commit.

Cedar is an alternative policy language for the same job: authored rules, evaluated against structured input, with a machine-readable verdict. Choose it where its authorization model fits better than Rego.

Machine-readable governance artefacts that describe a policy's intent and scope in a schema an agent runtime can consume directly. An emerging way to make policy portable across the stack.

A policy is not a control; a gate that can block the build is. Wire policy-as-code into CI and admission control so a failing rule stops the deploy with a logged reason.

Turn a fundamental-rights or data-protection impact assessment into a versioned, executable artefact generated from a template, cross-referenced to the registry entry, not filed as a one-off document.

Build and maintain the eval suites (capability, safety and adversarial) and the harness that runs them. This is the workflow that most sharply separates the engineer from the analyst.

Wire the eval suite into CI so a failing eval blocks the release, versioned alongside the model it tested. Know the limits too: an eval gate proves what it measures, not everything.

Adversarial testing as evidence: jailbreaks, prompt injection and tool misuse, run as repeatable probes rather than one-off exercises. The findings feed the guardrails and the threat model.

Start from a named failure mode or a named harm, then work back to the control. Threat models for AI draw on catalogues of agent and model techniques rather than generic checklists.

Input and output filters and tool-call mediation at the enforcement point: the runtime line that holds when an eval or a policy is not enough. Configure them against the failure modes red teaming found.

Turn agent behaviour into a control signal: traces, guardrail decisions and drift, streamed through OpenTelemetry into observability. The runtime data path is what makes the registry and the evidence live.

Every agent under its own workload identity with a bounded scope, not a shared human credential. Paired with a tested kill switch, this is among the cheapest controls with the largest blast-radius reduction; non-human identity is the precondition of agent governance.

A tested way to stop an agent, and a human-in-the-loop checkpoint where the stakes require one. Article 14 oversight is a design problem, not a paragraph.

The Model Context Protocol connects agents to tools, and every connection is attack surface. Learn to secure the protocol before you let an agent act through it.

Detection-to-report plumbing for serious incidents, including the reporting clock for high-risk systems. The evidence is captured as the incident runs, not reconstructed afterwards.

Emit audit-ready evidence as a by-product of the build (machine-readable OSCAL component and assessment artefacts), so the audit is a query, not a project.

Structured, signed and tamper-evident logs are what make evidence hold up later. Signing and attestation turn a log line into something an auditor can trust.

Map one control to the many obligations it serves (an AI Act article, an ISO/IEC 42001 control, a NIST AI RMF subcategory), so an auditor can trace the control back to the obligation. Generate the crosswalk from the evidence, do not maintain it beside it.

Assurance produced continuously from telemetry, not a point-in-time attestation: control status as a live signal any lower layer writes into and an auditor reads from. This is the top of the maturity ladder.

General-purpose models with systemic risk carry their own evaluation, red-teaming and incident obligations. A specialisation for anyone governing frontier or foundation models.

Most AI is procured, not built. A due-diligence gate asks a supplier for the same evidence you would produce yourself (an AIBOM, evals, a control mapping) before the system enters.

Score where your programme sits on the ladder from paper to production, and read the next rung as concrete engineering work. A capstone that turns the path into a plan.

A team of one cannot build all five layers at depth, but it can build the spine thinly, end to end. One vertical slice that touches every layer beats one layer built out and four left on paper.