What an AI Governance Engineer does.

The workflows

Seven workflows the role owns.

The engineer owns workflows, not documents — each a running system with inputs, outputs and a stack layer it maps to.

1. 01 Layer 02

   Intake and classification

   Every AI system, model and agent enters through an intake that classifies it by risk tier, regulatory exposure, data sensitivity and autonomy. The engineer builds intake as a form-plus-code path that scaffolds a registry entry, triggers the right impact assessment and routes the system to the controls its class requires.

   Read in chapter 06 →
2. 02 Layer 02

   Inventory and registry

   The engineer owns the inventory of models and the agent registry — every non-human actor with an owner, a declared scope, a status and a kill switch. What distinguishes the engineer is the runtime data path: the registry is fed by the deployment pipeline and by discovery against production, not typed into a spreadsheet.

   Read in chapter 06 →
3. 03 Layer 03

   Evals and red teaming as evidence

   The engineer builds and maintains the eval suites — capability, safety and adversarial — and wires them into an eval gate so a failing eval blocks the release. This is the workflow that most sharply separates the engineer from the analyst: the engineer writes the test the model must pass and owns the harness that runs it.

   Read in chapter 06 →
4. 04 Layer 01

   Policy-as-code and gates

   The engineer expresses governance rules as executable policy that evaluates in CI/CD and at admission, and maintains the gates that enforce them. The output is a merge that is blocked or allowed, with a logged reason — not a recommendation in a review.

   Read in chapter 06 →
5. 05 Layer 04

   Runtime monitoring and incidents

   The engineer instruments runtime: guardrail decisions, tool-call mediation, drift signals and agent behaviour stream into observability. They own the detection-to-report path for serious incidents, including the Article 73 clock for high-risk systems, and the tested kill switch for agents.

   Read in chapter 06 →
6. 06 Layer 05

   Assurance and audit evidence

   The engineer emits audit-ready evidence as a by-product of the build — OSCAL component and assessment artefacts, signed logs, structured eval results — so the audit is a query, not a project. This is continuous assurance: the control status is a live signal, not a point-in-time attestation.

   Read in chapter 06 →
7. 07 All layers

   Regulatory translation

   The engineer reads the obligation well enough to build the control that meets it — turning an AI Act article, an ISO/IEC 42001 control or a NIST AI RMF subcategory into a gate, a registry field or an evidence artefact, and back, so an auditor can trace the control to the obligation. This is translation, not legal advice.

   Read in chapter 06 →

The skills

Core and supporting skills, by workflow.

Read in chapter 06 →

Analyst versus engineer

One line separates the two.

The AI governance analyst describes the system from the outside and files the description; the AI governance engineer reads the system directly and ships the control that changes what it does.

Read in chapter 06 →

Three ways in

Convert from an adjacent discipline.

• 01

  From Legal or privacy

  Your edge is regulatory translation; your gap is the build. Turn one assessment into a versioned, executable artefact and learn enough pipeline to see where the control fires — start at policy-as-code and intake.

• 02

  From Security or GRC

  Your edge is the control mindset; your gap is the model layer. Add the AI-specific objects — evals as controls, agent identity and scope, and the model and agent failure modes of the OWASP Agentic Top 10 — starting at evals-as-evidence and the agent registry.

• 03

  From MLOps or ML engineering

  Your edge is the runtime data path everyone else lacks; your gap is the obligation. Add the eval gate rather than the eval report, the registry field for owner and scope, and the evidence artefact the audit needs — start at eval gates in CI and runtime monitoring.

Read in chapter 06 →

What employers get wrong

Three tells in the job description.

1. 01
   BLOCK Certifications as a proxy for capability

   descriptions list AIGP, CIPP, CISSP and CISM as if a certificate produced a control, while under-specifying the load-bearing skills — eval harnesses, policy-as-code, the runtime data path.

2. 02
   BLOCK Analyst work under an engineer title

   many "AI Governance Engineer" postings describe intake, mapping and reporting at engineer pay; the tell is the absence of any build — no eval gate, no registry integration, no evidence pipeline.

3. 03
   BLOCK Everything, in one hire

   a single posting asks for policy-as-code, red teaming, identity, observability, incident response, regulatory translation and stakeholder management. That is a function, not a person; a first hire owns two or three workflows and builds the paved path for the rest.

Read in chapter 06 →

The market

What the primary sources report.

Also reported, as a demand signal rather than a headline figure: AI governance, year over year, up +150% — LinkedIn 2026 Skills on the Rise (reported via EdTech Innovation Hub).

The maturity ladder

From paper to production, in five levels.

Each level is assessed across all five stack layers; the overall level is the weakest layer.

1. 01

   Documented

   Governance exists as artefacts a human maintains — a policy PDF, a spreadsheet inventory, a risk register, a review before launch. The rules are written and someone is accountable, but nothing executes.

   • Policy documents
   • A populated spreadsheet inventory
   • Meeting minutes
2. 02

   Inventoried

   There is a real inventory of models and an agent registry, fed by a runtime data path rather than typed by hand: a deploy registers a system with an owner, a scope and a status. You can answer what is running on any given day.

   • A registry with an owner and a class for every system
   • A discovery job reconciling registry against production
3. 03

   Tested

   Systems are evaluated against defined tests — capability, safety and adversarial evals — and the results are recorded as evidence. Failures are visible, but a failing eval does not yet stop anything.

   • Versioned eval suites
   • Stored, timestamped eval results
   • Red-team findings
4. 04

   Enforced

   The tests bite: policy-as-code and eval gates run in CI/CD and at admission, and a failing control blocks the merge or the deploy. Identity precedes autonomy, and the gating suites’ own coverage and adversarial quality are assessed, not just their existence.

   • Pipeline logs showing blocked releases with reasons
   • Admission-control denials
   • The registry acting as a deploy gate
   • A tracked coverage or adversarial-quality metric for the gating suites
5. 05

   Continuous

   Assurance is produced continuously from the runtime data path: guardrail decisions, drift and agent behaviour stream into observability, and evidence is emitted as machine-readable artefacts as the pipeline and runtime operate. The audit is a query.

   • A live assurance store
   • Streaming eval and guardrail telemetry
   • An audit answered by running a query

Read the maturity model in chapter 07 →