06. The role

New to the field? Start with what AI governance is.

Capability first, title second

The Thesis 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.

The role also has a one-page summary: AI governance engineer, with the workflows, the skills, the salary medians and the ways in. This chapter is the full treatment, with its sources.

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. The NIST AI RMF’s Map function is the natural vocabulary for the classification step. Intake asks, in order: whether the problem needs AI at all (strategy, value and whether to use AI at all, chapter 12); whether the system counts as AI (the definitional decision and its registry fields, chapter 11); what the use-case record says about purpose and decision authority (chapter 14); which risk tier the use-case risk profile gives it (chapter 13); and where it sits on the AI Act risk ladder (chapter 18). A system that is bought rather than built enters with a Deployment Decision Record (chapter 15). The Use-Case Intake & Risk Tiering pattern builds the intake, and the AI Act triage drafts the classification decision record. 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, and every non-human actor in it carries its own identity; chapter 23 sets out what an agent’s registry entry has to carry. 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, with the threat model that says which runtime failures the controls are built against⁵. Chapter 17 covers incident response and root-cause analysis. 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, and chapter 18 reads the EU AI Act in one pass for the engineer who has to translate it.

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 broad: LinkedIn’s 2026 Skills on the Rise lists governance and responsible-AI skills among its fastest-rising clusters, alongside the technical AI capabilities⁷. 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. What each scheme assesses, and how this book relates to it, is set out neutrally on the certifications page.
• Analyst work under an engineer title. In our reading of the postings, “AI Governance Engineer” titles often 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.

What you can do this week

1. Map the seven workflows. Write down who owns intake, inventory, evals, policy-as-code, runtime and incidents, assurance and regulatory translation today, and mark the ones nobody owns.
2. Own one workflow outright. Pick the one with the least build in it (often the registry or the eval gate) and ship one control there that blocks or records, not one that recommends.
3. Rewrite one job description. Replace the list of certifications with the workflows the hire will own and the artefacts they will ship in their first quarter.
4. Practise one core skill on a real system. From the skills table, take the core skill your workflow lacks and use it once on a live pipeline: one policy in OPA/Rego, one eval in a harness, one trace in OpenTelemetry.
5. Translate one article in a pair. Sit a lawyer or DPO with an engineer and turn one AI Act article into a gate, a registry field or an evidence artefact, and back again.

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] “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)
4. [4] 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)
5. [5] 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)
6. [6] 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)
7. [7] LinkedIn 2026 Skills on the Rise (governance and responsible-AI skills among the fastest-rising clusters; no per-skill percentage published). LinkedIn, via EdTech Innovation Hub. 2026. https://www.edtechinnovationhub.com/news/linkedins-2026-skills-on-the-rise-shows-global-ai-driving-hiring-shifts (verified: secondary)
8. [8] “What is GRC Engineering” (capability, not a job title). GRC Engineer. 2025. https://grcengineer.com/what-is-grc-engineering/ (verified: primary)