How to Get an AI Governance Manager Job in 2026-27

What an AI governance manager actually owns, and the titles it gets confused with

The job is making an organisation's use of AI defensible: defensible to a regulator, to an auditor, to a customer's procurement team, to a journalist, and to the person the system made a decision about. That is the whole of it. Everything in the role is downstream of that sentence.

Concretely, an AI governance manager owns seven things. First, the inventory: a single authoritative list of where AI is being used, which in most organisations starts out badly incomplete because nobody counted the tools people bought on a corporate card. Second, intake and triage: how a use case enters the process and how it gets a risk tier. Third, the gate: what must be true before something goes live, and who can say no. Fourth, the written floor: policy, standards, and the templates that turn a standard into an artefact somebody can actually fill in. Fifth, third party assessment: what you demand of a vendor and what you do when they refuse. Sixth, what happens after launch: monitoring thresholds, re-review triggers, incident handling, and the question of who notices when a model quietly changes. Seventh, the reporting line: a committee or a board that receives a short document and records a decision.

The unit of governance is the use case, not the model. This is the single most important structural idea in the job and the one that separates people who have done it from people who have read about it. The same model, say a hosted large language model behind an API, is low concern when it drafts internal meeting notes and high concern when it screens job applicants. Governing models gets you a list of model names and no control over risk. Governing use cases gets you a list of decisions, each with an owner, a data footprint, a population affected, and a tier. Candidates who describe their work as an inventory of models signal that they inherited a spreadsheet. Candidates who describe an inventory of use cases with an owner per row signal that they ran something.

A real week in the job is unglamorous and worth knowing before you apply for it. You spend it reading intake forms that are filled in badly, chasing a product manager who launched something without telling you, arguing about whether a vendor's evaluation results mean anything, rewriting a four page assessment template down to two because nobody completed the four page one, sitting in a design review and asking the question the engineers were hoping nobody would ask, and writing the paragraph that will be read by an executive who has eleven minutes. If you want to work on AI, this is not that job. If you want the organisation's use of AI to be something you would defend in public, it is exactly that job.

Several titles sit next to this one and get confused with it constantly. Applying to the wrong one is the most common wasted month in this market, because the screen is done by a different function and asks for different evidence.

• Model risk manager or model validator. The older and more established version of this work, found in banks, insurers and some health payers, built on supervisory guidance rather than AI specific law. Owns validation: independent challenge of whether a model does what it claims. Deeper on statistics, narrower in scope (traditionally credit, market, pricing and capital models rather than a chatbot in HR). In financial services, AI governance is very often a subteam or a retitling inside this function.
• Responsible AI lead or trustworthy AI lead. Usually product side, usually at a technology company or an AI vendor, usually reporting into engineering, product or research rather than risk. Owns evaluation design, red teaming, safety policy for a product surface, and the content of a model or system card. Measured on whether the product behaves, not on whether the paperwork exists.
• AI counsel or AI regulatory counsel. A lawyer. Owns the legal position: how an obligation applies, what a contract must say, what risk the company accepts. Does not usually own the operating process. Many organisations hire this role first and then discover nobody is running the intake queue, which is how the governance manager role gets created.
• Privacy manager or data protection officer. Owns personal data: lawful basis, records of processing, data protection impact assessments, subject rights, transfers. Enormous overlap with AI governance machinery and often the same person in a mid sized company, but a privacy programme is scoped to personal data and a great deal of AI risk (accuracy, intellectual property exposure, security of an agent that can take actions, safety) is not a personal data question at all.
• Trust and safety manager. Owns harm on a platform: abuse, content policy, enforcement, escalation. Shares vocabulary with AI governance and increasingly shares tooling, but is measured on outcomes in a user community rather than on control evidence.
• AI ethicist. Usually a research or advisory role, sometimes an academic one. Thinks about what the organisation should do. The governance manager is accountable for whether it happened. Job postings using the ethicist title and describing an operating process are usually misnamed governance roles, and are worth applying to.

Four different jobs hide under this title. Read the reporting line before you apply

Postings for AI governance manager describe at least four distinct jobs. They want different evidence, interview differently, and pay on different ladders. The tell is not the title or the responsibilities list, which are near identical across all four. The tell is the reporting line, which is usually one line in the posting and sometimes only visible if you look up the hiring manager.

Work out which one you are reading before you write a single line of your application, because the opening paragraph of your resume summary should be written for that version and only that version.

The four, with the reporting line that identifies each one and the evidence each screens on:

