The incident whose root cause was a model update you never shipped

A principal engineer at a media analytics company told me about an incident that broke their mental model of incidents. Their AI feature had been stable for months, and one Tuesday it started producing noticeably worse output. The team went through the usual investigation, looking for what they had changed, and the answer was nothing. No deploy, no prompt edit, no config change, no data shift they could find on their side. Eventually they discovered that the model provider had rolled out an update to the model, and the update had shifted its behavior in a way that broke an assumption their feature relied on. The root cause was a change they did not make, to a component they did not control, that they had no way to see coming.

A dependency that changes itself is a new kind of dependency

Incident response has an unspoken assumption, that the cause is somewhere in the system you control. Something you deployed, something that failed, something that changed in your environment. The five-whys, the change log review, the search for the recent diff, all of it assumes the cause is yours to find, because in most systems it is. Your dependencies are versioned, they change when you upgrade them, and an upgrade is a change you made.

A hosted model does not behave like that. The provider can update it underneath you, on their schedule, without your action, and the update can change the model’s behavior in ways that affect your feature. This is a dependency that changes itself, which is close to unheard of in traditional software, where a library you pinned stays pinned until you move it. When the model shifts, your feature can break with no corresponding change on your side, and your entire incident process, tuned to find the internal cause, comes up empty, because there is no internal cause. The change was external, invisible, and outside your control, and it still broke your feature.

The trap is how long the investigation takes to consider this. The team spends hours looking for what they changed, because that is where causes live, and this cause is not there. They exhaust the internal search before anyone thinks to ask whether the model moved, partly because most teams do not track the model version well enough to notice that it did. The delay is not incompetence. It is an incident process that has no box for a dependency that updates itself.

Treat the model as a changing dependency

The lesson is that a hosted model is a dependency that can change without you, and your operations have to account for that, both to detect it and to respond. The model shifting has to be a first-class possibility in your incident process, not a discovery you stumble into after hours of looking inward.

What teams do to handle a model that changes underneath them.

Track the model version and detect when it changes, so a provider update is visible rather than a mystery.
Add “did the model change” to the incident checklist, so on-call considers the external cause early, not last.
Run an ongoing evaluation that would catch a behavior shift, so a model update that degrades output pages you before customers do.
Pin to a specific model version where the provider allows it, so updates happen on your schedule and become a change you made.
Have a plan for the day the model changes and you cannot stop it, including fallbacks and prompt adjustments to absorb the shift.

The model changing is not a rare edge case, it is a standing property of building on a hosted model, and the teams that operate these features well plan for it instead of being ambushed by it.

How we approach it at Density Labs

The incident with no internal cause is one of the most disorienting things a strong team runs into with AI features, precisely because it violates the assumption underneath all incident response. They look for what they changed, they find nothing, and the real cause is a model update they did not make and could not see. Hours go by before anyone thinks to look outside their own system.

Our AI Opportunity Assessment is a fixed two-week engagement, priced at $2,500, that scopes the real work of shipping an AI feature. Part of that is treating the model as a dependency that changes itself, tracking its version, watching for behavior shifts, and planning for the update you did not schedule, so a model change is a known risk you manage rather than a surprise that eats an afternoon.

Most incidents are caused by something you changed. With a hosted model, some are caused by something that changed itself, and your process has to know that is possible.