Decide Which Decisions Stay Human in an AI-Centric Organisation

Keep people accountable for the rules an AI workflow follows and the commitments it makes. Reserve consequential judgements for a qualified, authorised person, and define any class of routine actions the company permits automatically. Decide the boundary from the actual effects of an error, the ability to recover, and the company's obligations, then fund the people who must handle exceptions.

Separate setting policy from applying it

Begin with the decisions the company already makes. A leadership team chooses its priorities and risk appetite. A commercial owner sets terms within their mandate. An operator applies an approved rule to an eligible case. AI assistance can change how they prepare the evidence, but management still needs to decide who has authority over each outcome.

Distinguish a rule from the judgement that creates or changes it. Applying an approved routing label is different from deciding which customers receive urgent service. Checking an order against a price list differs from authorising a discount exception. Write both decisions down so the workflow doesn't turn an ambiguous case into an unapproved policy change.

Keep trade-offs with the person who owns them. An AI system can model options for a delivery schedule, but someone must settle how the company balances contractual promises, overtime, and service to other customers. A target such as minimising cost leaves those priorities underspecified. Give the system approved constraints rather than asking it to invent the company's values.

Permit automatic application only within a defined, tested class of cases and the company's existing authority rules. Name the eligible inputs, allowed action, limits, and exception route. An uncertain business rule belongs with its owner. A high model confidence score cannot establish permission to interpret a contract or change a service entitlement.

A Reddit discussion about the authority behind human approval asks what a recorded approval actually proves about the reviewer. It raises design questions rather than providing measured evidence. Use those questions to check whether the workflow can establish the person's mandate for the particular decision, not merely record their click.

For a small company, a short register and existing approval process may cover the first workflow. A large company needs the same clarity across units and shared services. A central AI team can maintain execution controls; local management owns the business rules. Sharing a platform across a PE portfolio doesn't transfer a company's decision authority to the platform team.

Judge reversibility and downstream consequences

Describe what a wrong decision changes outside the application. Who receives it, which process acts on it, and how soon does the effect occur? A field you can edit may already have triggered an order, an access grant, or a customer message. Restoring that field doesn't necessarily restore the prior business situation.

Assess recovery in operational terms. Name who can detect the error, how long they have before harm occurs, and what they need to correct it. Check whether the company can contact affected parties, retrieve the relevant records, and coordinate downstream work. A rollback button without that recovery path offers incomplete evidence of reversibility.

Consider volume and cumulative exposure. A modest adjustment on a single account may have a tolerable correction cost, while the same adjustment across thousands of accounts can overwhelm the team. Evaluate how many actions can happen before monitoring detects a problem. Give the owner a defined way to stop the affected operation.

Include the cost of delay. A decision that must wait for a specialist can affect service or safety even when the system doesn't act. Staff the escalation path according to the workflow's needs, with an approved fallback for absence or outage. Leaving every uncertain case in an unmonitored queue doesn't settle the decision boundary.

Use a consequence review to select controls, rather than reducing every judgement to a single risk score. A low-value transaction can disclose sensitive information or establish a contractual promise. An expensive internal planning calculation may have no external effect until a person uses it. Explain the specific reason for the boundary in the register.

Test the proposed recovery before wider use. Follow a deliberately incorrect test action through the systems it touches, in an approved environment. Check whether the team can locate the resulting work and restore the intended state. Record effects that the test cannot represent, and keep those limits in the release decision.

Allocate authority through a decision-rights register

Use the register to allocate business authority before choosing the approval interface. For each decision, state the policy owner, the person or role authorised to approve a case, and the allowed delegation. Define what evidence they need and what they can reject or change. Connect the register to the company's existing financial and operational mandates.

These examples propose a discussion framework, not universal legal rules or permission to bypass a company's controls. The organisation must set its actual boundaries for the use case and jurisdiction. A role title alone doesn't establish authority: a finance analyst may understand a payment without holding its release mandate.

