Hiring · July 29, 2026 · 10 min read

How to hire an AI governance lead: skills and process

How to hire an AI governance lead: what the role owns, why regulation created it, how to spot a policy-deck impostor, and job-shaped ways to test judgement.

← Part of The five pillars of hiring: what assessments measure

This one is for the hiring manager staring at a new requisition and a title nobody used two years ago: AI governance lead, or responsible AI officer, or AI compliance manager — the same job wearing three hats. Regulation created it. When the EU AI Act placed employment and other high-stakes AI in its high-risk tier, when Korea's AI Basic Act arrived, and when a US state patchwork — NYC's Local Law 144, Illinois, California, Colorado — each added its own rules, 'someone should probably track where we use AI' turned into a named, accountable job. What that person actually does is unglamorous and load-bearing: inventory the AI systems in use, classify each by risk, own the impact assessments, run the human-oversight process, and keep the audit trails a regulator will one day ask for. You need one when AI touches real decisions across real jurisdictions and no single person can currently answer 'what are we running, and who signed off?' You do not need one when you run a tool or two and your General Counsel can hold it in their head. Where it sits varies — legal, engineering, or a Chief AI Officer's remit — but the mandate is constant: coordinate legal, engineering and HR so obligations become process, not a slide deck.

What does an AI governance lead actually do?

Strip the title back and the job is custody of a question: where does this organisation use AI, and can we prove we use it responsibly? The lead maintains the inventory of AI systems, classifies each by risk, owns the impact assessments and human-oversight processes, and keeps audit trails intact — coordinating legal, engineering and HR so nothing falls through the seam between them. It is quiet, continuous work, not a quarterly report.

A real week looks less like ethics philosophy and more like plumbing. A product team wants to ship a feature that scores support tickets with a model; the lead has to work out whether that lands in a high-risk bucket and what documentation attaches before launch. HR is trialling a new CV-screening tool and someone has to ask the vendor the awkward questions before it goes near a candidate. A bias-audit result comes back looking off, and the lead decides whether it is a real adverse-impact signal or a small-sample artefact — then who needs to know. And when a customer's procurement team sends a forty-line AI due-diligence questionnaire, the answers exist because the lead kept the records current. The day-to-day usually includes:

• Keep a live inventory of every AI system in use — bought, built, or quietly bolted on by a team that never told anyone.
• Classify each system by risk against the regimes you operate under, and re-classify when a tool's use changes.
• Own impact assessments and the human-oversight process — the review step where a person can understand, question and override an automated output.
• Keep audit trails a regulator or auditor can actually query: what was decided, by whom, on what basis, and when.
• Coordinate legal, engineering and HR — translating an obligation into a workflow each will follow, then checking it holds.
• Field external scrutiny — customer due-diligence questionnaires, auditor requests, board questions — with evidence, not assurances.
• Own the process, not just the policy: success is a governance step engineers run because it helps, not one they route around.

Why does this role exist now?

Because the rules stopped being optional. For years, 'responsible AI' lived in principles pages and voluntary charters. Then it acquired teeth. The EU AI Act placed employment-related and other high-stakes AI in its high-risk tier, carrying obligations around documentation, human oversight, logging and transparency — read the EU AI Act and hiring for what high-risk means in practice. New York City's Local Law 144 requires an independent bias audit before an automated employment decision tool screens candidates. Layer on Korea's AI Basic Act and a widening US state patchwork, and a company operating across borders faces a stack of overlapping duties that no one owns by default.

That is the shift that created the job. When obligations were aspirational, tracking AI use was a nice-to-have somebody did in spare cycles. When they became enforceable — with documentation to produce and records to keep — 'someone should track this' became a role with a name and a line manager. Our own view, from the vendor side, is that this was always coming: we argued in compliance-first hiring AI that hiring AI is high-risk AI and that the records regulators want are a design input, not an afterthought. The governance lead is the person who makes that true inside your walls rather than on a vendor's roadmap.

Do you actually need one?

Often, not yet — and a good governance lead will tell you so rather than manufacture work. If you run one or two AI tools, hire in a single jurisdiction, and your General Counsel or Head of People can hold the whole picture in their head, a dedicated hire is premature. The obligations are real but the surface area is small, and a part-time owner covers it. Hiring too early gives you a governance function with nothing to govern and, worse, someone who justifies their seat by generating process nobody needs.

The threshold is genuine complexity, not headcount. You need a dedicated lead when several of these are true: AI touches consequential decisions like hiring, lending or access; you operate across multiple regulatory regimes at once; product teams are shipping models faster than anyone can track; or a customer, auditor or regulator has already asked for documentation you could not readily produce. That last one is the clearest tell. If answering 'what AI are you running and who oversees it?' currently requires a scramble across three teams, the coordination cost has outgrown the spare-cycles model. Until then, name an accountable owner, give them a fraction of their week, and revisit when the surface area grows.

What separates a strong lead from a policy-deck writer?

Every one of these titles attracts the same impostor: the candidate whose CV is a catalogue of frameworks authored, principles published and committees chaired, with no evidence any of it changed how a single system got built or shipped. Policy writing is the easy, visible half of governance and the half that fools interviewers. It reads as authority. It photographs well in a deck. And it has no operational teeth — a document engineers have never read governs nothing.

The real signal is a governance process people actually follow. A strong lead can point to a control they designed that a product team adopted willingly because it removed friction rather than adding it — a pre-launch checklist that got a feature to ship faster with the right records attached, an intake step that caught a risky vendor before procurement signed. They read enough law to know what an obligation requires and enough of the systems to know what is feasible to build, and they live in the tension between the two. Ask any candidate for a policy they wrote and they will oblige; ask for a process they shipped that is still running and followed a year later, and the impostor goes quiet. Look for:

