AI risk #45/99: Your critical suppliers now share a supplier you have never met

Late on the evening of 3 September, Australian time, Claude stopped answering. Grok followed about twenty minutes later, and ChatGPT just after midnight. Claude and Grok were down for more than three hours each, ChatGPT for about two. Each company gave a different reason, and the shared infrastructure underneath them reported nothing wrong all night.

You did not have to be using any of the three to feel it. A payroll platform, a help desk, a developer tool or a meeting-notes service with one of those models running underneath stopped when the model did, and the supplier list gave no clue why. The AI vendor was never on it. Nobody had signed a contract with it, so nobody had asked what would happen when it went away.

The supplier you never signed with

Cursor showed how the chain works. The coding tool, used by a large number of software teams, confirmed its own outage that morning and put it down to Claude and Grok failing upstream. Its customers had never dealt with either vendor. They had bought a coding tool, the coding tool had bought a model, and when the model went down the tool went with it.

SpaceXAI, which runs Grok, put out a short apology afterwards. It was addressed to Grok users, and then added a second group: "We'd also like to apologize to our impacted compute partners." SpaceXAI did not say who those partners were. Whoever they are, they run on the same compute, and their customers sit one step further away again. Elon Musk said the company was "taking corrective action to ensure this does not happen again". The apology is worth noticing for who it was aimed at: businesses two steps removed from the fault, whose own customers would never have connected the two.

This is an old line on the register

Supplier dependence is not a new risk. Most registers have carried it for years under a name like critical supplier failure, owned by operations or procurement, with a safeguard that reads something like "contract in place, second supplier identified, business continuity plan tested". Every part of that safeguard assumes three things: that you chose the supplier, that you can name it, and that your suppliers fail one at a time.

AI has changed the driver under all three. A supplier nobody chose now sits inside most of the suppliers you did. It is not on any contract you signed, so it is not on the list. And these particular suppliers fail in public and in overlapping windows, so a bad afternoon for one is a bad afternoon for a whole shelf of your operations. The second supplier you identified does not help when it runs on the same handful of models as the first.

Regulators had already said as much before 3 September. In its letter to industry on AI in April, APRA wrote that "AI capabilities are increasingly embedded within software, platforms or developer tools", which "can mean upstream dependencies such as foundation models, training data sources and fourth party service providers are opaque". It asked regulated entities to be "mapping and maintain visibility over the full AI supply chain, including material, third-party and fourth-party dependencies". That is regulator language for a plain business fact: the AI inside the products you buy is a supplier you did not pick, with a failure mode you have not assessed.

For regulated businesses, it is now a contractual question

For Australian banks, insurers and super funds, this stopped being only a register question on 1 July. The updated CPS 230 commenced that day, and with it the transition period for existing supplier contracts closed. A supplier that a critical operation depends on is a material service provider, and the standard expects you to manage the risk from the suppliers behind it too. APRA's April letter also asked for "ongoing consideration of third-party and concentration implications in relation to common platforms, services, and providers". Three vendors, three hours, one evening: 3 September was the worked example.

Outside financial services nobody is going to write to you about it. The register still should.

What a supplier review needs before the next one

There is one question worth adding to the next supplier review: which of our suppliers has AI inside it, and whose is it? Not whether the supplier uses AI. Whose.

Then three moves, none of which needs a technologist.

Name the AI inside each critical supplier. Ask them in writing which model vendors they depend on, and what happened to their service on 3 September. The ones who cannot answer quickly have told you something useful.

Write down what happens when it stops. For each critical operation, what is the manual path, how long can it run, and who decides to switch to it? On 3 September the answer in many teams was "wait", which is a plan only if it is written down and everyone knows it.

Re-score the supplier line. It was set for a world where your suppliers failed independently and one at a time. Score it for a world where three of them can fail in the same three hours, each blaming something different, and where the supplier you depend on most is one you have never met.

If you would rather have that question asked across the whole plan than the supplier list alone, the AI Disruption Index takes about ten minutes and costs nothing: it scores the risks AI is driving against your objectives, ranks them, and drafts a safeguard for each. It cannot tell you which of your suppliers runs on which model. It will show you where else in the plan the same dependence is hiding.