• Compliance led. Reports to a chief compliance officer, general counsel or data protection officer. The job is obligation mapping, policy, assessments, records, training and audit readiness. Screens hardest on regulatory knowledge and on programme building experience. Strongest home for privacy, legal and compliance backgrounds. Interview weight sits on the regulatory map and on how you handle a business unit that does not want to comply.
• Risk led. Reports into a chief risk officer, head of operational risk or head of model risk, and is most common in banks, insurers, asset managers and large health payers. Treats AI as a model risk and inherits an existing apparatus: an inventory standard, a tiering methodology, independent validation, a model risk committee, and an internal audit function that will test you. Screens hardest on whether you have worked inside a three lines of defence structure and survived an examination. Strongest home for model risk, validation, audit and quantitative backgrounds. Interview weight sits on tiering methodology, independent challenge, and documentation that stands up to a regulator reading it two years later.
• Product led, often labelled responsible AI. Reports into engineering, product or a chief technology officer. The job is embedding review into the development lifecycle, designing evaluations, running red teaming, writing system cards, and deciding launch readiness. Screens hardest on technical credibility. Strongest home for ML engineers, data scientists and technical programme managers. Interview weight sits on evaluation design and on whether an engineering team would listen to you.
• Customer facing assurance, the newest of the four and the most underrated way in. Reports into trust, security, legal or revenue operations at a software or AI vendor. AI vendors now receive AI questionnaires from every enterprise buyer, the way they received security questionnaires a decade ago, and somebody has to answer them, keep the answers true, and hold the evidence behind them. The job is those questionnaires, the trust centre, supporting ISO/IEC 42001 certification or a SOC 2 with AI in scope, and handling customer AI addenda in contracts. Measured on deals unblocked and sales cycle time, which means the business value is immediate and the screen leans less on a prior AI governance title than the risk led version does.
• How to read a posting in thirty seconds: if it names a committee you would staff, it is risk led or compliance led. If it names a release process or a launch gate, it is product led. If it names customers or questionnaires, it is assurance. If it names all three, the role is under resourced and you should ask in the screen who else is on the team and who holds the budget.

The regulation and standards map you are expected to know cold

This is the part candidates most often get wrong, and they get it wrong in a specific way: they memorise a summary written by a vendor, repeat a date, and are wrong in the one room that matters. The rule for this market is simple. Know the obligation and the structure, be careful with the date, and name the primary source you would check. Multiple AI timetables in both the EU and US states have been moved after enactment, so treating any specific compliance date as settled without checking the current text is the easiest way to lose credibility in this field.

Say it in an interview in roughly this shape. "High risk systems carry obligations covering risk management, data governance for training and validation data, technical documentation, record keeping and logging, human oversight, accuracy, robustness and cybersecurity, and a conformity assessment before the system is placed on the market, with post-market monitoring and serious incident reporting afterwards. The application timetable is staggered and has been amended since adoption, so I would check the current consolidated text rather than quote you a month." That answer is better than a confident date, and a hiring manager who has lived through one deferral will hear the difference immediately.

The EU AI Act is the centre of gravity for the knowledge test, whether or not your employer is in Europe, because it is the most structured scheme in existence and interviewers use it as a shared vocabulary. Know these pieces properly. The risk structure: a small set of prohibited practices; high risk systems defined partly by product safety annexes and partly by a list of use areas including employment, education, essential private and public services, credit, life and health insurance pricing, law enforcement, migration and biometrics; transparency obligations for things like chatbots, emotion recognition and synthetic content; and everything else, which carries no specific obligation beyond the general AI literacy duty that applies to providers and deployers alike. Separately, obligations attach to general purpose AI models themselves, including technical documentation, information for downstream providers, a copyright policy and a summary of training content, with additional obligations for models presenting systemic risk. A code of practice process exists for general purpose models; check its current status before describing it.

The role distinction matters more in practice than the tier list, and it is the question that separates candidates. A provider develops a system or places it on the market under its own name. A deployer uses one under its own authority. Most companies are deployers and assume that caps their obligations. It does not always: a deployer that puts its own name or trademark on a high risk system, that substantially modifies one, or that changes the intended purpose of a system in a way that makes it high risk can become a provider and inherit the heavier set of duties. Deployer duties are lighter but real, including use in line with the instructions, human oversight by competent people, input data relevance where the deployer controls it, log retention, informing affected workers, and for some deployers a fundamental rights impact assessment. Being able to walk through that with a concrete example (a company that fine tunes an open weight model, brands it, and uses it to screen applicants) is worth more in an interview than reciting any annex.

In the United States there is no single federal AI statute, and the honest framing is that AI is governed by existing law applied to new systems plus a growing patchwork of state statutes. The federal direction changed materially after the 2024 election: the prior executive order on AI was revoked and replaced, and the Office of Management and Budget memoranda that govern federal agency AI use and AI procurement have since been reissued. If you are interviewing for a government role or a federal contractor, read the current memoranda rather than a summary, because this is the area most likely to have moved again since any article you read, including this one.

Existing law you should be able to apply without looking up: Section 5 of the FTC Act on unfair or deceptive practices, which is how overstated AI capability claims get enforced; the Equal Credit Opportunity Act and Regulation B, which require specific and accurate reasons for adverse action and therefore constrain any credit model whose reasons you cannot articulate; the Fair Credit Reporting Act, where a third party's model output used to make eligibility decisions about a person can constitute a consumer report; Title VII and the Americans with Disabilities Act for selection procedures, together with the Uniform Guidelines on Employee Selection Procedures at 29 CFR Part 1607, which is the durable citation now that federal agency guidance pages on AI hiring tools have been added and removed; HIPAA for protected health information in any clinical or payer deployment; and the Gramm-Leach-Bliley Act and its safeguards expectations in financial services. Under the GDPR, Article 22 on decisions based solely on automated processing is the clause European interviewers probe, and the practical question is whether your human review is meaningful enough that the clause does not bite. In financial services, the Federal Reserve and OCC supervisory guidance SR 11-7 on model risk management remains the operative framework and predates the AI conversation entirely, which is why banks were the least surprised institutions when generative AI arrived.

