06. The role

Capability first, title second

The manifesto insists that AI governance engineering is a capability, not a job title — the same claim the parent discipline makes for GRC engineering, a capability anyone close to the build can develop¹¹. This chapter makes it concrete without contradicting that: a capability still lives in someone’s week — the tickets they own, the pipelines they maintain, the incidents they are paged for. So we describe the AI governance engineer as the person, on whatever org chart, who holds that capability and is accountable for the three questions in production: what AI is running, what it is allowed to do, and what evidence proves it.

The distinction matters because the title is still forming. The same work is advertised as “AI Governance Engineer”, “AI Risk Engineer”, “AI Evaluation & Governance Engineer”¹, “Responsible AI Engineer” and, inside GRC teams building the AI-forward version of their function, “GRC Engineer” with an AI mandate². A security engineer who writes the eval gate, a privacy engineer who turns a FRIA into code, an MLOps engineer who wires the registry to the deploy — each is doing AI governance engineering under a different title. We define the role by what it owns, not by what HR called the requisition.

One line separates it from its analyst neighbour, and the rest of the chapter earns that line: 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.

What the role owns, by workflow

The engineer owns workflows, not documents. Each workflow below is a running system with inputs, artefacts and evidence — and each maps to one of the five layers of the stack (chapter 04). Grouping responsibilities this way keeps the role honest: you own a workflow when you can be paged for it, not when your name is on a policy.

Intake and classification

Every AI system, model and agent enters through an intake that classifies it — by risk tier, by regulatory exposure (EU AI Act high-risk, GPAI, out of scope), by data sensitivity and by autonomy. The engineer builds intake as a form-plus-code path, not a meeting: a request that scaffolds a registry entry, triggers the right impact assessment (FRIA, DPIA), and routes the system to the controls its class requires. Live postings name exactly this — one VP role is scoped to “AI intake, classification and approval aligned to NIST AI RMF”³. Maps to Inventory & Transparency.

Inventory and registry

The engineer owns the inventory of models and the agent registry — the runtime-aware record of every non-human actor, each with an owner, a declared scope, a status and a kill switch. The capability that distinguishes the engineer here is the runtime data path: the registry is fed by the deployment pipeline and by discovery against production, not typed into a spreadsheet. Registry work appears verbatim in senior postings that ask for an “enterprise agent registry” and non-human identity governance⁴. Maps to Inventory & Transparency.

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 analyst reviews a model report; the engineer writes the test the model must pass and owns the harness that runs it (Inspect AI, promptfoo, Garak, Giskard, DeepEval, Ragas as category examples, illustrative not endorsed). The “AI Evaluation & Governance Engineer” role is defined around “automated testing harnesses and safety guardrails” and adversarial red-teaming¹. Maps to Evals & Red Teaming as Evidence.

Policy-as-code and gates

The engineer expresses governance rules as executable policy (OPA/Rego, Cedar, Policy Cards) that evaluate in CI/CD and at admission, and maintains the gates that enforce them. A public GRC engineering-manager posting frames the mandate as “translate policies into policy-as-code”⁵. The engineer’s output here is a merge that is blocked or allowed, with a logged reason — not a recommendation in a review. Maps to Govern-as-Code.

Runtime monitoring and incidents

The engineer instruments runtime: guardrail decisions, tool-call mediation, drift signals and agent behaviour stream into observability (Langfuse, Arize Phoenix over OpenTelemetry as examples). They own the detection-to-report path for serious incidents, including the EU AI Act’s Article 73 clock for high-risk systems, and they own the tested kill switch for agents. Postings scope this as “threat modelling, red teams, MCP security” and “incident response for LLM systems”⁴⁶. Maps to Runtime Controls & Observability.

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’s status is a live signal, not a point-in-time attestation. Maps to Assurance & Continuous Compliance.

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; the engineer depends on Legal to confirm the obligation is read right. Maps to all five layers; it is the spine that chapter 08 indexes.

Skills, by workflow

Skills are grouped by the workflow they serve, not by the certificate that teaches them. The table is a capability map: it says what you must be able to do, in rough order of how load-bearing it is for each workflow. It is illustrative, not a checklist to pass.

