Most AI approval records name a system. Fewer state, in specific terms, the job that system was approved to do. The gap is easy to miss, because nothing about the system changes when its job does. The model, the vendor and the license all stay the same. The risk does not.
This article uses the term intended-use drift for the gradual movement of an AI system into uses that its original review did not consider. The term is the author’s label, not one defined by NIST or the EU AI Act. Both, however, treat the purpose of an AI system as a basic input to managing its risk.
Note: statements attributed to a named source come from that source. Everything else, including passages marked “Interpretation,” is the author’s interpretation. The example in this article is illustrative and does not describe any real organization.
Risk belongs to a use, not only to a system
The NIST AI Risk Management Framework (AI RMF 1.0), which NIST released on January 26, 2023 for voluntary use, puts purpose at the start of its MAP function. Subcategory MAP 1.1 reads: “Intended purposes, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented.” The considerations it lists include “the specific set or types of users along with their expectations” and “potential positive and negative impacts of system uses.”
MAP 3.3 adds that the “targeted application scope is specified and documented based on the system’s capability, established context, and AI system categorization.” The framework also states that outcomes in the MAP function “are the basis for the MEASURE and MANAGE functions.” NIST states that AI RMF 1.0 “is being revised as part of the White House AI Action Plan.”
Interpretation: if measuring and managing risk rest on a documented purpose, then a system used outside that purpose is running without a current assessment, even if the system itself passed review.
How drift happens
Drift rarely comes from a single decision. It builds up through ordinary, reasonable steps.
Take an illustrative case. A team approves a generative AI tool to draft summaries of customer emails. The summaries prove useful, so a manager starts using them to decide which complaints to escalate. Later, the same summaries feed a report on staff performance. Each step is small, and the tool has not changed. But the people affected, the cost of an error and the decisions involved are no longer the ones that were reviewed.
NIST anticipates this. In the AI RMF Playbook guidance on MAP 1.1, it says “organizations should expect broadly deployed AI tools to be reused, repurposed, and potentially misused regardless of intentions.”
Interpretation: a few features of current AI use make drift more likely. General-purpose tools can do many tasks, so there is no technical barrier to a new use. Outputs travel, and a summary or score created for one purpose can be copied into another process. A system that has passed review can also come to seem “approved” in general, even though the review covered one use.
Why an approval can go out of date
An approval is a judgment about specific conditions. The users, the data, the decisions and the harm an error could cause were weighed for a particular use. When the use changes, some of those conditions change with it.
The Playbook offers practical language for this. Under MAP 1.5, it suggests that organizations “review uses of AI systems for ‘off-label’ purposes, especially in settings that organizations have deemed as high-risk.” It also lists a documentation question: “What conditions and purposes are considered ‘off-label’ for system use?” In the framework itself, MAP 1.4 expects the business value or context of business use to be clearly defined and, for existing AI systems, re-evaluated.
Interpretation: the “off-label” framing is useful because it changes the question. Instead of asking whether a system is approved, it asks what the system is approved for.
What the EU AI Act adds
The EU AI Act (Regulation (EU) 2024/1689) builds much of its structure on the same idea. Article 3(12) defines “intended purpose” as “the use for which an AI system is intended by the provider, including the specific context and conditions of use,” as specified in the provider’s instructions for use, promotional or sales materials and statements, and technical documentation. Article 3(13) defines “reasonably foreseeable misuse” as use “in a way that is not in accordance with its intended purpose,” which may result from reasonably foreseeable human behavior or interaction with other systems.
For high-risk AI systems, intended purpose comes up again and again. Providers must operate a risk management system that includes estimating and evaluating the risks that may emerge when a system is used “in accordance with its intended purpose, and under conditions of reasonably foreseeable misuse” (Article 9(2)(b)). The instructions for use must state the system’s intended purpose (Article 13(3)(b)(i)). Deployers must take appropriate technical and organizational measures to use high-risk systems in accordance with those instructions (Article 26(1)).
The provision most directly linked to drift is Article 25. Under Article 25(1)(c), a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, subject to the provider obligations in Article 16, if they “modify the intended purpose of an AI system, including a general-purpose AI system, which has not been classified as high-risk and has already been placed on the market or put into service in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6.”
Interpretation: under the Act, a change of use is not only a governance question. In some circumstances it can change an organization’s legal role and the obligations that come with it. Whether that happens in a particular case depends on the facts and on how the classification rules in Article 6 apply, which is a matter for qualified legal advice. The Act’s text cited here is the EU AI Act Service Desk rendering, which the Service Desk says is based on the EUR-Lex consolidated version as at July 27, 2026.
Practical controls for intended-use drift
None of the sources above prescribes a single method for catching drift. The practices below are interpretation, built on the documentation and review ideas the sources describe.
- Write the approved use down precisely. A useful scope statement names the tasks the system may perform, the decisions it may inform, its users, the data it may receive and any uses that are excluded.
- Treat a new use as a change. The AI RMF lists change management among the mechanisms in post-deployment monitoring plans (MANAGE 4.1). Organizations that already review model or vendor changes can send a new use through the same gate, even when the technology is unchanged.
- Decide who can approve a new use. If anyone with access can extend a system’s job, the approval process covers only the first use.
- Watch for signals. New user groups, new data sources and outputs that start feeding decisions about people are signs that a system’s job may have grown.
- Reconfirm the use at each review. A periodic review that asks what the system is actually used for today can reveal more than one that only rechecks performance.
Conclusion
Approvals are usually recorded against a system name, so it is natural to treat them as attached to the system. The sources discussed here point to a different view. NIST’s MAP function starts from intended purposes and context, and the EU AI Act defines intended purpose and ties several obligations to it. In both, the assessment is attached to a use.
That adds a simple question to every governance review. Is this system still doing the job it was approved for? When the answer is no, the earlier approval does not cover the new job.
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 19, 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; NIST, AI Risk Management Framework, https://www.nist.gov/itl/ai-risk-management-framework; NIST AIRC, AI RMF Playbook: Map, https://airc.nist.gov/airmf-resources/playbook/map/; European Commission AI Act Service Desk, Articles 3, 9, 13, 25 and 26, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3 (and article-9, article-13, article-25, article-26)