State and sector specifics worth knowing by name, with the caution that status and dates move and should be checked against the statute or the regulator's own page. New York City's Local Law 144 requires an annual independent bias audit of an automated employment decision tool, publication of a summary of results, and notice to candidates, and it is in force. Colorado enacted a broad AI consumer protection statute addressing algorithmic discrimination whose commencement has been moved by the legislature. Illinois has both a video interview AI statute and an amendment to its Human Rights Act addressing AI in employment decisions. Texas enacted a responsible AI governance statute. California has layered several obligations including automated decision making technology rules from its privacy regulator, training data transparency, provenance disclosure for generative systems, and frontier model transparency, and more than one of those has been amended after passage. Utah requires disclosure when generative AI is used in regulated occupations. For insurers, the NAIC adopted a model bulletin on the use of AI systems that many state departments have issued in their own name, and it is the single most useful document to read before an insurance interview. For medical devices, the FDA regulates AI enabled devices and has a mechanism for pre-authorised model updates through a predetermined change control plan, which is the closest thing in US law to a solved answer for the problem of a model that changes after approval.

Outside the US and EU: the United Kingdom has no AI act and governs through existing regulators, with the ICO, FCA and MHRA most relevant, plus a national AI safety and security institute doing evaluations. Canada's broad AI bill died with the parliamentary session and the current position should be checked rather than assumed. China has binding rules on recommendation algorithms, deep synthesis and generative AI services including filing and labelling requirements, which matters if your employer ships there. Brazil, South Korea, Japan and India are all at different points and are worth a sentence each rather than a confident paragraph.

Standards are the part most candidates skip and the part that increasingly decides interviews, because standards are what an auditor tests against. Know which of these your target employer uses, because a bank will speak SR 11-7 and NIST, a European manufacturer will speak the AI Act and ISO, and a software vendor will speak ISO/IEC 42001 and SOC 2.

• NIST AI Risk Management Framework 1.0. Organises the work into Govern, Map, Measure and Manage. Voluntary and American, used worldwide, and the vocabulary most US employers default to.
• NIST Generative AI Profile (NIST AI 600-1). The most useful single list of generative specific risks in print, and the document to rewrite your intake questionnaire against. Read it end to end rather than in summary.
• ISO/IEC 42001. Specifies a certifiable AI management system, and the standard an enterprise customer now asks your employer to certify against. Understanding that it certifies the management system rather than any particular model is a distinction you will need in a sales conversation and in a vendor assessment.
• ISO/IEC 23894 and ISO/IEC 42005. Risk management guidance aligned with ISO 31000, and AI system impact assessment respectively. 42005 is the most practical of the set when you are writing your own assessment template.
• The accreditation layer. There is a companion standard setting requirements for the bodies that certify an AI management system, which is why accredited 42001 audits now exist and why a certificate has a scope statement worth reading rather than a logo worth trusting.

Which backgrounds get hired, and the gap each one has to close

Almost nobody in this field has ten years of AI governance experience, because the field is not ten years old at scale. Every person in the job arrived from somewhere else, and hiring managers know it. What they are screening for is transferable machinery plus one closed gap.

The pattern across all of them: the easy part to acquire is AI knowledge, and the hard part to acquire is experience of running a control process that someone independent has tested. If you have the second, you can learn the first in a quarter. If you only have the first, you need to manufacture evidence of the second, which is the twelve week plan at the end of this guide.

One background that does not transfer as well as people expect: general project or programme management with an AI certificate. It fails because the job is not coordinating a project, it is holding a position under pressure. A hiring manager's unspoken question is whether you can tell a vice president that something is not shipping this quarter and still be invited to the next design review. Nothing in a project management track demonstrates that, and a short course certificate actively hurts when it is the most prominent credential on the resume, because it reads as a substitution for experience.

Ranked by ease of transition, with the gap each background has to close and the specific thing that closes it:

