Your AI Vendor Can Vanish Overnight: The Summer That Proved It

An 18-day frontier-model outage, slipped launches, and corporate bans — this summer proved model access is a vendor dependency. The continuity framework.

Illustration of a severed link between a cloud and a workflow tile with a dashed failover path to a glowing local server

This summer, businesses that had built workflows on Anthropic's newest frontier model got an involuntary lesson in dependency: US export controls took the model offline for roughly eighteen days. It returned in early July with new security controls — and, days later, a changed billing structure moving access to usage credits for many subscription tiers. In the same stretch, Google's flagship launch slipped past two announced dates, and Alibaba reportedly classified a major AI coding tool as high-risk software and cut employee access to it. None of these were failures of the technology. All of them were interruptions of access — and access is the part your business actually depends on.

The dependency nobody wrote down

Most companies treat AI models the way they treat the weather: ambient, assumed, and nobody's responsibility. But the moment a model sits inside a revenue workflow — the intake pipeline, the drafting process, the support queue — it is a vendor dependency exactly like your ERP or your phone system, with one difference: it can change or disappear with far less notice. Models get deprecated on a schedule you don't control, repriced mid-year, rate-limited during capacity crunches, restricted by your own counterparties' policies, and — as of this summer — switched off by governments. "The model went away" is now a documented business continuity scenario, not a hypothetical.

The continuity framework

Inventory the dependency. Which workflows call which models, through which contracts, at what monthly spend, with what business impact if they stop? If that table doesn't exist, that's the first finding.

Abstract the connection. Workflows should call a routing layer, not a hard-coded model. Swapping providers should be a configuration change measured in hours — not a re-engineering project measured in quarters.

Name the fallback before you need it. For every dependent workflow, designate a second model — different provider, ideally different jurisdictional exposure — and actually test the workflow against it. A fallback you've never run is a hope, not a plan.

Keep a floor you own. For workflows that genuinely cannot stop, an open-weight model on your own hardware is the only tier immune to deprecation, repricing, and export policy. It may be the third-best model in your stack — but it's the one nobody can take away, and "degraded but running" beats "down" in every continuity plan ever written.

Re-verify quarterly. Model versions, prices, and terms now change faster than annual vendor reviews can track. Continuity posture goes on the quarterly roadmap like everything else.

The uncomfortable question

If your most AI-dependent workflow lost its model tomorrow morning, who in your company would know by lunch, and what would they do by Friday? If the answer involves shrugging, that's the gap. Mapping model dependencies is part of the AI readiness assessment; maintaining the routing, fallbacks, and quarterly re-verification is standing work inside Managed AI Operations. Book a briefing — preferably before the next eighteen-day surprise, not after.