45% of the FTSE 250 Is Hiring an AI Governance Chief. A Year Ago It Was 10%.

For three years, AI governance in most large companies was a slide deck owned by whoever had least successfully avoided the meeting. It described principles, referenced fairness and transparency, and had no budget, no headcount, and no authority to stop anything. That arrangement survived exactly as long as AI remained something companies experimented with. It stopped surviving the moment agents started taking actions with legal consequences, and the hiring data shows precisely when the switch flipped.

A Four-and-a-Half-Fold Increase in Twelve Months

Hiring data is a better indicator of corporate belief than survey responses about strategy, because a job requisition costs money and a survey response does not. Going from roughly one in ten firms to nearly one in two inside a year is not a trend line. It is a step change, and step changes in senior hiring almost always trace to a specific external forcing event.

The forcing event here is legible. As we covered when the deadline was approaching in how the EU AI Act reprices every agent in production, the August 2 date attached financial consequences to obligations that had previously been aspirational. Penalties of that magnitude change who owns the problem. A risk that can cost 7% of global revenue is a board-level risk, and board-level risks acquire named executives.

Why Existing Functions Could Not Absorb It

The obvious objection is that large companies already have risk, compliance, legal, security, and data protection functions, all staffed by people who govern things for a living. Why did AI need its own. The answer is a property of the systems rather than a claim about their importance.

Every existing governance function is built around artifacts that hold still. A contract says what it says until it is amended. A deployed application behaves as it behaved until someone ships a change. A control is tested annually and remains effective in between. AI systems violate that assumption in several directions at once: the model behind a stable API can be updated by the vendor, the behaviour of an agent depends on retrieved context that changes hourly, and the same input can produce different outputs on Tuesday than it did on Monday.

That distinction is why the role tends to sit awkwardly in organisation charts. Report it into legal and it produces documents nobody can implement. Report it into engineering and it loses independence at exactly the moments independence matters. The arrangements that seem to work put it alongside risk with a hard line to the board and an explicit, funded engineering capability of its own, because a governance function that has to ask another team to build its instrumentation will never have any.

What the Role Actually Does

Job descriptions for these roles are mostly aspirational prose. The real work, judged by what occupies the calendar of people already doing it, breaks into five things.

Maintaining the inventory

Nothing else is possible without knowing what exists. Which models are in use, in which products, touching which data, with which providers, under which contracts, and which of those meet the regulatory definition of high risk. This sounds like a two-week project and is a permanent function, because the estate grows faster than any manual process can track. Only 21% of organisations keep a real-time agent registry, which is the same statistic we cited in the non-human identity crisis, and it is the first thing a new governance hire discovers is missing.

Classifying risk without stopping the business

Most AI usage in a large company is genuinely low risk and should pass through with a light touch. A small share carries real legal or safety exposure and needs documentation, testing, and human oversight. The value of the function lies almost entirely in separating those two quickly and defensibly. A governance process that treats a marketing copy assistant the same as an automated credit decision will be ignored within a quarter, and deserves to be.

Owning the evidence

Regulatory obligations for high-risk systems come down to being able to show what you did: what the system was tested against, what the results were, who reviewed them, what human oversight exists, and how incidents are handled. That evidence has to be produced continuously by the systems themselves, which is why this role ends up caring intensely about evaluation harnesses and trace data. A governance function without access to production telemetry is writing fiction.

Managing provider dependency

Your obligations do not transfer to your model vendor. When a provider updates a model, deprecates an endpoint, or changes its data handling terms, the exposure lands on you. Somebody has to read those terms, track version changes against your regulated use cases, and hold the fallback plan for a provider becoming unavailable or unacceptable. This is unglamorous contractual work that engineering teams reliably neglect.

Running incidents

When an agent does something it should not, there needs to be a defined path: who is notified, who can halt the system, how the affected parties are identified, what gets reported and to whom, and how the finding feeds back into testing. Given that 98% of organisations have already had a disruptive agent incident, as we covered in the incident data, this is not a hypothetical process being designed for a rainy day. It will be used this quarter.

The First Ninety Days, Honestly

Talk to people who have taken one of these jobs and the first three months follow a recognisable arc. Week one is a mandate and a welcome. Week three is the discovery that the AI inventory someone assembled for the board is a spreadsheet of eleven systems, and that procurement records show forty-three vendors with AI in their product description. Week six is the realisation that the gap is not carelessness but definition: nobody agreed what counts.

Does a vendor SaaS product with an embedded assistant count as your AI system or theirs. Does a script that calls an API twice a day count. Does a team's internal coding agent count, and if not, what about the one that has write access to a production repository. The answers matter enormously for scope and there is no authoritative source for them, so the first real deliverable of the function is usually a definition rather than a control.