Two cross-cutting skills sit under all seven: enough Python to glue systems together (postings put Python in roughly one in four AI-governance listings⁷), and enough law-reading to parse an article without mistaking it for advice. Neither is optional; neither is the whole job.

Analyst versus engineer

The clearest way to define the role is against the analyst it grows from. The contrast below is written for AI governance and modelled on the analyst-vs-engineer table that the GRC Engineer literature uses for its parent discipline². Both roles are needed; the engineer is not “better”, but does different work and is measured differently.

The distinction is cadence and artefact, not competence or clearance. It is not that the analyst cannot read a registry or the engineer cannot write a report; it is that the analyst’s deliverable is a periodic description and the engineer’s is a continuous control. A good analyst reads systems closely; a good engineer writes clearly. The failure modes differ too, and naming them keeps both honest. The analyst’s failure mode is compliance theatre: documentation that runs ahead of reality. The engineer’s failure mode is over-engineering: automating a control for a process nobody agreed to fix, or building a gate so brittle that engineers route around it. Neither role is safe from its own failure mode by title alone.

The career ladder

The role has observable rungs, each defined by what the person can be trusted to own end to end, not by years served — and verifiable by looking at the systems, not a self-assessment.

1. Associate. Runs existing controls: adds an eval to a suite, registers an agent correctly, produces evidence from a control someone else built.
2. AI governance engineer. Builds a control end to end — one obligation into a gate, an eval suite for a system class, wired into CI/CD — and owns at least one workflow for a product area.
3. Senior. Owns a full workflow across the organisation and designs the paved path others adopt; the registry, eval gate or evidence pipeline they built is the standard template.
4. Staff / principal. Owns the reference architecture — how the five layers fit together — and the cross-cutting decisions (identity model, evidence format, incident path).
5. Head of AI governance engineering. Owns the function and its shared ownership with engineering, measured by realised risk reduction, not by controls stopped. A public engineering-manager posting scoped to “build an AI-forward GRC engineering function” sits at this rung⁵.

A person can hold the capability at rung two while the title lags at “analyst”, or hold the title without the capability. The ladder describes the work, and the work is visible in the systems.

Three ways in

Nobody starts as an AI governance engineer; everyone converts from an adjacent discipline, keeping its strength and adding what it lacks.

• From Legal or privacy. Your edge is regulatory translation; your gap is the build. Turn one assessment into a versioned, executable artefact (a FRIA-as-code template, a policy in OPA/Rego), and learn enough pipeline to see where the control fires. Start at policy-as-code and intake.
• From Security or GRC. Your edge is the control mindset; your gap is the model layer. GRC engineering already taught the parent moves — policy-as-code, continuous assurance, evidence as a by-product²; 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⁸. Start at evals-as-evidence and the agent registry.
• 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, the evidence artefact the audit needs. Start at eval gates in CI and runtime monitoring.

The market

The role is defined by the workflows above, not by the vacancies — but the market is forming and the evidence is public, and it corroborates the shape of the work. Treat every figure as sourced; salary points are survey medians or posting ranges, not guarantees.

Survey bands. The IAPP Salary & Jobs Report 2025-26 (1,600+ respondents, 60+ countries) puts technical AI-governance roles in the tech sector at a median of USD 221,000 — its highest band — against USD 151,800 for AI-governance work generally and USD 169,700 for combined privacy-and-AI- governance roles⁹. The premium is for the technical, build-the-control end of the discipline, which is exactly the role this chapter describes.

Skills in demand. Analysis of US postings since January 2026 (Axial Search) reports observability/monitoring in 41-42% of AI-governance listings, Python in 27-28%, NIST frameworks in about 27%, foundation-model familiarity in 25.6% and cloud in 18.2%; median advertised pay was USD 169,000 and median required experience five years⁷. And the demand signal is steep: LinkedIn’s 2026 Skills on the Rise placed AI governance at a reported +150% year over year¹⁰. The load-bearing signal is the skills mix — observability, Python, the runtime data path — not the salary headline.

What employers get wrong in the job description

Reading the postings against the workflows above, three mistakes recur.