• Model risk management and model validation. The strongest route by a wide margin, especially into banks, insurers and payers. You already own an inventory with a tiering standard, you already write independent challenge, you have already been examined, and you already know what documentation looks like when a regulator reads it. Gap: generative and agentic systems break assumptions your methodology is built on, because there is no training dataset you control, no stable version, and no single performance metric. Close it by validating one generative use case end to end and being able to say what you did instead of a backtest.
• Privacy programme management. Second strongest and the most common route in mid sized companies. Your machinery maps almost one to one: a record of processing becomes a use case inventory, a data protection impact assessment becomes an AI impact assessment, a vendor due diligence process becomes vendor AI assessment, a lawful basis analysis becomes a purpose and necessity analysis. Gap: a large share of AI risk is not personal data (intellectual property exposure, factual accuracy, security of an agent with tool access, safety) and privacy trained candidates routinely under scope assessments. Close it by producing an assessment that materially addresses accuracy, security and IP without turning them into privacy questions.
• Internal audit, IT audit and GRC. Third. You understand control design versus control operation, evidence, sampling and testing, and you can tell a real control from a document that describes one. You are also the person who knows that a policy nobody follows is worse than no policy. Gap: credibility with builders, and a tendency to produce findings rather than a working process. Close it by designing and running an intake process yourself rather than auditing one, and by being able to read a model evaluation report and say something useful about it.
• Regulatory, product or technology counsel. Fourth for the manager role and first for the counsel role. You can read the primary source, which is rarer than it should be, and you own the question of what the company is actually required to do. Gap: operating. Many lawyers can tell you what the obligation is and have never built the queue, the template, the tier rule or the committee pack that makes it happen. Close it by showing an artefact you built that someone else used without you in the room.
• Applied machine learning and data science. Fifth by ease, first by ceiling. You can look at a system and know whether a claim about it is plausible, which is the thing every other background on this list has to fake. Gap: control language, evidence discipline, and patience with committees. A common failure is treating governance as an engineering problem and producing an excellent evaluation harness with no decision record attached to it. Close it by writing one assessment in the register and reporting language an auditor expects, and by learning to say "the control is X, the evidence is Y, the owner is Z" without flinching.
• Trust and safety and content policy. Strong for consumer platforms, AI labs and anywhere the risk is harm to users rather than regulatory exposure. You have run real escalations under time pressure, which almost nobody else on this list has. Gap: the enterprise and regulated vocabulary (tiering, controls, audit evidence, committee reporting). Close it with a credential that forces that vocabulary on you and one artefact written in it.
• Procurement and third party risk. Underrated, and the fastest route in at a company that mostly buys AI rather than building it, which is most companies. Vendor AI assessment is a large fraction of the day job there. Gap: you have to be able to tell when a vendor answer is technically true and practically useless, which requires enough technical depth to ask the second question. Close it by taking one AI vendor through a full assessment and writing down the answers you refused to accept.
• Clinical informatics, nursing informatics and physician informaticist. The route into health systems, which hire for this work under titles that rarely mention AI. You understand clinical workflow, which is the thing that determines whether a model does any good, and you can say what a clinician will actually do with an alert at two in the morning. Gap: regulatory and vendor machinery outside the clinical frame. Close it with the HIPAA and FDA angles plus one completed vendor assessment of a clinical AI product.

How the hiring process actually runs

There are two very different paths in, and the posted one is the smaller of the two. A large share of these roles are created inside organisations and filled by someone already there who had started doing the work: the privacy manager who built the first inventory, the model validator who took the first chatbot, the audit manager who ran the first AI readiness review. If you are inside an organisation that uses AI at all, that is your highest probability route and the final section of this guide is a plan for it. The external market exists, is real, and is more competitive per posting because the title attracts everyone.

For an external process, the loop is more structured than general compliance hiring and less structured than engineering hiring. Expect four to six conversations across three to six weeks. Larger banks and insurers run longer, because a risk hire usually needs sign off from a second line head and sometimes from audit.

Who screens, in order. A recruiter who is working from a requirements list they do not fully understand, which means keyword matching is unusually decisive at this stage: get the framework names and the artefact names into the resume literally. Then the hiring manager, who is one of a head of model risk, a chief privacy officer, a general counsel, a chief compliance officer, a head of responsible AI or a chief information security officer, and whose version of the job you should have identified from the reporting line. Then a technical counterpart, who is the interview candidates most often fail. Then stakeholders: legal, security, procurement, a business line leader, sometimes internal audit. Occasionally a panel run as a mock review board.

On the technical counterpart interview, understand what is being tested, because it is not your knowledge of transformers. An ML lead or staff engineer has been asked to assess whether you will be a drag. They are listening for three things: whether you understand enough to know which of their answers are evasions, whether you distinguish risk from inconvenience, and whether you will give them a decision or six weeks of ambiguity. The way to pass is to ask the questions a thoughtful engineer would want asked, and then say what you would and would not block. The way to fail is to perform technical knowledge you do not have, which they detect inside two follow up questions, or to answer every question with a reference to a framework.

Timing and seniority notes. Manager level roles in the US are commonly posted at five to ten years of total relevant experience with no requirement for that experience to be AI specific, which is the most important sentence in most postings and the one candidates do not believe. Director and head of roles want a programme built from nothing at least once. The market is senior heavy and genuinely thin at entry level: there are very few junior AI governance jobs, and the realistic entry route is an adjacent junior role (privacy analyst, model validation analyst, IT audit associate, trust and safety analyst) followed by an internal move. If you are early career and someone is selling you a direct path into AI governance management, they are selling you something.

The written exercise is the distinctive stage of this loop and it appears in most serious processes. It takes one of four shapes, and knowing which one you have been handed tells you what is being graded.

• Triage a use case. You are given two to five short use case descriptions and asked to tier them and say what each needs. Graded on whether you ask what happens to the output rather than what model it uses, whether your tiering rule is consistent across the cases, and whether you separate what you would require from what you would recommend.
• Critique a document. You are handed a policy, an assessment or a vendor response and asked what is wrong with it. Graded on whether you find the gap that matters rather than the ten that do not, and on whether you distinguish a missing control from missing paperwork.
• Write a template. Draft the intake questionnaire or the assessment template. Graded almost entirely on length and usability. A fifteen question one page form that people actually complete beats a thorough four page form every time, and saying so out loud is itself a strong signal.
• Present a plan. A thirty, sixty and ninety day plan for a described organisation. Graded on sequencing. The strong answer starts with the inventory and one real decision, not with a policy. Anyone who proposes writing a policy in the first thirty days has not done this work, because a policy written before you know what people are actually doing prohibits the wrong things and gets ignored.
• Whichever shape it takes, keep it under two hours of your time and say what you did and did not do. "Here is the tiering rule, here are the three cases, and here are the two questions I would have asked the business owner before finalising case two" is a stronger submission than a polished document that pretends no information was missing.

The resume: what lands, and what gets skipped entirely

