Module 2 of AI Risk Management Pro: discovering the AI systems you did not know you had, a classification decision path that puts the Art. 2 and Art. 6(3) carve-outs before Annex III, and recording the derivation rather than the conclusion.
Classification is where most programmes generate their first serious error, and the error is almost always the same: Annex III is read first. Annex III is a list of use cases, it is easy to pattern-match against, and matching it feels like progress. But the Regulation's logic puts three filters before Annex III, and skipping them produces a programme that over-scopes some systems, under-scopes others, and cannot explain either.
First find them
You cannot classify what you have not found, and the inventory is almost never the list the IT function already holds. Four seams produce the systems people forget:
Features inside purchased software. A CRM that added lead scoring, an HR suite that added CV ranking, a ticketing tool that added sentiment routing. No procurement event marked the arrival of an AI system; a release note did. These are the largest single category in practice.
General-purpose assistants pointed at consequential decisions. The tool was adopted for drafting. Someone is now using it to sift applications. Under Art. 25 that repurposing can make you the provider of a high-risk system.
Models built by analysts. A notebook that became a monthly process, with no owner and no documentation. It still infers, and it still influences decisions.
Embedded components in physical products. If your organisation makes anything covered by the Annex I legislation, the AI inside it follows that route, with a different deadline and a different conformity assessment.
Practical discovery methods that work: a procurement sweep over the last 24 months for anything describable as analytics, scoring, matching or generation; a vendor-release review for the top twenty SaaS tools; a question in the quarterly business review rather than a survey nobody answers; and an expense review for AI API spend, which finds what the other three miss.
The decision path, in the order the Regulation puts it
For each candidate, settle these in sequence. Stopping early is the point: most systems stop at step 2 or 3.
1 — Is it an AI system at all? (Art. 3(1)) Does it infer from input how to generate outputs? If a human wrote every rule and the system only applies them, you are probably outside the definition. Record the judgement either way. Over-inclusion is not free: every system you pull in acquires a review burden.
2 — Is it carved out of the Regulation entirely? (Art. 2) Art. 2 excludes, among others, systems used exclusively for military, defence or national security purposes; scientific research and development as the sole purpose; and pure personal non-professional use. Research exemptions get misread constantly — the exclusion attaches to the purpose of the system, not to the fact that a research team built it. A model developed in research and then put into production is in scope from the moment it is put into service.
3 — Is it prohibited? (Art. 5) This is a hard stop, not a tier. Social scoring, untargeted facial-image scraping, emotion inference in the workplace or in education outside narrow exceptions, certain biometric categorisation, and real-time remote biometric identification in public spaces for law enforcement outside the listed cases. Note the date: a further Art. 5 prohibition takes effect 2 December 2026. A system that hits Art. 5 is withdrawn, not mitigated.
4 — Which high-risk route, if any?
- Annex I — the AI is a safety component of, or is itself, a product covered by the listed Union harmonisation legislation. The AI Act obligations are integrated with that legislation's conformity assessment, and apply from 2 August 2028.
- Annex III — standalone high-risk use cases. Chapter III applies from 2 December 2027.
Only now is Annex III worth opening.
5 — Does an Annex III carve-out apply? The carve-outs decide a large share of real cases and are routinely missed. Two examples that recur:
- Point 5(b) covers creditworthiness evaluation and credit scoring, but excludes systems used to detect financial fraud.
- Point 1 biometrics excludes systems whose sole purpose is biometric verification — confirming that a person is who they claim to be, one to one.
6 — Are you relying on Art. 6(3)? Art. 6(3) lets a system that falls within an Annex III point escape high-risk classification where it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision-making. The listed situations are narrow: a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns without replacing or influencing the prior human assessment, or a preparatory task.
The condition that swallows most attempted reliance: profiling of natural persons always makes it high-risk, whatever else is true.
And reliance is not free. Under Art. 6(4) you must document the assessment before the system is placed on the market or put into service, supply it to authorities on request, and register under Art. 49(2). "We rely on Art. 6(3)" with no document is the weakest position available — worse than having classified the system high-risk, because it reads as a conclusion reached to avoid work.
Record the derivation, not the label
This is the module's one operational insistence. For each system, the inventory row should hold:
| Field | Why it earns its place |
|---|---|
| System name, owner, business process | Nothing can be reviewed without an owner |
| Art. 3(1) judgement, with reasoning if borderline | Borderline calls must be visible to be re-made |
| Art. 2 exclusion considered | Prevents silent over- and under-scoping |
| Art. 5 screen, dated | The 2 Dec 2026 prohibition needs a re-screen |
| Route: Annex I (which legislation) / Annex III (which point) / neither | Drives the deadline and the assessment route |
| Carve-out applied or rejected, with reasoning | The highest-value field in the row |
| Art. 6(3) relied on? If yes, link to the Art. 6(4) document | A bare "yes" is a liability |
| Your role: provider / deployer / both, and the limb | Decides which artefacts you owe |
| Derived tier | Derived. Never typed |
| Last reviewed, next review, review triggers | Makes it a process |
The last two rows are what distinguish an inventory from a spreadsheet. The AI System Inventory & Classification template included with this track implements exactly this: the tier is computed from the answers along the decision path rather than entered, so a classification cannot be asserted without the reasoning that produces it.
The triggers that re-open a classification
A classification is valid until something changes. Name the triggers and wire them to the owners:
- Procurement of anything new, or renewal of anything with new AI features.
- Model retraining or fine-tuning, especially on your own data — Art. 25 territory.
- Intended purpose change, including a user community adopting the tool for something new.
- Vendor notification of a substantial modification.
- Regulatory movement — the 2 December 2026 Art. 5 addition is a worked example.
- Incident, which frequently reveals that the recorded intended purpose was not the actual one.
Check yourself
- It matches Annex III point 5(b), so it is high-risk. — Check the carve-out. Fraud detection is excluded from 5(b).
- Our research team built it, so Art. 2 covers it. — No. The exclusion attaches to the system's sole purpose, not the team. Putting it into service brings it in scope.
- We rely on Art. 6(3) because the human makes the final call. — Does it profile natural persons? If so, high-risk regardless. And Art. 6(4) requires the assessment documented before market placement, plus Art. 49(2) registration.
- Our inventory records the tier for every system. — Does it record how the tier was derived? A label without a derivation cannot be defended or incrementally updated.
Next: Module 3 — The risk register: Art. 9 as a running system →
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth — including what the AI Act adds on top of an existing DORA programme.
The AI Act for financial institutions ↗ Explore regulation-dora.eu ↗Frequently Asked Questions
Art. 3(1): a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that infers from input how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. Inference is the hinge. A deterministic rules engine that a human wrote and that applies those rules without inferring anything is generally outside; a scoring model fitted to data is inside. Borderline cases should be recorded as borderline, with the reasoning, rather than resolved silently.
Both, but the derivation is the part that has value. A tier recorded as a bare label cannot be defended, cannot be reviewed, and has to be redone from scratch when the system changes. A derivation — the Annex III point considered, the carve-out applied or rejected, the Art. 6(3) assessment if relied on — can be checked by someone else and updated incrementally.
At a fixed cadence and on named triggers. The cadence exists because shadow AI accumulates between sweeps; the triggers exist because a modification or a repurposing can change a classification overnight under Art. 25. A quarterly sweep with triggers on procurement, model retraining, intended-purpose change and vendor notification is a defensible starting point.