Governance you can run, not just read.
AI governance engineering is the application of engineering practice — systems thinking, product thinking and code — to the governance of AI systems.
An evidence chain: a policy denies model deployment unless the safety eval scores at least 0.95; the registry lists agent support-bot, model gpt-class, owner platform; the safety eval scores 0.97; runtime guardrails hold the line; and assurance stamps the verdict PASS.
The three questions
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.
-
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.
-
02
What is it allowed to do?
Governance rules expressed as executable policy that evaluates in CI/CD and at runtime, so a bad release is blocked at the earliest point it can be — not discouraged in a review.
-
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.
The stack · five layers
A build order, from policy to proof.
Five layers that answer the three questions. Evidence is produced at the bottom and flows up; three layers are inherited from GRC engineering, two are new to AI.
- Govern-as-CodeinheritedWrite the rule as codePolicy-as-code libraryCrosswalksCI/CD wiringA structured policy verdict
- Inventory & TransparencyinheritedInventory what is runningAgent registryTransparency documentsAIBOMFRIA and DPIA references
- Evals & Red Teaming as EvidencenewRun evals as evidenceEval suites and the eval gateCapability and quality evalsAdversarial and red-team evalsSafety-threshold evals
- Runtime Controls & ObservabilitynewHold the line at runtimeGuardrailsObservabilityAgent runtime identity
- Assurance & Continuous ComplianceinheritedClose with continuous assuranceMachine-readable evidenceFramework mappings generatedIncident and reporting plumbing
Values
Eight values, each a trade made on purpose.
Governance-as-code over policy documents
inheritedEvals that can fail the build over reviews that can only recommend
newRuntime evidence over point-in-time attestations
Agent identity and scope over shared credentials
newMachine-readable evidence over screenshots
inheritedInspectable, composable tooling over black boxes
Measured risk reduction over framework coverage
inheritedShared ownership with engineering over gatekeeping
The role
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
- Intake and classification
- Inventory and registry
- Evals and red teaming as evidence
- Policy-as-code and gates
- Runtime monitoring and incidents
- Assurance and audit evidence
- Regulatory translation
A policy is not a control. An eval that can fail the build is.
Body of Knowledge · v0.2 · CC BY 4.0
Eleven chapters, versioned and open.
- 00 Preface Why this book exists, who it is for, and how to use it.
- 01 The definition AI governance engineering is the application of engineering practice — systems thinking, product thinking and code — to the governance of AI systems.
- 02 Why now AI governance engineering is forming now because the thing being governed changed shape, the market renamed the role before the profession named itself…
- 03 Values and principles The eight values and six principles of the manifesto, each expanded with what it means in practice and the anti-pattern it rejects.
- 04 The stack (five layers) The reference architecture of AI governance engineering: five layers that answer the three questions, where evidence is produced at the bottom…
- 05 Patterns A catalogue of reusable AI governance engineering patterns, each named to a layer of the stack, in the CSIRO Responsible AI Pattern Catalogue structure.
- 06 The role The AI governance engineer as a concrete role: a capability first and a job title second, defined by the workflows it owns and the evidence it produces…
- 07 Maturity model (five levels) A ladder from paper to production — Documented, Inventoried, Tested, Enforced, Continuous — where each level is proven by what the running systems show…
- 08 Regulatory map (obligation → artefact → layer) The reverse index of every "Maps to" line in the book: for each obligation it names the engineering artefact that satisfies or supports it…
- 09 Glossary The canonical definitions for the book: every term defined once, alphabetically, and cross-referenced to the chapter that treats it in full.
- 10 Reading list The sources that formed the discipline, curated and annotated — each with a verified URL and a one-line note on why it matters.
Resources
Curated, cross-referenced, in the open.
- Frameworks The obligations — EU AI Act, ISO/IEC 42001, NIST AI RMF — mapped to the artefacts that satisfy them.
- Tools Reference tool categories per layer, from policy engines to eval harnesses and evidence formats.
- Reading list The sources that formed the discipline, each with a verified link and a one-line note.
- Glossary Every term defined once, cross-referenced to the chapter that treats it in full.
Open, versioned, contributable.
The Manifesto and Body of Knowledge are CC BY 4.0. Read them, use them, send a pull request.