The Roles Behind This, and Who Owns What
A fair objection here is that this just re-labels data governance roles for AI. It mostly does, on purpose. I use six roles for this, borrowed almost directly from data governance, because the underlying problem is the same: business judgment calls dressed up as technical decisions. Only one of them sits inside IT; everything involving what an AI system is allowed to do, who it affects, and why it matters is a decision I treat as belonging to the business.
Head of AI / Chief AI Officer — Business
I look to this role to set the AI strategy, the funding, and the enterprise-wide risk appetite. It decides which categories of use case the organisation pursues, and which it explicitly doesn’t, before any individual project can quietly decide that for itself.
AI Governance Lead — Business
This is the role that designs and operates the governance machinery itself: the approval process, the risk tiers, the documentation standards. I usually place it alongside, or inside, the existing data governance office, since most of the underlying machinery already exists there.
Use Case Owner — Business
Accountable for a specific AI use case in production. I need this person to set the acceptance criteria for what “good enough” looks like, approve the use case before launch, and answer for the outcome if it goes wrong. It’s a domain leader, not a data scientist, for the same reason a Data Owner isn’t a database administrator.
Responsible AI Steward — Business
Monitors model behaviour day to day: fairness, drift, unexpected outputs. I lean on this role to coordinate the response when something looks off, and to promote standards for how a use case gets documented and reviewed. It’s the AI-specific evolution of a Data Steward, embedded close to the use case rather than sitting in a central function.
ML Engineer / AI Platform — IT
The one role I place in IT. It builds, deploys, and maintains the models and the infrastructure they run on: uptime, latency, access controls. Like a Data Custodian, it builds and secures the environment; it doesn’t decide what the model should be allowed to do.
Model Risk & Compliance — Business (Risk function)
Assesses AI-specific risk: bias, regulatory exposure, safety, alignment with policy. I keep this in the business, typically in risk or legal, not in IT, because the judgment being made is about acceptable risk, not technical feasibility.
The seventh role sits outside the tiering on purpose: the AI User, whoever acts on a model’s output day to day. They’re often the first person to notice when something is wrong, so I make sure their feedback has somewhere to go rather than treating them as a passive audience.
At a glance: who comes from where
| Role | Organisational home |
| Head of AI / Chief AI Officer | Business (executive leadership) |
| AI Governance Lead | Business (governance office) |
| Use Case Owner | Business (domain leadership) |
| Responsible AI Steward | Business (embedded in domain) |
| ML Engineer / AI Platform | IT |
| Model Risk & Compliance | Business (risk function) |
| AI User | Business (any department) |
The pattern is the same one I see in every governance structure worth having: only the platform-building role sits in IT. Everything involving what the model is allowed to do, who it’s allowed to affect, and why it matters is a business and risk decision. IT builds and secures the environment that makes those decisions executable; it doesn’t make them.
A quick example
Say a retail company wants to launch a customer-facing support chatbot. The Head of AI has already decided customer-facing chatbots are a category the company will pursue, within limits. The Use Case Owner, the Head of Customer Support, sets what “good enough” looks like and signs off before launch. The AI Governance Lead runs it through intake and tiers it Medium risk, since it touches customers directly but doesn’t make financial or safety decisions. Model Risk & Compliance checks it for bias in tone and accuracy across customer segments. ML Engineer/Platform builds and deploys it, keeping it online and within its access boundaries. The Responsible AI Steward watches for drift once it’s live, and when a support agent, an AI User, flags a run of confusing answers, that feedback goes straight back to the Steward and the Owner rather than getting lost in a support ticket queue.
The RACI matrix I actually use
The Use Case Owner carries the most Accountable tags here, same as the Data Owner did in the data governance version of this matrix. The ML Engineer / Platform role never carries one, anywhere in the table. That’s the structural signal I look for: IT builds and operates, but final ownership of the outcome always sits with a business-side role.
Leave a Reply