The AI Governance Engineer: A Role That Didn't Exist in 2024

What the role actually is

An AI governance engineer takes an obligation that exists on paper and turns it into a control that runs in continuous integration. That is the whole job, stated plainly. The obligation might come from a statute, from a regulator's expectations, from a client contract or from an internal risk policy. The control is a piece of software: a test that fails a build, a gate that blocks a deployment, a policy check that refuses to merge, a routing rule that cannot be bypassed, a log that produces the evidence an auditor will ask for eighteen months later.

The reason this is a distinct job rather than a task that someone else absorbs is that it requires two skill sets which almost never sit in the same person. You need to be able to read a legal instrument closely enough to identify what it actually requires, as opposed to what a summary blog post says it requires. And you need to be able to build and operate the thing that enforces it, in the same repository, with the same review process, as the product code. Most people can do one of those. The organisations paying well are paying for the intersection.

It helps to be precise about what the role is not, because it gets confused with three adjacent jobs that already existed and that hire differently.

Role	Primary output	Owns the obligation?	Shipping surface
AI governance engineer	A control in the pipeline, plus the evidence it emits	Yes — accountable for whether the control works	The repository. Their code blocks deployments.
AI ethicist / responsible AI researcher	Position papers, principles, model cards, impact assessments	No — advises on what should be true	None. Influence is through persuasion and documents.
GRC analyst	Evidence collected, control tested, findings logged	No — verifies that someone else's control exists	A register or GRC platform, not the product.
ML platform engineer	Serving stack, training pipelines, gateways, observability	No — runs the platform the control sits on	The platform, but the obligation is somebody else's.

The distinction that matters most in interviews is between the governance engineer and the GRC analyst, because job titles blur them constantly. A GRC analyst asks whether a control exists and gathers proof that it does. A governance engineer writes the control and is accountable when it fails to catch something. If a vacancy describes evidence collection, questionnaire response and control testing, it is a GRC role with a fashionable title, and it will pay accordingly. If it describes building policy checks, instrumenting agents and owning a gate in the deployment path, it is the engineering job.

Why the role exists now

Roles get funded when three things happen at once: the risk becomes legible, the tooling becomes buildable, and the obligation acquires a deadline. All three landed between mid-2025 and mid-2026, which is why a job that barely existed as a title in 2024 had thousands of open vacancies by 2026.

The vendors shipped primitives. You cannot govern what you cannot name, and until 2025 an autonomous agent acting inside an enterprise had no first-class identity. That changed. Microsoft's Entra Agent ID reached general availability in April 2026, giving agents directory objects that can be assigned, audited and revoked like any other principal. Okta introduced Cross App Access, an OAuth extension for agent-to-app authorisation, in June 2025, and expanded it through 2026 — including Amazon Bedrock support and stated openness to rival identity providers as of May 2026. Once an agent has an identity, a lifecycle and a revocation path, "who did this and under what authority" becomes an answerable question. Answerable questions are what controls are built on.

OWASP named the risks. The Non-Human Identities Top 10 and the Top 10 for Agentic Applications, released in 2026, gave the failure modes shared vocabulary. OWASP's own framing is worth repeating because it is unfashionably sober: agents mostly amplify existing vulnerabilities rather than creating entirely new ones. That framing is a gift to anyone entering this field, because it means your existing application-security and platform knowledge transfers almost completely. The published evidence supports the framing. Secret leakage and long-lived secrets — NHI2 and NHI7 in that taxonomy — account for the majority of named non-human identity breaches written up over the last two years. Secret-scanning vendors estimate that roughly 29 million new hardcoded secrets were exposed on public GitHub during 2025, up about 34% year on year, and that 64% of secrets exposed as far back as 2022 were still valid in early 2026; those are scan-derived figures from companies selling remediation, not an independent audit. None of that is an exotic agentic attack. It is credential hygiene at a scale that agents made worse.

