The job ad said «AI Governance Manager» and the description was, paragraph for paragraph, a privacy officer posting with two sentences about artificial intelligence bolted on at the end. It is not a one-off: it is the pattern the market is using to fill the function. The assumption is that anyone coming out of privacy or compliance already has half the job done in AI governance. That is half true and half a trap, and the difference only shows from inside a system that has been running in production for months.
The thesis in one line: the three functions people confuse daily — privacy officer, compliance officer, AI governance owner — are not delimited by the org chart. They are delimited by the object each one supervises. Personal data, the regulatory frame, the system lifecycle. Mixing them up is not a problem about titles on a card: it is the reason that, when an agent gets something wrong, a meeting burns forty minutes without anyone able to name who answers for it.
DPO vs AI Governance Manager: the difference is the object, not the org chart
The three functions answer different questions because they watch different things. The privacy officer watches a processing activity: that there is a lawful basis, that the data is the minimum needed, that the person knows it exists. The compliance officer watches a frame: that the company sits inside the rules that bind it, sectoral, corporate or employment. The AI governance owner watches a system over time: what data it was built on, what it decides, how much it drifts, who approves it and who switches it off. Three objects, three different clocks.
| Function | Object it supervises | Reference frame | Question it answers |
|---|---|---|---|
| Privacy officer / DPO | Processing of personal data | State privacy laws; GDPR arts. 37-39 if you have EU exposure | Is this processing lawful and proportionate? |
| Compliance officer | The regulatory frame that binds the company | Sectoral, corporate, employment | Are we inside the rules that apply to us? |
| AI governance owner | The AI system lifecycle | NIST AI RMF (GOVERN); EU AI Act arts. 10 and 26 in the EU | Can this system ship, and who answers if it fails? |
In a sixty-person company all three can be the same person, and that is fine: the function does not require a headcount. What does break is assuming that covering one object covers the other two. A processing activity that is spotless from a privacy standpoint can sit on top of a system that has been wrong about one case in twelve for four months with nobody measuring it, because that error is not a personal-data problem: it is a lifecycle problem.
What a privacy officer actually supervises, and where the perimeter ends
Where a DPO exists as a formal role, its mandate is written down. Article 39 of the GDPR lists five tasks: inform and advise, monitor compliance with data protection rules, advise on the impact assessment and monitor its performance, cooperate with the supervisory authority and act as its contact point. All five hang off the same object, the processing of personal data. That is the legal delimitation, not our reading of it: see Article 39 GDPR, tasks of the data protection officer. Scope: European Union, and any US company with EU operations.
Now put two real failures next to it. An agent that classifies inbound tickets and misroutes one in twelve, so the customer waits two days longer than they should. An agent quoting from a price table that fell behind at the last revision. Neither one puts personal data at risk, and both cost money and trust. The privacy officer has nothing to supervise there, and that is not a failure on their part: the failure falls outside their object. What does fall inside the AI governance object, from day one, is the reach that agent has into your systems: the detail is in what permissions to give an AI agent.
Why coming from compliance is half the job and not the whole job
There is no US federal article that tells you who signs. What there is, and what most US enterprises actually run on, is the NIST AI Risk Management Framework, whose GOVERN function exists precisely to set accountability: its own wording asks that «accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained» for managing AI risk. Source: NIST AI 100-1, AI Risk Management Framework 1.0. Empowered, responsible, trained. Three legs, not one — and the framework is voluntary, which means nobody will fail you for skipping it. That is exactly why it gets skipped.
Here is the trap in the shortcut. Someone coming from compliance brings the third leg nearly whole — authority, and the habit of writing it down, which is not nothing — and brings a lot of the second when the risk is regulatory. What they do not bring by default is competence over the system: knowing what an output means, under what conditions it degrades, what a plausible wrong answer looks like, what a false positive costs against a false negative in that specific process. That is not read, it is acquired by operating. So «half the job done» is accurate. The problem starts when the hire is made as if it were the whole job, and the gap shows up on the day of the first incident.
Where the obligation actually starts if you operate in the EU
If you sell into Europe or run a European entity, the voluntary frame stops being the only one. The conversation there usually starts at Article 10 of the EU AI Act, which covers data and data governance: training, validation and testing datasets, their quality criteria, bias examination and provenance traceability. It is a decisive article, but it mostly speaks to whoever builds the system. And most companies do not build: they deploy. They buy, configure, connect it to their data and put it to work. For them the article that bites is 26, the one on deployers, and that order — first where you sit, then what binds you — is what orders everything else. The long version, with the full frame, is in the guide to governance and control of AI automation.
Three paragraphs of that same Article 26 draw the function better than any job description. Paragraph 2 requires deployers to «assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support». Paragraph 5 requires monitoring operation, informing the provider and the market surveillance authority where there is risk and suspending use of the system, plus reporting serious incidents immediately. Paragraph 6 requires keeping automatically generated logs for at least six months. Source: Article 26, Regulation (EU) 2024/1689, consolidated text. And paragraph 9 points back to the impact assessment under Article 35 GDPR — that last one is the seam, the one document privacy and AI governance co-sign instead of signing separately.
The Omnibus delay does not hand you two free years
The high-risk calendar moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal of the European Union, pushes obligations for stand-alone high-risk systems to 2 December 2027 and those embedded in already-regulated products to August 2028; the implementation timeline tracked by the Future of Privacy Forum breaks it down block by block. What stayed standing in August 2026 we already covered in the AI Act got delayed, but your chatbot still has to disclose and we are not repeating it here. Scope: European Union.
The operational point is a different one, and almost nobody draws it out of the delay: the date that moved is the date of non-compliance, not the date of the problem. And one detail makes it urgent anyway. If the rule is going to ask you for at least six months of logs, a system that starts logging the week the obligation lands arrives with an empty file, which in practice is the same as arriving with no logs. The evidence clock starts before the compliance clock, and that is the only argument you need for not waiting until 2027.
The two questions that delimit the function better than any job description
Job descriptions for this function all look alike because they are written from the rulebook. If you want to know whether you actually have it covered, do not read the document: ask two questions about one concrete system, the one moving the most money, and listen for how long the answer takes.
- Who signs off on the deployment? Not who approved it in a committee, but who put their name on the decision that this system would ship with that reach and those permissions. If the answer is a governing body, nobody signs. If the answer is «the vendor certifies it», also nobody: the vendor answers for the product, the deployer answers for the use.
- Who answers when it fails? And inside that, the one question that really separates oversight from theatre: who can switch it off without asking permission? Accountability without the power to stop is a decorative signature. If unplugging the agent means waiting for Thursday's committee, the system is not supervised: it is accompanied.
The two questions have a useful property: they are answered with a name or they are not answered. A governance framework can be spotless in PDF and fail both. If you want to see the jump from the written policy to the policy that executes, we worked it through in your AI usage policy is in a PDF and your agent cannot read it.
When you do NOT need an AI Governance Manager
With one system in production, one process and one owner who knows it by heart, naming an AI governance owner is premature, and what you buy with that appointment is not a control: it is a committee. Heavy governance ahead of time has a concrete, measurable cost, and it is the weeks the first use case spends not shipping while the framework that will regulate it gets drafted. The full profile of the function, with its seniority ladder and what the market is asking for, is on the AI Governance Lead page.
The threshold is not a headcount figure, it is a symptom: the day nobody can list from memory every agent running in the company, the function is already needed, named or not. And the census comes before the function, because a policy does not apply to a fleet nobody has counted: we argued that in the AI agent inventory your company does not have.
What I would do on Monday
- List the AI systems that are running and, next to each one, a name. Not the team: the person. The empty boxes are your diagnosis, and there are usually more of them than you expect.
- For the two moving the most money, answer both questions in writing. One sentence each. If it does not fit in one sentence, it is not answered yet.
- On one page, separate the privacy object from the AI governance object for those two systems, and mark where they cross: the impact assessment. That is the one document both sign.
- Start the log clock today, even if the obligation is a 2027 one and even if you are only exposed to a voluntary framework. Six months of history cannot be backdated, and it is the only item on this list that depends on the calendar rather than on you.
AI governance does not get solved by hiring a title. It gets solved by deciding who signs and who switches it off, and leaving a trace of both. If you want to stand that function up without spending six months writing the framework before controlling anything, that is exactly what we ship in governing your company's AI agents: the trace, the permissions and the chain of accountability first, and the document after, which is the order that actually works.