A backup model is only the beginning of recovery.

Use this guide to: identify the dependencies needed to deliver a working AI service.

Constructed planning exercise. The recovery target, task set and time allocations are AI Keeper assumptions. They are not a tested recovery result, vendor commitment or industry benchmark.

The task has to recover, not just the API

Imagine an internal document assistant. It reads approved documents, produces a structured answer with supporting references and sends uncertain questions to a human. It cannot modify source records or approve transactions. The team has a second model provider and assumes that changing the endpoint makes the service resilient.

That assumption leaves several questions open. Does the second provider receive the same permitted context? Does it return the expected structure? Do references still point to evidence? Can the application distinguish an uncertain answer from a successful one?

Define a bounded recovery goal

For this exercise, the owner chooses a 60-minute target from a confirmed primary-provider outage to a validated, limited service on the alternative route. It is a planning target, not a promise to users. During validation, automated answers pause and requests enter a visible queue or go to the existing human process.

The alternative route must preserve document access restrictions, source references and human escalation. It does not need identical wording. No new tools or broader permissions are granted during the switch.

The planned sequence totals 50 minutes, leaving 10 minutes within the chosen target. Those figures establish a testable budget; they do not show that the team can achieve it. A drill must measure the actual elapsed time, including handoffs.

Build the replay set before the outage

Use a fixed set of 100 permitted test tasks: 40 direct questions with an answer in one document, 30 requiring multiple supporting passages, 20 with insufficient evidence and 10 access-boundary checks. These counts are illustrative. A production set should reflect the workload and the consequences of failure.

Score factual support, required output fields, correct references and appropriate escalation. For access-boundary checks, the expected outcome is denial or omission of inaccessible material. Any unauthorized disclosure stops this exercise. The owner must set acceptance thresholds for the other categories before seeing the alternative's results.

Stress the dependency that is easiest to miss

Suppose the drill reveals that the application needs 20 additional minutes to repair a response-format mapping. The sequence becomes 70 minutes and misses the target by 10 minutes. Merely having valid backup credentials did not meet the service goal.

The next action is concrete: prepare and validate the mapping in advance, then repeat the drill. Do not erase a failed task from the test set simply to obtain a pass. Record whether the queue is recoverable, whether duplicate work is prevented and whether the human process can handle the interruption.

Keep an honest fallback decision

A second provider is useful only if the complete route has been exercised with the required data controls and output checks. If the alternative cannot meet those conditions, the defined fallback may be a smaller service or a human process. The label “backup” should describe demonstrated behavior.

Keep a short drill record: scenario, owner, configuration, task-set version, measured time, failed checks and corrective action. Revisit it when the workflow, model or permissions change. The useful result is evidence about recovery, including the limits.

Trace the wider supplier dependencies ↗