Regulation put dates on the calendar. This is the part that converts a concern into a budget line. Most of the EU AI Act's Article 50 transparency obligations applied from 2 August 2026. The Digital Omnibus agreed in 2026 deferred the high-risk obligations — to 2 December 2027 for standalone Annex III systems, and to 2 August 2028 for AI embedded in Annex I regulated products — but deferral is not cancellation, and the transparency obligations were not deferred. Penalties reach EUR 35 million or 7% of global annual turnover. We covered what became enforceable and what moved in our breakdown of the August 2026 go-live.

A principle without a date is a discussion. A principle with a date, a penalty and a named accountable executive is a hiring requisition. That is the entire causal story of this role, and it is why the hiring signal has been so sharp — recruitment-market analyses report AI governance hiring up around 150% year on year, with more than 14,000 roles listed on LinkedIn. The market context is covered in more detail in our piece on the governance hiring wave and non-human identity.

The obligation-to-control translation

This is the core skill, and it is what an interview loop for this role is really testing. Given an obligation in prose, what is the engineering artefact? Three worked examples, chosen because they cover the three shapes most obligations take: disclose something, involve a human, keep data somewhere.

Obligation (prose)	Engineering artefact	Evidence it produces
Disclose that content is AI-generated (EU AI Act, Article 50)	A content-marking pipeline plus a provenance assertion attached at generation time	A verifiable manifest per asset, and a CI test that fails when an output path emits unmarked content
Ensure meaningful human oversight of a high-impact decision	An approval gate with a signed audit trail, and a kill switch that has been pulled in a drill	Per-decision approver identity and timestamp; a dated drill record with measured revocation latency
Keep personal data within a jurisdiction (DPDP, GDPR, client contract)	Request routing keyed on residency, plus a per-request assertion that routing held	A trace attribute per request showing inference region and audit sink, queryable for any date range

Take the first one. "Disclose that content is AI-generated" is one clause of prose. As an engineering problem it decomposes into: where in our system is synthetic content produced, what marking standard do we attach, does the marking survive the transformations our pipeline applies, what happens when a downstream service strips it, and how do we prove on any given day that every generation path was marked. The practical implementation is covered in our guides to machine-readable content marking with C2PA and to shipping Article 50 transparency as code. The governance engineer's specific contribution is the last part: the test that fails when a new endpoint is added and nobody wired the marking in.

The second obligation, human oversight, is where most organisations are weakest, because the control is easy to build badly. An approval gate that a tired operator clicks through at 40 requests an hour is not oversight; it is a click-through log that will read badly in an incident report. Good versions sample and escalate, capture a reason code, and are measured on how often the human disagrees with the model — if that number is zero, the gate is decorative. The kill switch is the same story in harder form. Almost every organisation says it has one. Very few have pulled it in anger, timed the result, and written down what was still running ninety seconds later.

The third, data residency, is the one that bites Indian and UK firms hardest because it arrives through client contracts as often as through statute. A UK bank's supplier obligations may require that inference for its customers never leaves a London region; an Indian services firm delivering for a European client may carry a residency requirement stricter than anything the DPDP Act imposes. The routing mechanics are covered in our data residency routing guide; the governance artefact is the proof, not the routing.

Here is what the first kind of control looks like in practice — a policy check that fails a build when an agent's declared scopes exceed what its approved policy allows. It is deliberately unglamorous. Controls that survive are.

# tools/governance/check_agent_scopes.py
"""Fail CI when an agent's declared scopes exceed its approved policy.

    python -m tools.governance.check_agent_scopes agents/ policy/agent-policy.yaml
"""
import pathlib
import sys
import yaml


def load_policy(path):
    doc = yaml.safe_load(pathlib.Path(path).read_text())
    return {a["id"]: set(a["allowed_scopes"]) for a in doc["agents"]}


def declared(manifest):
    doc = yaml.safe_load(manifest.read_text())
    return doc["id"], set(doc.get("scopes", [])), doc.get("owner", "UNOWNED")


