Aug 19 / James Kavanagh

The gap between job ads and the real work being done in AI Governance roles

What employers are writing in AI governance job ads, and the eight objectives the job really comes down to.
I read a lot of AI governance job descriptions and talk every day to practitioners doing the work. Some have just started, others have been doing technology governance work for years. I love understanding what they find themselves doing and working to achieve day-to- day, and it's one of the reasons I often leave my calendar open for anyone to reach out and talk. Every so often I reach out myself to the recruiters and hiring managers writing those job descriptions. It's not that I'm looking for a job, but we exist at AI Career Pro to prepare people to do this work and to help them do it well. So I want to know how organizations are imagining the role, what they're seeking and at times where their picture and the real job drift apart.
Now most of the people I work with in our online training, our cohorts and coaching are mid-career, often moving into AI governance from law, security, data protection, audit, engineering, management or wherever they built the first stretch of a career. They're not just chasing another certificate to pin on the wall, or a self-congratulatory post on LinkedIn. They're making a real bet on a new direction, often a brave one. So I feel a real responsibility to make sure the practices I teach and tools we build support the work as it really is, not some made-up version from a textbook or the muddled and at times wildly speculative versions that appear in job ads. And the ads, they have some truly odd expectations. Here's a few gems I uncovered:
"We are looking for a seasoned and inspired leader in the AI space, who is ready to embrace the challenge and make a meaningful impact with us!" - a software firm for an entry-level governance role
"Expertise in Computer Science or Information Technology with a focus on: AI/ML systems, Law with specialization in Technology Law or Digital Rights, Ethics or Philosophy with focus on Technology Ethics, Public Policy with concentration in Technology Policy. Preferred Certifications Include: CIPP, CAIEP, PMP, AIGP" - a bank
"10+ years of combined experience in risk, compliance, audit, model risk management, with at least 3 years of hands-on depth governing generative and agentic AI (LLM eval, red-teaming, guardrails). Critical skills include current banking-supervisory command, and recent Big Four or boutique advisory work" - a consulting firm
A few things show up again and again. The first is a demand for experience that can't possibly exist yet. One boutique consultancy wanted ten years across risk and compliance, at least three of them in AI-specific governance, including 3 years of technical hands-on work governing agentic AI, with red-teaming and guardrails implementation experience. That's for a class of systems that was barely running in a lab three years ago. A US bank asked for eight years and more of experience, then gave a preferred list of skills that ran from decades-old model-risk rules straight through to prompt injection testing and vector database risks, as if one person could plausibly have lived in all of it. The discipline is new, but the years being asked for don't match.
Then there's the credential and qualification list. A run of certifications, privacy, audit, project management, actuarial finance, each with an "advantage" or "highly regarded" beside it and no hint of why any one of them would make you better at the actual work. Throw in the aspirational hope for mastery in AI technology itself - engineering or computer science. One posting I read asked for expertise in computer science, and law, and ethics, and public policy, in the same human being. That isn't a role. It's four specialist disciplines and nobody writing the job description has decided what they really need.
And then, most of all, the lists of activities. Not a description of what the role is for, but a long inventory of what the person will do. One federal contractor's entire role was a single run-on paragraph of maybe twenty verbs, implement, manage, develop, enforce, establish, create, maintain, coordinate, with nothing anywhere pointing to what all those tasks were supposed to produce. Another bank listed a dozen activities and then hilariously added " plus perform other duties as assigned." And somewhere in the midst of these sits the line "comfortable operating in ambiguity." Bit of a giveaway that the writer isn't sure what the job is either, so they're hoping you'll work it out once you arrive.
Strip away the branding and the buzzwords and so many of them come down to the same thing though. A pile of activities: Write the AI policy, stand up a committee, keep a register, brief the board, audit for compliance, do risk assessments. A pile of things to do.
So unfortunately, here's what I think tends to happen, and I've seen it more than once. Apart from the waste where a lot of people qualify themselves out, or HR filters them out, eventually someone does get the job. They get handed that pile and, reasonably enough, they treat the pile of tasks as the job. They work through the list, keep it moving, stay busy. And a year later there's a policy, a committee, a register, a gap analysis, a report. 
But not a lot of governing really going on.
I suspect if you've worked in any form of governance before, you know the shape of the gap I mean. A committee can meet every month for a year and never change a single decision. I've seen risk registers that were spotless and completely out of date at the same time, which honestly takes a kind of effort. Policies get written, praised, filed, and then ignored by everyone they apply to. In every one of those the activity happened and the outcome didn't, and from the outside you can't tell them apart, because the activity is the part people can see. And people mistake the task for the outcome. They're not at all the same thing.
The activities are just something you do. What matters is whether any of these add up to the outcomes the organization needs. And that's a much much harder thing to point at or write in a job ad.

