AI Governance Engineer
GitHub

Governance you can run, not just read.

An open reference architecture for turning AI safety, risk and policy claims into eval gates, runtime controls and machine-verifiable evidence.

Explore the Stack Open controls

Read the Thesis Frontier labs & evaluators

78 frameworks mapped
  • EU AI Act
  • NIST AI RMF
  • ISO 42001
  • ISO 23894
  • OECD AI Principles
  • GDPR
  • CoE Convention
  • TC260 Framework 3.0
  • Colorado ADMT
  • NYC LL 144
  • Singapore GenAI
  • Korea AI Act
  • Stack layers 5
  • Workflows 7
  • Chapters 24
  • Values 8
  • Frameworks mapped 78
  • Patterns 33
  • Body of Knowledge v0.5.0
  • License CC BY 4.0

The discipline, defined.

AI governance engineering is the application of engineering practice (systems thinking, product thinking and code) to the governance of AI systems.

  1. risk management obligation

    The EU AI Act's Article 9 risk-management duty is the obligation the loop exists to answer: a legal requirement stated in prose, not yet anything a running system can enforce.

    compiles to

  2. deny model.deploy unless eval.safety ≥ 0.95

    Policy-as-code compiles that obligation into an executable rule, so the requirement becomes a gate the pipeline applies rather than a paragraph someone must remember.

    scopes

  3. agent: support-bot · owner: platform

    The inventory is the registry of what is actually running, here the support-bot agent owned by the platform team, so every control and every piece of evidence attaches to a named, owned system.

    checks

  4. eval.safety 0.97 ≥ 0.95

    The eval gate runs the safety evaluation and checks the result against the policy threshold, which turns a measurement into a pass/fail decision the build must respect.

    gates

  5. guardrails on · tools scoped · trace ok

    Runtime controls keep the governed behaviour true after deploy (guardrails on, tools scoped, traces intact), so the promise made at the gate holds while the agent is live, not only at release.

    emits

  6. attestation issued · signed

    The evidence store captures the signed attestation as a machine-readable record produced as a by-product of the build, so the proof that the controls fired exists before anyone asks for it.

    attests

  7. audit = a query

    For the auditor the whole loop collapses to a query against that evidence: assurance becomes something a regulator can read as data, not a screenshot reassembled after the fact.

Evidence closes the loop, back to the obligation.

Seven steps, from obligation to auditor. Read how the governance loop works

What is AI governance? → Open the Body of Knowledge → See the open controls →

Three questions define the discipline.

Legacy AI governance leaves them unanswered because nothing is connected to production. The engineer answers all three from the running system.

  1. 01

    What AI is running?

    A runtime-aware registry of every model, service and agent (each with an owner, a scope and a status), written by the deployment pipeline, not typed into a spreadsheet.

  2. 02

    What is it allowed to do?

    Governance rules written as executable policy and enforced at runtime, under each agent's own identity and scope, so a bad release or an out-of-scope call is blocked at the earliest point it can be, not discouraged in a review.

  3. 03

    What evidence proves it?

    Structured eval results and machine-readable evidence emitted as the build runs, so assurance is a live query rather than a point-in-time attestation assembled by hand.

A build order, from policy to proof.

The stack is five layers that answer the three questions. Evidence is produced at the bottom and flows up; three layers are established engineering practice, two are new to AI.

Build order

01Govern-as-Code02Inventory & Transparency03Evals & Red Teaming as Evidence04Runtime Controls & Observability05Assurance & Continuous Compliance
  1. Govern-as-CodeestablishedWrite the rule as codePolicy-as-code libraryCrosswalksCI/CD wiringA structured policy verdict
  2. Inventory & TransparencyestablishedInventory what is runningAgent registryTransparency documentsAIBOMFRIA and DPIA references
  3. Evals & Red Teaming as EvidencenewRun evals as evidenceEval suites and the eval gateCapability and quality evalsAdversarial and red-team evalsSafety-threshold evals
  4. Runtime Controls & ObservabilitynewHold the line at runtimeGuardrailsObservabilityAgent runtime identity
  5. Assurance & Continuous ComplianceestablishedClose with continuous assuranceMachine-readable evidenceFramework mappings generatedIncident and reporting plumbing

Explore the stack →

Where AI Governance Engineering operates.

Three surfaces where a governance claim becomes something that runs: the evaluation gate, the runtime control and the assurance record.

  1. Layer 03

    Evals

    Evaluation results become evidence when the metrics and thresholds are fixed before the run and a failure blocks the release.

  2. Layer 04

    Runtime

    Every model, tool call and agent runs under an identity, a scope and a stop handle, enforced at the point where it acts.

  3. Layer 05

    Assurance

    Controls emit structured records as they run, so conformity is a query over evidence rather than a document assembled by hand.

Browse the open controls → For frontier labs and evaluators →

Eight values, each a commitment made on purpose.

Governance is code, not a document

Policy documents describe a control; code runs it, versioned and enforced without anyone remembering to, and only what runs can be measured.

established

Evals fail builds; reviews only recommend

A review can only recommend; an eval returns a verdict with consequences, and a failure blocks the release the system did not pass.

new

Evidence comes from runtime, not from a point-in-time attestation

A point-in-time attestation says a control was in place when someone looked; runtime evidence shows it working continuously, emitted by the system as it runs.