The recommendation from people who have done this twice is to define by consequence rather than by technology. Anything that can take an action affecting a customer, move money, change a record of account, or produce output a customer sees without a human in between is in scope regardless of how it is built. Anything else is inventory-only until it changes. That definition is defensible to a regulator, comprehensible to an engineer, and small enough to actually execute in the first year.

Weeks eight through twelve are then spent on the least interesting and most valuable work available: getting automated discovery in place so the inventory maintains itself. Every organisation that skipped this step has a governance function whose primary activity is chasing teams for spreadsheet updates, and every one of those functions is quietly failing.

The Failure Mode: Governance That Only Says No

The predictable way this goes wrong is well documented in every previous wave of corporate control functions. A new function arrives with a mandate and no delivery obligation, discovers that approving things carries career risk while blocking them does not, and gradually becomes an organisation whose only reliable output is delay. Teams respond rationally by not asking.

In AI this is worse than usual, because the tooling is consumer-accessible. A team blocked from using an approved enterprise model does not stop; it uses a personal account. That is the shadow AI dynamic we described in shadow AI inside companies, where prohibition reliably produces invisible usage with worse data handling than the thing that was prohibited. A governance function measured only on risks prevented will manufacture this outcome and never see it.

The Board Question Everyone Gets Asked

Every person in one of these roles eventually faces the same question from a non-technical board, usually phrased as: are we exposed. It is a reasonable question and it is unanswerable as asked, and how it gets handled sets the tone for the function's first two years.

The weak answer is a maturity score. Somebody produces a framework with five levels, places the organisation at level two, and proposes a programme to reach level four. It satisfies the meeting and communicates nothing, because a maturity level is not evidence about any particular system and cannot be checked.

The strong answer is a short list of specific systems with a stated risk classification, what each was tested against, when it was last tested, and what happens when it fails. Even a partial list beats a complete framework, because it is falsifiable. It also has the useful property of making the gaps visible as gaps rather than as a lower maturity score, which is what gets them funded.

The second question, usually asked immediately after, is what competitors are doing. The honest answer in 2026 is that almost nobody has this fully in place, that the median organisation cannot enumerate its agents, and that being merely competent here is currently a differentiated position. That is more reassuring than it sounds and considerably more actionable than a benchmark against peers who are also guessing.

What Eighteen Months In Looks Like

The functions that are working share three visible properties, and none of them are documents.

The inventory updates itself, sourced from cloud billing, API gateway logs, identity systems, and procurement rather than from a quarterly survey. Classification happens at intake, so a team starting a new AI feature gets a risk determination in days rather than discovering one at launch. And the evidence a regulator would ask for is generated by the systems as a byproduct of running, not assembled by a person ahead of an audit.

The functions that are failing at eighteen months share one property: their primary artifact is still a spreadsheet somebody maintains. That is the diagnostic. It means the function never got the engineering capacity it needed, and it will stay perpetually six months behind an estate that grows faster than it can be surveyed.

What This Means If You Are an Engineer

Two practical consequences, one immediate and one about careers.

Immediately: the artifacts this function needs are artifacts you should have anyway. An evaluation harness, structured traces with cost and outcome attribution, a registry of deployed agents and their permissions, and a documented human oversight point for consequential actions. Teams that already have those experience governance as a reporting requirement. Teams that do not experience it as a project, delivered under time pressure, with someone else setting the deadline. The work is identical; only the timing and the stress are different.

For careers: this is a genuinely new senior track, and it is currently being filled by people from compliance and legal backgrounds because those are the candidates who apply. The candidates who will be better at it are engineers who understand evaluation, telemetry, and how model deployment actually works, and who can read a regulation without needing it translated. That combination is rare enough right now that the people who have it are setting their own terms. If the specialisations in shortage are where the leverage is, this is one of them, and it does not require becoming a machine learning researcher.

Where This Goes

Expect the 45% to keep climbing through 2027, and expect the role to specialise as it matures, splitting into policy, assurance engineering, and incident response the way security did fifteen years ago. Expect the first enforcement actions under the high risk provisions to reset everyone's sense of what documentation is adequate, probably uncomfortably. And expect a period where companies with the function outcompete companies without it, not on compliance but on speed, because the ones who can demonstrate what their systems do will be able to deploy into regulated contexts that the others cannot enter at all.

That last point is the one worth holding onto. Governance is being sold internally as a cost of doing business, and for the first year that is what it will feel like. The organisations that treat it as capability rather than overhead end up with an inventory, telemetry, and evaluation infrastructure that everyone else lacks. Those are the same assets that make AI systems work. It is an unusual case where the compliance-driven build and the engineering-driven build converge on the same thing.