Roles and Accountability

Accountability Before Committees

Organizations often begin AI governance by creating a committee. A committee can be useful, but a meeting structure is not the same as accountability. Someone still needs authority to make decisions, responsibility to carry them out, and an obligation to preserve enough information for those decisions to be reviewed.

A useful governance model starts with the decision, not the org chart. If a proposed AI use involves personal information, a high-impact decision, a new vendor, or a material change to an existing system, the organization should know who owns the decision and which functions must participate before the decision is made.

Who Owns What

The exact model will vary by organization, but the same categories of responsibility tend to appear:

• Leadership establishes risk appetite and governance expectations.
• Business or system owners remain accountable for the use case.
• Technical teams design, integrate, test, and monitor the system.
• Specialist functions provide privacy, security, legal, compliance, accessibility, ethics, or risk review where relevant.

The important point is not that every organization needs the same committee or title. It is that responsibilities should be explicit enough to prevent important work from falling between teams.

Decision Rights Matter More Than Job Titles

A governance chart may show who participates, but decision rights explain what each participant can actually do. Can the privacy team require a change before launch? Can security stop deployment after a failed test? Can a product owner accept residual risk? Who approves use of a new model or vendor? Who decides whether a material change requires a new assessment?

These questions matter because governance is ultimately a system of decisions. A role with no defined authority can become advisory in practice even when the policy language sounds strong. Conversely, a role with broad authority but no documented process can create inconsistent decisions that are difficult to audit later.

A practical model should identify four things for important decisions:

• who proposes;
• who reviews;
• who approves; and
• who records the decision.

One person may fill more than one role. Separation should become stronger when risk or required independence increases.

Escalation and Exceptions Are Part of Governance

Good governance does not assume every review ends in approval. Some uses should be changed, delayed, escalated, or rejected. Others may proceed with a documented exception or temporary risk acceptance.

An escalation path is especially important when teams disagree about the significance of a risk or the adequacy of a safeguard. Without one, disagreements are often resolved informally by whoever controls the delivery schedule. That may be fast, but it is difficult to defend later if no one can show how the risk decision was made.

A useful exception record should identify:

• the requirement or control affected;
• the reason for the exception;
• the risk created and any compensating safeguards;
• the approving authority; and
• an expiration or review point where appropriate.

This structure turns an exception into a governance record rather than a permanent workaround.

Accountability Should Leave Evidence

Accountability becomes auditable when ownership and decisions leave reliable records. Useful evidence may include governance charters, role assignments, system inventories, approval records, risk decisions, meeting minutes, exceptions, remediation ownership, and change history.

The goal is not to document every conversation. It is to preserve the decisions that matter, the people who owned them, the information considered, and the actions that followed.

Part 3 moves from ownership to the next practical question: once a risk has been identified, how does it become a control, and what evidence should show that the control actually exists?