Every agent carries its own identity and scope

Shared credentials make an actor ungovernable; a distinct identity and a declared scope are what make its actions attributable and its access revocable.

new

Evidence is machine-readable or it is not evidence

Screenshots and exported spreadsheets cannot be queried or verified at speed; only machine-readable artefacts turn the audit into a query.

established

Tooling must be inspectable and composable

A black box asks you to trust a verdict you cannot trace; inspectable, composable tooling lets you follow the decision and wire it into your own pipeline.

Success is measured in realised risk reduction, not framework coverage

Framework coverage proves you have read the framework, not that any risk fell; success is the failure mode dropping, the blast radius shrinking, the incident caught earlier.

established

Governance is owned with engineering, not enforced from outside

Gatekeeping from outside is a bottleneck engineers route around; governance owned jointly with engineering becomes the paved path, part of how things are made.

Read the principles →

The role is a capability first, a job title second.

The person, on whatever org chart, who holds the capability of AI governance engineering and is accountable for the three questions in production: what AI is running, what it is allowed to do, and what evidence proves it.

Seven workflows

  1. Intake and classification
  2. Inventory and registry
  3. Evals and red teaming as evidence
  4. Policy-as-code and gates
  5. Runtime monitoring and incidents
  6. Assurance and audit evidence
  7. Regulatory translation
USD 221k Median technical AI-governance salary, tech sector (highest band) IAPP Salary & Jobs Report 2025-26 USD 151.8k Median AI-governance salary (work generally) IAPP Salary & Jobs Report 2025-26 USD 169.7k Median combined privacy-and-AI-governance salary IAPP Salary & Jobs Report 2025-26

What an AI governance engineer does → Start the learning path → See the whole map →

Every control on this site can fail a build, block a release, or sign an attestation.

BLOCK PASS

24 chapters in five parts, versioned and open.

The Body of Knowledge is at v0.5.0 and published under CC BY 4.0. Foundations, The lifecycle, and Law and standards carry the discipline from what an AI system is, through its life, to the law that binds it.

  1. The discipline

    Chapters 00–07

    What AI governance engineering is, why it is forming now, and how it is built, staffed and measured.

    1. Preface
    2. Definition
    3. Why Now
    4. Values & Principles
    5. The Stack
    6. Patterns
    7. The Role
    8. Maturity Model

  2. Reference

    Chapters 08–10

    The indexes the rest of the book points into: the regulatory map, the glossary and the reading list.

    1. Regulatory Map
    2. Glossary
    3. Reading List

  3. Foundations

    Chapters 11–13

    What counts as an AI system, how an organisation runs its governance program and where risk management sits.

    1. AI Defined
    2. Governance Program
    3. Risk Management

  4. The lifecycle

    Chapters 14–17, 23

    Governing a system from use case to retirement: development, deployment, fairness, incidents and agents.

    1. Development
    2. Deployment
    3. Fairness & XAI
    4. Incidents
    5. AI Agents

  5. Law and standards

    Chapters 18–22

    The EU AI Act, data protection, the law that already applies, AI laws worldwide, and the principles and standards.

    1. EU AI Act
    2. Privacy & AI
    3. Existing Law
    4. AI Laws Worldwide
    5. Principles & Standards

Browse the chapters by part →

Curated resources, cross-referenced, in the open.

All resources →

What applies now.

The EU AI Act, read from the obligation register: what already applies, and the next three dates with what each one switches on.

Applies today Arts. 3(1), 4, 4a, 5, 50, 52, 53, 53(1)(c), 54, 55, 60, 87

    • New bans on AI-generated NCII and CSAM apply Art. 5
    • Marking grace for existing systems ends Art. 50

    • GPAI models placed on the market before 2025-08-02 comply by this date (Art. 111(3)) Arts. 52, 53, 53(1)(c), 54, 55

Dates as the register states them, last reviewed 24 Sep 2026. Indicative, not legal advice and not a claim of conformity.

The obligation register → Full timeline → The post-Omnibus timeline → Routes by audience →

Follow the changes.

Every chapter shows the date it last changed, and every release is written up in the changelog. Get an email when a chapter changes, or follow the feed.

Open work

  1. Evaluation Environment Control Profile

    Draft v0.1 Updated

    Nine draft control specifications for the environment a model or agent is evaluated in; open for technical review.

  2. Agent Runtime Control Profile

    Draft v0.2 Updated

    Forty-two reference controls derived from the agent controls of chapter 23; every control is a draft.

  3. The evaluation environment is part of the system

    Draft v0.1.0 Updated

    A research note on why an evaluation that ignores the harness, tools, credentials and network measures only part of the system.

  4. Frontier labs and evaluators route

    Draft Updated

    Where the controls, patterns and evidence formats on this site apply to evaluating and deploying frontier systems.

  5. Incident notes on three cases

    Draft Updated

    System boundary, control assumptions and the controls that would have caught each failure, for three incident cases.

  6. Four planned research notes

    Planned Updated

    Themes listed on the research index and not yet written.

RSS feed → Changelog → Contribute →

Open, versioned, contributable.

The Thesis and Body of Knowledge are CC BY 4.0. Read them, use them, send a pull request.

Contribute on GitHub Follow on LinkedIn