Two audiences read an article like this. Someone has been asked to build an AI governance function and wants to know what roles to open, in what order, reporting to whom. And someone wants to move into the field and wants to know what the work is and what would make them credible. This is written primarily for the first and should be useful to the second, because the honest answer to the second question is contained in the first.
The most useful thing to establish early: most organisations need fewer new roles than they expect. What they need is clarity about which existing roles now carry AI duties, and one or two people whose whole job is the part nobody currently owns.
Which roles actually exist
Job titles in this field are unstable, and the same title means different work in different organisations. Function is the more reliable frame.
| Function | Usually a | Owns |
|---|---|---|
| Programme leadership | Head of AI Governance, Chief AI Officer, or an existing risk or data executive | The mandate, the forum, classification decisions, the escalation route, and answering for the programme |
| Risk assessment and challenge | AI risk manager, model risk analyst | Running assessments, challenging first-line claims, tiering, sign-off below the forum threshold |
| Technical assurance | ML engineer or data scientist embedded in governance | Reading evaluation evidence critically, running or commissioning tests, judging whether a claim is supported |
| Legal and regulatory | Counsel with AI regulation depth, often shared | Regulatory perimeter, contract terms, role determination under the EU AI Act |
| Privacy | Existing DPO or privacy counsel | Lawful basis, data minimisation, impact assessments, the overlap with fairness measurement |
| Security | Existing security function | Model and tool abuse, prompt injection, tenancy, agent permissions |
| Independent assurance | Internal audit | Sampling the evidence the gates produced and reporting whether the programme works |
| First-line ownership | Product owners, ML engineering, deploying business units | Building it, documenting it, monitoring it, raising incidents |
Four of those eight are usually existing roles acquiring new scope. Two, programme leadership and risk assessment, are the ones most often genuinely new. Technical assurance is the one most often missing entirely, which is why some programmes accept vendor evaluation claims they have not evaluated.
The Chief AI Officer, now with a reference implementation
Until recently this title was mostly an invention, applied to anything from a research lead to a transformation programme manager. US federal policy has made it concrete: agencies had to designate a Chief AI Officer by 30 June 2025 under OMB M-25-21, with responsibility for establishing the processes that govern high-impact AI.
Whatever your view of the wider policy, the role design is instructive on three points. It is a single named accountable person rather than a committee, which forces classification decisions to have an owner. It combines convening authority across a distributed organisation with responsibility for the inventory. And it carries the ability to stop non-compliant use, which is what separates a governance role from a coordination role. Our public sector article covers the surrounding regime.
The trap in commercial adoption is appointing a CAIO whose actual remit is adoption and enablement, then expecting governance from them. Those are different jobs with opposing incentives at the moment of a difficult decision. If one person must hold both, be explicit about which one wins when they conflict, and expect to be tested on it.
Where the function should report
There is no correct answer, and anyone who tells you otherwise is describing their own organisation. There are only trade-offs, and the useful discipline is to choose one and then deliberately compensate for its known weakness.
| Reports to | Gains | Loses | Compensate by |
|---|---|---|---|
| Risk or compliance | Independence, an established challenge culture, a route to the board | Engineering credibility. Risk of becoming a documentation gate | Embedding technical assurance capability inside the function |
| Engineering or CTO | Technical credibility, early involvement, practical controls | Independence. Hard to refuse your own organisation's release | A reporting line to risk for escalations, and third-line sampling |
| Legal | Regulatory depth, comfort with ambiguity | Tends toward advisory. Often lacks the technical depth to review | Explicit decision rights, plus a technical reviewer with standing |
| Data or analytics | Proximity to the systems and the inventory | Competes with delivery targets. Weak on rights and legal framing | Legal and privacy as standing veto holders in the forum |
| CEO or COO directly | Authority. A refusal holds | Rare, fragile if the sponsor leaves, can lack operational grounding | Written mandate that survives a change of sponsor |
Three things matter more than the box: a written mandate, a route to an executive who will back a refusal, and enough technical literacy inside the function to review rather than accept. A function with all three works from any reporting line. A function missing the second will fail from the best one. The wider structure is in building an AI governance operating model.
Role by role: mandate, first 90 days, failure mode
The skills matrix
Four competencies, and the scarce thing is the combination rather than any one of them.
| Competency | Enough looks like | Common substitute that fails |
|---|---|---|
| Regulatory | Can read a statute, identify what applies, and say what it means for a specific system | Familiarity with summaries and vendor webinars, which breaks the moment a system does not match the example |
| Statistical | Can read a disparity table and an evaluation report and say whether the conclusion follows | Comfort with dashboards without the ability to question how a metric was constructed |
| Engineering | Understands the lifecycle well enough to know where a control can actually be placed | Vocabulary without mechanism, which produces controls engineers cannot implement |
| Facilitation | Can hold a difficult decision open and get a room to a documented conclusion | Consensus-seeking that avoids the decision, which is how programmes stall politely |
The translation ability that spans these is what to hire for and the hardest to test with a CV. A regulatory specialist who cannot tell whether an evaluation supports its claim will approve things they do not understand. An engineer who cannot see why a rights-based objection is not a technical inconvenience will lose every argument that matters.
Build or borrow
Centralise what needs consistency, and federate what needs context. Consistency matters for the risk methodology, the tiering rule, classification decisions, the inventory, and the regulatory perimeter, and none of those work if each business unit invents its own. Context matters for use case knowledge, subject matter judgement, monitoring, and incident response, and none of those work if a central team tries to hold them.
The pattern that works in larger organisations is a small central team owning method and decisions, with named governance contacts embedded in each business unit who carry first-line responsibility. That contact is usually part time and is the single highest-yield structural choice available, because it gives the central function reach without headcount and gives the business unit someone accountable.
Where a small organisation should not compromise: someone must be able to say no, and someone must be able to read the technical evidence. Both can be part of a wider job. Neither can be absent.
Hiring signals, and questions that test them
The most useful interview questions in this field describe an ambiguous situation and ask for a decision, because the work is mostly deciding under incomplete information.
- Judgement under ambiguity. A team wants to deploy in two weeks. The vendor cannot supply fairness evidence. It is a consequential decision about people. What do you do? Strong answers narrow the use, add human review, or decline, and say what evidence would change the answer. Weak answers escalate without a recommendation.
- Technical honesty. Hand them a real evaluation report with a thin test set. Do they notice? Do they say so?
- Regulatory reasoning from source. Ask them to reason about a system against an actual article text rather than recall a summary.
- Willingness to be unpopular. Ask for a time they stopped something. Then ask what it cost them, because the second answer reveals whether it happened.
- Proportionality. Ask how they would govern a document summariser. Applying high-risk process to everything is a real failure mode and trains the organisation to route around you.
What credentials tell you
Formal credentials in this field are young. The IAPP AI Governance Professional certification exists and is the most widely recognised general credential. Others come from standards bodies and from vendors.
A credential tells you someone invested time and can speak the shared vocabulary, which is genuinely useful for shortlisting. It does not tell you whether they can read an evaluation report critically or hold a difficult decision. Treat it as evidence of seriousness rather than of capability, and test capability directly.
For people moving into the field, the adjacent backgrounds that transfer best are model risk management, privacy, internal audit, safety-critical engineering, and industrial and organisational psychology, the last being unusually well suited to fairness measurement in employment contexts. In each case the gap to close is the other side of the translation: technical people need the rights framing, and specialists in rights and process need enough statistics to challenge a claim.
Sequencing hires
| Stage | Hire | Because |
|---|---|---|
| First | Programme lead with decision authority | Nothing else functions without someone accountable and able to refuse |
| First three | Add risk assessment, and technical assurance | Assessment creates throughput; assurance stops you accepting unverified claims |
| First five | Add embedded business unit contacts, part time | Reach without headcount, and first-line accountability that exists |
| Beyond | Specialisation by risk area or by regime, and tooling | Only once the method is stable, or you automate an immature process |
AI literacy is a standing obligation
Since 2 February 2025, Article 4 of the EU AI Act has required providers and deployers to ensure a sufficient level of AI literacy among staff and others operating their systems on their behalf. Two features make this a people-function concern rather than a training-catalogue item. It reaches contractors and service providers, not only employees. And it is outcome-based, with no prescribed format, so a completion certificate does not by itself discharge it.
The version of this that survives contact with reality is narrow: identify the decisions people actually make about AI in your organisation, and give each group the competence that decision requires. A reviewer who accepts fairness evidence needs to read a disparity table. A product owner accepting residual risk needs to understand what they are accepting. That is a smaller and more useful programme than organisation-wide awareness training.
Retention
People leave these roles for a consistent reason: they were hired to govern and given no authority to do it. Someone who spends eighteen months writing assessments that never change an outcome will leave, and they will be right to.
What retains them is unglamorous. A decision they made that held. A refusal that was backed. Evidence that the programme changed something. Budget for the tooling that removes the manual work. And a route out of the function that is not out of the organisation, because a governance specialist who becomes a product leader is the best outcome available for both parties.
Frequently Asked Questions
What is the first AI governance hire?
Someone with decision authority rather than a specialist, because a specialist without authority produces analysis that nothing acts on. Concretely, a programme lead who can be accountable for classification decisions, convene the people who need to be in the room, and refuse a deployment with backing. In a smaller organisation this can be part of an existing risk, legal or data leadership role, provided the mandate is written down and a sponsor will support a refusal.
Do we need a Chief AI Officer?
You need the function: a single named person accountable for classification, the inventory, and the authority to stop non-compliant use. Whether it carries that title depends on your size and whether the title would help or attract expectations you cannot meet. The failure to avoid is appointing someone whose real remit is AI adoption and expecting governance from them, because those roles have opposing incentives precisely when a hard decision arrives.
Should AI governance sit under risk or under engineering?
Both work and both have a characteristic weakness. Under risk you get independence and a challenge culture, and you have to buy technical credibility, usually by embedding someone who can read an evaluation report. Under engineering you get credibility and early involvement, and you have to buy independence, usually through an escalation line to risk and third-line sampling. Choose based on which weakness you can genuinely fix in your organisation, not on which structure looks better on a chart.
How large should the team be?
Size by the volume of decisions rather than by company headcount. The measure that predicts workload is how many AI use cases require a real assessment each quarter, and how many are consequential enough to need the heavy path. A useful pattern in large organisations is a small central team owning method and decisions, plus part-time embedded contacts in each business unit. That gives reach without proportional headcount, and it puts first-line accountability where the context is.
What background transfers best into AI governance?
Model risk management transfers most directly, because the discipline of independently challenging a model's fitness already exists there. Privacy transfers well on process and rights. Internal audit transfers on evidence and independence. Safety-critical engineering transfers on failure analysis. Industrial and organisational psychology is unusually well suited to fairness measurement in employment settings. In each case the gap is the other half of the translation, and candidates who know which half they are missing tend to close it faster.
Is a certification worth getting?
For someone entering the field, yes, mainly because it gets a CV past a filter and provides a structured tour of vocabulary you will need. For someone already doing the work, the return is lower than a demonstrable artefact: an assessment you wrote, an audit you ran, a control you designed that engineering adopted. As a hiring signal, treat a credential as evidence of seriousness and test capability directly, because the certification does not distinguish between someone who can read an evaluation report critically and someone who cannot.
