An international operations team monitoring a connected city at dawn as a network disruption is routed around, representing AI continuity and operational resilience

If your AI stopped tomorrow, could your business still operate?

SIMPLEX INSIGHTS · AI GOVERNANCE & OPERATIONAL RESILIENCE

Imagine tomorrow morning. A customer-service assistant cannot reach its model. An overnight coding agent has exhausted its budget. A workflow is waiting for a tool it can no longer access. The team knows how to use these capabilities—but nobody is certain which business activities depend on them, what was completed, or how to continue safely without them.

This is not a prediction of a particular outage. It is a practical question about the operating model we are building around AI: when an intelligent service becomes a dependency, are we managing it like one?

AI adoption is accelerating. Operating maturity must keep pace.

In McKinsey’s August 2026 State of AI survey, 40% of respondents from large organisations reported scaling AI agents in at least one function. McKinsey also reported that 80% of respondents saw improved individual productivity, while 37% attributed a positive impact on organisational EBIT to AI. Those figures are not outage statistics; they highlight that widespread adoption and enterprise-wide value are different achievements.

A separate McKinsey analysis on scaling agentic AI argues that organisations need to redesign the underlying work, ownership, technical foundations and governance—not simply add agents to existing processes. That observation matters for resilience as much as it does for productivity.

For many organisations, the question is shifting from “Can AI help us?” to “Which parts of our operation now assume AI will always be there?”

The dependencies are often larger than the model

An AI-enabled process can rely on several things at once: a model provider, an integration, a budget, permissions, data quality and the context accumulated along the way. A failure in any one can stop the whole process—or, more dangerously, leave it partially completed.

  • Model or provider availability: What happens when a service is unavailable, degraded or withdrawn?
  • Usage and cost limits: Can a quota, token budget or unexpected consumption halt a business-critical activity?
  • Access and integration: What if an agent loses permission to a repository, customer system or operational tool?
  • Context and evidence: Can the organisation recover task state, relevant conversation history, decisions and the audit trail needed to resume responsibly?
  • People and process: Does anyone know how to take over, reverse or safely defer the work?

A second model provider may help with one part of this problem. It is not, by itself, a continuity plan. Switching models does not automatically restore missing context, interrupted transactions, revoked credentials or unclear accountability.

Agents raise the stakes

A chatbot that stops responding is frustrating. An agent that can initiate actions across several systems requires a different level of operational discipline. It may already have created a ticket, changed a configuration, written code or initiated a workflow before a later step fails.

A resilient agentic workflow therefore needs more than a retry button. It needs defined permissions, a record of what has happened, approval or escalation points, safe re-execution rules and a way for a person to intervene. Otherwise, restarting the workflow can compound the problem.

Five questions worth asking before the next rollout

  • 1. Can we see our AI dependencies? Which important workflows use AI, which providers and tools do they depend on, and who owns them?
  • 2. What continues when AI stops? Is there a manual route, a controlled pause or a fallback with an acceptable level of service?
  • 3. Can we recover the work—not just the service? Can we restore task state, authorised context, evidence and the last trustworthy step?
  • 4. Who is allowed to intervene? Is there clear accountability for disabling an agent, approving recovery and communicating with affected teams?
  • 5. Have we actually tested this? Could we demonstrate the response and recovery process rather than simply point to a policy?

These are ordinary reliability questions applied to a new class of dependency. Google’s Site Reliability Engineering guidance emphasises testing failures, designing graceful degradation and defining reliability in terms that matter to users. The same principles are useful when an AI capability becomes part of a business-critical service.

Governance needs to work on an ordinary Tuesday

The NIST AI Risk Management Framework organises AI risk activities around Govern, Map, Measure and Manage, with governance extending across the full lifecycle. It also describes risk management as continuous rather than a one-time checklist.

That is a useful standard to hold ourselves to. A policy that no one can translate into operational decisions offers limited protection. A recovery plan that has never been exercised is still largely an assumption.

The test of AI maturity is not only what an organisation can automate. It is also what the organisation can understand, control and recover.

A small exercise you can run this week

Choose one important AI-assisted activity—perhaps customer support triage, software delivery or internal knowledge retrieval. For a short, controlled exercise, assume the external model or one critical agent tool is unavailable for half a day.

Ask the process owner to walk through what happens next. Identify what is paused, what continues, who decides, how incomplete work is detected, and what information must be recovered. Write down the gaps and test the most important fixes.

You do not need a large transformation programme to begin. You need visibility into one real dependency and the discipline to close what you discover.

From readiness to ongoing control

At Simplex, this is why we view AI readiness as a continuing process rather than a single assessment score. Our Meridian approach follows a repeating cycle: Identify → Establish → Implement → Monitor → Evolve. Assessments help establish an evidence-led baseline; the next steps are to improve controls, test their effectiveness and reassess as technology and business needs change.

We are developing Meridian technology to support that longer-term operating model. The immediate starting point is straightforward: understand where you stand, which dependencies matter, and what deserves attention first.

Could your organisation operate through an AI interruption?

A Meridian Readiness Assessment can help identify AI dependencies, governance gaps and practical priorities across strategy, engineering and operational controls.

Further reading and sources

Simplex Insight · Published 25 October 2026. This article provides general operational guidance, not an assessment of any particular organisation or provider.