AI Disaster Recovery: A Business Continuity Checklist.

How does AI disaster recovery support business continuity?

An AI assistant might update customer records, create bookings or send messages. What happens if it makes the wrong changes for an hour before anyone notices? Switching it off may stop further damage, but the business still has affected customers, uncertain records and unfinished work.

Teams need a second question alongside testing the normal workflow: if this fails, how do we get back to a state we can trust? Disaster recovery is the work of restoring systems and data after serious disruption. Business continuity is how essential work carries on during that recovery. An AI workflow needs both.

This is different from a single failed step that can be retried. The concern is a wider loss of trust: damaged data, unavailable services, unreliable answers or actions whose outcome nobody can establish. The recovery plan should match the possible business impact.

How many businesses are missing the recovery piece?

There is no defensible single percentage for every business. There is, however, relevant evidence of a preparedness gap. In research released on 16 September 2026, Cohesity reported that 56% of respondents said they were not well prepared to detect, contain and recover from unintended or incorrect actions by AI agents, copilots or workflows.

The same research reported that only 39% said their cyber response and recovery plans comprehensively covered attacks targeting AI systems. These are different questions: neither figure means the remaining organisations have no backups or no recovery plan.

Cohesity commissioned Vanson Bourne to survey 3,200 IT and security decision-makers in July 2026. Participants worked at organisations with at least 1,000 employees across 12 countries, including Australia. These are vendor-sponsored, self-reported enterprise findings, not a measurement of recovery failures or a representative estimate for Australian small businesses.

• Cohesity: Global Cyber Resilience Report findings and methodology, 16 September 2026 ↗

Replit: the recovery feature existed, but the agent did not know it

In its 29 July 2025 account, Replit acknowledged that its coding agent deleted database data from an app being built by SaaStr co-founder Jason Lemkin. Replit said he eventually restored the database fully using rollback, while the agent had been unaware that the recovery feature existed.

Replit also described separating development and production databases by default. Its account explains that the earlier setup allowed development changes to affect the production application.

The lesson for a business owner is practical: identify the documented recovery method, who can use it and what it actually restores. Test it separately from the assistant’s advice. An AI-generated explanation of why recovery is impossible is not a substitute for checking the platform’s recovery controls.

• Replit: database incident, rollback and environment separation, 29 July 2025 ↗

Anthropic: the service can be available while the answers get worse

In a postmortem published on 17 September 2025, Anthropic described three infrastructure bugs that intermittently degraded Claude responses between August and early September. One issue caused output corruption; Anthropic reported rolling back the responsible change on 2 September and adding detection tests.

This was a response-quality incident, not a reported database deletion. It illustrates another recovery question: how will you notice that the AI is producing unsuitable results even when requests still complete?

Keep a small set of approved business checks and a safe fallback. That may mean routing work to people while investigating. Changing to another model or provider can also change behaviour, access arrangements and costs, so it needs its own validation rather than an automatic assumption of equivalence.

• Anthropic: A postmortem of three recent issues, 17 September 2025 ↗

Atlassian: a backup is not the same as a fast business recovery

Atlassian’s April 2022 outage was caused by an operational script, not AI. Its post-incident review reports that 775 customers lost access, with disruption lasting up to 14 days for some. Atlassian said no customer lost more than five minutes of data.

Its review explains that restoring individual data stores was possible, but coordinated recovery of many customer sites and their connected products was not sufficiently automated for that event. It met its data-loss objective but missed its recovery-time objective.

For AI workflows that connect several services, the lesson is to practise restoring the whole business task. Recovering a database alone may leave permissions, linked records or queued work out of step. This historical example illustrates recovery complexity; it is not evidence of a current Atlassian defect.

• Atlassian: Post-Incident Review on the April 2022 outage, 29 April 2022 ↗

What an AI recovery plan needs to cover

Map the complete task: the AI service, workflow instructions, approved knowledge, connected tools, access permissions and final business records. Include pending work and records of actions already completed. If your AI retrieves company documents, plan how those documents and the searchable knowledge store can be restored consistently.

Agree two business limits in plain language: how long essential work can be unavailable, and how much recent data the business could afford to lose. Engineers may call these recovery time and recovery point objectives. Write down the targets, then measure them during an exercise; targets are not evidence of achieved recovery.

Protect recovery access and backups so that the same compromised or mistaken agent cannot erase the route back. Use the controls your platforms support, with an authorised owner responsible for keeping them usable.

• A named person who can pause the workflow, stop new work and control pending actions.
• A fallback for essential work, such as an agreed manual review process.
• Protected, usable backups and saved workflow settings, with a known safe recovery point.
• A record of what changed and which outside actions already happened.
• Recovery access and contact details available even if the normal system is down.
• Clear checks and a named owner who approves the restart.

A simple recovery process to rehearse

Use this as a starting point for a scoped exercise. Your engineer or service provider should adapt it to the actual systems, permissions and business consequences. Preserve evidence and coordinate the response before making recovery changes.

1. 1. Stop the spread

   Pause harmful actions, scheduled work and automatic retries. Keep the evidence needed to understand what happened.

2. 2. Keep work moving

   Tell the responsible people and switch essential tasks to the agreed fallback.

3. 3. Restore a safe state

   Use the authorised recovery procedure. Reconcile completed actions and protect valid work created after the recovery point.

4. 4. Verify the result

   Check records, permissions, answers and pending work. Confirm the business task works without repeating completed actions.

5. 5. Resume carefully

   Obtain approval, restart with a limited scope and watch for recurrence. Update the plan with what the exercise exposed.

An example: the booking exists, but its confirmation is missing

Consider an invented booking workflow. It creates a booking, then loses its connection before recording success or sending the confirmation. A restored copy of the workflow thinks the request is still pending. Replaying it from the beginning could create a second booking.

The recovery exercise should check the booking service first, establish whether the booking exists and reconcile the pending request before allowing another create action. If the result remains uncertain, send it to an authorised person for review. Retry only the work that is safe and still needed.

A restored database also cannot recall an email that has already reached a customer. External actions may need correction, cancellation or a customer update rather than a rollback. Do not restore an old snapshot over valid new business data without an agreed reconciliation plan.

Test recovery without creating a real disaster

Start in an authorised sandbox with invented records and outbound actions disabled or simulated. Practise one interruption: an unavailable AI service, an unsuitable workflow update or a lost response after an action. Check whether the owner can stop it, restore safely and complete the task without duplication.

Capture what was restored, the recovery point, elapsed time, remaining gaps, failed checks and the decision to resume or stay paused. Include the business work waiting during the outage. Repeat after material changes to tools, workflow rules or providers.

A discussion exercise can reveal unclear responsibilities. A restore exercise tests whether the procedure actually works. Neither a completed backup job nor one successful exercise proves that every future incident is covered.

How VisiFlo can help you prove the way back

Bring one AI workflow and the business outcome you cannot afford to lose. VisiFlo can help identify failure scenarios, clarify expected recovery behaviour and agree a focused validation exercise with your engineer or service provider.

The useful result is a clear account of what can be recovered, what was actually tested, which actions need human reconciliation and what should improve first. Where implementation is agreed and access permits, we can help improve the controls and repeat the relevant checks.

The approach can apply to n8n, Make, Zapier, OpenClaw, Hermes, custom agents, APIs and web services. Feasibility depends on the actual setup and evidence available. Scope, access, responsibilities, timing and price are agreed before work starts. This article does not promise a recovery time or a managed emergency-response service.

• Download the AI recovery readiness checklist (editable Markdown) ↗