The map of objectives underneath the tasks

So when people ask me what the job of being an AI Governance practitioner really looks like, underneath all the tasks, and stripped of the language in job ads, I've landed on a fairly stubborn answer. Whatever the org chart says, I've found the work comes down to a handful of objectives that the governance function exists to produce and then to keep on producing. I make it eight. Here they are quickly:
1. A function with real authority. Governance only shapes decisions if it has the standing to. Mandate, resources, decision rights that people actually recognize, a route up to executive or board oversight, and a seat where the decisions about buying, building and using AI genuinely get made. The bit that can be hard is that none of this shows up just because your title says it should. You build it through the organization's own structures, and depending on where you've landed, a lot of the early months is just honestly just establishing standing and authority that isn't there yet.
2. Making the whole estate visible. You can't govern what you can't see. So you need a good-enough, current-enough picture of the AI in your scope, and that has to include the AI buried inside things you bought without ever thinking of them as AI, the pilots that quietly slid into production, and the stuff nobody told you about. Being straight about where the gaps are is part of the outcome, not a weakness in it. You'll never get it perfect, and the estate never sits still, but this has to be something that keeps running in an automated way, not a survey you did once and put in a folder.
3. Defining what good looks like. Once you can see the estate you need something to hold it up against. This is where the organization's values, its obligations, it's commitments, its appetite for risk, its context, and what the teams on the receiving end actually need, all get turned into something a normal person can use: principles, requirements, controls, policy that people can and want to follow. The documents on their own don't do it. If the criteria don't make it into the lifecycle and the day job, they just sit there looking pretty.
4. Risk visible and reducing. Now you can put the inventory you have against those criteria and ask where harm could actually come from. The whole cycle has to turn: find the risk, assess it, do something about it, watch it. Where it sits above what the organization has agreed it can live with, it comes down, or it gets handled some other way. And whatever's left over gets owned, deliberately, by a named person with the authority to accept it, and stays under review. 
5. Obligations understood and met, in a provable way. Laws, regulations and contracts hand you obligations. So do the standards you sign up to and the promises your organization makes in public, especially the moment it claims to conform to them. If you take each source on its own terms, you'll find yourself building overlapping controls multiple times, gathering the same evidence over and over again for what is really one requirement from different perspectives. This is the part I know best, from years running regulatory engagement where we had to translate the world's laws and standards to engineering requirements and evidence. And it's where I've watched people burn whole quarters in unproductive cycles. The outcome you want is to work out what genuinely applies, map the overlaps onto shared controls, hold on to the differences that actually matter, and keep evidence that shows how each one is met.
6. Building governance into the lifecycle. Stick governance on at the end and it's expensive, resented, and usually too late to change anything worth changing. Design it in instead: into how AI gets developed, bought, configured, shipped, changed and eventually retired, with the right checks at the right points and no heavier than the risk deserves, including before anything goes live. What you're really trying to do is make the governed path the easy one, so people don't have to be heroes to do the right thing and don't get rewarded for routing around you.
7. Deployed AI stays governed. A system that was fine at launch drifts, and even when it doesn't, the world around it moves. The data shifts, the usage shifts, the vendor changes something, the threat picture changes, a new rule lands. You need a loop that catches the signals that matter, works out what they mean, gets them in front of someone who can decide, and closes with a record of what was done. This one sounds obvious and is genuinely hard, because closing a loop is nowhere near as satisfying as opening one, and it's the outcome that quietly goes dark first when everyone's busy.
8. Independent verification. Your own confidence that all of this is working is worth having, but it isn't independent, and everyone in the room knows it. At some point someone suitably independent and competent has to test specific claims against clear criteria and real evidence and come back with a conclusion. And that conclusion only ever covers what they actually looked at, which is worth holding on to both when you're paying for assurance and when someone waves a certificate at you.