def main(agent_dir, policy_path):
    policy = load_policy(policy_path)
    failures = []

    for manifest in sorted(pathlib.Path(agent_dir).rglob("agent.yaml")):
        agent_id, scopes, owner = declared(manifest)

        # An agent with no policy entry is a governance failure, not a default-allow.
        if agent_id not in policy:
            failures.append(f"{manifest}: '{agent_id}' has no approved policy entry")
            continue

        excess = scopes - policy[agent_id]
        if excess:
            failures.append(
                f"{manifest}: '{agent_id}' (owner {owner}) requests "
                f"un-approved scopes {sorted(excess)}"
            )

    for line in failures:
        print(f"FAIL {line}", file=sys.stderr)
    return 1 if failures else 0


if __name__ == "__main__":
    raise SystemExit(main(sys.argv[1], sys.argv[2]))

Forty lines, no machine learning, and it is a real control: it is deterministic, it runs on every pull request, it fails closed on an unregistered agent, and it produces a named owner in its failure message so the person who has to fix it is unambiguous. The scope model underneath it comes from our guide to least-privilege credentials for AI agents.

The residency obligation produces a different shape of control — an assertion rather than a gate, because the thing being proved is a runtime property.

# tests/governance/test_residency.py
import pytest
import requests

from governance.audit import fetch_trace

CASES = [
    # (user residency, required inference region, required audit sink)
    ("IN", "ap-south-1",   "s3://audit-in-mumbai"),
    ("GB", "eu-west-2",    "s3://audit-uk-london"),
    ("DE", "eu-central-1", "s3://audit-eu-frankfurt"),
]


@pytest.mark.parametrize("residency,region,sink", CASES)
def test_request_is_routed_and_proved(residency, region, sink):
    resp = requests.post(
        "https://staging.example.com/v1/complete",
        json={"prompt": "residency probe", "user_residency": residency},
        timeout=30,
    )
    assert resp.status_code == 200
    trace = fetch_trace(resp.headers["x-trace-id"])

    # The control is not "we configured a region" — configuration drifts.
    # The control is "we can prove, per request, where it ran and where the log went".
    assert trace["gen_ai.inference.region"] == region, "inference left the region"
    assert trace["audit.sink"] == sink, "audit record left the region"
    assert trace["gen_ai.prompt.persisted"] is False, "prompt persisted off-region"

The skills ladder

Because the role is new, the ladder is not yet standardised across companies, but the capability progression is consistent wherever it is being done seriously. The useful way to think about each band is as a triple: what you can build, what you can argue, and the artefact that proves both.

Band	Must be able to build	Must be able to argue	Artefact that proves it
Entry (0-2 years in governance)	A control matrix from a regulation; an agent instrumented end to end with OpenTelemetry; a single deterministic policy check in CI	Why a given clause maps to a given test, and what the test does not cover	A public repository mapping clauses to executable assertions, with a green build and an honest coverage gap section
Mid (2-5 years)	An evals-in-CI gate with thresholds people accept; least-privilege agent credentials with short-lived tokens; a working revocation path	Where the threshold came from, why the false-positive rate is tolerable, and what happens on the day the gate is wrong	A gate running in a real pipeline, with a written record of the two times it blocked a release and the one time it was overridden
Senior (5+ years, the band most postings ask for)	A whole assurance argument: the control set, its evidence, its owners, its failure modes and its cost	The argument to an auditor, to a regulator, to a board risk committee and to the engineers who have to live with it — four different audiences	An assurance case that survived an external audit, plus a costed proposal showing what was deliberately not controlled and why

Some specifics on the rungs. At entry level, instrumentation is the highest-leverage skill you can acquire, because every control above it depends on being able to see what the system did; our guide to instrumenting agents with OpenTelemetry is the right starting point, and the semantic conventions matter more than the SDK. The control matrix is the other entry-level skill, and it is more intellectually demanding than it sounds: reading a clause and deciding what would constitute evidence of compliance is genuine analytical work, and doing it badly produces a matrix full of assertions that are true by construction.

