The AI Governance Function: What the Work Is and Who Does It

Job titles in this area are unsettled. AI governance lead, responsible AI manager, AI compliance officer, AI risk analyst, and several variations appear in postings, sometimes describing the same work and sometimes describing quite different work.

That instability makes the title a poor thing to organise around, whether you are hiring or trying to move into the field. The work is much more stable than its name.

So this lesson describes the function rather than the position: the set of tasks an organisation deploying AI has to get done, regardless of who holds them or what their business card says.

One clarification that shapes everything: unlike the data protection officer under the GDPR, the EU AI Act does not require the appointment of a designated officer. There is no statutory AI compliance officer role, no mandated independence, and no protection from dismissal attached to a named position. The obligations attach to the organisation as provider or deployer, and it decides how to discharge them.

That absence explains why the work is currently distributed rather than concentrated, and it is the most common misconception about this area.

Strip away the titles and the function decomposes into seven recurring tasks. Every organisation running AI systems does some of these, well or badly, deliberately or by accident.

Discovery and inventory: establishing what AI systems the organisation actually operates, including features inside software bought for other reasons.

Classification: determining the organisation's role for each system, provider or deployer, and its risk tier, with the reasoning recorded.

Governance operation: running the approval gate, maintaining decision rights, keeping the risk register current, and getting systems reassessed when their use changes.

Documentation and evidence: producing and maintaining what the Act requires, from technical documentation and impact assessments through to the record of judgement calls.

Vendor diligence: asking the questions that establish a supplier's regulatory position, and negotiating the terms that make your own compliance possible.

Assurance and monitoring: checking that controls actually work, that performance has not drifted, and that human oversight is real rather than nominal.

And incident handling: recognising an AI incident, escalating it within the deadlines, and turning the postmortem into a change.

These seven are the job, whatever it is called.

The obvious comparison is the data protection officer, and it is instructive in both directions.

What transfers. The GDPR created a role whose work is structurally similar: maintaining a record of processing, advising on impact assessments, monitoring compliance, acting as a contact point for the supervisory authority, and doing so with independence from the business activities being assessed. Many organisations already have this person, and the AI work overlaps their existing map substantially.

What does not transfer. The GDPR mandates appointment in defined circumstances, requires the DPO to report to the highest management level, prohibits instructions on how to perform the tasks, and protects against dismissal or penalty for performing them. The AI Act creates no equivalent. There is no mandated appointment, no statutory independence, and no protection.

The practical consequence is that AI governance work carries the awkward part of the DPO role, telling the business it cannot do something, without the structural protection that makes the DPO role tenable.

That is worth knowing before entering it. Where an organisation places this work matters more than in a mandated role, because nothing external supplies the independence. Someone doing this inside the team whose systems they assess is in a structurally weak position, and the weakness is not fixed by seniority.

In practice the work distributes across functions that already exist, and each holds the pieces closest to its existing competence.

Data protection and privacy typically takes classification support, impact assessments and the record-keeping, because the apparatus is the same one they run for the GDPR.

Legal takes the regulatory interpretation, the derogation judgements and the contract terms.

Risk and internal audit take assurance, the register and the monitoring of whether controls work.

Engineering and data science hold the inventory of what actually exists, the technical documentation and the measurement.

Procurement holds vendor diligence.

The business function owning each decision holds accountability for its system.

The seams between these are where the failures live. Nobody owns the inventory across the whole organisation, so it is incomplete. Nobody owns the trigger that reclassifies a system when its use changes, so it fires late. The coordinating work is the part that is genuinely new, and it is the part most often unassigned.

Organisations concentrate this work into a named position under fairly predictable conditions, and recognising them tells you where such roles exist.

Provider status. An organisation that builds high-risk systems faces the quality management system, technical documentation, conformity assessment and post-market monitoring. That is a standing workload rather than a project, and it justifies dedicated capacity.

Regulated sector. Banks, insurers and healthcare organisations already have compliance functions, established regulator relationships and, in financial services, model risk management practices that predate the AI Act. AI governance lands inside an existing structure and often gets a named owner quickly.

Scale of AI use. Beyond a few dozen systems the coordination cost exceeds what someone can absorb alongside another job.

Public sector. Public bodies face the fundamental rights impact assessment obligation and registration duties that private deployers largely do not.

