AI inventory: the record that fixes scope, risk, and ownership before use
A tool list is not enough. Classification depends on intended purpose, the function actually performed, the context of use and, where relevant, Article 6's two routes: regulated product or an Annex III use case.
- Nature
- Operational guide with a Velqory classification record
- Audience
- Product, legal, risk, procurement, security, and process owners
- Published and verified
- 4 August 2026
- Limit
- The record supports the decision; it does not replace legal classification of the specific case
In brief
An organisation needs a stable unit of analysis: system, version, purpose, affected population, and supported decision. It can then record the role of provider, deployer, importer, or distributor; test the product-safety route; compare use against Annex III; document exceptions; and name the person approving the conclusion. The Velqory record is not a legally prescribed form. It is an operational mechanism that prevents classification from living only in a slide deck or falling behind system change.
- An inventory by vendor hides different uses; the useful unit is system × purpose × context × version.
- Article 6 has two high-risk routes: a regulated product requiring third-party conformity assessment and Annex III uses.
- A non-high-risk conclusion under Article 6(3) needs documented reasoning and may change with actual use.
- Classification guidance published in May 2026 is still identified as draft and must not be described as final.
Classification starts before asking whether a system is high-risk
Record who supplies and uses the system, but do not stop at its commercial name. The same model may summarise internal documents, shortlist applicants, or support access to an essential service. Purpose and effect differ, so the record and analysis must differ too.
For the product route, determine whether the system is a product or safety component covered by relevant harmonisation law and subject to third-party conformity assessment. For the second route, map actual use against Annex III. Do not classify through word matching: describe the function and the people on whom it has an effect.
Classification path with evidence gates
- INPUTFix the unit
System, version, intended purpose, context, process, users, and affected population.
- ROLEDetermine position
Record who develops, places on the market, imports, distributes, and uses under its authority.
- ROUTE ATest regulated product
Identify applicable law, safety function, and third-party assessment requirement.
- ROUTE BTest Annex III
Compare actual use, effect, and affected people with every relevant category.
- GATEApprove and set review
Store reasoning, evidence, owner, restrictions, date, and reclassification triggers.
The minimum record turns labels into verifiable facts
A useful inventory lets another reviewer reconstruct the decision without relying on its author's memory. Every field should point to evidence: instructions for use, contract, process design, affected group, conformity assessment, or product decision.
Classification record and acceptance criterion
| Field | Operational question | Evidence | Gate |
|---|---|---|---|
| Identity | Which system and version? | Internal ID, supplier, version, date | No version, no approval |
| Purpose | Which decision or action? | Actual flow and use instruction | Ban unevaluated uses |
| Role | What is each entity's position? | Contract, control, market placement | Escalate ambiguity |
| Article 6 route | Regulated product or Annex III? | Legal and functional mapping | Legal review where needed |
| Conclusion | High-risk, not high-risk, or out of scope? | Reasoning, approver, conditions | No reasoning, no launch |
| Change | What reopens the decision? | Model, data, purpose, population, process | Reclassify before change |
The inventory only works when approved use and real use stay aligned
Connect the record to procurement, production approval, and the integration catalogue. The system owner confirms purpose periodically and responds immediately to material change; legal interprets the rule, while the operational owner proves what happens in practice.
Where a conclusion relies on Article 6(3), document why the system does not pose a significant risk of harm to health, safety, or fundamental rights and which relevant condition supports that view. Do not turn the exception into a preselected checkbox.
- Block secondary uses until a new record is approved.
- Connect incidents, complaints, and supplier changes to review triggers.
- Retain the evidence version, not only a live link.
- Separate ‘not high-risk’ from ‘no obligations’: other AI Act rules may still apply.
Sources consulted
Consulted on the stated update date.
Opens in a new window.- 01AI Act Article 6 — Classification rulesAI Act Service Desk · EU-AIACTDESK
- 02AI Act Annex III — High-risk use casesAI Act Service Desk · EU-AIACTDESK
- 03AI Act Article 26 — Obligations of deployersAI Act Service Desk · EU-AIACTDESK
- 04Draft guidelines on classification of high-risk AI systemsEuropean Commission · EU-DIGITAL
- 05Navigating the AI Act — official FAQEuropean Commission · EU-DIGITAL
- 06Regulation (EU) 2024/1689 — Artificial Intelligence ActEUR-Lex · EU-EURLEX
Participate
Share the analysis. Add context.
Distribute the article through your channel or leave an observation connected to the topic.
Comments
Loading the conversation.