At mid level, the shift is from writing controls to owning gates that other engineers cannot route around, which is as much a political skill as a technical one. Putting evals in CI is the canonical example and the canonical trap: a gate with a threshold nobody agreed to will be disabled within a month. The credential work is the other half — short-lived tokens, per-capability scopes, a revocation path that has been exercised.

At senior level, the job stops being about individual controls and becomes about the argument. An assurance case is a structured claim — "this system is acceptably safe for this use, and here is the evidence chain" — that has to hold up to four audiences with different tolerances. The senior skill nobody advertises is costing it: telling a board that full coverage of a control set costs a certain number of engineer-months and proposing which risks to accept instead. Governance engineers who cannot have that conversation stall at mid level regardless of technical depth.

Proof-of-work that actually lands

Here is the structural fact that makes this role unusually accessible: nobody can have ten years of experience in it, so credentials cannot be the filter. Hiring managers know this. What they screen on instead is whether you have built something that demonstrates the translation skill, and the bar for "something" is lower than most candidates assume — but the bar for how it is written up is higher.

Five projects that land, in rough order of effort.

1. An open-source control matrix (a fortnight)

Pick a bounded regulatory surface — EU AI Act Article 50 is ideal because it is live as of 2 August 2026, narrow, and unambiguously relevant. Map each obligation to one or more executable test assertions against a small demo application. Publish the matrix as machine-readable data, not a spreadsheet, so it can be consumed by a pipeline.

# controls/article-50.yaml
- control_id: A50-DISCLOSE-CHAT
  obligation: >-
    Natural persons must be informed they are interacting with an AI system,
    unless it is obvious to a reasonably well-informed person.
  applies_when: interface_type == "conversational"
  assertions:
    - test: tests/test_chat_disclosure.py::test_first_turn_contains_disclosure
    - test: tests/test_chat_disclosure.py::test_disclosure_survives_locale_switch
  evidence: screenshot + transcript hash, retained 24 months
  not_covered: >-
    Voice channel. No disclosure control exists for the telephony path;
    tracked as GAP-004, owner unassigned.

What makes this good rather than ordinary is the not_covered field. Any candidate can produce a matrix that claims full coverage. A candidate who documents their own gaps, names them and leaves them visible is demonstrating the exact professional honesty the role requires, and every experienced reviewer will notice.

2. A kill switch with a measured revocation latency (a weekend)

Build a small agent with a real credential, then build the revocation path — and then time it. How long between pressing the button and the agent's last successful API call? Include the ugly parts: the in-flight request that completed anyway, the cached token that stayed valid for its remaining lifetime, the queued job that ran forty seconds later. Publish a chart of revocation latency across three different revocation mechanisms.

This is the single most under-supplied artefact in the field, because organisations claim kill switches constantly and almost never publish a number. If your write-up says "revocation completed in 4.2 seconds for direct token revocation, 61 seconds for the cached path, and one queued job executed post-revocation", you have said something almost nobody else has said.

3. A secrets-expiry audit over a public repository corpus (a weekend)

Given the vendor scan estimate that 64% of secrets exposed as far back as 2022 were still valid in early 2026 — a claim worth testing rather than repeating — build a tool that measures the problem on a sample of public repositories — detect credential patterns, check structural validity and expiry claims without ever attempting authentication, and report the distribution of apparent age. Publish the methodology and the aggregate statistics only.

4. A reproducible red-team suite (a fortnight)

A fixed adversarial corpus, a deterministic runner, versioned results and a regression report showing how a model or prompt change moved the numbers. Our guide to red-teaming and adversarial safety evals covers the construction. The governance angle, and the thing to emphasise in the write-up, is reproducibility: an audit finding needs to be repeatable by someone who does not trust you.

5. An agent identity lifecycle demo (a fortnight)

