AI governance manager: writing the rule, not just checking it
Compliance takes a rule somebody else wrote and checks a system against it. That works when the rule exists. In this field, for a large share of the questions an organisation actually faces, nobody has written one: no statute says whether your support team may use a model to draft replies to customers, on what data, reviewed by whom. So the governance role has to decide the organisation's own position and then live with it, which is a policy job with a technical dependency rather than an audit job. That distinction has a practical edge. Someone who cannot tell the difference between restricting a credential and instructing a system not to do something will write rules that sound firm and constrain nothing, and the engineers will know within a week that the rules are theatre.
AI governance manager, in short
Emerging role| In one sentence | Owns the rules: what may be built, on what data, with what approval, and how it is evidenced afterwards. |
|---|---|
| Judged on | Whether the organisation can answer, on demand, what its systems do and on what basis. |
| Fails when | Governance becomes a gate rather than a service, and teams route around it. |
| Most confused with | Compliance, which checks against an external rule; governance also has to decide the internal one. |
Real work, but the scope differs enough between employers that the title alone tells you little. No compensation figures: see methodology.
The four artefacts, and why they are short
An inventory. What is running, where, doing what. Most organisations cannot produce this, and the exercise of building it typically surfaces several systems nobody in the centre knew about, which is itself the finding.
A classification. Each system placed by consequence: what happens if it is wrong, and to whom. This is the input to every other decision, and it maps onto the risk-based regimes that now bind in Europe and South Korea without having to adopt anyone else's categories.
A named owner per system. A person, not a team. Systems without one decay, because monitoring is nobody's Tuesday.
A statement of what is not permitted. Short, specific and enforceable. Three clear prohibitions that everyone knows are worth more than a twelve-page policy nobody has read, and this is the artefact governance functions most reliably get wrong by making it long.
Why the gate model fails
A governance function that exists to approve things, and that is slow, produces a predictable response: people stop asking. Work continues, systems ship, and none of it reaches the function whose job is to know about it.
That state is worse than having no governance at all, because the organisation believes it has coverage. The inventory is confidently incomplete, the classification covers the compliant minority, and the first anyone hears about the rest is an incident.
The functions that work invert the offer. They make the compliant path the fast path: a default architecture that is pre-approved, a short form for the ordinary case, and a real conversation reserved for the genuinely unusual. Teams take the fast path because it is faster, which is the only enforcement mechanism that scales.
Deciding the position when nobody has decided for you
The questions that arrive have no external answer. May a team use a system that was trained on data of uncertain provenance. May customer conversations be used to improve a system. Is it acceptable for a system to draft something a customer will read without a human checking.
These are value judgements about what the organisation is willing to do, and the honest approach is to take them as such rather than to hunt for a regulation that settles them. The useful discipline is to write the reasoning down alongside the decision, because the decision will be revisited and the reasoning is what makes the revision informed rather than a reversal.
Where a regime does bind, the work is different and easier: read what the relevant jurisdiction requires and map the inventory onto it. That is closer to conventional compliance, and it is the smaller half of the job for most organisations.
Governance for agents is a different conversation
Everything above assumes a system that produces output a person reads. Once a system takes actions, the governance question changes shape: it is no longer only what may be built but what the thing is permitted to do, which of those actions cannot be undone, and who signed off on that boundary.
Singapore's framework was extended to cover agentic systems from January 2026, which is a useful signal about where expectations are heading generally. The practical preparation is to require, for any system that can act, a written record of its permissions and an explicit decision about irreversible actions. That record cannot be reconstructed afterwards with any credibility, because the honest answer to who authorised this is either a name and a date or nothing at all.
Where the role comes from and where it leads
People arrive from risk, from legal, from data protection and occasionally from engineering. The engineers are rarer and are noticeably better at the part that matters, because they know which controls are real.
The path out leads toward broader risk leadership, or back toward the technical side with an unusual specialisation. The people who do this well tend to end up with more influence than the job description implies, because they are the only ones holding the picture of everything the organisation is running.
