Who Can Approve, Pause, or Override an AI System? A Decision-Making Matrix for AI Governance Committees
Turn AI oversight into accountable action with a decision-rights matrix for approvals, residual risk, escalation, and shutdown authority in the AI Governance Committee.
Lewis Ho
A regional sales team wants to activate an AI agent that can read customer records, generate pricing proposals and send follow-up emails. The vendor contract is nearly final. Legal has concerns about retention; Security objects to the proposed permissions; the business says delay will cost revenue. The AI Governance Committee has reviewed the tool. However, who is supposed to make the final decision?
Our previous article addressed the first question enterprises tend to ask when forming an AI Governance Committee: who should be in the room? Legal, Risk, Privacy, Cybersecurity, Technology, Procurement, Data, Internal Audit, and the business each see a different part of the problem. The next question is more consequential: who decides when those functions disagree?
This is where many otherwise serious AI governance programs begin to fail. They assume that assembling the right people, publishing a policy, and creating a committee with a sensible remit will produce control. Yet a committee can meet regularly, review impressive slide decks, and still leave the organization unable to answer a basic question after an incident: Who authorized this system to access that data, make that recommendation, or take that action?
The gap is counterintuitive because legal and governance professionals are accustomed to treating documentation as evidence of control. A policy demonstrates expectations. A vendor contract allocates obligations. A risk assessment records concerns. Meeting minutes show that people discussed them.
Technical reality is less forgiving. An AI system may be altered by a model update, a new connector, an expanded retrieval database, a revised vendor feature, or a line of code that changes a human-reviewed drafting tool into an agent that can act. None of those events is necessarily captured by the original approval. A sophisticated terms of reference document cannot, by itself, determine whether a business team may enable a new customer-data integration on Friday afternoon.
That is why AI Governance Committees need decision rights, not merely membership lists and operating principles.
A committee’s purpose is not to become a slow-moving tribunal for every employee’s use of a productivity tool. Nor should it duplicate the work of Security, Legal, Procurement, Privacy, or model-risk teams. Its purpose is narrower and more practical: to establish who may approve material AI risks, who may accept the residual risk when safeguards are incomplete, who may require escalation, and who can stop a system once it is live.
The distinction matters. A RACI chart is useful, but it is not enough. It identifies who is Responsible, Accountable, Consulted, and Informed. It does not necessarily establish whether the CISO can suspend an unsafe AI agent, whether a business executive can override a Privacy objection, or whether a committee has authority to reject a vendor exception that Procurement is prepared to accept.
A RACI describes participation. A decision-rights matrix defines authority.
The point at which conventional controls break down
Consider a common scenario. A regional sales team wants an AI assistant that can summarize customer calls, draft follow-up messages, and prepare account plans. The initial proposal looks unremarkable: a licensed enterprise tool, a familiar vendor, a limited pilot, a productivity case.
Then the product roadmap changes. The vendor offers a connector to the company’s CRM. The assistant can now retrieve account histories, identify renewal opportunities, draft pricing language, and send messages to customers after a user approves them. A later release permits automated sending within predefined rules.
At each stage, ordinary corporate controls may appear to function:
Procurement has a contract;
Security has completed a questionnaire;
Privacy has reviewed the data-processing terms;
Legal has flagged several limitations;
Technology has configured access;
the business sponsor has a budget; and
the AI Governance Committee has been informed.
Yet the critical question remains unresolved: who has authority to move the system from “drafting support” to “customer-facing action”?
The contractual answer is inadequate. A contract may permit the company to use the vendor’s service, but it cannot decide whether the company should give the service access to sensitive customer records. The policy answer is also inadequate. An AI policy can prohibit certain uses, require human oversight, or require assessments for high-risk systems. It still needs a person or body that interprets those requirements in a live case.
This is the operational fault line. Most failures do not occur because an enterprise had no policy at all. They occur because a material change falls between functions:
Legal believes it raised the issue;
Security believes it set a condition;
the business believes the pilot was approved;
Procurement believes the contract exception was accepted;
Technology believes the integration was requested by an authorized product owner; and
the committee believes it provides oversight but not operational approval.
The result is approval by momentum. The system goes live because each participant has done enough work to assume that someone else made the final call.
That assumption becomes expensive only after something goes wrong: a customer receives an inaccurate communication; proprietary information enters an unauthorized workflow; an agent changes a record; a third-party model provider changes data handling; or a regulator, auditor, customer, or board committee asks for the decision trail.
At that point, the enterprise may be able to produce policies, contracts, risk registers, and minutes. It may not be able to produce the one record that matters most: the documented decision linking a defined use case, defined permissions, defined risks, and a named accountable executive.
The point at which conventional controls break down
Consider a common scenario. A regional sales team wants an AI assistant that can summarize customer calls, draft follow-up messages, and prepare account plans. The initial proposal looks unremarkable: a licensed enterprise tool, a familiar vendor, a limited pilot, a productivity case.
Then the product roadmap changes. The vendor offers a connector to the company’s CRM. The assistant can now retrieve account histories, identify renewal opportunities, draft pricing language, and send messages to customers after a user approves them. A later release permits automated sending within predefined rules.
At each stage, ordinary corporate controls may appear to function:
Procurement has a contract;
Security has completed a questionnaire;
Privacy has reviewed the data-processing terms;
Legal has flagged several limitations;
Technology has configured access;
the business sponsor has a budget; and
the AI Governance Committee has been informed.
Yet the critical question remains unresolved: who has authority to move the system from “drafting support” to “customer-facing action”?
The contractual answer is inadequate. A contract may permit the company to use the vendor’s service, but it cannot decide whether the company should give the service access to sensitive customer records. The policy answer is also inadequate. An AI policy can prohibit certain uses, require human oversight, or require assessments for high-risk systems. It still needs a person or body that interprets those requirements in a live case.
This is the operational fault line. Most failures do not occur because an enterprise had no policy at all. They occur because a material change falls between functions:
Legal believes it raised the issue;
Security believes it set a condition;
the business believes the pilot was approved;
Procurement believes the contract exception was accepted;
Technology believes the integration was requested by an authorized product owner; and
the committee believes it provides oversight but not operational approval.
The result is approval by momentum. The system goes live because each participant has done enough work to assume that someone else made the final call.
That assumption becomes expensive only after something goes wrong: a customer receives an inaccurate communication; proprietary information enters an unauthorized workflow; an agent changes a record; a third-party model provider changes data handling; or a regulator, auditor, customer, or board committee asks for the decision trail.
At that point, the enterprise may be able to produce policies, contracts, risk registers, and minutes. It may not be able to produce the one record that matters most: the documented decision linking a defined use case, defined permissions, defined risks, and a named accountable executive.
The regulatory signal: governance is becoming operational
The regulatory landscape does not create a single universal legal requirement to establish an AI Governance Committee. That would be an overstatement. The more significant development is that privacy, AI, data, and financial-sector frameworks increasingly expect organizations to demonstrate accountability in operational terms: risk assessment, human oversight, documented controls, monitoring, incident handling, supplier management, and clear responsibility.
Hong Kong’s PCPD provides a direct example. Its Artificial Intelligence: Model Personal Data Protection Framework, published in June 2024, recommends an internal AI governance strategy that includes governance considerations for procuring AI solutions and an AI Governance Committee or similar body to guide the purposes for which AI may be procured, implemented, and used.
The important phrase is “or similar body.” The PCPD’s framework does not prescribe a ceremonial committee. It points enterprises toward a governance mechanism that steers procurement, implementation, and use. Those are decision points. They occur before contracting, at deployment, and again whenever the system’s capabilities or data flows change.
Singapore’s Model Artificial Intelligence Governance Framework, Second Edition makes a complementary point. It treats internal governance structures, human involvement in AI-augmented decision-making, operations management, and stakeholder communication as related elements of a practical framework. The structure must support decisions about acceptable risk and the appropriate degree of human involvement, not merely endorse general principles.
Mainland China presents a different but equally practical challenge. The Interim Measures for the Management of Generative Artificial Intelligence Services apply to the provision of generative AI services to the public within China, rather than to every internal enterprise AI deployment. Still, they illustrate the direction of travel: relevant providers must maintain records, respond to unlawful use, cooperate with supervision, and explain matters such as training-data sources, scale, types, labeling rules, and algorithmic mechanisms when requested by authorities.
The common thread is that regulators and counterparties are increasingly interested in the organization’s ability to show how it made a decision, not merely its ability to state a principle.
The matrix: six decisions that should never be left implicit
A useful AI decision-rights matrix should be concise enough to use and specific enough to settle disagreement. The starting point is six decisions.
The table is deliberately not a conventional RACI. It does not merely show who is consulted. It forces the enterprise to name the person or body that can decide.
Each row should contain five additional fields in the underlying operating document:
scope of decision — what precisely is being approved;
risk threshold — what can be handled locally and what requires escalation;
evidence required — assessments, testing, contracts, data maps, and controls needed before approval;
conditions and expiry — limits on the approval, including a review date; and
decision record — the location and minimum content of the documented decision.
This approach makes a difficult but healthy distinction: technical expertise may be distributed, but accountability cannot be.
Design the authority around the action, not the label “AI”
Enterprises often attempt to categorize systems by technology: generative AI, machine learning, large language models, predictive analytics, and agents. That taxonomy is useful, but it is not the most reliable way to allocate authority.
The better question is: What can the system do, and what happens if it is wrong?
A text-generation tool that helps employees draft internal summaries may require ordinary vendor review and acceptable-use controls. The same tool, connected to an internal knowledge base, may require additional data-governance review. Connected to CRM data and permitted to contact customers, it becomes a different proposition. Permitted to alter prices, approve refunds, change employee records, or execute transactions, it becomes different again.
Authority should therefore rise with the system’s practical power:
access to personal, confidential, regulated, or strategically sensitive data;
ability to communicate externally;
ability to make or influence high-impact decisions;
ability to trigger financial, legal, operational, or employment consequences;
ability to alter records or invoke tools;
cross-border processing or foreign vendor access;
reliance on vendor-controlled model updates or subcontractors; and
difficulty of detecting or reversing harm.
This is especially important for agents. A model that produces an inaccurate answer is one kind of risk. An agent that retrieves data, sends messages, books services, changes records, or triggers workflows is another. The committee’s matrix should separate approval to use an AI model from approval to give that model access, tools, and authority.
That distinction makes governance more credible because it matches how harm occurs. The significant question is rarely “Was the model approved?” It is more often “Why was the model allowed to do that?”
Residual risk: the decision that must have a name beside it
Every mature control system confronts the same fact: not all risk can be eliminated. Vendors will resist certain contract changes. Testing will reveal limitations. A business case may be compelling even though a control cannot be implemented immediately. That is where residual-risk acceptance becomes essential.
A residual-risk decision should never be inferred from silence, buried in a steering-committee deck, or treated as the inevitable consequence of a project deadline. It should identify:
the risk that remains;
the control gap or uncertainty;
the likely impact and affected stakeholders;
the available alternatives;
the mitigation measures and time limit;
the person authorized to accept the risk; and
the condition that requires the issue to return for review.
Legal, Privacy, Security, and Risk should have meaningful challenge and escalation rights. But they should not be forced into a false choice between accepting operational responsibility for a commercial decision and being ignored when the business proceeds. The accountable executive should own the final residual risk within the organization’s approved risk appetite.
If the risk exceeds that appetite or if a material legal, safety, privacy, or security objection cannot be resolved, the issue should move upward. Depending on the enterprise, that may mean the CRO, CEO, executive risk committee, Board Risk Committee, or Board Audit Committee.
This is not a question of granting Legal a veto over innovation. It is a question of preventing a business imperative from becoming an undocumented exception to the company’s own control framework.
A defensible paper trail is an operational asset
The committee’s work should create a record that is useful during a review, an incident, a vendor dispute, an audit, or regulatory engagement. The objective is not to generate paperwork for its own sake. It is to make the decision reconstructable.
For each material deployment, the enterprise should be able to retrieve:
the AI use-case description and risk classification;
the intended users, affected individuals, and jurisdictions;
the business owner and accountable executive;
a data-flow map, including cross-border transfers and third-party access;
the vendor, model, hosting environment, and material subprocessors;
the security, privacy, legal, and risk assessments;
testing results and any known limitations;
the approved human-oversight model;
the permissions granted to any agent or connected tool;
the committee or delegated approval decision, including conditions;
any dissenting views and their disposition;
any residual-risk acceptance;
the review or expiry date;
material changes to models, data, permissions, integrations, or vendors; and
incident, override, complaint, and remediation records.
This is consistent with the direction of the Singapore framework, which emphasizes documentation, monitoring, remediation, and review, and with the PCPD framework’s focus on governance across procurement, implementation, and use.
The record also changes behavior. When teams know that an executive must formally approve an agent’s access to a customer system, they ask better questions earlier. When a vendor model change triggers a documented reassessment, “minor upgrade” stops being a phrase that conceals a material shift in risk.
From committee meetings to a decision system
The test of an AI Governance Committee is not whether it has a well-written mandate. It is whether it can answer a small set of questions quickly and consistently:
Who can approve this use case?
What evidence must be provided before approval?
What conditions limit the approval?
Who owns the residual risk?
What change requires a new review?
Who can stop the system immediately?
What will the organization be able to show afterward?
If the answers depend on which executives happen to be present, the enterprise does not yet have a decision system. It has a meeting.
A well-designed matrix does not centralize every AI choice. It gives routine, lower-risk activity a clear path. It reserves senior attention for systems that affect people, data, money, regulated outcomes, or the company’s reputation. And it converts vague accountability into decisions that can be defended months later, when the original enthusiasm for the project has faded and only the record remains.
In our governance audit practice at Lexguard, the most useful starting exercise is not drafting another AI policy. It is tracing three real AI use cases from proposal to deployment and asking where approval, risk acceptance, and shutdown authority actually reside. The gaps revealed by that exercise are usually more instructive than any committee charter.
What AI governance expectations apply across Hong Kong, Singapore, and Mainland China?
Hong Kong’s PCPD recommends AI governance structures in its Artificial Intelligence: Model Personal Data Protection Framework. Singapore’s PDPC Model Framework and MAS FEAT Principles emphasize accountability and human involvement. In Mainland China, PIPL Article 38 governs qualifying cross-border personal-information transfers, while CAC rules regulate public generative-AI services.
Why do AI contracts, policies, and RACI charts fail to control AI risk on their own?
Contracts allocate vendor obligations and policies state internal rules, but neither necessarily determines who may approve an AI agent’s data access, external communications, system permissions, or residual risk. A standard RACI identifies participation; a decision-rights matrix assigns approval authority, escalation thresholds, conditions, and emergency suspension powers.
What documentation makes an AI Governance Committee decision defensible?
A defensible record links the approved use case to its risk tier, data flows, vendor terms, testing, human-oversight model, agent permissions, decision owner, approval conditions, residual-risk acceptance, and review date. Singapore’s PDPC Model Framework emphasizes documentation, monitoring, remediation, and periodic review of AI governance measures.