Register an agent identity, issue it a scoped short-lived credential, have it perform a delegated action against a second service, log the full authorisation chain, then de-provision it and show the audit trail from creation to deletion. This is the concrete demonstration that you understand what the vendor primitives actually do, rather than that you have read the launch announcements.

On write-up: a hiring manager will give your project about five minutes. That means the README must answer four questions above the fold — what obligation this addresses, what the control does, how to run it, and what it does not cover. A green build badge and a single command that reproduces your result do more than three paragraphs of context. The general form of this argument is in our guides to the AI engineer portfolio that gets you hired and breaking into AI agent security through proof of work.

What the market pays and where the roles are

Published compensation data for this role is thin, recent and mostly American, so treat every figure below as indicative rather than authoritative, and note the source when you quote it.

Market / band	Reported figure	Source and caveat
Median advertised salary	$158,750	Axial Search analysis of 146 AI governance postings, January 2026. Predominantly US roles.
Common posted range	$120,000 - $270,000	Same survey. Posted ranges, not offers made.
Director / VP / chief level	$300,000+	Same survey. Small sample at this level.
Experience sought	85% of postings want 5+ years	Same survey. Rarely five years of governance specifically.
India, experienced practitioner	₹21-48 lakh	Market survey range. Wide because the title is not standardised.
India, metro vs tier-2	~10-20% premium	Market survey. Same band, different city.
India, financial services and healthcare	~20-30% above general technology	Market survey. Regulated sectors carry the obligations.
United Kingdom	No comparable published dataset	Treat any specific UK figure you find online with suspicion.
Demand growth	~150% year on year; 14,000+ roles listed on LinkedIn	Market survey. Counts roles matching a governance search, not a clean taxonomy.

The honest reading of that table is that the highest-paying postings are American and that neither an Indian nor a UK candidate should benchmark against them. What the American numbers tell you is the shape of the market — that seniority is rewarded steeply, that the ceiling is genuinely high, and that the demand curve is steep enough to pull compensation up elsewhere over time.

In the UK, demand is concentrated in financial services and other regulated sectors. There is no AI-specific statute as of August 2026; AI is regulated through existing law and sector regulators, with the ICO on personal data, Ofcom on telecoms and online services, and the FCA on financial services. That produces a distinctive local shape of work — mapping AI systems onto existing model risk management, consumer duty and operational resilience frameworks rather than onto a new AI regime — and it layers on top of EU extraterritorial reach, since a UK company placing an AI system, model or output on the EU market or serving EU users is in scope of the Act regardless of where it is registered. A UK governance engineer therefore usually carries two regimes at once: sectoral UK expectations and EU obligations.

In India, demand is concentrated in Global Capability Centres and services firms, for the straightforward reason that both carry client obligations. A GCC of a European bank inherits that bank's regulatory surface; a services firm delivering an AI platform for a UK insurer inherits the insurer's. The DPDP Act governs personal data domestically and a Digital India Act with an AI chapter has been in draft, but the immediate commercial driver is contractual rather than statutory. That is a good market to enter, because the obligations are concrete, the client is demanding, and the work is unambiguously billable. The channel itself is covered in our guide to AI roles in Global Capability Centres.

One caution about titles when searching in either market. Vacancies for this work appear as "AI Assurance Engineer", "Responsible AI Engineer", "Model Risk Technology", "AI Controls Engineer" and, in banks, occasionally as a specialisation inside an existing model risk management function. Searching for "AI governance engineer" alone will miss most of them.

Common pitfalls

Five failure modes account for most of the disappointment in this field, in candidates and in the teams that hire them.

Writing policy nobody can test. The failure: a document that says the organisation will ensure AI systems are fair, transparent and robust. It cannot be violated, so it cannot be enforced, so it does nothing. The fix: for every policy statement, write the test that would fail if it were untrue before you write the statement. If you cannot construct the test, the statement is aspiration and should be labelled as such rather than smuggled into a control set.

