Run a 30-Minute AI Dependency Audit Before Your Next ChatGPT Outage

The outage is the audit

The moment that matters is when a model disappears and the team has to decide what the customer sees. In that minute, someone has to choose whether to degrade the feature, route the work to humans, or communicate the gap. The question is not whether the API is back. It is whether your product can still do the thing it promised, and whether the message you send does not sound like a panic memo.

A short AI dependency audit is the tool for that moment. It is not a security review. It is not a vendor negotiation. It is a working map of where your company is coupled to third-party intelligence and what happens when that coupling fails.

The recent outage made the point plainly. The outage began around 17:00. Users reported that the outage prevented use of both the website and mobile app. ChatGPT and Codex were reported as affected. OpenAI said it had applied corrective measures and was monitoring recovery, while Claude's status indicated that affected models included Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8, and Opus 4.6. OpenAI's ChatGPT was reported as the first service to return to normal operation. It is not the drama. If your product, support workflow, or internal ops lean on a model that can disappear from a status page, you need to know what the customer sees, who can switch, and whether the fallback has been run before the customer asks.

Run the audit in five fields

Do not start with a spreadsheet of every prompt. Start with the customer. For each place where an LLM touches a user, a support agent, a sales rep, or an internal operator, record five fields. The goal is to finish a pass that tells you what the customer sees, who owns the gap, and whether the fallback has been tested.

You do not need a war room. You need a short, repeatable pass. The goal is to surface the dependencies that matter, not to catalog every clever prompt in the codebase.

1. Customer impact. Map the customer-facing surface. List every feature where a model generates, summarizes, classifies, drafts, or routes customer-visible output. Include support macros, sales outreach, onboarding, search, and internal tools that eventually affect customers. For each item, write what the customer sees when the model fails: what breaks, degrades, or becomes slower; whether the user is blocked, delayed, or receiving lower-quality output; and whether the failure is visible to the customer or only to your team. If the answer is 'nothing,' verify it. If the answer is 'a generic error,' improve it. If the answer is 'we do not know,' that is the first thing to test.
2. Fallback. Record what happens when the model is unavailable: a human queue, a cached response, a reduced feature, a manual review, or a polite delay. If the fallback is 'we will try again,' that is not a fallback. The fallback should be clear enough for a deputy to run if the owner is unavailable.
3. Owner. Assign one person who can make the call to switch, pause, or communicate. Not a team. Not 'engineering.' A name. The owner should be able to decide whether to degrade the feature, route to humans, or pause the workflow.
4. Status message. Write the exact message shown to customers or agents when the feature is degraded. Do not wait for the outage. A good message names the affected feature, says what still works, and gives a next step. It should be calm, specific, and not promise a time you cannot keep. It should not sound like a press release or a confession.
5. Last test date. Record when you actually verified the fallback works. Not when you wrote it. Not when you discussed it. When did you run it? For high-impact manual fallbacks, run a realistic scenario: model unavailable, customer asks, agent responds. Time it. Note where the process stalls. If you cannot remember when you tested it, treat it as untested. The date is not bureaucracy. It is the difference between a fallback and a hope.

The point is not to create a document that impresses an investor. The point is to create a document that lets a tired support lead make a decision at the worst possible time. If the model is down, the team should not be debating whether the fallback exists. It should be executing it.

There is a simple triage rule. If customer impact is high and the fallback is manual, schedule a test within a week. Manual fallbacks are where outages become incidents. They require people, judgment, and speed, and they are the first thing that breaks when volume rises.

The audit should be short enough to finish in one sitting and specific enough to act on. If it takes longer, you are probably auditing the model instead of the dependency. The model is not your problem. The coupling is.

It is the ability to say what the customer sees, who can switch, and whether the fallback has been run. The calm choice is to degrade, route to humans, or communicate, and to make it before the customer asks. That is the payoff: a decision made at the moment of failure, not a scramble after the customer notices.

It also keeps the decision from becoming a group argument. The owner can say what the customer sees, what still works, and what happens next. The status message can be calm because it was written before the outage. The fallback can be trusted because it was tested, timed, and noted for where it stalls. In that moment, the team is not discovering the dependency; it is executing the choice.