• Operational translation — turning 'we must keep an audit trail' into a specific logging step engineering agreed to, not a paragraph in a wiki.
• Risk judgement under ambiguity — deciding whether a use is high-risk when the mapping is genuinely unclear, and being able to defend the call.
• Cross-functional credibility — engineers, lawyers and recruiters all take the person seriously, which requires speaking three dialects fluently.
• Comfort with being the friction — willing to slow a launch when it matters and, just as important, to get out of the way when it does not.
• Evidence over assertion — instinctively reaching for the record that proves a decision, because they have been on the receiving end of an audit.
• Enough regulatory literacy to be dangerous, not a law degree — the lead flags what needs proper counsel; they are not a substitute for it.

How do you test those skills?

Interviews reward the impostor here more than in almost any role — the job is partly talking well about governance, and a polished framework recitation is easy to mistake for competence. So do not ask what they know; give them the work. Job-shaped tasks, assessed on judgement and clarity rather than jargon, separate the people who have run governance from the people who have only presented it. Three tasks map onto the real job:

• Draft the intake questionnaire for a new AI tool a team wants to adopt — you are looking for the questions that surface real risk, not a generic vendor form padded to look thorough.
• Triage a bias-audit finding: hand them a result that looks like adverse impact and watch whether they distinguish a real signal from a small-sample artefact, decide what to escalate, and to whom.
• Brief a sceptical VP who thinks governance is red tape — a short written or spoken brief that makes the case in plain language, without hiding behind acronyms.

Score those on the same rubric for every candidate: did they ask the sharp question or the obvious one; did they reach for evidence; could a non-specialist follow them. This is work-sample assessment applied to a governance role — the same logic we use for engineers in work sample tests, pointed at judgement instead of code. Because much of the modern job involves reasoning about AI systems and using AI tools to move through a review backlog, it is worth observing how a candidate works with AI directly rather than taking their word for it — our guide to how to assess AI fluency covers reading that signal, and the 4D framework of Delegation, Description, Discernment and Diligence gives you a rubric for it. Run the tasks in a realistic AI Sandbox where the tools are genuinely available, and you watch the behaviour rather than infer it. However you run it — our platform, a well-designed take-home, an hour of shared-screen review — the principle is the one every auditor lives by: see the work, do not just hear the story.

What does the interview loop look like?

Keep it structured — same tasks, same questions, same scorecard for every candidate — because gut-feel chats reward exactly the fluent-framework impostor you are trying to screen out. A structured loop for this role does not need to be long; it needs the right people in the room and a clear division of what each stage tests.

The stages, and who runs them

• Screen — a short structured conversation on scope: have they owned an AI inventory, a risk classification, an audit response? You are checking for operational history, not principles they admire.
• Work sample — the intake-questionnaire and bias-audit-triage tasks above, run once and scored against a shared rubric. This is the stage that carries the most weight.
• Legal and engineering panels — a lawyer probes their regulatory judgement and where they know to stop and defer to counsel; an engineer probes whether their controls are buildable and whether teams would actually follow them.
• The sceptical-stakeholder exercise — the VP brief, ideally with a real internal sceptic in the room, testing whether they can carry a room that starts out hostile.
• Reference and scenario debrief — one or two structured references aimed squarely at 'did the process they built outlast them, and did people follow it?'

Read structured interviews for how to keep the scoring consistent across those panels, so you are evaluating demonstrated capability rather than the confidence of the pitch. Keep the loop tight; strong governance candidates are scarce and increasingly courted, and six rounds of vibes will lose you the good ones to a faster employer.

Seniority and where the role reports

Compensation and level shift too fast and vary too much by market for any figure here to be honest, so treat this qualitatively. Because the job blends regulatory judgement, cross-functional authority and enough technical fluency to earn engineers' respect, a credible lead sits at a senior individual-contributor or manager level — junior enough to still do the work, senior enough to tell a VP no. The rarer the combination of law-literacy and systems-literacy in your market, the higher you should expect to reach. Benchmark against your own bands and, far more importantly, hire on demonstrated operational judgement rather than anchoring on a title or a number.

Reporting line signals what you think the role is for. Under legal, it reads as risk containment; under the CTO, as governance built into systems; under a Chief AI or Data Officer, as strategy. Any of those can work — what cannot work is a governance lead with responsibility and no mandate to convene legal, engineering and HR. The authority to pull those teams into a room matters more than the box on the chart.

First 90 days: what good looks like

A strong lead does not open with a framework. They open with a map. In the first month, good looks like a credible inventory of the AI systems actually in use — including the ones no one mentioned — and a first-pass risk classification against the regimes you operate under. Not perfect; visible. You should be able to ask 'what are we running and how risky is it?' and get an answer that did not exist before they arrived.

By the end of the quarter, the map should have turned into one or two working processes: an intake step for new AI tools that a team has genuinely used, and the beginnings of an audit trail you could hand an auditor without a scramble. Just as telling is what they have not done — a good lead in ninety days has not blanketed the company in policy nobody reads, blocked every launch on principle, or made themselves the bottleneck on decisions others should own. The signal is a small number of controls people follow because they help, plus a clear, unhysterical view of where the real exposure sits. If instead you have a large policy library, a slower engineering org and a lead who cannot point to a single process a team adopted willingly, you hired the deck-writer after all — and you will feel it the first time someone external asks you to prove your work.

Governance is not the document you can produce; it is the process people follow when no one is auditing them. The best AI governance leads are judged the same way you would judge the systems they oversee — not by the policy on the shelf, but by the behaviour in the wild. Hire for that, test for that, and stop mistaking a fluent framework for a working one.