Skip to content
AIMS-in-a-Box
User guide · part 2

Build the register and classify

This is the part people skip, and it is the part everything else rests on. An hour spent here saves a fortnight later, because every document the app generates reads from this list.

Finding your AI systems

Most organisations underestimate this by half. The usual misses:

  • Features built on somebody else's model. If your product calls an API to summarise, rank, classify or generate, that is an AI system and you are its provider as far as your customers are concerned.
  • Tools the business bought without telling IT. A recruitment screener, a support-ticket classifier, a sales-forecasting add-on.
  • Things in development. Register them at "planned" or "in development". Classification is far cheaper before launch than after.
  • Vendor features switched on by default. An AI assistant inside a SaaS tool you already pay for is still something you deploy.

Ask each team lead one question: "what have you shipped or switched on in the last year that makes a decision, ranks something, or writes text?" That phrasing finds more than "do you use AI?" does.

Adding a system

  1. Name it as your organisation names it

    Use the name the team who owns it uses, not a formal one you invent. The register is only useful if people recognise their own system in it.

  2. Say what it does, in one line

    "Ranks applicants for shortlisting" is a better entry than "ML-powered talent acquisition optimisation". The one-liner is what an auditor reads first, and it is what distinguishes two systems with similar names when the app generates a document about one of them.

  3. Decide your role: provider, deployer, or both

    Provider — you develop it, or you put your name on it. If it is part of the product you sell, you are almost certainly its provider, even if the model underneath is somebody else's.

    Deployer — you use it under your own authority. A tool you bought and switched on.

    Both — you build it and you also use it internally. More common than people expect.

    Get this right: a provider of a high-risk system carries twelve obligations, a deployer seven, and they are different obligations. This single field decides which list you get.

  4. Name an owner

    One person, accountable. ISO/IEC 42001 Clause 5.3 expects it, and in practice an unowned system is one nobody re-assesses when it changes.

The AI system register with seven systems, two of which show a Not classified lozenge.
Illustration A register in progress. Two systems have not been classified, and the app shows that as 'Not classified' rather than assuming they are minimal risk — an unasked question is not an answer.

Classifying a system

Press Classify on a row. Seven questions, two minutes. The wizard only asks what is relevant — the Article 6(3) derogation question, for instance, appears only once you have named an Annex III area, because before that it means nothing.

The questions, and what they are getting at

  1. Your role. Provider, deployer or both. Pre-filled from the register.
  2. Prohibited practices (Article 5). Social scoring, manipulative techniques, untargeted facial scraping, emotion inference at work or school, real-time remote biometric identification in public, predictive policing from profiling, biometric categorisation by sensitive traits. If any apply, the answer is not a risk tier — it is that the system may not be placed on the market or used.
  3. Annex I products. Is it a safety component of, or itself, a product covered by EU harmonisation law needing third-party conformity assessment? Machinery, medical devices, lifts, toys.
  4. Annex III areas. Biometrics, critical infrastructure, education, employment and worker management, essential services, law enforcement, migration, justice. If you are not sure, say so — the app treats it as provisionally high-risk and flags it, which is the safe direction to be wrong in.
  5. The Article 6(3) derogation. Only if you named an Annex III area. Does it perform a narrow procedural task that does not materially influence outcomes or profile people? Claiming this needs a justification you can defend.
  6. Transparency triggers (Article 50). Does it interact with people, generate synthetic content, or do emotion recognition or biometric categorisation? These stack on top of any tier.
  7. General-purpose AI. Do you provide a GPAI model — not just use one through an API? Different question, different chapter of the Act.
The classification wizard on question four of seven, asking about Annex III high-risk areas.
Illustration Question four. The help text under each question is the plain-language version — you should not need the regulation open beside you to answer.
The classification result showing high risk and twelve obligations from articles 9 through 73.
Illustration A provider of an Annex III employment system: high risk, twelve obligations, each with its article. This list is what turns 'we should look into the AI Act' into a work plan.
What to do with the obligations

They are not tasks in the app — they are the shape of the work. Most of them map onto ISO 42001 controls you are about to work through in part 3: Article 9's risk management is Clause 6.1.2, Article 12's logging is Annex A.6.2.8, Article 14's human oversight is Annex A.9. Doing the standard properly covers most of the Act.

When to reclassify

Re-run the wizard when any of these happen. Each is cheap; missing one is not.

  • The system's purpose changes — especially if it starts influencing a decision about a person.
  • It moves from development into use.
  • You start providing something you previously only deployed, or you put your name on it.
  • You were unsure last time and now you know.

Each classification is recorded in the audit trail with who ran it and when, so "when did we last look at this?" has an answer.

← Getting started Next: close the gaps →