Two readers see your resume. A recruiter matching keywords, and a hiring manager looking for evidence that you have operated a process. Write for both, in that order, in the top third of page one.

Open with a three line summary that names the version of the job you are applying for, the machinery you have run, and one number. Not a profile paragraph about your passion for responsible AI. Every applicant has that paragraph and it is skipped by every reader.

What gets skipped entirely, and listing it costs you space you need: a tool list without context (naming a governance platform tells a reader you had a licence, not that you ran a process); the phrase "passionate about ethical AI" and all of its variants; short online course certificates listed above real credentials; a claim to be "familiar with" a framework, which reads as having read the executive summary; generic cross functional collaboration lines; any sentence containing the word "leveraged"; and conference talks about AI ethics with no operating experience behind them.

Confidentiality, handled properly. A lot of your best evidence is sensitive: the use case that was stopped, the vendor that failed, the finding from an examination. Do not name the business line, the vendor or the regulator. Do describe the shape and keep the number. "Blocked a candidate screening deployment after the vendor could not produce selection rate data by category, and sourced an alternative that could, adding five weeks to the programme" names nobody and tells a hiring manager everything about how you work. If you cannot say it without naming names, say the category instead.

Credentials, ordered by what actually moves a screen. The IAPP AIGP is the one recruiters recognise by name and the cheapest signal available; it opens a screen and will never close an interview, and anyone who tells you it qualifies you to run a programme is wrong. For a privacy led route, CIPP (in the E or US variant that matches your market) and CIPM remain the stronger pair, with CIPT if you work closely with engineering. For audit and risk routes, ISACA's CISA, CRISC and CISM carry real weight, and ISACA's newer AI audit and AI security credentials are becoming recognised in audit heavy organisations. An ISO/IEC 42001 lead implementer or lead auditor course matters specifically if your target employer is pursuing certification, and you should say which. CISSP matters if the role sits in security. For model risk routes, the FRM or a quantitative master's degree carries more weight than any AI credential. A law degree is required only for counsel roles and is neutral to mildly helpful otherwise, with one caveat: a lawyer applying for a manager role must show operating evidence or the resume reads as a counsel application in the wrong pile. PMP is close to neutral. A short AI course certificate from a course platform, listed prominently, is a negative signal in this specific field.

One formatting note specific to this role. Name the frameworks and the artefacts literally, using both the full name and the acronym, because the recruiter's search is literal: "NIST AI Risk Management Framework (AI RMF)", "ISO/IEC 42001", "EU AI Act", "model risk management (SR 11-7)", "data protection impact assessment (DPIA)", "AI impact assessment", "model card", "use case inventory", "third party AI risk assessment". Candidates who write around these terms elegantly get filtered out before a human reads the elegance.

The rule for bullets: a bullet earns its place if it contains an artefact, a count, a unit of time, or a decision. Most AI governance resumes contain none of the four. Below are weak and strong versions of the same work, of the kind a privacy or audit manager has usually already done. The counts in the strong versions are illustrative of the shape to aim for, not benchmarks to hit: use your real ones.

• Weak: "Responsible for AI governance across the enterprise." Strong: "Built the first AI use case register (142 use cases from 38 teams, 11 tiered high risk) by reconciling single sign on grants, card spend and cloud model API billing against a 9 question survey, and closed 24 duplicate tools in the first quarter."
• Weak: "Familiar with NIST AI RMF and ISO/IEC 42001." Strong: "Rewrote the intake questionnaire against the NIST Generative AI Profile, which added retrieval permission scope and prompt injection exposure as triage questions and reclassified 4 use cases upward."
• Weak: "Performed AI risk assessments." Strong: "Ran 31 AI impact assessments to decision, cutting median time from intake to go or no go from 6 weeks to 9 days by tiering 70 percent of intake into a documented light path."
• Weak: "Worked with vendors on AI risk." Strong: "Assessed 19 AI vendors against a 24 control questionnaire; rejected 3 for refusing to confirm in writing that customer data was excluded from training, and negotiated model version pinning and 30 day deprecation notice into 6 contracts."
• Weak: "Supported AI governance committee." Strong: "Wrote the charter and the monthly pack for an AI review committee chaired by the chief risk officer; every high tier use case reached a recorded decision before launch, and the process passed internal audit with 2 low findings."
• Weak: "Created AI policy." Strong: "Authored a 2 page AI use standard that prohibits 3 named practices (customer personal data in consumer tools, unreviewed autonomous actions on production systems, and generated output presented to customers without a named human owner), and trained 400 staff against it."

The interview, question by question

The questions below are the ones that actually recur, with what each is testing and the shape of a strong answer. Prepare three stories before you walk in: a time you stopped something, a time you let something ship that made you uncomfortable and how you bounded it, and a time you were wrong. The second and third are the ones that separate candidates, because this job requires judgement under commercial pressure and anyone who has only stopped things has not been trusted with much.

"Walk me through how you would build an AI inventory here." Testing whether you have actually done it, because the answer from people who have is specific about data sources and the answer from people who have not is a process diagram. Strong: name the evidence sources (single sign on and OAuth app grants, expense and card data for AI subscriptions, procurement and contract records, cloud and model API billing, browser extension inventory, a short survey to team leads, and the security team's shadow IT findings), say you reconcile them rather than trusting any one, say the register is by use case with a named owner per row, and say you expect the first version to be wrong and plan a second pass. Add the hard part out loud: the inventory decays the moment you publish it, so it needs a trigger (procurement, a new tool request, a design review) that feeds it automatically rather than an annual refresh.

"A product team wants to put a customer facing support assistant live in three weeks. What do you do?" Testing whether you can govern on a real timeline. Weak answers either wave it through or demand a twelve week process. Strong: establish what the assistant can do (answer only, or take actions like issuing a refund or changing an account), what it reads (public help content, or customer records), what the user sees, and what happens when it is wrong. Then name the conditions you would require before launch and the ones you would accept after: scope the retrieval corpus and confirm permission handling, an evaluation set with a baseline you can regress against, a tested escalation path to a human, disclosure that it is an AI system, logging sufficient to reconstruct a conversation, a kill switch somebody has actually used in a drill, and no autonomous write actions in version one. Say which of those you would refuse to launch without, which is the whole point of the question.

"Are we a provider or a deployer, and does it matter?" Testing whether your EU AI Act knowledge is structural or memorised. Strong: explain that most organisations are deployers of systems built by others, that deployer obligations are lighter but not nil, and that you can become a provider by putting your own name on a high risk system, substantially modifying one, or changing the intended purpose so that it becomes high risk. Then apply it: a company fine tuning an open weight model, branding it, and using it to rank job applicants is in a very different position from a company using an off the shelf tool for the same purpose. Then be honest that the classification is a legal determination you would reach with counsel on the facts, which is the answer a general counsel wants to hear.

"How do you tier risk?" Testing whether you have a rule or a vibe. Strong: tier on consequence, not on technology. The questions that drive the tier are whether the output affects a person's access to employment, credit, housing, insurance, education, healthcare or a legal right; whether a human meaningfully reviews it before it takes effect; whether it is visible to a customer; what categories of data it touches; whether it can take actions in other systems and at what scope; and whether a regulated obligation attaches. Give your thresholds rather than adjectives. Then say what the tier changes: a high tier gets an impact assessment, independent review, defined evaluation evidence, a committee decision and post launch monitoring; a low tier gets a registered record and an attestation, and crucially a route to escalate if the use changes. A tiering scheme with no light path is a scheme that gets bypassed.

"The business will go around you. How do you stop that?" Testing seniority. Weak answers reach for policy enforcement. Strong: you make the sanctioned path faster than the unsanctioned one, you give a same week answer on low tier items, you get into design reviews before anything is built rather than reviewing at the end, you make the register the route to budget and procurement approval so bypassing it costs money, and you accept that some of your job is marketing the process internally. Then add the enforcement backstop honestly: a documented exception process with an executive signature and an expiry date, because exceptions that never expire are how programmes rot.

"How do you know a human in the loop control is working?" Testing whether you understand that controls decay, which is the most useful single idea in this field. Strong: a human in the loop is only a control if the human sometimes disagrees. Measure the override rate and the time spent per decision. If reviewers approve all but a handful of recommendations and spend a few seconds on each, you have automation bias and a rubber stamp, and you should say so in the committee pack. Fixes are concrete: show the reviewer the evidence rather than the conclusion, sample and audit a share of approvals, require a written reason for an override and for an approval on high impact cases, rotate reviewers, and set a threshold that triggers re-review of the control itself.

"What would you do about shadow AI?" Testing pragmatism. Strong: start by assuming it is happening and that forbidding it will not stop it, because the alternative to a sanctioned tool is a personal account with no logging. Measure it (network and single sign on data, expense data), provide a sanctioned option fast, prohibit the small number of things that are genuinely intolerable with a clear reason attached, and make the amnesty explicit: register what you are using and you are fine. Candidates who answer with a block list and training have not managed people.

"A vendor says their model is fair and tested. What do you ask?" Testing whether you can get past marketing. Strong: ask for the evaluation set and who built it, the metrics and the subgroups measured, whether the test population resembles yours, the date and the model version the results refer to, what happens to results when they update the model, whether they will commit in writing to version pinning and deprecation notice, whether your data is used for training and how to exclude it, their retention and subprocessor list, their incident notification timeline, and whether they indemnify you for intellectual property claims arising from the output. Then say the thing that matters: a certificate against an AI management system standard tells you they have a management system, not that this model behaves on your population, and a vendor who cannot distinguish those two things in conversation is a risk in itself.

"Tell me about a time you were wrong." Testing whether you are governable yourself. A strong answer involves a control you built that nobody used, a tier you set too high and had to climb down from, or an assessment that asked the wrong questions and missed something real. People who cannot answer this are usually people whose process is a document rather than a working system.

Then there are the questions you ask, which are themselves a signal, and the answers that should make you walk away.

• Ask: who chairs the committee that receives your work, and has it ever said no. How many use cases are in the current inventory and who built it. Whether you are the first person in this role. What happened the last time a launch was delayed on a governance finding. Whether internal audit has reviewed the programme.
• Ask above all: does this role have authority to stop a launch, or only to document a concern. That is the most important question in the entire process. A governance role with no stop authority and no escalation path is a documentation job with a risk title, and you want to know that before you accept rather than in month four.
• Red flags in the other direction: nobody can tell you the inventory count; the role reports three levels below the decisions it is meant to influence; the team is you alone with enterprise scope and a certification deadline; or the hiring manager describes the job entirely as implementing a purchased platform.

What it pays, where the jobs are, and how to get one with no AI title

Pay first, and honestly. There is no US Bureau of Labor Statistics occupational code for AI governance manager, so any single band you read in a blog post is somebody's survey or somebody's guess. The useful structural fact is this: the same work is paid on three different ladders depending on which function hosts it. Inside a bank's model risk organisation it pays on the risk ladder. Inside legal or compliance it pays on the compliance ladder, which in most companies sits below risk at the same level. Inside engineering or product as a responsible AI role it pays on the technology ladder, which is usually the highest of the three and the one with equity. Moving between those ladders with the same skills is the largest single lever on your compensation in this field, larger than a credential and larger than a title bump.

To get a real number rather than a guess, do this: search the exact title and its variants on job boards filtered to Colorado, California, New York, Washington and Illinois, where pay transparency laws require posted ranges, and read twenty postings at your level and sector. That gives you the live market in an afternoon, and it is more accurate than any salary report. For bracketing context, the BLS Occupational Employment and Wage Statistics series for 13-1041 Compliance Officers, 13-2054 Financial Risk Specialists, 11-3021 Computer and Information Systems Managers, 15-2051 Data Scientists and 23-1011 Lawyers covers the territory. For large technology companies, level based compensation data from sites that aggregate self reported offers is reasonable for the shape of base and equity and should be treated as indicative. In the UK and EU, posted ranges are less common; the comparable approach is to ask the recruiter for the band in the first call, which is normal and expected in this market.

What actually moves the number: sector (financial services and large technology pay most, health systems and public sector pay least, consultancies sit in between with a different work pattern), whether you have survived a regulatory examination or a certification audit, whether you can do the technical half yourself rather than depending on an engineer to interpret evidence, and whether you have built a programme from nothing. A credential moves it very little. Being the person who can both write the assessment and read the evaluation report moves it a lot, because that combination is genuinely scarce.

Where the jobs are. Search all of these titles, because the same job is posted under all of them: AI Governance Manager, AI Risk Manager, Responsible AI Manager or Lead, AI Compliance Manager, AI Assurance Manager, AI Governance Lead, Director of AI Governance, Head of AI Governance, Model Risk Manager with AI or ML in the description, AI Policy Manager, Trustworthy AI Lead, AI Ethics Manager, Senior Manager AI Risk and Controls, and Technology Risk Manager with AI scope. Then search the artefact names rather than the titles, which surfaces roles whose titles do not mention AI at all: "AI inventory", "AI impact assessment", "ISO 42001", "NIST AI RMF", and "model risk" together with "generative".

Which employers are hiring in 2026-27, by category: banks, insurers and asset managers, where the function already exists and AI is being folded into it; health systems and payers, hiring under compliance, clinical informatics or quality rather than under AI; the large accountancy and consulting firms, which have built AI governance practices and hire in volume, and which are the single best place to acquire breadth quickly at the cost of depth; AI and software vendors, hiring for the customer facing assurance variant; large multinationals with European operations, driven by the EU scheme; government bodies and their contractors; and certification bodies and auditors, who need people who can audit an AI management system. A meaningful share of openings are never posted externally because they are filled internally, which is the argument for the plan below.

A note on how to talk about the gap, because it decides the first ninety seconds of every screen. Do not apologise for not having an AI title. Say the true thing plainly: "I have run the machinery this job needs (inventory, tiering, assessment, vendor review, committee reporting) in a privacy programme for six years, and I have applied it to AI on nine real use cases including two generative deployments. Here is the tiering rule I wrote and here is what I stopped." That is a stronger position than a two year AI governance title with no artefacts behind it, and hiring managers in this field know the difference because most of them made the same move.

The plan, for the reader who has no AI title and wants one. This is twelve weeks of work inside your current job, and it is the highest return path in this field by a wide margin, whether you intend to move internally or externally. Each step produces an artefact you can describe in an interview with a number attached. Do not do this covertly: tell your manager you are going to map AI use and offer the output as something useful to them, which it will be.

• Weeks 1 and 2: build the inventory. Reconcile single sign on and OAuth grants, card and expense data for AI subscriptions, procurement records, cloud and model API billing, and a nine question survey to team leads. One row per use case with an owner, the business process, the data classes touched, the vendor and model, whether output reaches a customer or affects a decision about a person, and whether it can take actions in other systems. Count it. The count is your first resume number.
• Weeks 3 and 4: write the intake questionnaire and the tiering rule. Fifteen questions, one page. A tiering rule with explicit thresholds and a documented light path for low tier items. Test it by tiering everything already in the inventory and checking whether the rule gives the answer you would have given by judgement. Where it does not, fix the rule, not the answer.
• Weeks 5 and 6: run one assessment end to end on a live use case, preferably a generative one. Produce the artefact: purpose, population affected, data footprint, failure modes, evaluation evidence and its limits, controls with named owners, residual risk, and a recommendation. Get it reviewed by somebody who will argue with you.
• Weeks 7 and 8: assess one vendor properly. Send the questionnaire, read the answers, identify the two that are technically true and practically useless, and go back with the second question. Write up what you would and would not accept, including the contract terms you would require.
• Weeks 9 and 10: write a two page standard. Not twelve pages. Name three practices that are prohibited and say why each one is prohibited in a sentence a non specialist understands. Name the exception process and give exceptions an expiry date.
• Weeks 11 and 12: take it to a decision. A committee, a leadership meeting, a risk forum, whatever exists. Get one decision recorded against a date and write the one page report. If no forum exists, propose one and write its charter, which is itself a better artefact than most candidates have.
• Alongside the twelve weeks: take the AIGP, which costs weeks rather than months and gets you past recruiter screens, and read the primary sources instead of summaries of them. The NIST Generative AI Profile end to end, the ISO/IEC 42001 clause structure, and the actual EU AI Act articles covering high risk obligations and the provider and deployer roles. Reading the primary text is the clearest differentiator in interviews, because most candidates have only read about these documents and it becomes obvious in the second follow up question.
• If your work cannot be described externally at all: run the same process on a public AI product and publish the assessment, or publish a tiering rule and an intake template other people can use. One well argued public assessment of a real system is worth more than any number of opinion posts about AI ethics, and it is the only evidence available to a career changer with nothing to point at inside a job.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• AI Governance Manager
• AI governance
• AI Risk Manager
• AI risk management
• Responsible AI
• Responsible AI Lead
• Responsible AI Manager
• AI Compliance Manager
• AI Assurance Manager
• AI Governance Lead
• Head of AI Governance
• Director of AI Governance
• AI Policy Manager
• Trustworthy AI
• AI Ethics Manager
• Technology Risk Manager
• Model Risk Manager
• Model risk management
• Model validation
• Independent model validation
• SR 11-7
• Three lines of defence
• Second line of defence
• Internal audit
• IT audit
• GRC
• Governance risk and compliance
• Enterprise risk management
• Operational risk
• Control design
• Control testing
• Audit evidence
• Regulatory examination
• Issue management
• AI use case inventory
• AI inventory
• Model inventory
• Use case register
• AI intake process
• Risk tiering
• Risk classification
• AI impact assessment
• Algorithmic impact assessment
• Fundamental rights impact assessment
• Data protection impact assessment
• DPIA
• Model card
• System card
• Technical documentation
• AI policy
• AI standard
• AI governance framework
• AI governance committee
• AI review board
• Committee reporting
• Board reporting
• Exception management
• Third party AI risk
• Vendor risk assessment
• Vendor due diligence
• Procurement
• Contract review
• AI addendum
• Trust centre
• Enterprise security questionnaire
• NIST AI Risk Management Framework
• NIST AI RMF
• NIST AI 600-1
• Generative AI Profile
• ISO/IEC 42001
• AI management system
• AIMS
• ISO/IEC 23894
• ISO/IEC 42005
• ISO/IEC 22989
• ISO/IEC 27001
• SOC 2
• EU AI Act
• High risk AI system
• Prohibited AI practices
• General purpose AI
• GPAI
• Provider obligations
• Deployer obligations
• Conformity assessment
• CE marking
• Post-market monitoring
• Serious incident reporting
• AI literacy
• GDPR
• Article 22
• Automated decision making
• ADMT
• Data minimisation
• Lawful basis
• Records of processing
• Subject rights
• HIPAA
• Protected health information
• FCRA
• ECOA
• Regulation B
• Adverse action notice
• Fair lending
• UDAAP
• FTC Act Section 5
• Title VII
• Americans with Disabilities Act
• Uniform Guidelines on Employee Selection Procedures
• Automated employment decision tool
• AEDT
• NYC Local Law 144
• Bias audit
• Colorado AI Act
• Illinois Human Rights Act
• Texas Responsible AI Governance Act
• California AI transparency
• Training data transparency
• NAIC model bulletin
• Insurance regulation
• FDA
• Software as a medical device
• Predetermined change control plan
• Clinical AI
• Clinical informatics
• ICO
• FCA
• AI Safety Institute
• OMB memorandum
• Federal AI procurement
• IAPP
• AIGP
• Artificial Intelligence Governance Professional
• CIPP
• CIPP/E
• CIPP/US
• CIPM
• CIPT
• CISA
• CRISC
• CISM
• CISSP
• ISACA AI audit
• ISO 42001 lead implementer
• ISO 42001 lead auditor
• FRM
• Machine learning
• Large language model
• LLM
• Generative AI
• Foundation model
• Open weight model
• Fine-tuning
• Retrieval augmented generation
• RAG
• Vector database
• Embeddings
• Permission aware retrieval
• AI agents
• Agentic AI
• Tool use
• Autonomy levels
• Human in the loop
• Human oversight
• Automation bias
• Override rate
• Model evaluation
• Evaluation harness
• Golden dataset
• LLM as judge
• Red teaming
• Adversarial testing
• Jailbreak
• Prompt injection
• Indirect prompt injection
• Guardrails
• Content filtering
• Hallucination
• Factual accuracy
• Model drift
• Data drift
• Performance monitoring
• Canary prompts
• Version pinning
• Model deprecation
• Explainability
• Interpretability
• SHAP
• Feature importance
• Reason codes
• Fairness metrics
• Disparate impact
• Selection rate
• Impact ratio
• Four-fifths rule
• Subgroup analysis
• Data provenance
• Training data documentation
• C2PA
• Content credentials
• Watermarking
• Synthetic data
• Differential privacy
• Memorisation
• Data extraction
• Shadow AI
• AI acceptable use
• Security review
• Incident response
• Kill switch
• Logging and traceability
• Audit trail
• AI governance platform
• Stakeholder management
• Cross-functional influence
• Policy writing
• Training and awareness
• Programme management

Mistakes that cost people this job

Questions people ask