Define delegation precisely. Specify the records, action type, value limit where relevant, and conditions that require another approver. Add a duration or review point for temporary cover. A manager's holiday shouldn't force staff to choose between a stalled process and a colleague approving something outside their mandate.

Keep approval independent where the company's controls require it. Someone who creates a proposal may not be the person permitted to release it. AI-generated preparation doesn't remove that separation. The application should enforce the approved roles and prevent a user from selecting an easier approval path for an ineligible case.

Give policy disputes a named destination. When sources conflict or a case falls outside the rule, route it to someone who can resolve the business interpretation. The technical team can explain a system failure, but it may lack authority to change a customer's entitlement. Record whether the resolution applies only to the case or changes the policy for future work.

Connect the register to the implementation team. The engineer needs concrete permission and routing rules; the manager needs instructions for escalation and cover. Our guide to AI quality review and decision ownership explains how to place the review once the company has allocated those rights.

Reserve judgement over customer commitments

Classify customer communication by its effect. An approved status message from a verified record may fit a bounded policy. A new delivery promise, contract interpretation, or response to a disputed obligation can require commercial judgement. The fact that both actions produce an email doesn't give them the same decision boundary.

For an illustrative distributor, allow the assistant to prepare a response using approved order status. Reserve an exception to the agreed delivery terms for the commercial owner. Let the owner compare the customer's request with stock, contract terms, and the effect on other orders. Keep the assistant's recommendation visible as preparation for that judgement.

Check the cost of a wrong commitment before authorising automatic sending. A correction email may not remove a promise the customer has already relied on. If the organisation allows a narrow class of automated messages, define the recipients, approved content, source freshness, and conditions that block sending. Escalate conflicting or incomplete records.

Give the customer a clear route to challenge an outcome and reach someone with authority. A complaint routed repeatedly through the same mistaken rule can intensify the problem. Define who can suspend the disputed action, investigate the evidence, and communicate the current position. Keep that role connected to the operating team.

Keep publication authority distinct from drafting capability. Staff may use AI to prepare public material without gaining permission to issue a company statement or disclose client information. Apply the existing review to the actual content and audience. Record the approved version, and check material changes before release.

For investors reviewing an AI business, inspect a customer case where the system reaches a commitment boundary. Ask who settles an exception and how the customer can obtain review. That evidence helps you understand both the product's scope and the company or service team that must support it after deployment.

Treat financial exposure as a control problem

Distinguish preparing financial information from moving money or changing the authority to do so. An assistant can reconcile a proposed payment with an invoice while finance staff retain the release decision under existing controls. A vendor bank-detail change is a separate decision with its own verification path. Don't merge it into approval of an otherwise ordinary invoice.

Use the company's actual limits and verification requirements. They may depend on counterparty, transaction type, or cumulative exposure as well as amount. Verify identity and destination through the approved process. Reading a plausible explanation from the model doesn't establish that a payment instruction belongs to the intended supplier.

Consider repeated actions. An illustrative policy that permits a small adjustment per case needs to address multiple adjustments to the same account and total activity within a period. Management sets those boundaries from the business exposure and its controls. The workflow should aggregate the relevant activity rather than treating every request as unrelated.

OWASP's 2025 guidance on excessive agency recommends limiting tool permissions, requiring approval for high-impact actions, and enforcing authorisation in downstream systems. Apply the permission rule where the action occurs. A prompt asking the assistant to respect a finance limit doesn't enforce the company's mandate.

Keep the approved proposal linked to the eventual action. If the destination, amount, or relevant account state changes, recheck whether the approval still applies. Define expiry and rejection behaviour with finance and engineering. A record that a person approved something earlier doesn't establish permission for a changed transaction.

Handle uncertainty without generating another commitment. A timeout may leave the team unsure whether the receiving system completed an action. Reconcile the outcome before retrying under the destination's supported controls. Our guide to when AI assistants should read, recommend, or act covers the execution and recovery boundary.

Check rights, professional duties, and regulatory context

