When an organization approves an AI tool, the record usually carries a product name. The review itself looked at something narrower: a model, with a particular set of instructions and data, tested at one point in time. The product name can stay the same while those parts change. When that happens, the approval still reads “approved,” but it now describes a system that is no longer running.
This article calls that a silent model change. The term is the author’s label, not one defined by NIST or the EU AI Act. Both, however, treat change after deployment as something risk management has to plan for.
Note: statements attributed to a named source come from that source. Everything else, including passages marked “Interpretation,” is the author’s interpretation. The examples in this article are illustrative and do not describe any real organization or vendor.
What an approval covers
A governance review is a judgment about specific conditions. Reviewers look at what the system does, how it behaves on the tasks that matter, what data it uses and what could go wrong. Those observations are tied to the version they examined.
Change control is a familiar idea for conventional software releases. AI tools deserve the same treatment, with one difference. The part that matters most, the model, may change without any visible sign. The interface, the login and the contract can all look exactly as they did on the day of the review.
Interpretation: an AI approval is better understood as an approval of a configuration than of a product. The configuration includes the model version, the instructions or prompts, the data it draws on and the settings around it.
How a model can change without anyone noticing
Take three illustrative cases.
A team uses a vendor’s writing assistant that was reviewed and approved last quarter. The vendor later moves the product to a newer model. The release notes describe the update in general terms, and nobody inside the organization reads them.
An internal team maintains a classification tool. To fix a recurring error, an engineer edits the system prompt. The fix works for that error. Nobody checks whether it changed behavior on other inputs.
A model is retrained on more recent data. Its average accuracy improves, but its handling of an uncommon category, one that matters to a small group of customers, gets worse.
None of these changes is necessarily a mistake. Each may well be an improvement on average. The governance question is narrower. Is the system still fit for the specific use that was approved? “Better on average” and “still acceptable for our use” are different questions, and only a check against the approved use can answer the second.
What NIST’s AI RMF says about change
The NIST AI Risk Management Framework (AI RMF 1.0) treats risk management as ongoing rather than a one-time gate. Its GOVERN function includes subcategory GOVERN 1.5: “Ongoing monitoring and periodic review of the risk management process and its outcomes are planned and organizational roles and responsibilities clearly defined, including determining the frequency of periodic review.”
The MEASURE function expects that “Test sets, metrics, and details about the tools used during TEVV are documented” (MEASURE 2.1), where TEVV stands for test, evaluation, verification and validation. MEASURE 2.4 states that “The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production.”
The MANAGE function names change directly. MANAGE 4.1 says that “Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.” MANAGE 4.2 adds that “Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors.”
The framework also describes testing tasks during operations as involving “ongoing monitoring for periodic updates, testing, and subject matter expert (SME) recalibration of models.”
Interpretation: read together, these passages point to a practical rule. If test sets are documented and production behavior is monitored, the organization already has what it needs to recheck a system after a change. What can be missing is the trigger that tells anyone a change happened.
What the EU AI Act says about substantial modification
The EU AI Act addresses change for high-risk AI systems through the idea of “substantial modification.” Article 3(23) defines it as “a change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance of the AI system with the requirements set out in Chapter III, Section 2 is affected or results in a modification to the intended purpose for which the AI system has been assessed.”
Article 43(4) states that high-risk AI systems that have already been through a conformity assessment “shall undergo a new conformity assessment procedure in the event of a substantial modification, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer.” The same paragraph says that, for high-risk systems that continue to learn after deployment, changes “pre-determined by the provider at the moment of the initial conformity assessment” and documented in the technical documentation do not constitute a substantial modification.
Conformity assessment is an obligation of the provider (Article 16(f)). Under Article 25(1)(b), a deployer, distributor, importer or other third party that makes a substantial modification to a high-risk AI system, in such a way that it remains high-risk, is considered a provider and takes on the provider’s obligations.
Interpretation: these provisions apply to high-risk systems and to specific legal roles, and whether a given change counts as a substantial modification is a legal question. The idea behind them is still useful for any organization. Changes that were planned and documented in advance are handled differently from changes that were not. That distinction works well as an internal governance habit, whatever the legal classification of a system.
Practical controls
The following controls are interpretation, offered as a starting point rather than a complete program.
- Record the configuration as well as the product. The approval record should name the model or version, the main instructions or prompts and the data sources that were reviewed. An AI inventory is a natural place to keep this.
- Ask for notice of changes. For vendor tools, ask how and when the organization will be told that the underlying model has changed, and whether the contract says so. For internal tools, make a prompt edit or a retrain a logged change.
- Keep a small set of test cases. A short, stable set of examples that reflect the approved use makes it possible to rerun a check after a change and compare the results.
- Define what counts as a significant change. Decide in advance which changes need only a quick retest and which need a fresh review. A planned, documented change is different from an unannounced one.
- Name who decides. Someone has to judge whether a change keeps the system within its approval. That decision should have a clear owner.
- Link it to the review cycle. Periodic reviews are a good point to confirm that the configuration on record matches the one in use, which fits the idea of governance as a continuing cycle.
A change of model is related to, but different from, a change of use. The earlier article on intended-use drift looks at the second case, where the system stays the same and its job grows.
Conclusion
An approval is a statement about a specific system at a specific time. NIST’s AI RMF expects monitoring, documented testing and change management after deployment. The EU AI Act sets out when a change to a high-risk system is significant enough to need a new conformity assessment. Both treat change after approval as normal, and both expect a process for it.
That leaves a simple question for every AI system in use. If the model behind it changed tomorrow, how would we know, and who would decide whether the approval still holds?
This article reflects the author’s personal views, not those of any employer, and interpretation of publicly available materials from NIST and the European Commission’s EU AI Act Service Desk, as available on October 20, 2026. It is not affiliated with or endorsed by either body and does not reproduce their full requirements. It is general information, not legal, compliance or certification advice, and reading it does not create any advisory relationship. Laws, guidance and application dates change. Refer to the official texts, including the EU AI Act as published in EUR-Lex, and get qualified advice before acting on how they apply to your organization.
Sources: NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf; European Commission AI Act Service Desk, Articles 3, 16, 25 and 43, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3 (and article-16, article-25, article-43)