Where none of these hold, and the organisation is a deployer of ordinary tools, the work genuinely is a part-time addition to an existing role, and building a dedicated function would be disproportionate.

So the honest picture is uneven: concentrated in providers, regulated sectors and the public sector, distributed everywhere else. Anyone looking to do this work full-time should look where the conditions above hold.

Where the function sits shapes what it can do, and each common placement has a characteristic weakness.

Inside legal or compliance. Strong on interpretation and on saying no. Weak on knowing what actually exists, because engineering does not route through them, and prone to producing documents rather than controls. The failure mode is a governance framework that is textually excellent and describes an organisation that does not exist.

Inside engineering or data science. Strong on the inventory and the measurement, which is exactly what the other placements lack. Weak on regulatory interpretation, and structurally compromised, since assessing systems your own team builds is not an independent assessment. The failure mode is confident classification decisions that a lawyer would not have made.

Inside risk or internal audit. Strong on assurance discipline and on independence, which is the scarce ingredient. Weak on technical depth, and can end up auditing whether a process was followed rather than whether a system works. The failure mode is a clean audit of a system that performs badly on a subgroup nobody measured.

The arrangement that works is not a fourth placement but a pairing: independence from one function and technical access from another, with the coordination explicitly assigned to someone rather than assumed. Which of the three you sit in matters less than whether the other two are reachable.

The gap between the job description and the actual week is worth setting out, because it is large.

A realistic distribution. A substantial share of time goes to finding things out: chasing which team owns a tool, what a vendor's system actually does, whether a feature was switched on. This is unglamorous and it is the foundation everything else rests on.

Another substantial share goes to writing: assessments, reasoning, records, and the same explanation adapted for engineers, executives and lawyers.

A smaller share goes to judgement calls, the classification decisions and derogation assessments that the role exists for. These are the highest-value hours and there are fewer of them than expected.

And a persistent share goes to persuasion, because the function usually has no authority to compel anything and works through others' decisions.

What it is not: reviewing model architectures, or interpreting statute in the abstract. Someone expecting either will find the reality closer to programme management with a regulatory specialisation than to law or machine learning.

That is not a criticism of the work. It is the shape of any function that has to know what an organisation is really doing, and it suits people who are comfortable being the one asking questions others find tedious.

AI governance rarely stands alone, and the neighbouring regimes determine both how the work is staffed and how transferable the experience is.

Data protection is the closest neighbour. Most AI systems process personal data, impact assessments overlap, and the record-keeping apparatus is shared. This is why so much AI governance lands with privacy teams.

Model risk management, in financial services, long predates the AI Act. Banks have run model inventories, validation functions and independent review for years under supervisory expectations. Where that function exists, AI governance is an extension of it rather than a new discipline, and the vocabulary already exists.

Information security supplies the assurance machinery and, through ISO/IEC 27001, the management-system pattern the Article 17 quality management system resembles.

Product safety and quality supply the conformity assessment, CE marking and notified body concepts wholesale, since the AI Act borrowed them.

Sector regulation continues to apply on top: medical devices, financial services conduct rules, employment and non-discrimination law.

The practical implication for anyone entering: you are not starting from nothing, and the fastest route in is usually through whichever of these you already know rather than through AI itself.

A question worth answering before designing a team: how much of this is there, actually?

For a deployer of ordinary tools with no Annex III systems, the standing work is small. An inventory kept current through procurement triggers, a policy, a literacy programme, transparency obligations, and periodic review. That is a fraction of one person's time, permanently.

For a deployer with one or two Annex III systems, it grows: classification with real judgement, oversight design, monitoring, vendor management, and where applicable a fundamental rights impact assessment. Part of a role, and it needs the judgement to be someone's explicit responsibility rather than an absorbed extra.

For a provider of high-risk systems, it is a function. The quality management system alone is continuing work, and technical documentation, conformity assessment and post-market monitoring are recurring rather than one-off.

Two warnings in opposite directions. Under-sizing produces a framework nobody maintains, which is worse than none because it creates a false record. Over-sizing produces a function that generates process to justify itself, exhausts the organisation's patience, and gets cut in the first cost review.

The useful sizing question is not how big should this be but which of the seven tasks currently has no owner. That is where the first hour, and the first hire, belongs.