There is a particularly uncomfortable sentence in enterprise AI:
“Nobody changed anything.”
The engineering team did not deploy a new release. The application code is unchanged. The prompt is unchanged. The configuration is unchanged. The system passed its last review. And yet, the AI is behaving differently.
The model provider upgraded the underlying model. A vendor retired an older version. A retrieval source changed. A third-party API changed its behavior. A model alias moved to another version. A dependency was updated outside your release process.
Nothing changed inside your deployment pipeline. Something changed in the system. That distinction is becoming one of the harder problems in AI governance.
The change nobody deployed
Imagine an NBFC has an AI system that helps classify customer complaints before they reach the operations team. It has been stable for months. Engineering has not touched the application. The prompt has not changed. The workflow has not changed.
Then the operations team notices that the system is suddenly routing more complaints into the escalation category. The first instinct is to ask what changed in the application. The answer is nothing. The model provider changed something upstream.
This is not an exotic possibility. AI providers already operate model lifecycles involving version upgrades, deprecations and retirements. Microsoft, for example, documents deployment configurations that can automatically move to newer model versions, including when an existing version reaches retirement. Google also supports model aliases that can point to different model versions over time.
These mechanisms are not inherently bad. Models improve, old versions become unsupported, security issues are fixed and infrastructure evolves. The governance problem is somewhere else.
Your organization may have approved one set of assumptions while the system is now operating with another. And nobody on your team necessarily made the change.
AI is not only what your engineers deploy
Traditional software change management works reasonably well when the organization controls most of the system. Code changes. Someone reviews it. Infrastructure changes. Someone approves it. A new release goes into production. There is a deployment record.
AI systems increasingly cross that boundary.
A production AI workflow may depend on a foundation model, retrieval system, external API, data source, embedding model, safety layer, tool, cloud service and several other components. Some are controlled internally. Others are controlled by vendors. Some change frequently. Some can change without a pull request appearing anywhere in your repository.
NIST's 2026 work on monitoring deployed AI systems highlights this growing complexity, including fragmented logging across distributed infrastructure, difficulty detecting degradation and drift, policy complexity, and the challenge of scaling human-driven monitoring as AI systems proliferate. That changes the question governance needs to ask.
It is no longer enough to ask:
Did our team deploy a change?
The better question is:
Could anything this AI depends on have changed its behavior?
That is a much larger surface.
Yesterday's problem was version history. Today's problem is external change.
Yesterday's article looked at a different failure. Engineering can often reconstruct the exact state of an AI system, while governance may still be holding an approval that describes an older state. The problem was the missing relationship between the system's history and the governance decisions attached to it. Click here to read the full article
Today's problem begins before that. Suppose you have solved the version-control problem. You know which model is running, which prompt is active, which configuration is deployed and which approval applies.
Then your model provider changes something. Now the question becomes:
Who was responsible for knowing that the change happened, determining whether it mattered and deciding whether the existing governance still applied?
That is no longer simply a version-control problem. It is a dependency and accountability problem.
Five ways your AI can change without a deployment
- The first is the most obvious: the model itself can change. Your application can continue making exactly the same API call while the underlying model changes. The deployment still looks familiar, but the intelligence producing the output is different.
- The second is data. A model can remain completely unchanged while the information surrounding it changes. A fraud system sees a new transaction population. A customer-service assistant receives a revised policy document. A retrieval system indexes thousands of new documents overnight. The model is identical, but the information it uses is not.
- The third is context. Modern AI behavior depends on much more than the model. System instructions, retrieved information, conversation history, available tools, business rules and permissions can all influence what the system does. A frozen model operating in a different context is not necessarily the same AI system in any meaningful operational sense.
- The fourth is dependencies. Your AI may rely on an external API, embedding service, safety layer, library, cloud service or vendor-controlled component. That dependency can change while your own application remains untouched.
- The fifth is the operating environment. A new database becomes accessible. A service account receives additional permissions. A new tool is connected. A previously restricted data source becomes available. The model did not become more capable, but the system around it did.
NIST's AI Risk Management Framework already treats third-party software, data, pretrained models, post-deployment monitoring and change management as part of AI risk management. The important implication is that the governance boundary cannot stop at the model.
The environment in which the AI operates is part of the system you are governing.
The dangerous word is “external”
Organizations are generally comfortable assigning responsibility for internal changes. If engineering changes the model, there is a ticket. If IT changes a permission, there is a request. If the business changes a decision threshold, someone approves it.
External changes are different. Suppose an organization assessed an AI system when Model A was operating behind an API. The assessment established certain performance expectations, limitations, testing results and controls.
Six months later, the provider moves the deployment to Model B. The vendor considers this a normal lifecycle event. Engineering sees that the API still works. The application continues processing requests. But the governance team now has a different question:
Does the evidence supporting the original approval still apply?
The vendor owns the change. The enterprise owns the consequences of continuing to use the changed system. That distinction matters.
You cannot outsource the governance consequence simply because part of the AI stack is supplied by someone else.
A vendor notification is not a governance control
Modern AI providers provide release notes, migration guides, deprecation notices and version documentation. Those are useful. But knowing that something changed is not the same as knowing what the change means for your organization. Imagine a provider announces that your model will be upgraded.
Engineering needs to know whether the API continues to work. Governance needs to know whether the assumptions behind the existing approval still hold.
Did the model's capabilities change? Did its known limitations change? Do previous evaluation results still apply? Did the risk assessment depend on characteristics of the old model? Does the permitted use case remain appropriate? Do existing controls still cover the new behavior?
These are not vendor questions. They are enterprise questions. This is why model lifecycle management increasingly recommends testing replacement models against the organization's own prompts and representative data rather than assuming that a newer model is automatically equivalent simply because the provider says it is a replacement.
A technical migration can therefore succeed while the governance migration remains incomplete.
The real danger appears when small changes interact
A single external change may not matter. That is precisely why this problem is easy to miss. A model upgrade might be acceptable. A new retrieval source might be acceptable. A new permission might be acceptable. A refreshed dataset might be acceptable.
Now combine them. The model changes, the training population changes, a new customer-data source is introduced, the AI receives access to another internal system and the business lowers the threshold at which its recommendation triggers action.
No individual change necessarily looks alarming. Collectively, the system may now operate under a very different set of assumptions from the one that was originally assessed.
This is where traditional change management starts to struggle. It is very good at asking whether individual changes were approved. Modern AI governance increasingly needs to understand how several changes interact and whether they alter the system's risk, purpose or operating assumptions.
That is a fundamentally different problem.
The trigger cannot simply be “deployment”
This is where AI governance needs to evolve. Traditional governance often revolves around scheduled events: an annual review, a quarterly review, a new deployment, a major incident or a vendor assessment. AI systems need another trigger:
Material change.
That does not mean every change should create a governance meeting. A routine patch may be irrelevant. A normal data refresh may not require reassessment. A minor configuration change may have no meaningful impact.
The objective is not to review everything constantly. The objective is to recognize when something has changed enough that the previous governance conclusion may no longer be reliable. A model replacement may cross that boundary. A new external AI dependency might. A new data source might. A major permission change might. A change in the business process using the AI certainly could.
The difficult part is not detecting that something changed. The difficult part is determining whether that change matters.
This is where monitoring stops and assurance begins
A monitoring system can tell you that a model version changed. That is useful. It cannot, by itself, tell you whether the change invalidates an existing risk assessment. That requires context.
What system is using the model? What decision does it support? What assumptions were made during the previous assessment? Which controls depended on the previous behaviour? What evidence exists for the new state? Who has authority to decide whether the system can continue operating?
This is the distinction between change detection and governance impact. The first is technical. The second is organizational. The two have to connect. Otherwise you end up with the modern enterprise version of a smoke alarm that tells you there is smoke but leaves everyone arguing about whose job it is to investigate.
The accountability problem gets harder with agents
This becomes even more important as organizations move toward AI agents. A traditional AI application may produce an answer. An agent can select tools, retrieve information, interact with systems and take actions.
That means the environment around the model becomes increasingly important. A change in a connected tool, permission or data source can alter what the agent is capable of doing without changing the model itself.
NIST's work on AI agent security reflects this broader concern: agents increasingly interact with software systems and external resources, creating new questions around permissions, autonomy, monitoring and control. The governance question therefore shifts from:
Which model did we approve?
toward:
What could this AI do in the environment we gave it, and has that environment changed?
That is a much more consequential question.
The enterprise still owns the consequence
This is probably the most important mental model to take away.
A vendor can change a model. A cloud provider can change infrastructure. A data provider can change its dataset. A software company can change an API. An internal team can change permissions. A business team can change the process.
Different parties may own different pieces of the change. But the organization deploying the AI still owns the decision to keep operating it. That means AI governance needs a clear path from change to consequence.
When something changes, the organization should be able to identify what changed, understand which AI systems depend on it, determine whether the change is material, identify the accountable owner, decide what action is required and preserve the evidence supporting that decision.
Without that connection, organizations can have excellent monitoring and still have weak governance.
The uncomfortable question for every AI owner
Ask your AI owner a simple question:
What can change this AI without our engineering team deploying anything?
If the answer is “nothing,” keep going. Ask which external models, vendors, APIs, retrieval sources, datasets, tools, permissions and infrastructure components the system depends on. Then ask how the organization would know if one of them changed and who has the authority to determine whether that change affects the existing governance conclusion.
Finally, ask whether the organization could prove what those dependencies looked like when an important decision was made.
That last question connects directly to yesterday's problem. Knowing that something changed today is useful. Knowing what the AI actually depended on when it made a decision six months ago is assurance.
“We didn't change anything” is no longer a sufficient answer
The old software mental model was straightforward:
We change the system, so we review the change.
The AI environment is becoming:
Something changes, we determine where it came from, we determine whether it matters, and we decide whether the existing governance still holds.
That is harder. But it is also much closer to reality. Models are upgraded and retired. Data changes continuously. Vendors evolve their services. Dependencies move underneath applications. AI systems increasingly operate across distributed infrastructure and external services. NIST is already identifying fragmented monitoring, drift, third-party dependencies and rapidly changing deployment environments as significant challenges for deployed AI systems.
The implication is bigger than model management.
AI governance can no longer assume that the organization is the only thing capable of changing the AI system. Sometimes the most important change in production is the one nobody inside the company deployed. And that may be the one governance is least prepared to see.
Yesterday, we asked whether your governance could reconstruct the exact AI state it approved. Today, the question is more uncomfortable:
What if your AI changed, and nobody on your side changed it?
That is where AI governance starts becoming an operating capability rather than a collection of approvals.