• Certifications as a proxy for capability. Descriptions list AIGP, CIPP, CISSP and CISM as if a certificate produced a control. The Axial data shows certs appear in under 11% of postings each⁷; the load-bearing skills — eval harnesses, policy-as-code, the runtime data path — are the ones the JD under-specifies. Ask for the workflow, then the cert if it helps.
• Analyst work under an engineer title. Many “AI Governance Engineer” postings describe intake, mapping and reporting — analyst work — at engineer pay. The tell is the absence of any build: no eval gate, no registry integration, no evidence pipeline.
• 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: the seven workflows are owned across a team, and a first hire owns two or three and builds the paved path for the rest.

Maps to: EU AI Act Art. 9 (risk management), Art. 26/27 (deployer duties, FRIA), Art. 72 (post-market monitoring), Art. 73 (serious-incident reporting) · ISO/IEC 42001 (roles, responsibilities and competence) · NIST AI RMF (Govern) · OWASP Top 10 for Agentic Applications 2026. Mappings are illustrative, not a claim of conformity.

Sources

1. [1] “How the AI Engineer role is unbundling in 2026” (names the AI Evaluation & Governance Engineer). AI Journal. 2026-08-26. https://aijourn.com/how-the-ai-engineer-role-is-unbundling-in-2026/ (verified: secondary)
2. [2] “The GRC Engineer role” (analyst-vs-engineer table; career paths). GRC Engineer. 2025. https://grcengineer.com/grc-engineer/ (verified: primary)
3. [3] “AI Governance VP” posting (intake, classification, approval aligned to NIST AI RMF), USD 120,000-202,500. State Street (via SimplyHired). 2026-09. https://www.simplyhired.com/job/iy04VeXdd9DR3vffvKZvupPCsoZtHi405zOLc_RMSJXOSRJVqLbhmw (verified: secondary)
4. [4] “AI Governance Engineer” posting (agent registry, threat modelling, red teams, MCP security), USD 175,000-260,000. Dalio Family Office (via SimplyHired). 2026-09. https://www.simplyhired.com/job/vKibNHPKReLf8h5PgcPxYjWZOx1ctDsml8sjzydKbSpd6ZoNoNvP-Q (verified: secondary)
5. [5] “Engineering Manager, GRC” posting (AI-forward GRC engineering function; policies into policy-as-code), USD 405,000. Anthropic (via General Catalyst jobs). 2026. https://jobs.generalcatalyst.com/companies/anthropic/jobs/78167778-engineering-manager-grc (verified: secondary)
6. [6] “AI Governance Engineer” posting (security controls, threat models, incident response for LLM systems), USD 100,000-150,000. Bright Vision (via SimplyHired). 2026-09. https://www.simplyhired.com/job/s2v6mqCI9KO8Xldf5enD0Z46iDqIBLdwS0jqZlgtO8YhD-DU_4XDog (verified: secondary)
7. [7] AI governance jobs analysis (US postings since Jan 2026: observability 41-42%, Python 27-28%, NIST ~27%, foundation models 25.6%, cloud 18.2%; median pay USD 169,000; median 5 yrs). Axial Search. 2026-08-04. https://axialsearch.com/insights/ai-governance-jobs (verified: secondary)
8. [8] Top 10 for Agentic Applications 2026. OWASP GenAI Security Project. 2025-12-09. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (verified: primary)
9. [9] Salary & Jobs Report 2025-26 (technical AI-gov in tech median USD 221,000; AI governance only 151,800; privacy + AI governance 169,700). IAPP. 2025-08-03. https://iapp.org/resources/article/salary-survey-summary/ (verified: primary)
10. [10] LinkedIn 2026 Skills on the Rise (AI governance reported +150% YoY). LinkedIn (reported via EdTech Innovation Hub). 2026. https://www.edtechinnovationhub.com/news/linkedins-2026-skills-on-the-rise-shows-global-ai-driving-hiring-shifts (verified: reported)
11. [11] “What is GRC Engineering” (capability, not a job title). GRC Engineer. 2025. https://grcengineer.com/what-is-grc-engineering/ (verified: primary)