Fallback and manual workaround

What it does

It lets the business continue without the model. For each AI component in a process that matters, an alternative is defined, resourced and rehearsed: staff working a documented manual procedure, an earlier rules-based system, a second model, or the service running with reduced function. The trigger for invoking it and the person who decides are named in advance. The owner of the business process is accountable; the system owner designs degraded modes. It is designed before go-live and invoked on failure or withdrawal.

How to implement it

• Decide, before automating, how the process will run when the model is unavailable or untrusted.
• Design the system to degrade: queue, route to people, or apply simple rules.
• Keep the manual procedure documented and the skills alive through periodic practice.
• Size the fallback against realistic volume and state how long it can be sustained.
• Define the trigger and authority for switching over, and for switching back.
• Test the switch-over, including out of hours.

Evidence it operates

Design: a fallback plan for each material AI component, with capacity and trigger. Operation: test records at realistic volume; training or practice records for staff; an instance of the fallback being invoked; review after each use.

Where it fits

In design and in incident response. It is the primary control for no fallback for AI failure and AI service outage, and supports untested AI failure scenarios. It is what makes the human override and stop mechanism usable in practice.

Limits

Keeping a fallback costs money, which is the reason it is so often removed. Manual capacity is rarely enough for full volume, so the fallback buys time and reduced operation. Skills that are not used fade. Where the model's judgement cannot be reproduced by rules or people at speed, the only fallback may be to stop.