Identify decisions that affect a person's employment, access to a service, or other consequential interests. Involve the appropriate domain and compliance owners before using AI in that process. Define what evidence the system can prepare, who evaluates it, and how the person can challenge the outcome. Keep data permissions and fairness checks within the design.

A person at the end of the workflow cannot necessarily repair an earlier exclusion. If the system filters out a case before the reviewer sees it, the decision boundary may already have had an effect. Examine selection and routing as well as the final approval. Review missing and rejected cases so oversight doesn't cover only the population the system chose to present.

The European Commission's AI Act Service Desk explains Article 14 as a human-oversight requirement for high-risk AI systems. It addresses understanding limitations, interpreting outputs, avoiding over-reliance, and the ability to override or stop the system. That specific scope doesn't make every business workflow a high-risk system or create a universal approval rule.

Have the responsible legal or compliance owner establish the rules that apply to the actual system and use, including applicable dates. Record their conclusion and its scope with the decision register. Product labels and a generic statement of responsible AI don't settle sector duties, contractual commitments, or jurisdiction-specific requirements.

For professional work, reserve the relevant opinion and sign-off for someone qualified and authorised under the engagement. They need to inspect the evidence and explain their reasoning, including the limits of AI assistance. A workflow that asks them to endorse an opaque answer gives them inadequate means to perform that responsibility.

For a PE portfolio, share the review method while keeping each company's assessment specific. A control suitable for internal inventory analysis may not support a healthcare, lending, or employment use. A venture investor can ask for evidence that the startup has identified its customers' intended use and the responsibilities it leaves with them.

Make human oversight an operating capability

Give reviewers enough evidence, time, and authority to decide. Show the proposed change, its effect, and the source records they need to inspect. Distinguish verified facts from generated interpretation. Let them reject the proposal, request clarification, or use the established manual route without the system repeatedly submitting the same rejected action.

Train people on consequential failure patterns in an approved test setting. Ask them to identify a wrong counterparty, an unsupported commitment, or a case outside their mandate. Check that they can explain the issue and use the escalation route. A record of training attendance doesn't show whether the person can perform the actual review.

Plan staffing from the decisions that require judgement and the time they take. If the system can create cases faster than qualified people can review them, cap intake or use the agreed fallback. Don't widen automatic authority simply because the queue is growing. Investigate whether the scope, evidence presentation, or staffing needs to change.

Watch whether reviewers can disagree in practice. A target that rewards only throughput can put pressure on staff to approve doubtful cases. Measure decision quality and unresolved exceptions alongside turnaround time. Give someone outside the daily delivery pressure a way to inspect samples of accepted and rejected work.

Keep logs proportionate and protected. Record the case, relevant policy version, approver's authority, decision, and resulting action under approved retention rules. Avoid copying unnecessary personal or client information into another system. The record must support investigation without creating an unrestricted archive of sensitive material.

Use live operating evidence to inspect the human boundary. Track wrong actions, missed escalations, reversal effort, and cases that wait beyond the agreed service need. Follow a disputed decision from the original evidence through approval and execution. Those records tell management where the allocation of authority needs work.

Review delegation when the operation changes

Review decision rights when the workflow gains a new action, audience, or source. Adding a customer-facing channel can change the effect of the same generated text. Moving from a draft to a write changes authority even when the interface looks similar. Make that change a named operating decision with supporting evidence.

Keep the boundary explicit during organisational changes. When an approver changes role or leaves, update the mandate and cover arrangement as well as system access. When companies share a service, establish which company owns the affected decision. A familiar name in an approval list doesn't establish current authority.

Inspect requests for broader automation by decision class. Compare representative cases with difficult exceptions, check the routing and recovery path, and explain what evidence supports the proposed delegation. Keep the company owner responsible for the policy and its monitoring. A high average accuracy score alone doesn't settle the consequence of a rare wrong action.

Start with a working session around a real process. Ask the owner and operators to identify where the workflow changes a person's situation, commits the company, or creates exposure that the team cannot readily reverse. Assign the authority and exception route at those points, then give engineering the rules it must enforce before the next release.