Treating the audit as the goal. The failure: work organised around passing an assessment, which produces controls tuned to look good in evidence packs and to be quietly bypassed in production. The fix: treat the audit as an artefact of a system that already works. The question to ask when designing any control is "what would this catch on a normal Tuesday?" — not "what will this look like in the evidence pack?"

Confusing open-weight with open-source in a compliance claim. The failure: asserting that a model is open-source, and therefore covered by whatever obligations or exemptions attach to that, when the licence in fact publishes weights under restrictions on field of use, redistribution or scale. These are different things with different legal consequences, and the distinction has become sharper as licences have proliferated. The fix: read the licence, record its actual name and version in your control matrix, and never let "open" appear unqualified in a document a regulator might read.

Building a kill switch nobody has ever pulled. The failure: an emergency stop that exists in an architecture diagram and has never been exercised, which reliably means it misses something — a cached token, a queued job, a second credential path, a downstream service that keeps serving from its own cache. The fix: schedule a revocation drill, run it in a real environment, measure the latency, and write down what was still running afterwards. Then fix that and run it again. An untested control is a claim, not a control.

Chasing certifications ahead of shipped artefacts. The failure: collecting AI governance certificates while having built nothing. In a field this new, certifications signal that you have read the syllabus, which is worth something but is not scarce. The fix: build one thing, publish it, then take the certification if you still want it. The ordering matters because the artefact makes the certificate credible and the certificate does not make the artefact.

Assuming a deferred deadline means deferred work. The failure: reading the Digital Omnibus deferrals — 2 December 2027 for standalone Annex III high-risk systems, 2 August 2028 for AI embedded in Annex I products — as breathing room. The fix: work backwards. A control that must be operating and evidenced by December 2027 needs to be designed, built, tested, socialised and running long before that, and in a bank or a hospital group the change cycle alone consumes several quarters. The deferral moved the audit date, not the build date.

A 90-day plan

This assumes you are coming from backend engineering, machine learning or security, and that you have a few hours a week rather than unlimited time. It is deliberately sequenced so that each phase produces something publishable.

Weeks 1-2: read primary sources. Not summaries. Read the actual text of EU AI Act Article 50, the OWASP Non-Human Identities Top 10 and the Top 10 for Agentic Applications, and — depending on your market — the ICO's guidance on AI and data protection, the FCA's published expectations on model risk, or the text of India's DPDP Act. Keep a running list of every obligation you encounter that you cannot immediately imagine testing. That list is your curriculum.

Weeks 3-4: build the control matrix. Take Article 50 and map every obligation to executable assertions against a small demo application you write yourself. Include the coverage gaps honestly. This is your first artefact and the one most directly aligned with the job.

Weeks 5-6: instrument something properly. Take an agent — yours or an open-source one — and add OpenTelemetry tracing with attributes that would let you answer an auditor's questions: which model, which region, which tools were called, which identity authorised them, how long each step took. Then write three queries against those traces that a regulator might plausibly ask, and check that the data actually supports them. Most instrumentation fails this test.

Weeks 7-8: build the kill switch and measure it. Revocation across at least two mechanisms, with latency numbers and an honest account of what kept running. Publish the chart.

Weeks 9-10: put a gate in a pipeline. Take the scope-check pattern from earlier in this guide, adapt it to something you actually run, and make it block a merge. Then live with it for a fortnight and write down every time it was annoying, because that record is the beginning of understanding why controls get disabled.

Weeks 11-12: write it up and make it findable. One clear post per artefact, each answering the four questions above the fold: what obligation, what control, how to run it, what it misses. Then make sure the work is discoverable by the people who source for these roles — a public profile using the vocabulary the postings use, with the artefacts linked directly, on a directory that hiring teams in India and the UK actually browse. Applications are the least efficient part of this channel; being found is the efficient part.

Ninety days is not enough to make you a senior AI governance engineer. It is enough to make you a credible junior one with three public artefacts, which as of August 2026 puts you ahead of most of the field, because the field is two years old and almost nobody has done the work in public. More career guides are collected in our careers tips section.