Intended Purpose: The Hinge of EU AI Act Classification
Intended purpose (Article 3(12)) decides an AI system's risk class — driving the Annex III match, the Article 6(3) filter and the Article 25 provider flip.
Ask "is this AI system high-risk?" and the honest first answer is "what is it for?" Under Regulation (EU) 2024/1689, almost every classification turns on one definition: intended purpose. Get the intended purpose right and the rest of the analysis — the Annex III match, the Article 6(3) filter, the risk-management scope, even who counts as the provider — falls into place. Get it wrong and every downstream step inherits the error.
This page treats intended purpose as the operational hinge of classification, not just a glossary term. (For the bare definition, see the intended purpose definition; this page is about how it actually drives a classification decision.)
The high-risk obligations these decisions feed into apply from 2 December 2027 for stand-alone Annex III systems, the date set by the Digital Omnibus — Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026.
What "Intended Purpose" Means — Article 3(12)
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 information supplied by the provider in the instructions for use, promotional or sales materials and statements, and in the technical documentation.
Two things follow. First, intended purpose is set by the provider, through what it writes and says — the instructions for use and the marketing are not decoration, they are the legal anchor of the classification. Second, it is not the same as how a system could be used. That gap — between what a system is for and what it might be misused for — is handled separately by reasonably foreseeable misuse.
How Intended Purpose Drives Each Step
| Step | What intended purpose decides | Article / Annex |
|---|---|---|
| Annex III match | Does the stated use fall in a high-risk use area? | Annex III, Article 6(2) |
| Article 6(3) filter | Is the use a narrow procedural / preparatory task only? | Article 6(3) |
| Risk management scope | Which foreseeable risks must be managed? | Article 9 |
| Reasonably foreseeable misuse | Which off-label uses must be designed against? | Articles 3(13), 9 |
| Provider flip | Has a deployer changed the intended purpose? | Article 25 |
1. The Annex III match (Article 6(2))
Annex III lists high-risk use areas — employment, creditworthiness, biometrics, migration, and the rest. A system is matched to Annex III by what it is intended to do, not by its underlying technology. The same large language model is minimal-risk in a recipe app and potentially high-risk if its intended purpose is to rank job applicants. Classification is by use; intended purpose is how "use" is fixed in law.
2. The Article 6(3) filter
Even inside an Annex III area, Article 6(3) can pull a system back out — if its intended purpose is a narrow procedural task, improving a previously completed human activity, detecting decision patterns without replacing human assessment, or purely preparatory work. Only one of the four conditions is needed. But the assessment runs entirely on the stated intended purpose, and any system that profiles natural persons is always high-risk regardless. Frame the intended purpose loosely and you forfeit the exemption; frame it accurately and you may keep it.
3. Reasonably foreseeable misuse (Article 9)
Intended purpose has a shadow: reasonably foreseeable misuse (Article 3(13)) — use in a way not aligned with the intended purpose but which may result from reasonably foreseeable human behaviour. The Article 9 risk-management system must address it. So intended purpose does double duty: it sets the in-scope use and defines the boundary against which foreseeable off-label use is judged. A narrow, well-documented intended purpose makes both jobs tractable.
The Provider Flip — Article 25
Here is where intended purpose bites hardest. A deployer carries lighter obligations (Article 26) than a provider (Article 16). But Article 25 flips a deployer (or distributor or importer) into a provider of a high-risk system if it:
- puts its own name or trademark on a high-risk system already on the market; or
- makes a substantial modification (Article 3(23)) to a high-risk system; or
- modifies the intended purpose of a system — including a non-high-risk one — such that it becomes high-risk.
That third limb is the trap. Take a general-purpose tool with a benign intended purpose, repurpose it to screen CVs, and you have changed its intended purpose into an Annex III use — you are now the provider, with the full Article 16 stack. The original provider's intended purpose protected it; your new intended purpose exposes you.
Worked Example
Brightfold GmbH (a fictional German HR-tech firm, ~90 employees, ~€14M turnover) licenses a general text-analysis API whose provider documents its intended purpose as "summarising and categorising free-text documents." Brightfold wires it into a hiring tool that ranks candidates and presents a shortlist to recruiters, and markets the result under its own brand.
- Original system: intended purpose is document summarisation — not an Annex III use; minimal/limited-risk.
- Brightfold's use: the intended purpose it sets — rank job applicants — is Annex III point 4 (employment). That is a high-risk use area.
- Article 6(3) check: the system influences the human hiring decision and is not merely preparatory, so the exemption is unlikely; if it profiles candidates, it is high-risk outright.
- Article 25 flip: by putting its name on the system and changing the intended purpose to a high-risk one, Brightfold becomes the provider — Article 16 obligations, Annex IV documentation, Article 43 conformity assessment, Article 47 declaration, registration.
- Exposure: getting this wrong — running a high-risk system as if it were minimal — sits in the €15M or 3% tier (Article 99(4)). Under Article 99(6), a company Brightfold's size pays the lower of the percentage or the fixed amount.
The verdict: nothing about the underlying model changed. The intended purpose did — and that single fact moved Brightfold from light-touch deployer to full-obligation provider.
How Confir Helps
Confir's classification works the way the Regulation does — from the intended purpose. It captures the stated use and context per system, matches it against Annex III, applies the Article 6(3) filter, derives whether you are provider or deployer, and flags an Article 25 flip when a recorded use changes the intended purpose into a high-risk one. The engine is rule-based and deterministic: the same intended purpose yields the same classification, and the rule that fired is written in plain English.
Related guides
- Intended purpose definition (Article 3)
- High-risk classification explained (Article 6)
- How Annex III classifies high-risk AI
- Provider vs deployer obligations
- Deployer obligations (Article 26)
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →