Stakeholders and Authority

Chapter 1 stated the principle this policy rests on, and Chapter 2 drew the boundary around the systems it governs. Neither is binding until we name the people the policy applies to and the authority that makes it enforceable. This chapter converts the principle into an operating structure. It names who and what the policy protects, who it empowers and who it constrains. It also addresses how the policy fits into existing organizational control functions, who owns the policy, and what happens when the policy’s granted authority is contested.

Who This Policy Protects

The scenarios in Chapter 1 had a common theme. AI compressed several steps of a cross-function process from a single command or question, into a single action, and the work concluded without including people the organization assigns accountable for those functional domains. The harm was not just the error in each case. It was that the accountable owner never saw the work before the consequence had caused harm. When that happens, the organization loses the control that each domain owner was hired to provide.

This policy protects those owners. It does not give them new power, and it does not invent additional layers of authority. It preserves the authority the organization has already assigned, and keeps that authority attached to the work when AI execution routes around it.

A role-holder, as defined in this policy, is a person who, under the organization’s existing structure, is accountable for the outcomes of a particular function, decision, or work product. A “domain custodian” is a role-holder who owns a business domain and holds ‘review-to-veto’ authority over AI-assisted work products that affect or involve responsibility of that domain. Every domain custodian is a role-holder. The term names the role-holder at the point where their authority over their domain is engaged, whether the work in that domain was produced by a person, by an AI system, or by both.

Protecting the domain custodian’s authority is how the organization keeps control over the quality and appropriateness of its work. The custodian’s review is not a courtesy extended to the custodian. It is the mechanism by which the organization catches a problem within its structure before that problem becomes an undesirable outcome. The principle states that responsibility for AI-assisted work does not move to the tool. Preserving the custodian’s authority over their domain is how that principle stays true in daily practice rather than on paper.

Who This Policy Empowers, and Who It Constrains

From one perspective, authority looks like empowerment, and like constraint from another. The same rule that gives a domain custodian the right to review AI-assisted work in their domain obligates the operator whose work crosses into that domain to route it through the custodian. Both sides are stated directly, because a policy that describes only the empowerment reads as a grant of privilege, and a policy that describes only the constraint is viewed as an obstacle.

Three roles carry the accountability preserved by this policy. The operator uses the AI system. The domain custodian owns the affected domain. The executive sponsor sits above one or both roles and answers for the outcomes in the function. Externally, the organization as a whole remains accountable as the deploying party, and the executive sponsor is the role through which the organizational accountability falls upon.

The policy empowers domain custodians with explicit review and veto authority over AI-assisted work products that affect their domain, regardless of who produced the work or which tool produced it. This authority is the operational form of the principle’s first corollary. It does not depend on the custodian having been consulted and made aware in advance. The work entering the custodian’s domain is what engages the authority, not the path the work took to get there.

The policy also empowers operators, in a way that is easy to miss. An operator is entitled to know when a task crosses into a domain that is not theirs, so that they are not silently turned into the entire verification step for work they are not equipped to verify. Chapter 1 described employees who were, without realizing it, doing several other people’s jobs at the same time. Naming the operator’s right to hand that work to the accountable custodian is a protection for the operator, not only a duty placed on them.

The constraints follow from the same structure and are critical to the responsible usage of AI systems. An operator must route AI-assisted work that affects a domain they do not own through that domain’s custodian before the work becomes consequential, and an operator may not treat an AI system’s output as self-verifying. The scenarios in Chapter 1 reveal the potential consequences of failing to acknowledge either of these constraints.

A domain custodian may not abdicate the review the authority carries with it, because declining to look at work in one’s domain does not remove the accountability for that domain or place it elsewhere. The veto authority and the duty to exercise it are the same thing. An executive sponsor may not resolve the tension between speed and review by overriding a custodian informally. The sponsor carries the outcome in the function and is therefore constrained to the contest pathway described later in this chapter rather than an off-the-record override.

For the operator, the first step when work will invariably touch a domain that is not theirs is to raise it to that domain’s custodian.

The Policy’s Place Among Existing Controls

Chapter 1 made the case that the organization’s existing accountability frameworks are not obsolete in the age of AI. Their assumptions are inadequate however in the age of AI. They assume the work is done by the accountable role-holder or by someone under that role-holder’s direction. AI lets work happen outside that path because today’s models are not trained to respect this structure.

This policy supplements the organization’s existing risk, audit, legal, compliance, security, and privacy functions. It does not replace them, and it does not create a parallel control function alongside them. There is no separate AI accountability to be administered by a separate body. There is the accountability the organization already has, applied to work that AI now helps produce.

What the policy adds is reach. Where AI-assisted work affects a domain that an existing control function governs, the requirements of this policy bring that work within view of the function that already owns it. The organization has already invested in these functions and staffed them with people who know their domains. The policy’s contribution is to make sure AI-routed work does not slip by them, not to rebuild what they do in the shadows. The benefit to the organization is continuity.

The Policy Owner

