An AI feature once changed a customer’s legal name to an email signature with impressive confidence. It extracted the company, contact, route and date with impressive confidence. It also changed the customer’s legal name to the sender’s email signature. There was no preview and no undo.

The feature was technically efficient. So is a shredder.

AI copilots promise to remove repetitive work, surface patterns and accelerate decisions. Their usefulness depends less on whether they can act and more on whether people can understand and recover from those actions. Undo is not a secondary convenience. It is part of the trust model.

Automation changes the cost of mistakes

A manual error usually affects the thing a person is editing. An automated error can update hundreds of records, send messages or trigger downstream systems before anybody notices.

Speed magnifies both value and consequence. Product teams should classify actions by reversibility, scope and impact. Drafting a summary is different from approving a payment. Suggesting a category is different from changing a legal entity across contracts.

This should shape the interaction. Low-impact, easily reversed actions can be fluid. Consequential actions need preview, confirmation, permissions and audit. The goal is not to make AI timid. It is to give its confidence an appropriate blast radius.

Undo needs a real model

An Undo button is easy to draw and difficult to support. The system must know what changed, what the previous state was and whether later actions depend on it.

For a text suggestion, undo may restore a previous version. For a workflow change, it may need to reopen an approval, notify another team or create a compensating transaction rather than erase history. Some actions cannot be reversed: a message was sent, a customer saw a price, an external system issued an invoice.

Designers should work with engineering and operations to define reversible, compensatable and irreversible actions. The interface must not offer a comforting arrow that merely changes the screen while reality continues elsewhere.

Show the proposed change

The safest correction is the one users can make before committing. Preview what the copilot intends to change, highlight differences and group related updates. Use the language of the task rather than a raw JSON confession.

For document or record extraction, link values to their source. Let users inspect the email sentence or attachment region behind a suggestion. Confidence is more useful when attached to a field and evidence than when displayed as a theatrical percentage at the top of the page.

The NIST Generative AI Profile emphasises risk management throughout the AI lifecycle and recognises that different uses require different oversight. Product interaction is one place that oversight becomes practical: preview, approve, monitor and recover.

Keep the human in control of commitment

“Human in the loop” is often used as a reassuring phrase without defining what the human controls. A person who can only approve a completed batch in five seconds is not exercising meaningful oversight.

Control requires time, evidence and authority. Users should understand which parts were generated, what rules were applied and what happens when they accept. For high-consequence work, support selective approval rather than all-or-nothing commitment.

In operational platforms such as the work described in my Aerios case study, recommendations can affect commercial, contractual and operational decisions. AI may accelerate loadability checks, request capture or follow-up, but ownership of the final action must remain explicit.

Design correction as learning

When users correct AI output, the product gains useful evidence. But correction should first serve the current task, not become unpaid model training disguised as housekeeping.

Make edits fast. Preserve the original suggestion for audit where necessary. Ask for a reason only when it improves governance or future performance enough to justify the interruption.

Be clear about whether feedback affects future behaviour. Users should not assume that correcting a result permanently teaches the system if the product does not support that. False learning creates repeated disappointment with the peculiar rhythm of arguing with a very polite goldfish.

Batch actions need batch recovery

Copilots become powerful when they operate across many items. This is also when a small misunderstanding becomes an afternoon.

Before batch execution, show scope and exceptions. Allow users to exclude items. After execution, provide a summary of successful, skipped and failed actions. Support reversal at the same level where safe; undoing 200 changes one at a time is technically possible and experientially vindictive.

If a partial failure occurs, do not present the whole job as simply Failed. Show what happened and prevent duplicate actions on retry. The product should be idempotent even if nobody uses that word outside the engineering meeting.

History should explain agency

Audit trails need to distinguish user actions, AI suggestions and automated system actions. “Record updated by Richard” is misleading if Richard approved a batch that the copilot assembled.

Record the suggestion, approver, time, changed fields and relevant model or rule version where governance requires it. Present a readable history to users and retain deeper technical details for investigation.

This protects both trust and accountability. People should not become the ceremonial owner of decisions they could not inspect, and AI should not appear as an independent colleague floating above organisational responsibility.

Failure is a design input

Teams often demonstrate the best AI output and test the average one. Trust is shaped by the worst plausible failure.

Test confident errors, incomplete sources, contradictory documents, stale data and adversarial input. Observe whether users notice and whether recovery is proportionate. Include accessibility: change highlighting, source inspection and confirmation must work with assistive technologies.

The WCAG guidance on error identification reinforces a broader truth: users need clear descriptions of problems. “The AI failed” is no more actionable than “Something went wrong”. Explain which items were affected and what the user can do.

Measure safe usefulness

Adoption alone is a dangerous success metric. People may use an unreliable copilot because management expects it or because the manual alternative is worse.

Measure time saved alongside correction rate, reversal rate, downstream errors and unresolved exceptions. Segment by action type and consequence. Pair metrics with research into whether users understand the system and feel able to challenge it.

The strongest signal may be calibrated reliance: users accept good suggestions quickly, inspect uncertain ones and reject bad ones without losing work.

Trust comes from recoverability

AI products do not earn trust by never being wrong. They earn it by making uncertainty visible, keeping commitment under human control and supporting recovery when mistakes occur.

Design the preview. Limit the blast radius. Preserve versions. Build batch recovery and honest history. Decide which actions can be reversed before placing a friendly curved arrow beside them.

Every copilot needs an undo button. More importantly, it needs a product model that makes Undo true.