AI drafts the RTO/RPO tier proposal per workload class, then generates the failure tabletops that pressure-test it — region loss, quota exhaustion, provider outage, and the scenario most 2026 DR plans still miss: the LLM dependency going away mid-transaction. The architect owns the tiers, the business owns the numbers, and the tabletop finds out if anyone was right.
Tier: Core · Hands-on time: ~30 minutes
DR strategy is two documents pretending to be one: a policy artifact (which workloads get which recovery promises, at what cost) and an engineering artifact (how those promises are kept). AI accelerates both halves differently — structuring the tiering proposal from workload inventories, and generating adversarial failure scenarios with a chaos-engineer's imagination and none of the scheduling cost. The new material this playbook forces in: AI features have become production dependencies with failure modes traditional DR taxonomies do not name — model API outages, quota exhaustion that looks like degradation rather than failure, and region failovers into regions where the model or its capacity does not exist.
Skip AI when the org has never had the RTO/RPO conversation at all — the first pass is a business negotiation about money and risk appetite, and no draft should anchor it.
Draft the tier structure from the inventory. "From the attached workload inventory, propose a DR tier structure: 3–4 tiers, each with RTO/RPO ranges stated as placeholders for business sign-off, the recovery pattern that typically achieves it (backup-restore / pilot light / warm standby / active-active), and a relative cost indicator. Assign each workload a proposed tier with one-line reasoning citing its criticality and dependencies. Mark every workload whose dependencies span tiers — a Tier-1 app depending on a Tier-3 service is a finding, not a tiering." The cross-tier dependency flags are the draft's highest-value output; they are where real DR plans quietly fail.
Take the tiers to the business as questions, not answers. The draft's RTO/RPO placeholders become the negotiation agenda: what does an hour of this workload's absence cost, and what will you pay to shorten it? The architect brokers; the business decides; the signed numbers replace the placeholders. AI never touches this step — recovery objectives are purchased, not computed.
Design the patterns against verified reality — including the AI dependencies. For each tier, confirm the recovery pattern against what actually exists (the backup that runs versus the backup that is configured), and give AI dependencies explicit treatment: for each AI feature, what is its degraded mode (pb-45's ladder, if built), does the failover region have the model available with adequate quota — a claim to verify against provider documentation today, not assume — and is the gateway config itself recovered by the DR procedure? An AI feature whose "DR plan" is a region failover into a region without model capacity has a plan-shaped gap.
Generate the tabletop scenarios adversarially.
Generate 4 failure-tabletop scenarios for orbit-docs-copilot's DR
plan (attached: tier sheet, architecture summary, AI dependency
list). Requirements per scenario:
- A trigger with a realistic mechanism and timeline — not "the
region fails" but what observably breaks first, second, third.
- At least one scenario each for: full region loss; LLM provider
outage with our quota exhausted at the fallback provider; a
degradation that is NOT an outage (model latency 10x, error rate
creeping, responses subtly wrong after a provider model update);
and a failure during recovery (the DR runbook itself hits a
missing dependency).
- Inject points: 3–4 timed complications per scenario ("40 minutes
in: the status page says resolved but errors continue").
- Decision forks where the room must choose with incomplete
information, and what each branch costs.
- Do NOT include the answers. The plan under test supplies those or
fails to.
The degradation-not-outage scenario earns its mandatory slot: AI dependencies fail ambiguously — a 429 storm or a quality regression triggers no alarm that says "disaster," and plans keyed to binary failure never activate.
Run the tabletop with the real decision-makers. Facilitate against the clock: present the trigger, inject complications on schedule, force the forks, and record every moment the room reaches for a fact the plan should contain and doesn't — those gaps are the exercise's product. The AI's role ended at scenario generation; a human facilitates, because the room's confusion is data the exercise exists to collect.
Convert gaps to changes, and schedule the next one. Every gap becomes a plan change, a runbook fix, a monitoring addition, or an accepted risk with a name on it. Feed the fixed plan back through step 4 next cycle with fresh scenarios — tabletops repeat scenarios the way vaccines repeat strains, and last year's scenario tests last year's plan.
DR plans enumerate exactly what an attacker wants — critical systems, recovery paths, decision-makers — and BFSI regulators treat them as controlled documents. Draft and generate scenarios inside the approved boundary (client-tenancy endpoints, or local Ollama models — scenario generation is well within local-model range when the prompt carries the structure). The safest split: give the model a redacted architecture summary (roles, not hostnames; tiers, not team names) for scenario generation, and keep the real plan, runbooks, and contact trees entirely outside any prompt — injects reference "[TIER-1-PAYMENT-SERVICE]" and the facilitator translates live. The business negotiation and the tabletop room were always AI-free; the restricted variant costs this playbook less than any other in the area.
The business buys the RTO, the architect designs to it, and the tabletop audits both — with the LLM dependency scenario now mandatory, because a DR plan that has never imagined the model going away is a plan for the previous decade's failures.