Classification follows intended purpose. When a provider changes the intended purpose, or a deployer uses a system for a purpose outside the provider's specified purpose, the Article 5 screen and the Article 6 classification must be redone on the new facts, and Article 25 must be checked, because a change of intended purpose that makes a system high-risk can make the person who changed it the provider. A change in user group, deployment context, data, or integration can have the same effect even where the stated purpose has not formally changed. Reassessment should happen before the changed use goes live, not after it has been in operation.
What counts as a change of purpose?
A change of purpose occurs where the system is used for a use different from the use specified by the provider, or where the provider specifies a new use. Examples include using a general document tool to screen job applications, using a customer service assistant to evaluate workers, using a fraud tool to assess creditworthiness, or extending a system from one Annex III area to another. A change can also occur without a formal announcement: a deployer that gradually uses a system for consequential decisions, a team that adds a new user group, or a product update that enables a new function can change the effective purpose. The record should compare the specified purpose with the actual use, and treat a material difference as a purpose change, even if no document calls it one.
How does Article 25 treat a change of purpose?
Article 25 provides that a deployer, importer, distributor or third party shall be considered a provider of a high-risk AI system where it puts its name or trademark on a high-risk system already placed on the market, makes a substantial modification to a high-risk system that remains high-risk, or modifies the intended purpose of an AI system that was not high-risk so that it becomes high-risk. The consequence is that the person who changes the purpose assumes provider obligations for the system in its new form. Contracts cannot override that statutory effect, although they can allocate information, cooperation and evidence duties between the parties. A deployer planning a purpose change should therefore assess the new classification and the Article 25 consequence before the change, and should obtain the information needed to meet provider duties if the role changes.
For the broader regulatory framework, see high-risk AI systems.
What other changes can change classification?
Classification can change without a formal purpose change where the deployment context changes the Annex III analysis. A system used with a new population, in a new geography, with new data, or integrated with a new decision workflow can acquire a listed use case or a new risk profile. A model update that changes behaviour, a prompt or tool change that changes outputs, and a change in human review that changes material influence can also change the analysis, including the Article 6(3) filter. The change log should therefore capture purpose, users, data, integration, model version and review design together, and a material change in any of those should trigger a classification review, even where the product name and the stated purpose remain the same.
How should reassessment be triggered and recorded?
Reassessment should be triggered by a defined change process: a purpose-change request, a new deployment proposal, a model or integration update, a new user group, or a new geography. The trigger should require a fresh Article 5 screen, a fresh Article 6 test, a fresh Article 50 check, and a fresh Article 25 role check, each recorded with the new facts and the reviewer. The old classification should be retained, with its date and evidence, so that the change is visible as a decision rather than a silent overwrite. Where the new classification is high-risk, the conformity, documentation and registration work should be completed before the changed use goes live, subject to the application dates for the relevant provisions.
What should contracts say about purpose change?
Contracts between providers, deployers, importers and distributors should require notice of a proposed purpose change, the information needed to reassess classification, and cooperation in meeting any new provider duties. The contract should state the specified intended purpose, the permitted uses, the prohibited uses, and the process for approving a new use. It should also address model updates, integration changes, and data changes that could affect classification. A contract that only states a general purpose, without a change process, leaves both parties exposed: the deployer may change purpose without realising the Article 25 consequence, and the provider may learn of the change only after the system has been used in its new form.
Continue with Article 6 classification routes.
What is not decided by this guide?
This guide explains the purpose-change analysis in outline. It does not decide whether any particular change is a change of intended purpose, whether it is substantial, or whether Article 25 makes a particular person the provider. Those questions need the specified purpose, the actual use, the modification, and the classification on the new facts, read against Articles 3, 6 and 25 in the consolidated text. Purpose changes that move a system into a prohibited practice or a high-risk use case should be confirmed with a competent authority or legal adviser before the changed use goes live.
Frequently asked questions
Does using a system differently from its instructions change its classification?
It can. Classification follows intended purpose, and a deployer use outside the specified purpose must be reassessed. Article 25 can also make the person who changes the purpose the provider, where the change makes a non-high-risk system high-risk.
Is a model update a purpose change?
Not necessarily, but a model update that changes behaviour, outputs or the user group can change the classification analysis and should trigger a review. The review should cover purpose, data, integration and human review together.
Can a contract prevent Article 25 from applying?
No. Article 25 applies by statute where its conditions are met. A contract can allocate information and cooperation duties, and can prohibit purpose changes, but it cannot override the statutory role change where a prohibited purpose change in fact occurs.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