Use an inventory to collect facts
An inventory can help identify AI use cases, owners, deployment context and affected people before a legal classification is made. It does not determine AI Act applicability by itself. Obtain the current official regulation and qualified advice for obligations, dates and your organisation’s role.
Keep legal class separate from triage
The builder’s high-priority review label is an editorial routing rule based on data and autonomy. It is not the EU AI Act high-risk category. Add a separate legal-class field to your controlled register with the assessor, decision date and supporting reasoning. Never copy the triage output into that field automatically.
Capture provider and deployer context
Record what your organisation develops, markets, modifies or uses, who supplies components and how the system is intended to operate. Do not decide the role solely from whether you pay for a vendor service. Preserve a description of the actual use and any modifications for legal review.
Worked inventory example
A drafting assistant used to summarise internal public material and a system influencing recruitment decisions require different contextual records. Record purpose, affected groups, input data, human review and decision influence for each. That evidence supports assessment; the inventory does not assign either a legal category.
Track assessment and changes
Link the legal assessment reference, owner and next review date. Trigger reassessment when intended use, deployment role or decision influence changes. If applicability has not been determined, leave the field unassigned and seek qualified review rather than interpreting a complete inventory as permission to deploy.
Capture the facts a reviewer needs
For each deployment, preserve the intended purpose in the product or workflow owner's words, the actual use, affected people, setting, data, human role and any action the system can take. Record the provider, deployer and other operators based on what each organization actually does. A purchase order alone does not establish the legal role. Note the model and system version, modifications, supplied components, country of use and evidence sources in your controlled records. The manual builder does not have dedicated fields for every legal or technical detail, so link to the authoritative record where necessary.
Use an evidence column to distinguish a confirmed fact from a label, assumption or marketing description. Record who supplied the evidence and when it was checked. When a system changes purpose, audience, autonomy, data or integration, route it for a fresh assessment. Keep the inventory status separate from the legal conclusion and preserve the reviewer's rationale so later operators understand how the conclusion was reached.
Understand the high-risk assessment routes
The current consolidated Act describes two routes in Article 6: certain systems that are products or safety components under the Union legislation listed in Annex I and require third-party conformity assessment; and systems intended for the use cases described in Annex III. A broad industry label is not enough to decide either route. A reviewer must check the actual intended purpose, the specific Annex entry and any relevant conditions or exclusions.
Article 6(3) provides a derogation for an Annex III system only where it does not pose significant risk and meets one of the listed task conditions; profiling of natural persons remains high-risk. Under Article 6(4), a provider that considers an Annex III system not high-risk must document its assessment before placing it on the market or putting it into service, and Article 49(2) requires the provider or authorised representative to register the system. This is a provider assessment, not a field value an inventory tool can calculate.
Keep registration separate from the inventory
Article 49 does not create a registration task for every AI system. It specifies EU-database registration for providers or authorised representatives for certain Annex III systems, except point 2; it also covers providers that document an Article 6(3) not-high-risk conclusion for an Annex III system. Specified public-authority deployers have a separate registration role. Annex III point 2 uses national registration, and certain law-enforcement, migration, asylum and border cases use a secure non-public database section. The exact operator, system category and paragraph matter.
A row in this site’s CSV does not create an EU database entry, select the right registry or determine whether an Article 49 duty applies. If a reviewer finds a potential match, capture the specific provision, responsible operator, review date, rationale and required next step in the organization's legal workflow. Confirm timing and transition provisions against the current official consolidated text; this page does not set a deadline for a particular system.
Use an illustrative recruitment example
A hypothetical employer records a vendor system used to rank applicants for recruiter review. The inventory captures recruitment purpose, applicants affected, vendor, employer's actual configuration, input data, human review and decision influence. The reviewer then checks the precise Annex III employment entry and Article 6 conditions. A separate scheduling feature that only arranges interview slots must be examined for its own intended purpose and influence. The example is not a determination that any actual product or deployment is high-risk.
Keep a separate record for a provider's assessment, deployer obligations and any registration action. If facts are missing, assign a qualified reviewer and leave the legal conclusion unmade. Do not copy the builder's high-priority review label into an AI Act risk-class field.
Check the current EUR-Lex consolidated AI Act and its linked Official Journal acts. Use the AI inventory template, AI agent inventory template, and manual builder to organize facts; they do not replace legal review or registration.