When an AI System Changes Risk Tier Under the EU AI Act

Classification is not a one-time stamp. A system you correctly recorded as minimal or limited risk can become high-risk later — and the change can make you its provider, with the full Article 16 duty stack, even though you only meant to be a deployer. Under the EU AI Act, Regulation (EU) 2024/1689, two events trigger this: a substantial modification and a change of intended purpose. Both sit in Article 25, and both are easy to walk into without noticing.

This guide explains when a tier changes, when to re-run the Article 6(3) assessment, and what you owe once it does.

The two triggers that move a system into high-risk

Article 25(1) lists the ways a party other than the original provider takes on provider obligations. Two of them flip the tier:

• Article 25(1)(b) — substantial modification. You make a substantial modification to a high-risk system already on the market or in service. A substantial modification (Article 3(23)) is a change, not foreseen in the original provider's conformity assessment, that affects the system's compliance with the requirements or changes its intended purpose. Routine bug-fixes and planned updates the provider already documented are not substantial; a material retrain or re-architecture that the provider never assessed is.
• Article 25(1)(c) — change of intended purpose. You change the intended purpose of a system — including a non-high-risk one — so that it becomes high-risk under Article 6. This is the one founders miss: take a general analytics tool and point it at scoring job applicants, and you have created a new Annex III point 4 high-risk system by repurposing alone.

There is a third route on the same article — Article 25(1)(a), putting your name or trademark on a high-risk system already placed on the market. That does not change the tier; it changes who is on the hook for an already-high-risk system. Keep it distinct from the two above, which are about the tier moving.

---

When you must re-run the Article 6(3) assessment

The Article 6(3) filter lets an Annex III system escape high-risk status when it poses no significant risk of harm — a narrow procedural task, improving a completed human activity, detecting patterns without replacing human judgment, or preparatory work (any one is enough, but a system that profiles natural persons is always high-risk and cannot use it). That filter is only as good as the intended purpose it was run against.

Re-run it whenever the facts it depended on change:

• You alter the intended purpose — the exemption was scoped to the old purpose.
• You make a substantial modification that changes how the system influences a decision (e.g. it now scores candidates instead of only sorting them).
• You move the system from a back-office, human-checked role into one that materially drives an outcome.

If the re-run lands in high-risk, the system is high-risk from that moment — not from some future review date.

What changes when the tier flips: you may be the new provider

This is the part that bites. Under Article 25(1), the party that substantially modifies a high-risk system or repurposes a system into a high-risk one is considered a provider of that high-risk system and takes on the Article 16 obligations in full:

The original provider does not simply vanish: Article 25(2), rewritten by the Digital Omnibus, requires it to cooperate with you — handing over its technical documentation, known limitations and failure modes, and targeted technical access for testing — unless it clearly specified that the system was not to be changed into a high-risk one. But the provider duty has moved to you.

Penalties track the duty. A provider/deployer breach of these obligations sits in the €15,000,000 or 3% of worldwide annual turnover tier (Article 99(4)), not the Article 5 prohibition tier. For SMEs and start-ups, the fine is the lower of the percentage or the fixed amount (Article 99(6)).

Document the change like you documented the original

A reclassification is a compliance event, so leave a trail: what changed (the modification or the new purpose), the date, the re-run Article 6 and 6(3) reasoning, the new tier, and the new role. If you have become the provider, the technical documentation (Article 11, Annex IV) must now reflect the modified system, and you register it under Article 49 before the high-risk obligations apply. That record is your defence when a market-surveillance authority asks why the same system is now treated differently.

Worked example: Strandbyte GmbH, ~140 employees, ~€26M turnover

Strandbyte, a Hamburg logistics-software firm, deploys a third-party document-triage tool to sort incoming supplier emails — a narrow procedural task, recorded as Article 6(3) exempt, with Strandbyte as deployer. A product manager then connects the same tool to the applicant tracking system and uses it to rank job candidates. That is a change of intended purpose: the new purpose sits in Annex III point 4 (employment), the system now profiles natural persons, and the 6(3) exemption no longer holds. Under Article 25(1)(c) Strandbyte becomes the provider of a high-risk system and owes the Article 16 stack. The right move was to re-run classification before repointing the tool. Strandbyte rolls the change back, re-records the system as the original procedural use, and routes the hiring idea through a proper provider assessment.

How Confir helps

Confir keeps each registered system's classification live, so a change of purpose or a substantial modification re-runs the Article 5, Article 6 and Article 6(3) logic and shows the new tier, the Article 25 flip, and the new role with the cited rule that fired. The engine is deterministic and rule-based — the same change always produces the same reclassification and obligation list — and it flags when a modification has turned a deployer into a provider before the new duties quietly accrue.

Related guides

• How AI risk classification works
• How to classify your AI system
• The Article 6(3) exemption explained
• Provider vs deployer
• Article 25: responsibilities along the value chain
• Substantial modification (Article 3(23))