A release decision grants a system permission to participate in an operating process. The approving business owner needs evidence about the work it can complete, the mistakes it makes and what happens when it cannot continue. An impressive demonstration answers only part of that question.
Define the release narrowly enough to examine. Consider an invoice assistant that reads documents, proposes accounting-system matches and assembles supporting evidence for a reviewer. It cannot change supplier bank details, mark an invoice as paid or initiate a payment. Those boundaries make it possible to specify what must be true before staff rely on it.
Singapore's Model AI Governance Framework for Agentic AI, introduced in January 2026, discusses human accountability, significant approval checkpoints, baseline testing and controlled access to services. The Monetary Authority of Singapore (MAS) parliamentary reply on agentic AI, dated 5 August 2026, likewise describes authorisation, human oversight and records of consequential decisions. It presents these as elements of a potential approach, not a mandatory standard. These sources reinforce practical design questions while leaving the organisation responsible for the applicable requirements and its release decision.
Design the decision a person must make
Human oversight depends on a person being able to understand and change the outcome. Specify which decision belongs to that person: approve an exact action, resolve conflicting evidence, authorise another attempt or suspend the workflow. Giving someone a screen to click is insufficient if the action has already committed or the supporting evidence is unavailable.
Design the queue around that responsibility. Separate cases a reviewer can resolve from those requiring another owner. Give the reviewer enough time and access to inspect the evidence; measure checking and escalation effort. A service that generates proposals faster can overload the people whose judgement makes the proposals usable.
Oversight also includes decisions outside individual cases. A business owner accepts the release scope and residual risk; a technical owner enforces permissions and tests change; an operations lead manages exceptions and recovery. These are proposed working responsibilities, not a determination of legal liability. The Institutional AI Framework connects them to the wider operating design.
Ask for a release case
A release case is a compact argument supported by inspectable evidence. It names the workflow, the tested system version, the permitted users and the operating conditions. It should explain why the proposed use is acceptable within those limits.
Start with a statement the business can approve: “The assistant may prepare match proposals for these entities and document types, during these operating hours, with human approval before any accounting entry.” Record excluded cases and how they reach the existing process. A release for one entity does not automatically cover another entity's records, users or approval rules.
Attach results that someone other than the builder can review. Include the test-set composition, expected answers, error definitions and examples of failure. Retain the model and workflow versions, relevant configuration and source-data versions so the team can investigate a changed result later.
Quality has several dimensions
For the invoice assistant, extraction accuracy matters, but so do correct supplier identification, duplicate detection, valid amounts and appropriate handling of uncertainty. A proposed match should carry enough source evidence for a reviewer to assess it. The model's confident wording does not establish that the match is correct.
Measure both incorrect proposals and missed opportunities. A system can improve apparent precision by declining almost everything. That may be acceptable for a narrowly useful first release, but its throughput and business case should reflect the abstentions and resulting workload.
Test on records held back from development. Include ordinary cases, difficult cases and cases outside the permitted scope. Report results by important subgroup, such as document format or language, rather than relying on one aggregate percentage. Repeat relevant tests when variable outputs could change the outcome.
Set thresholds before examining the final results. The process owner decides how consequences affect acceptance. A formatting problem and a wrong beneficiary have different significance. Zero observed serious errors is useful evidence, but a finite test cannot establish that serious errors are impossible. The release limits and monitoring plan must account for that remaining uncertainty.
Prove what the system cannot do
Permission limits should be enforced by the systems that provide access. A written instruction telling an assistant not to make a payment is insufficient if its credentials can still execute one.
Test allowed and denied actions separately. The invoice assistant should be unable to read another entity's records or call an unapproved service. Documents may contain misleading instructions; verify that material supplied for processing cannot grant itself authority or redirect the workflow to an unauthorised action. Check that access is removed when a user's role changes.
Human approval also needs a working design. The reviewer must see the proposed action, supporting evidence and material uncertainty before deciding. Confirm that approval applies to the exact action executed. If the amount or destination changes after approval, the system should require a new decision. “A human is involved” is too vague to establish control.
Preserve a challenge route after approval
Record the proposed action, evidence inspected, approval and actual execution with a common case reference. The record should explain a changed or rejected proposal as well as an approved one. Retention and access must match the sensitivity of the data; indiscriminately logging everything can create a separate problem.
Sample completed cases for review and inspect whether people are discovering meaningful errors or merely confirming fluent explanations. Escalation frequency alone is ambiguous: a fall may reflect better performance, missing evidence or reduced willingness to challenge. Pair it with case review, consequences and actual handling time before deciding that oversight can be reduced.
Where the use materially affects a customer, employee or counterparty, identify how they can dispute evidence or an outcome, who reviews the dispute and how an accepted error is corrected. Assess applicable notification, remedy and timing requirements separately from this proposed operating method.
Rehearse interruption and recovery
A dependency will sometimes be unavailable. An upload may repeat. A worker may lose connectivity after submitting a decision. The release test should cover these ordinary disruptions and the business consequence of each one.
For a read-only proposal workflow, the team may be able to re-run a case safely after checking its status. A system that writes records needs stronger protection against duplicate effects. Test what happens when it is unclear whether the previous write succeeded. Operators need a way to inspect the authoritative state before retrying.
Demonstrate a pause procedure and the route back to manual work. State how long the business can tolerate the interruption and how the backlog will be handled. Preserve the records needed to explain prior actions, with access and retention appropriate to their sensitivity. Recovery is not complete if the software restarts but staff cannot determine which cases need attention.
Rehearse fallback with the people and capacity that will remain after the proposed savings. Record the interruption, incoming workload, catch-up rate and deadline. A manual procedure is insufficient if it relies on contractors or staff whose cost has been removed. The release and operating pack connects that rehearsal to the staffing and funding decision.
The release evidence sheet
Use this at the approval meeting. For each row, attach the evidence, name the owner and record “pass”, “hold” or “outside this release”. A blank field remains an unresolved decision.
| Area | Evidence to attach | Decision to record |
|---|---|---|
| Scope | Start/end states, entities, users, document types and excluded work | Exact operating boundary approved |
| Output quality | Held-back test results, error categories, subgroup results and failures | Thresholds met and residual errors accepted |
| Review effort | Observed handling time, queue load and reviewer feedback | Staff capacity sufficient at expected volume |
| Permissions | Allowed/denied-action tests and access configuration | Reads, writes and external actions permitted |
| Human approval | Demonstration of review, approval and changed-action handling | Who approves which consequential decisions |
| Data handling | Data flows, storage locations, access and retention settings | Required privacy/security decisions completed |
| Recovery | Dependency-failure, retry, duplicate and manual-fallback exercises | Recovery time and backlog process accepted |
| Monitoring | Error, cost, latency and exception alerts with escalation routes | Named responder and suspension triggers |
| Support | Operating instructions, service ownership and supplier escalation | Support coverage funded and available |
| Change control | Version record and re-evaluation requirements | Changes that require another release decision |
The sheet should record disagreement as well as approval. A technical test can pass while the operations team lacks enough reviewer capacity. That is a reason to limit or defer release, not an issue to bury in the handover notes.
Release only as far as the evidence supports
A sensible first release may expose proposals to a small group while retaining the existing process. Observe the workload, corrections and exceptions under real conditions before expanding authority or volume. Each expansion changes the claim the evidence must support.
Take the completed sheet to the business owner alongside the full operating-cost calculation. The approval should identify the version and scope being released, who can suspend it, and the evidence required for the next expansion. That makes the decision specific enough to operate and revisit.
Read our editorial principles for evidence, contribution and correction standards.