These objectives aren't a checklist

These all work together. Without authority, everything the other seven produce has nowhere to land. The inventory isn't just its own outcome, it's the raw material the risk work and the obligations work run on, and it's what an assessor will sample when they show up. The definition of good you land, comes back as the criteria for your lifecycle gates and for anyone verifying your claims. Verification sits near the end because it needs something to verify. 
The thing is that you could easily read those 8 and decide the role needs a risk specialist, an auditor, a lawyer, a safety engineer and a policy writer welded into one person. It seems like a whole lot of job specs are written as if that person exists. They just don't - or at least there are very few who do - and chasing that version of yourself is probably the wrong goal anyway.
The real work across all eight is joining them up. The generalist governance lead is the person who can commission a risk assessment and read it well, push back on a treatment that's mostly hope, make sure a real risk owner signs for what's left, brief an assurance provider and then read their opinion for what it does and doesn't cover. Thats just a completely different skill from doing any one of those pieces yourself, and it's the one the role turns on.
The worst and unfortunately the most common failure I see in this field is when the people building AI and the people governing it stop talking to each other, something I've written about before. You're the one who keeps that conversation going, across all eight of these objectives. You need to know the desired outcome well enough to run the work, pull in the right people, ask a specialist a question sharp enough to matter, and tell a real answer from a plausible one. You don't need to be the specialist, though in time, you may build your own specialist craft. Knowing where your own depth stops and whose depth to reach for isn't a gap in the role. It's honestly a big part of the job.
Now, there's one more thing sitting under this whole lot of eight objectives, and if you take anything from this, I hope you'll take this. Under every one of the eight is some variant of the same question: does this governance keep working as the system and the world change? "We can see the estate" only counts if the inventory keeps seeing it next quarter. "Deployed AI stays governed" only counts if the loop still closes when everyone's distracted. A mechanism that was well built on the day it shipped can quietly stop doing its job, not because anyone broke it, but because what it governs moved and the mechanism didn't. That's why writing a policy isn't the work, writing a policy that people follow and that adapts to change - that is.
That's the more advanced discipline of what we do, and it's a big part of what I mean by the adaptive leap: the move from being able to do to work of governance to being able to design governance that sustains while everything around it shifts.

So I see eight objectives - what about you?

You can take the eight I put forward here and maybe use them as a rough diagnostic on your own organization some quiet afternoon. Go through them one at a time and ask, is this one working, half working, or not really happening, and what evidence would back up your answer. It's not a maturity model and there's no scoring system. But perhaps it helps to drags the conversation off "do we have a policy?" and onto "is the thing that policy was supposed to produce actually happening?"
And maybe, just maybe, it might help recruiters and hiring managers write job descriptions that bring people with the right know-how, skills and experience to do the real work of AI governance in their organization. It's worth hoping for.
Thanks for reading. As always, any and all feedback welcome.
This is how we think about the work of AI governance at AI Career Pro. Way beyond gaining credentials, our focus is on training to prepare people to do the real work and building the tools they need. We can help you grow from knowing to doing to mastery in your craft. If you'd like to learn more, check out AI Career Pro, and in particular, our AI Governance Cohort. We have just a few spots left for a cohort starting on 25th August.