Edition 4 · 06 / 06
Tomorrow, Your Model Is Gone
A practical 30-day exercise for testing how an organisation would cope if its primary AI model became unavailable tomorrow.
This is a short exercise, not a prediction. Gather the people who own the service, security, operations, procurement and the underlying business process. Then start the clock.
09:00 Monday
Your organisation’s primary AI model becomes unavailable. You do not know when, or whether, it will return. A notice may eventually explain the cause. That does not restore the service.
The question is not whether somebody can change a configuration variable. It is whether the organisation can still deliver the underlying business outcome safely.
09:05 — What is affected?
Can you identify the internal services, customer journeys and third-party products that depend on this model? Do you know which customers, decisions and commitments sit behind them?
This is where Third-Party Shadow AI matters. Your own system may be visible. A supplier’s model dependency may not be. Ask which underlying models it uses, which fallback providers may receive your data and how the supplier would tell you that material behaviour has changed.
10:00 — Can the service fail safely?
Can the AI function be disabled without disabling the entire product? Could the service keep the case, present a clear delay or fall back to deterministic rules? Is there an action that must not be taken if the model cannot meet the established standard?
Safe degradation is often more valuable than an untested automatic route. A system that tells a customer it cannot complete a request is sometimes better than one that completes it with unvalidated behaviour.
13:00 — Is the alternative real?
Is another model already integrated? Has it passed representative evaluations for structured outputs, tools, safety, latency and the actual work? Can the organisation use it under current data, security, commercial and geographical controls?
An endpoint in a diagram is not yet a fallback. It becomes one only when there is current evidence that it can carry the service.
End of day — What happens without automation?
Name the manual process. Who does it? Where is the procedure? What information and authority do they need? How much volume can they absorb, and what must be postponed or paused?
This is the connection to AI capability debt. If automation has removed the people, practice and evidence that once supported the process, a model incident can become a business-continuity incident rather than an engineering incident.
Day 2, Day 7 and Day 30
As time passes, the dependency becomes more visible. By Day 2, can people absorb the workload without unacceptable delay or error? By Day 7, which service levels, customer commitments, revenue processes, regulated activities and internal operations are at risk? By Day 30, can the organisation still provide the underlying capability?
Use this sequence to make the questions concrete.
- Do you know which services, journeys and customers are affected?
- Can AI functionality be disabled without breaking the wider product?
- Is there a validated alternative model, not merely another endpoint?
- Can people absorb the workload, and with what quality or delay?
- Which SLAs, contracts or regulatory commitments are now at risk?
- Can the organisation still deliver the underlying business capability?
Read the result without false precision
The exercise does not need a numerical score. It should create an honest category for the service.
Resilient means a validated fallback exists and the human or business-continuity route has been tested.
Exposed means alternatives exist, but meaningful recovery requires intervention, evaluation or approval.
Dependent means the critical capability is inseparable from the incumbent model or supplier, with no credible route to continue the underlying work.
These categories are not permanent labels. They are a starting point for deciding what to preserve, test, contract for or communicate to customers.
The model does not need to disappear forever to expose the dependency. It only needs to disappear for longer than you can operate without it.
The question to keep
The model may remain the right technical and economic choice. This edition has not argued that every service should have a hot multi-provider architecture. It has argued for a deliberate decision: understand the behaviour on which the service depends, set a proportionate recovery objective and retain the evidence and capability needed to meet it.
If your model disappeared tomorrow, how long would it take to get your business back?