Most AI governance failures are accountability failures. The evaluation existed but nobody was assigned to re-run it after the model migration; the anomaly alert fired into a channel nobody owned; the API key belonged to an employee who left. The fix is boring and effective: for every AI use case, name three roles — Owner, Reviewer, and Operator — define what each is accountable for, and record the names in your AI registry. This is recommended practice, and the labels matter less than the completeness: every duty listed below should belong to exactly one role.
The Owner: accountable for the use case
The Owner is a named individual — typically a business or product leader, not necessarily technical — who is accountable for the use case existing and behaving. The Owner answers for: why the use case is justified against its risks; its risk-tier classification and scope (and any change to either); acceptance decisions at launch and after material changes; budget and spend; responses to escalations and anomalies; and the eventual decision to sunset. When something goes wrong, the Owner is who leadership calls. One person can own several small use cases; a high-stakes use case should occupy most of someone's attention. Ownership must transfer explicitly when people move — an orphaned use case is a finding waiting to be written.
The Reviewer: independent judgment on outputs and changes
The Reviewer provides the check the Owner cannot provide for themselves: independent assessment of whether the system's outputs and changes meet the bar. Concretely: running or approving pre-launch validation and post-change re-validation; owning the human-review sampling of production outputs; grading escalated outputs; and signing off — or refusing to — with their name on the record. The essential property is independence: the Reviewer should not report to the Owner for this duty and must be able to say "not good enough" without career consequence. In regulated industries this role often maps to an existing second-line function (risk, compliance, model risk management); elsewhere it can be a peer team, provided the independence is real.
The Operator: runs the system day to day
The Operator is the engineering role that keeps the system healthy and is first on call: deployments and configuration, credential hygiene and rotation, monitoring dashboards and anomaly triage, incident response execution, and applying changes — model migrations, prompt updates — that the Owner approves and the Reviewer validates. Operators hold the technical access; they should not be the ones deciding whether risk is acceptable, just as Owners should not be quietly pushing prompt changes to production. Separating "decides" from "executes" is precisely the segregation-of-duties property auditors test for.
Mapping roles onto platform permissions
Role definitions on paper are claims; permissions are evidence. The platforms let you make the two match. On the Claude API, organizations have distinct membership roles — user, claude_code_user, developer, billing, and admin — and workspaces add their own role set (Workspace User, Workspace Developer, Workspace Admin, and so on), with API keys scoped to a single workspace. A sensible mapping: Operators get developer-level access in their use case's workspace; Owners get visibility without deploy rights; only a small platform team holds the org admin role — which matters because only admins can provision Admin API keys, the credentials that manage members, keys, and workspaces. Reviewers often need no production access at all, only access to outputs and records. On Bedrock, Vertex AI, and Foundry, do the same with IAM roles, service accounts, and RBAC respectively (see least-privilege IAM).
One platform detail worth knowing when planning departures: on the Claude API, API keys are scoped to the organization and workspace rather than to individuals, and they persist when a user is removed. That is operationally convenient — an Operator leaving does not break production — but it means offboarding checklists must explicitly reassign key custodianship, because nothing will force the question.
Keep it proportional
For a low-risk internal tool, three names in a registry row and matching permissions may be the entire implementation — an afternoon's work. Reserve formal charters, sign-off workflows, and standing review meetings for use cases whose risk tier earns them. The discipline that must never be diluted is singularity: one accountable name per duty.
Where to go next
Roles plug into the wider structure in the AI steering committee and program foundations; the review duties are detailed in designing human oversight.