Human Fallback Gap Self-Assessment
When AI is good enough that people stop doing things manually, the manual capability atrophies. Find out how far that has gone in your organization.
This is the AI failure mode that gets worse the more successful your AI adoption is. The better the AI performs, the less frequently humans practice the process it replaced — and the faster that manual capability disappears. The obligation is to either preserve the fallback capability or explicitly accept, document, and govern the decision not to.
Identify What Depends on AI Today
List the operational processes in your organization that now depend on AI, commercial LLM APIs, self-hosted models, or AI features embedded in SaaS platforms (Microsoft 365 Copilot, Salesforce Einstein, ServiceNow AI, and similar).
Start with the ones that, if they failed at 2 AM, would generate a call from the CEO by 6 AM. A complete inventory is a later-phase objective — this table is a starting point, not a finished register.
| AI-Augmented Process | Manual Fallback Exists? | Last Practiced (Date) | Owner | |
|---|---|---|---|---|
Part 1 is not scored. It is a mapping exercise. Most organizations complete it and discover the list is longer than expected. That discovery is itself the output. Part 2 scores how much manual fallback capability remains for your highest-impact dependency.
Eight Questions About Your Highest-Risk Process
Choose the single process from Part 1 with the greatest business impact if it failed. Answer the following questions about that process specifically — not your AI program in general.
We can name, specifically, which operational processes now depend on AI rather than human judgment or manual execution.
For our highest-impact AI-dependent process, a written (not just remembered) manual procedure exists.
That written procedure has been executed end-to-end, not just reviewed, within the last 12 months.
The person(s) who used to perform this process manually are still with the organization and still capable of doing so.
If that person were unavailable during an incident, someone else could execute the fallback from documentation alone.
We have a defined, specific trigger (not a judgment call made under pressure) for when to switch from AI to manual fallback.
We have a defined process for validating that a restored AI service is producing correct output before fully resuming dependency on it.
Someone is named and accountable for monitoring AI output quality on an ongoing basis, not just assumed to notice if it degrades.