Ownership and roles

Do not start by copying generic job titles into a responsibility chart. Start with the decisions the system requires:

• approve the intended and prohibited uses;
• accept or reject residual risk before release;
• approve access to data, tools, and users;
• define evaluation and monitoring thresholds;
• decide whether a proposed change needs reapproval;
• respond to an alert or incident;
• pause, roll back, restrict, or retire the system.

Assign one accountable owner to each decision. One person can own several decisions, and ownership may transfer across lifecycle stages, but a decision should not have three equally accountable owners. Shared accountability often becomes no accountability when priorities conflict.

The accountable owner does not need to perform all the work. They ensure that evidence is collected, relevant specialists are consulted, the decision is recorded, and unresolved risk is escalated. Their authority must match their responsibility. Calling someone the owner while denying them the ability to delay a launch is only a label.

Organizations use different titles, but the jobs are recognizable.

Business or use-case owner: defines the purpose, affected users, acceptable outcomes, and business boundaries. This owner usually accepts the operational benefit and residual risk of the use.

Model or technical owner: understands the model and system configuration, maintains technical documentation, coordinates evaluation, and explains limitations. For a vendor model, this person still owns the organization’s configuration and integration evidence.

Data owner: authorizes data use, quality expectations, retention, and access. The data owner should know what sources feed prompts, retrieval, training, evaluation, and logs.

Control operators: run recurring controls such as access reviews, quality sampling, alert response, and human escalation. A control needs a frequency, procedure, backup operator, and evidence that it ran.

Independent reviewers: challenge evidence from a position not rewarded solely for shipping. Depending on risk, this may include privacy, security, legal, compliance, accessibility, safety, or a validation team.

Executive or risk approver: handles risk above the use-case owner’s delegated authority. Escalation should be based on defined thresholds, not on who is most senior in the meeting.

Affected users and subject experts: contribute real workflow knowledge. They may expose missing requirements and harms that a technical test misses, but consultation should not make them responsible for a system they cannot control.

A RACI chart labels people as responsible, accountable, consulted, or informed. It is useful when attached to a concrete decision or control. “Legal: consulted on launch approval” is clearer than “Legal: governance stakeholder.”

For each row, ask:

1. Is exactly one role accountable?
2. Does the responsible person know the procedure?
3. Are consulted people brought in early enough to affect the decision?
4. Are informed people told what changed and what action they must take?
5. Is there a substitute when the named person is unavailable?

Avoid making the AI governance committee accountable for everything. Committees can set standards, hear escalations, and provide challenge. Day-to-day systems still need named owners. Also avoid assigning ownership to a vendor. A provider may own its model service, but your organization owns its choice to use that service in a particular workflow.

For consequential systems, independence matters. The person who built an evaluation should not be the only person deciding whether its results are sufficient. A validator can inspect test design, subgroup coverage, failure severity, and reproducibility. An approver can then weigh that evidence against the proposed use.

Complete separation is not always practical in a small team. Compensating controls can help: peer review, documented acceptance criteria set before testing, time-separated review, external expertise, or approval by someone outside the delivery goal. The principle is to create meaningful challenge, not ceremonial signatures.

Ownership is tested when evidence is incomplete or people disagree. Define where a concern goes, the time available to decide, and the safe state while waiting. If monitoring crosses a critical threshold, the service operator may have authority to pause immediately and notify the use-case owner afterward. If a lower-severity trend appears, the owner may have two business days to investigate.

Record role names in a durable registry, not only in a slide deck. Review them when people change jobs, vendors change, or the system changes scope. An abandoned system with no current owner should not remain in production.