A policy whose entire purpose is to keep accountability single-threaded cannot be owned by a committee. Shared ownership of this policy would reproduce, at the top of the organization, the exact diffusion of accountability the policy exists to prevent. If everyone owns the policy, there is no one person the organization turns to when the policy needs a decision. Therefore, we take the position that this policy has one owner, and we hold it without hedging or apology.

The Policy Owner is the single accountable executive who owns this policy as both a document and an operating practice. The Policy Owner is accountable for the currency of the policy, keeping it accurate as practice and AI technology choices change. The Policy Owner is accountable for interpreting the policy in situations where its text does not settle edge cases on its own. The Policy Owner approves exceptions to the policy. And the Policy Owner is accountable for those exceptions as well as the policy being applied across the organization, not merely published.

The Policy Owner is a person. The AI Governance Council is a body made up of representatives involved in the funding, usage, monitoring, and measurement of AI-related programs across the organization. The AI Governance Council is the enterprise body that enforces this policy and resolves matters escalated to it. Its membership, structure, and reporting lines are established in later chapters. The two are distinct on purpose. The Policy Owner may bring matters to the Council and remains accountable for the policy regardless of how the Council is composed. A body can deliberate and enforce. It cannot be the responsible party the organization needs for a policy built on single-threaded accountability.

When Authority Is Contested

When a contest arises from the operator, or when a custodian pulls live work back into review, the organization needs a clear account of what happened, who decided, and why. That account is how the organization keeps control of its own decisions and learns from them. It is also how the next operator, custodian, or sponsor facing a similar question can find out how the last one was resolved. The records exist to serve the organization that produced it.

The first pathway is operator-initiated. When an operator or the operator’s management contests a domain custodian’s veto of an AI-assisted work product, the matter escalates to the AI Governance Council. The operator owns the responsibility of this escalation, not the custodian. When operators follow the constraints of this policy, this escalation is raised when the work has not yet shipped and the custodian has said no after a review.

The second pathway is custodian-initiated. When a domain custodian identifies, after deployment, that an AI-driven change in the production environment creates concern within their domain, (e.g., unacceptable resource usage, elevated risk, policy or SLA breach, legal exposure, regulatory or contractual non-compliance) the custodian exercises veto authority after the fact and escalates the matter to the AI Governance Council. The custodian owns the responsibility of this escalation, not the operator of the initiating workflow. Regardless of whether the operator followed the constraints of this policy previously, this is the case where the work is already live and the accountable custodian is pulling it back into review. This chapter establishes that the custodian holds this authority and has this pathway. How a production change is actually halted or reversed belongs to the change management and incident response operating frameworks offered in Part II of this policy. It may also follow existing change management practices commonly found in mature organizations.

The two pathways are not mirror images, and the way each is documented has to account for the difference. An operator-initiated contest has two opposed positions and no live exposure. A custodian-initiated escalation may have a single position at the moment it is raised and a problem already running in production.

Both contested and escalated matters must be documented. We do not prescribe the form of the record, and allow the organization to build the template that fits its own systems. The documentation standard proposed below however, ensures the record accounts for the following, written so that one standard serves both pathways:

• Which pathway the matter follows and what triggered it: the contested veto, or the post-deployment concern and the category of that concern.
• The AI-assisted work product or production change at issue, and the deployment context, meaning what the AI produced or did and where it operated.
• The potential business impact, area(s) affected, if not deployed, or if post-deployment, the blast radius.
• The affected domain and its domain custodian.
• Each party’s position, recognizing that a custodian-initiated matter may carry a single position at the point of escalation and no contesting party.
• For post-deployment matters, the exposure window: when the change went live and when the concern was identified. This is the detail that tells the Council how long the condition ran before someone with authority identified it.
• The resolution and who decided it: the custodian, the Policy Owner on a point of interpretation, or the Council.
• The disposition and follow-on ownership: any halt, reversal, or remediation, and the role-holder who owns it.

The record needs an owner for as long as it is open. The initiator of the pathway owns the record through resolution. Ownership does not transfer when the matter escalates to the Council. The custodian, if not the initiator, can participate in the record being kept current, accurate, and carried to resolution. Single-threaded ownership of the record mirrors the single-threaded accountability the rest of the policy preserves, and an open matter with no owner is how things stall.

The record also needs a home. The documentation is stored in the organization’s designated system of record for policy and control documentation, not in an individual’s personal files or local storage, and it is retained under the organization’s existing records-retention schedule. Where the matter involved a change to the production environment affected by an AI system, the record is retained under the same retention requirements that apply to production-change records for the affected system. Keeping the record where the organization’s retention rules already reach means the organization can find it when it needs it and meets its own retention obligations without standing up a separate process to do so.

This chapter named the roles and the authority that make the policy enforceable, and the roles now have names the rest of the policy uses. What those roles must do in practice is the subject of the chapters ahead. Part II gives operators and custodians their verification steps and decision rights, and gives the organization its change-management and incident pathways. Part III names the domain custodians function by function. Chapter 13 stands up the AI Governance Council named here. The taxonomy that follows is the reference the rest of the policy points back to.

Role Taxonomy