When Should AI Request Approval in a Product?

An AI assistant that asks for approval before every action soon becomes another form to clear. One that acts without asking can create errors that are hard to reverse. When should AI request approval is therefore not a setting to apply across a product. It is a product decision about authority, consequences and evidence.

For most teams, the useful question is simpler: what is the smallest action the system can take safely on its own, and where must a person remain accountable? The answer changes with the task. Drafting a support reply, updating a customer record and issuing a refund may all happen in the same workflow. They should not have the same approval rule.

When should AI request approval?

AI should request approval when an action is consequential, difficult to reverse, uncertain, or outside the authority a user has deliberately given it. Confidence matters, but it is only one input.

A model may be highly confident that a customer wants to cancel a subscription. It can still be wrong. Conversely, a low-confidence suggestion to reformat internal notes may be harmless. Treating both cases as a confidence-score problem produces poor interaction design.

We usually separate the decision into four practical dimensions: impact, reversibility, ambiguity and authority.

Impact is the effect of a wrong action. Sending an internal draft to the wrong person is inconvenient. Changing payment details or publishing information to customers has a greater effect.

Reversibility is the cost of putting things right. An editable draft is easy to undo. A deleted record, a submitted application or a message sent to thousands of recipients may not be.

Ambiguity is whether the system has enough reliable context to act. A request such as “follow up with the usual people” might be clear to a person who knows the account history, but unclear to a system working from partial records.

Authority is what the user has explicitly authorised. An assistant can prepare a purchase order without being authorised to submit it. Access to information is not permission to act on it.

These dimensions let you define approval points without making every workflow defensive and slow.

Use approval for commitments, not for every step

The cleanest pattern is often to let AI do the preparatory work, then ask for approval at the point of commitment. It can retrieve relevant records, propose options, fill fields and explain its reasoning before an external or irreversible action occurs.

Consider a product that helps an operations team reschedule appointments. The system might identify conflicts, suggest available slots and prepare messages to affected people. It should request approval before appointments are changed or messages are sent, unless the team has set clear rules that permit automatic rescheduling within defined limits.

That distinction gives people useful control. They are not asked to approve every lookup or calculation. They approve the action that changes another person’s schedule.

The same approach works in customer support. AI can classify an issue, gather account context and draft a reply. A person may need to approve the reply when it contains a refund decision, a contractual statement or advice specific to the customer’s circumstances. For routine status updates based on a reliable source, automatic sending may be appropriate if the product makes that behaviour clear and offers a way to inspect it.

Approval is not always the safer choice. An approval request can create delay at the exact point a user needs speed. It can also encourage rubber-stamping if the person is shown too much work with too little context. The goal is not maximum human involvement. It is meaningful human control at the points that need it.

Make the approval request reviewable

“Approve this action?” is rarely enough. A person cannot make a good decision without knowing what will happen, why the system chose it and what information it used.

A useful approval surface shows the proposed action in plain language, its scope and its expected result. It also shows the source material or rule that supports the proposal where that evidence is available. If the action changes data, show the before and after state. If it sends a message, show the final recipient list and message content. If it makes several changes, make the batch visible rather than hiding it behind a single button.

The interface should also make edits easy. Approval does not have to mean accept or reject. A user may want to change the wording, remove one recipient, adjust a date or choose a different option. If editing requires abandoning the whole flow, people will either accept a poor proposal or avoid the feature.

For higher-impact actions, record what was proposed, what was approved and what was changed. This is useful for operational review and for diagnosing failures. It is not a substitute for good permission design, but it gives teams an observable trail when something goes wrong.

Design for different levels of autonomy

Binary rules are often too blunt. A product can offer several operating modes that match the user’s role and tolerance for risk.

A new user might begin in a preview mode where the system only prepares work. A more experienced user may allow automatic action within limits, such as scheduling meetings only during business hours or applying a standard tag to incoming requests. An administrator may define team-wide rules for actions involving shared data.

The boundaries need to be specific. “Let AI manage my calendar” is broad and hard to interpret. “Move internal meetings of up to 30 minutes when all attendees have availability, but ask before changing customer meetings” is a rule a product can explain and a user can challenge.

Defaults deserve particular care. They communicate the organisation’s view of acceptable risk. If automatic behaviour is enabled by default, users need to see it before it affects their work. If approval is required by default, the product should not quietly widen authority after a user has used the feature for a while.

Confidence scores are signals, not permission

Teams often want a single confidence threshold: request approval below a score, proceed above it. This can be useful for triage, but it is not enough to determine authority.

A confidence score reflects the system’s estimate about an output under particular conditions. It does not measure the real-world cost of being wrong. It may also be poorly calibrated across task types. A score that is useful for classifying support tickets may tell you little about whether a generated statement is suitable to send to a customer.

Use confidence as one trigger among others. A product might always request approval for external communication, request approval when source data conflicts, and allow low-impact internal actions to proceed even when confidence is modest. Where confidence is shown to users, explain what it refers to. A vague percentage can imply precision that the system does not have.

When the system lacks evidence, say so directly. “I found two records with different renewal dates” is more useful than presenting a confident recommendation without its uncertainty.

Test the hand-off, not just the model output

A plausible answer in a demo tells you very little about whether an approval pattern works in real use. The critical interaction is the hand-off between suggestion, review and action.

Start with a model-connected prototype that uses representative data and realistic constraints. Give participants tasks where an automated action would save time, then include cases where the suggestion is incomplete, wrong or outside their authority. People should run those sessions and decide what the findings mean. AI can assist with synthesis, documentation and analysis afterwards.

Look for specific behaviours. Do users notice when an action has external consequences? Can they tell what data will change? Do they understand why approval is required in one case but not another? Do they edit proposals comfortably, or do they accept them without reading? These observations reveal more than whether users say they trust the feature.

Once the feature is live, instrumented feedback loops help you assess whether the rules are working. Track events such as proposals generated, approvals, edits, rejections, reversals and escalation to a person. Review the paths that lead to corrections. A high approval rate may mean the system is useful, or it may mean people are approving without scrutiny. You need the surrounding evidence to tell the difference.

Structured evaluation should include difficult cases, not only the common path. Test missing data, conflicting records, unusual permissions, bulk actions and users returning after an interruption. The approval design must hold up when the task is messy, because that is when people depend on it.

Keep permission rules visible to engineering

Approval logic is product behaviour, not just interface copy. Engineering needs a clear account of what the system may read, propose, change and send at each stage. That account should include failure behaviour: what happens when a required source is unavailable, a permission changes mid-task or the system cannot determine the correct action.

For teams using design system components and front end code, approval states should be treated as reusable patterns. The component needs states for loading, unavailable evidence, edited proposals, expired approval and partial failure. A polished confirmation button is not the pattern. The surrounding conditions are.

Your engineers should review and merge any front end implementation through their own repository and pipeline. That keeps approval behaviour aligned with existing permissions, audit requirements and release controls.

The most useful approval rule is one a user can predict before the system acts. Make the boundary visible, make the proposed action inspectable, and keep automatic behaviour inside limits that people can understand. That gives AI room to do useful work without asking users to hand over judgement.