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?

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:

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:

Check yourself

  1. It matches Annex III point 5(b), so it is high-risk. — Check the carve-out. Fraud detection is excluded from 5(b).
  2. 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.
  3. 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.
  4. 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 →

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.