You need to know whether your business simply uses that tool or whether the whole process now depends on it. Those are very different levels of risk.
There is an understandable reaction whenever a popular AI product has a bad day: people discover how much of their work has started to depend on it. A draft waits. Research stops. A customer response takes longer. Somebody checks a status page and carries on when the service comes back.
For many teams, that is not a crisis. It is exactly what happens when any useful third-party product becomes temporarily unavailable.
The more interesting question is what happens when the unavailable product is no longer just a tool somebody opens, but the only route through a business process.
The outage is not really the point.
A vendor outage is simply one easy way to expose a dependency that was already there. The same weakness can appear through usage limits, account restrictions, model changes, changes to the provider's connection, pricing changes, worse output quality or a feature being removed.
If a process only works because one particular product behaves a certain way, your business has become dependent on choices made by that provider.
Sometimes that is a perfectly rational trade-off. A small team using an AI assistant to help draft internal emails probably does not need a complex backup setup across several AI providers. The cost of an outage is low, the task can wait and the fallback is obvious: write the email normally.
But the calculation changes when AI sits inside customer service, lead handling, document processing, internal decision support or another process that is expected to keep moving without somebody manually rescuing it.
A tool and a system are not the same thing.
A tool is something your team chooses to use. A system is something the process expects to be there.
That distinction matters more than whether the AI is “custom”. A custom interface that still sends every request to one AI provider, with no checks, waiting queue or backup route, is still a single point of failure. It may look more custom, but the dependency has not disappeared.
A stronger system keeps several concerns separate:
- Current job record: the customer, case, task, transaction or document the process is actually about.
- Business information: what the AI needs to know for this specific job.
- Business rules: what the system is allowed to do, what must be checked and what requires approval.
- System access: CRM, email, calendar, database and other actions.
- AI service: the part doing the language or reasoning work, ideally kept replaceable rather than tied permanently to everything around it.
Interface dependency
The process only works because a person knows which AI website to open and what to type into it.
Model dependency
The application exists, but every critical path assumes one provider will answer successfully.
Context dependency
Important knowledge, instructions or the current job information live inside the AI provider instead of systems the business controls.
Where single-provider dependency hides.
The obvious version is an employee who cannot continue until their AI chat tool comes back online. The less obvious version is an automated workflow that looks independent because nobody is opening a browser, but still has one fixed AI dependency sitting in the middle of the process.
Imagine a lead intake system. A form arrives, AI reads the enquiry, classifies it, drafts a response and updates the CRM. If the model call fails and the entire workflow simply stops, the automation has moved the dependency out of sight rather than removed it.
A live business system should know what to do when the ideal path is unavailable. That does not always mean switching instantly to another AI provider. Retrying may be enough. The request could be held until it can retry. A simple fixed rule could handle the straightforward cases. The system could create a task for a person instead of sending anything automatically.
Resilience is not “always have another AI provider”. It is having an intentional failure path.
The setup to aim for.
The useful design principle is simple: keep the business process in software you control and call on AI only when AI is useful.
The lead, customer, case, document or operational task exists independently of the AI provider.
The relevant customer records, knowledge, history and permissions are brought together for this job.
Decide when to use AI, check the response and choose the next action.
One provider may be preferred, but the surrounding business process does not live inside it.
CRM updates, drafts, messages or escalations happen under explicit permissions.
This also makes model changes less dramatic. If a better provider becomes available, you are swapping one part instead of redesigning the business process around a new product.
It also makes AI easier to remove from the places where it was never needed. A lead with a known customer ID and a simple account-update request might be handled with ordinary rules. There is no prize for using AI when a fixed rule can do the job more reliably.
AI where it earns its place. Normal software everywhere else.
If you are trying to work out how a business workflow should be structured, start with the workflow rather than choosing a model first.
When one AI tool is completely fine.
Not every dependency deserves extra complexity. If your team uses an AI product for optional research, brainstorming, drafting or ad-hoc analysis, a temporary outage may be nothing more than an inconvenience.
Building backup systems around every piece of software would be expensive, unnecessary and, in some cases, less reliable than simply accepting the occasional interruption.
A useful test is to ask:
- Does a customer experience fail if this is unavailable?
- Does money, compliance, safety or a critical deadline depend on the result?
- Can a person continue the process without specialist knowledge?
- Can the request safely wait and be retried later?
- Is the current job information stored somewhere outside the AI provider?
The more serious the consequence, the less comfortable you should be with an invisible single point of failure.
A practical resilience checklist.
The AI should receive the context it needs, not become the only place that context exists.
Retrying later, holding the job in a queue, using a backup route, following a fixed rule or sending it to a person are all valid answers.
Especially before external messages, money movement, deletion or sensitive account changes.
A capable model does not need broad write access to every connected system.
If something fails or behaves unexpectedly, you should be able to see the AI request, the checks that ran and the resulting action.
You may never need to switch. The value is keeping the whole business process from being trapped inside one provider's product.
The better question to ask.
“What happens if ChatGPT goes down?” is useful, but it is narrower than the real design question.
A better one is: “What happens when any part of this process is unavailable, wrong or slow?”
That question forces you to look at the whole system: the data, the rules, the model, the tools, the people and what happens when something goes wrong. It is the difference between simply adding AI and building the process to cope with real-world problems.
Use the best model or product for the job. Just do not confuse that product with the business system itself.