An AI governance framework can contain extensive policies, review committees, and approval records while leaving a consequential question unresolved. Who has the authority to decide what the system is allowed to do, and who acts when its behaviour falls outside the conditions on which approval depended? An organisation needs answers that remain clear during operation, when time is limited and responsibilities are under pressure.
AI introduces several sources of uncertainty, including imperfect predictions, variable generated outputs, and changes in data or supplier behaviour. Their significance depends on the action supported and the consequences of error. An inaccurate internal summary, an unnecessary payment hold, and an inappropriate credit decision require different assessments. Applying one undifferentiated approval process to all three can create delay without resolving the material risks.
The previous article examined repeatable production delivery. This article addresses the decisions that govern permitted use throughout the operating life. Its central concern is the connection between evidence, authority, and accountability. Governance becomes effective when the organisation can identify the conditions under which a capability is acceptable, recognise when those conditions change, and make a timely decision about what follows.
Govern the action and its consequences
The unit of assessment needs to include the decision service and the action it enables. A model’s technical characteristics matter, but they do not establish the full risk of its use. The same output can support an employee’s investigation, trigger a request for evidence, or initiate a customer-facing action. Each use creates different consequences and control requirements.
The payment capability developed earlier in this series illustrates the distinction. The bank approved an automated check for an eligible standard-payment population and retained existing controls for an urgent-payment subset. The approval applied to a defined intervention within a defined scope. It did not authorise any action that could be connected to the model’s output.
Now the payments operation proposes holding flagged payments automatically until additional information is obtained. The team expects fewer failures and less manual work. However, the proposed action introduces a different balance of risks, including delayed legitimate payments, unclear customer communication, and a growing queue of unresolved holds. Existing evidence about automated checks cannot establish the acceptability of those consequences.
The governance assessment must therefore identify what has changed. It needs to examine the authority to hold payments, the permitted duration, the process for release, and the impact on customers. It also needs evidence about unnecessary holds and the operation’s capacity to resolve them. A technically unchanged model can sit inside a materially changed business decision.
The bank rejects immediate expansion of the existing approval. It authorises a limited evaluation of the proposed action only where the bank’s own legal, operational, and control assessment establishes that it is permissible. Existing production use remains within the original scope.
Match the evidence to the consequence
Proportionate governance begins with the significance of the decision and the ways it can fail. The assessment needs to consider customer harm, financial exposure, operational disruption, reversibility, and the ability to detect an error before its consequences grow. A readily corrected internal suggestion and a difficult-to-reverse financial action do not require identical evidence.
The employee assistant from the investment-priorities article warrants a lighter route where its use is confined to internal information retrieval, staff can check answers against authoritative material, and errors are readily corrected before they affect customers. That route still needs access controls, testing of relevant answers, clear limits on use, and a way to report errors. It does not need the same approval for consequential actions as the payment hold. Allowing the assistant to generate unchecked customer advice would change that assessment.
The lending case from the strategic-advantage article raises a different set of consequences. Decisions affecting access to credit need scrutiny of the model’s ability to distinguish relevant risks, fairness, the reasons supporting decisions, and the handling of challenge or correction. The assessment must account for the applicable obligations and the bank’s decision process. These contrasts make proportionality specific to permitted use, rather than a label attached to a model or tool.
For the proposed payment hold, a strong prediction score is insufficient. The evaluation needs to establish how often legitimate payments are delayed, whether the intervention prevents the targeted failure, and how long unresolved cases remain open. Customer communications, release procedures, and complaint handling also form part of the capability being assessed.
The evidence must include performance in conditions that challenge the design. Missing information, unusual transaction patterns, reduced staffing, and unavailable supporting services can change the result. Testing only the expected flow leaves the bank uncertain about whether its controls work when the operation is under pressure. Rare but consequential failures deserve explicit treatment, even where average performance looks favourable.
The bank sets illustrative evaluation conditions before testing. The action must reduce the targeted failures by at least 20%, while unnecessary holds must remain below 0.1% of eligible payments. Every held payment must have an identified release route. A queue-capacity limit determines when the operation stops creating new holds and returns to its established process. The thresholds are chosen from the business and control assessment, rather than borrowed from a generic AI benchmark.
The controlled evaluation records a 24% reduction in the targeted failures and unnecessary holds affecting 0.08% of eligible payments, with a documented release route for every held case. Both quantitative conditions are met. The business review also finds positive net value after intervention and operating costs. These illustrative results support progression, but production approval remains dependent on the operating controls passing their tests, including the queue-capacity response under surge conditions.
Approval then depends on the complete evidence, including the costs and customer effects. A favourable result in one measure cannot compensate automatically for failure in another. Where the evaluation cannot establish a safe and effective release process, the action remains outside permitted production use. That conclusion concerns the proposed intervention, rather than a blanket rejection of AI.
Give accountable owners usable authority
Naming an owner is insufficient if that person cannot influence the conditions on which success depends. Accountability needs a defined scope, access to relevant evidence, and authority to make or escalate decisions. It also requires clarity about responsibilities that remain with other functions.
AI governance should connect to the bank’s existing model risk, operational resilience, conduct, and supplier-management arrangements. Those functions retain their established responsibilities, with AI-specific gaps addressed explicitly. A common decision record can bring their assessments together without creating a parallel approval structure that repeats reviews or obscures who owns the final decision. The integration follows the nature of the use and the bank’s existing framework.
The payments business owner is accountable for the intervention, customer outcome, and operation of the service. The technical owner maintains the capability and reports material changes in performance or dependencies. Risk functions provide their defined oversight and challenge, while independent assurance assesses the effectiveness of the arrangements. The precise allocation follows the bank’s governance structure, with responsibilities documented rather than inferred from participation in meetings.
Acceptance of residual risk belongs with the role authorised to make that decision under the bank’s framework. A project team cannot accept it simply because delivery is complete, and a review committee cannot make accountability disappear through collective approval. The decision record must identify the permitted scope, conditions, unresolved limitations, and person or role authorised to accept them.
Operational authority needs similar precision. Staff must know who can suspend the intervention, who can authorise a restart, and which issues require escalation. The organisation needs cover for absences and out-of-hours incidents. Authority that depends on one unavailable executive is ineffective when a customer-facing problem develops at transaction speed.
For the payment service, the approved operating instructions give the duty operations manager authority to stop new holds when the queue limit is breached. Restart requires evidence that the backlog is controlled, the cause is understood, and the service can operate within its agreed conditions. Any proposal to loosen those conditions returns to the appropriate decision owner. This prevents an incident response from quietly becoming an expansion of risk appetite.
Make human oversight an effective control
Human review is often included as a reassurance without testing whether it changes the outcome. A reviewer needs sufficient information, relevant expertise, enough time, and the practical ability to disagree. If the process makes acceptance easier than challenge, the organisation risks adding a signature while retaining the original weakness.
In the payment example, a reviewer who sees only a model score has limited grounds for deciding whether to release a hold. The operation needs the relevant evidence, the reason for intervention, and a clear route for resolving uncertainty. Staff must understand the limits of the output and the consequences of each permitted action. Training should include ambiguous cases and situations in which the recommended action is inappropriate.
Oversight also has a capacity requirement. A queue that exceeds available review resources makes timely judgement impossible, even with well-trained staff. The bank’s limit on new holds protects the operation from creating obligations it cannot fulfil. The fallback process must be evaluated for its own risks and resource demands, rather than treated as safe simply because a person is involved.
The bank tests the arrangement under a simulated surge. The queue reaches its agreed limit, and the duty manager suspends new holds while existing cases continue through the release process. The exercise reveals that one escalation route depends on a specialist who is unavailable outside normal hours. The bank fixes the coverage gap before authorising production use of the new action.
That finding changes the governance decision. The control existed in documentation but failed an operating requirement. A tested review process provides stronger evidence than the statement that a human remains involved. Its value depends on whether people can recognise the problem, challenge the output, and act within the time available.
Keep approval connected to operating evidence
Approval establishes the conditions for use at a point in time. Those conditions need to remain visible as data, workflows, suppliers, and customer behaviour change. A materially different action or population requires assessment of the differences, even when the technical component remains familiar.
The linked service record introduced in the production article provides a useful home for that evidence. It can connect permitted scope, evaluation results, decision authority, operating limits, and value measures. The objective is traceability from the original decision to current use, with changes and exceptions recorded in a form that business, technical, and oversight teams can examine.
Operating reviews need to test whether the accepted conditions still hold. An increase in unnecessary holds, a growing unresolved queue, or a loss of required information can trigger restriction or suspension. Supplier changes can also affect the capability without a local release. The response needs to follow the significance of the change and its effect on the approved action.
In the illustrative case, production approval follows the satisfactory outcome evaluation, the coverage fix, and successful retesting of the operating controls. It is limited to the evaluated population, action, and operating conditions. The bank retains existing controls elsewhere and requires a fresh decision before changing the hold duration or widening eligibility. That closes the loop between the proposal, evidence, and authority.
Before approving consequential AI use, leadership needs answers to four questions. What action are we authorising, and within which boundaries? What evidence establishes that its benefits and risks are acceptable? Who can accept the remaining risk, change the conditions, or stop the service? What operating evidence will require that authority to be exercised?
Those answers make approval a set of operating conditions that identified people have the authority to enforce. In the payment case, that includes the duty manager stopping new holds and the decision owner refusing to relax the limits without fresh evidence. A record that something was reviewed provides little protection if nobody can act when its conditions cease to hold.
