Graceful Degradation for AI Products: Stay Useful Without Inventing

A conventional product often displays an error when its main service fails. An AI product can fail more deceptively: it still answers, but without the right source, with stale memory or after a silent tool failure. Graceful degradation must cover both availability and decision quality.

Six causes to prepare for

1. Model unavailable or too slow.
2. Missing, stale or conflicting source.
3. External tool failure.
4. Insufficient or revoked permission.
5. Output that violates a rule.
6. Confidence too low for the expected impact.

These situations should not all produce the same response.

Five product responses

Limit

Provide only the verifiable part. Show available facts without generating a recommendation they no longer support.

Ask

Request one missing item or resolve an ambiguity that would change the decision.

Queue

Preserve context, state the expected delay and assign recovery when a dependency should return.

Hand off

Give a person the sources, attempts, failure and expected action. A handoff without context merely moves the cost.

Suspend

Do not act when risk or irreversibility exceeds the approved scope. “I cannot verify this” is a safety feature.

Build the degradation canvas

For each capability, document:

• normal operating condition;
• the signal that the condition is no longer met;
• the action still allowed;
• the user-facing message;
• the context retained for recovery;
• owner and deadline;
• the signal for returning to normal;
• the full-stop criterion.

Keep this canvas close to product and operations, not in a forgotten policy document.

Avoid false fallbacks

Automatically switching models may improve availability, but it is not automatically safe. A backup model can have different capabilities, processing terms or behavior. Evaluate it on the task and identify it in the trace.

Likewise, using cached data without displaying its date creates apparent continuity at the expense of truth.

Test it as a user journey

Deliberately disable a source, revoke a permission, inject a non-compliant output and slow an integration. Verify that:

• the product detects the condition;
• the message does not promise normal operation;
• no prohibited action is sent;
• useful context is preserved;
• recovery does not duplicate the action;
• a person can understand the incident.

Measure fallback quality

Track frequency by cause, time in degraded mode, prevented actions, recovery time, duplicate executions and degradation discovered after the fact. Add a business metric: cases actually resolved or users able to continue.

Fact, inference and hypothesis

Direct fact: a technically generated answer can still be incorrect or unauthorized.

Inference: explicit degradation protects trust better than artificial fluidity.

Hypothesis to test: clearly disclosing limited capability harms retention less than an incorrect answer discovered later.

FAQ

Is switching to another model enough?

No. Compatibility, permissions, quality and business effect must be verified, and the change should be observable.

Is manual mode always available?

Only when a person, deadline and recovery context exist. Otherwise “go manual” is an empty promise.

Should users be notified every time?

When degradation changes quality, freshness, timing or authority, the difference should be visible and proportionate.

Next step

Complete the graceful-degradation canvas for your most important AI capability and run one failure test this week. For a review of the scenario and recovery path, email contact@yumea.fr with the subject “GRACEFUL DEGRADATION.”