EU AI Act AI system inventory: inventory and classify your AI systems
Built, licensed and vendor-embedded AI share one portfolio, and no register says which system carries which duty. Under Regulation (EU) 2024/1689 the organisation is provider under Art. 3(3) for what it builds and deployer under Art. 3(4) for what it uses. A system high-risk under Art. 6 carries Art. 9 and Art. 17 for the provider or Art. 26 for the deployer from the Annex III application date Deferred, moved by Regulation (EU) 2026/1744 with the obligations unchanged. The page gives the sequence, its records and the consequence of an unclassified system.
Where this starts
The portfolio question comes before any obligation question. Art. 3(1) defines an AI system as a machine-based system that operates with varying levels of autonomy and infers from its input how to generate outputs such as predictions, recommendations or decisions. That definition reaches a scoring function inside a procurement suite as much as a model the organisation trained, so the inventory lists functions, each with its inputs, its outputs and the natural persons it affects, rather than products or vendors. PR-CLS v1.0 takes that function inventory as its input in steps 1 to 7 and runs every later determination against it; the enterprise hub lists what the register holds once the inventory exists. A synthetic extract in the protocol's inventory layout:
system_id,function_id,function,source,inputs,outputs,affected_persons
S-01,F-01,ranks applications for interview,built,application text and CV fields,ranked list,job applicants
S-02,F-01,scores credit applications,licensed,application data,score and decision flag,loan applicants
S-03,F-02,summarises support tickets,vendor-embedded,ticket text,summary text,none identified
Role is decided per system, and the same organisation holds both roles. It is the provider under Art. 3(3) of a system it developed, or had developed, and places on the market or puts into service under its own name or trademark; it is the deployer under Art. 3(4) of a system it uses under its own authority, which covers licensed products and the AI functions inside vendor software. Art. 25(1) moves a deployer into the provider role when it puts its name on a high-risk system, makes a substantial modification, or changes the intended purpose, so a vendor model re-trained on the organisation's data for a new use is the row to check first. Tier follows Art. 6: Annex I products and safety components under Art. 6(1), Annex III use cases under Art. 6(2), and the Art. 6(3) filter, which fails wherever the function profiles natural persons. The Act sets no numeric criterion for any of these routes; the reading of "intended purpose" and of the four Art. 6(3) conditions comes from Commission guidelines on high-risk classificationDraft, at the stage the badge shows, and a final version of that guideline can change a recorded result. The risk classifier runs the routes on the published logic from self-reported answers; PR-CLS runs them on the intended-purpose materials and the observed behaviour of each function.
What each system carries depends on the pair of role and tier. A built high-risk system carries the provider obligations of Art. 16, among them the risk management system under Art. 9 and the quality management system under Art. 17. A deployed high-risk system carries Art. 26: use in accordance with the instructions for use under Art. 26(1), human oversight assigned to natural persons with the necessary competence, training and authority under Art. 26(2), and retention of the logs under the deployer's control for at least six months under Art. 26(6) unless applicable Union or national law sets a different period. An Annex III system judged not high-risk under Art. 6(3) leaves a document: Art. 6(4) requires the provider to record that assessment before placing the system on the market or putting it into service and to give it to the national competent authority on request, and the registration duty under Art. 49(2) that follows is shown on the enterprise hub with both readings of its application date. The obligation tracker renders the register for one role and tier pair; the portfolio register in the sequence below joins those pairs across systems with the regulation entry id on every date.
The sequence
The work runs in the order below: the inventory, then role and tier per system, then the register, then the first evidence check per high-risk system in each role, then one matrix format across the portfolio.
List every system that meets the Art. 3(1) definition, with each function, its inputs, outputs and affected persons.
Record System identification record and function inventory, one row per function, with the source of each system marked built, licensed or vendor-embedded
[Regulation (EU) 2024/1689, Art. 3(1); PR-CLS steps 1, 2 and 5]
Record the role per system, provider or deployer, and check each Art. 25(1) trigger on the deployed ones.
Record Role determination record per system with the Art. 25 trigger record
[Regulation (EU) 2024/1689, Art. 3(3), 3(4) and Art. 25(1); PR-CLS steps 8 to 10]
Match each function against Annex I and the Annex III use cases, and check the intended-purpose materials for consistency.
Record High-risk classification record per function with the intended-purpose consistency record
[Regulation (EU) 2024/1689, Art. 6(1), 6(2) and Annex III; PR-CLS steps 12 to 14]
Test each Annex III match against the four Art. 6(3) conditions and the profiling rule, and document the outcome.
Record Art. 6(3) assessment record per Annex III match, with the profiling check and the Art. 6(4) documentation check
[Regulation (EU) 2024/1689, Art. 6(3) and 6(4); PR-CLS steps 15 to 17]
Assign each function to the Art. 50 paragraphs that apply and record each general-purpose AI model in use.
Record Article 50 applicability record per function and GPAI determination record per model
[Regulation (EU) 2024/1689, Art. 50(1) to (4) and Art. 3(63); PR-CLS steps 19 and 35]
Compile one obligation register across the portfolio, with the regulation entry id for each application date.
Record Obligation register: applicable articles per system and role, regulation entry id per date, protocol per testable element
[PR-CLS steps 38 to 41]
For each built high-risk system, inventory the quality management documents and check the risk management file.
Record Document inventory and gap register per built high-risk system, with the risk management file check
[Regulation (EU) 2024/1689, Art. 9(1) and Art. 17(1); PR-17-QMS steps 2, 8 and 24 to 26]
For each deployed high-risk system, record the oversight assignment, the conformance to the instructions and the log retention.
Record Instructions-for-use conformance record, human oversight assignment record and log retention configuration evidence per deployed high-risk system
[Regulation (EU) 2024/1689, Art. 26(1), 26(2) and 26(6); PR-14-OVR steps 8, 9 and 25; PR-12-LOG steps 9 and 24]
Open one traceability matrix per system in the same format, from obligation to test to evidence.
Record Traceability matrix per system in one format: obligation, element, test, evidence location
[AIAssuranceLabs procedure]
Evidence this situation ends with
| Artifact | Answers | Produced by |
|---|---|---|
| AI system inventory with role, risk tier, Art. 50 function and general-purpose AI use recorded per system | Art. 3(1), 3(3) and 3(4): which systems are in scope and in which role the organisation holds each | the provider or the deployer, on the PR-CLS inventory layout |
| Role determination record (PR-CLS output) | Art. 3(3), 3(4) and Art. 25(1): the role per system and any trigger that moves a deployer into the provider role | PR-CLS v1.0 |
| High-risk classification record (PR-CLS output) | Art. 6(1), 6(2) and Annex III: the route tested and the result per function, with the intended-purpose consistency check | PR-CLS v1.0 |
| Article 6(3) assessment record (PR-CLS output) | Art. 6(3) and 6(4): the condition relied on, the profiling check, and the documentation dated before placing on the market | PR-CLS v1.0 |
| Obligation register (PR-CLS output) | Art. 16 and Art. 26: the applicable articles per system and role, with the regulation entry id per application date | PR-CLS v1.0 |
| Risk management file (Art. 9(1)) | Art. 9(1): the risk management system of each built high-risk system is documented and maintained | the provider |
| QMS gap analysis report (PR-17-QMS output) | Art. 17(1)(a) to (m): each aspect marked conforms, partial or gap per built high-risk system, with the sampled record | PR-17-QMS v1.0 |
| Human oversight assignment record (Art. 26(2)) | Art. 26(2): the natural persons assigned per deployed high-risk system, with competence, training and authority recorded | the deployer |
Each artifact follows a specification with a synthetic sample on the deliverables page: the classification and role records follow the assessment memo specification, the inventory and the obligation register follow the register or checklist specification, the gap analysis report follows the findings register specification, and the per-system matrix from the last step follows the traceability matrix specification, so that internal audit reads one layout across business units.
If nothing is done
A system left out of the inventory keeps its obligations. A built system whose intended purpose matches an Annex III use case and reaches the market after the Annex III application date without the Art. 16 evidence is subject to the market surveillance procedure of Art. 79: the authority evaluates the system and, where it finds that the Chapter III requirements are not met, requires the provider to take corrective action, to withdraw the system or to recall it within a period the authority sets, under Art. 79(2). A deployed high-risk system used without the Art. 26(2) oversight assignment or outside the instructions for use falls under the same procedure on the deployer's side, and a finding against the provider obligations in Art. 16 or the deployer obligations in Art. 26 sits in the penalty tier of Art. 99(4), with the amount set by the national authority under the Art. 99(7) criteria. A not-high-risk conclusion that was never written down cannot be produced on request under Art. 6(4), and an answer to an authority that is incomplete or misleading falls under Art. 99(5). The action that follows is the sequence above: the inventory, the classification under PR-CLS, the register, then corrective action under Art. 20 for a built system and suspension of use with notification under Art. 26(5) for a deployed one.
Services, guides and tools for this situation
The classification and readiness assessment runs PR-CLS v1.0 across the portfolio and delivers the classification memo, the obligation register and the gap list, within the limits stated on what we cannot do; the quality management gap analysis for built high-risk systems and the oversight and logging checks for deployed ones are separate services listed on the enterprise hub.
- Guides
- ICP hubs
Questions
What is AI Act classification?
Classification under Regulation (EU) 2024/1689 is the determination, per AI system, of the role under Art. 3 and the tier under Art. 6: high-risk as an Annex I product or safety component under Art. 6(1), high-risk as an Annex III use case under Art. 6(2), or removed from Annex III by an Art. 6(3) condition where the function performs no profiling. Role and tier decide the obligation set. Art. 6(4) requires a provider that relies on Art. 6(3) to document the assessment before placing the system on the market.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.