Build an AI system inventory that supports EU AI Act decisions

An AI system inventory should let an organisation decide what each use does, which legal role it may hold, who can be affected and which evidence is still missing. A vendor list or model catalogue is not enough.

The EU AI Act assigns obligations according to the system, use and actor. The Commission describes enforcement responsibilities for the AI Office and national authorities from 2 August 2026. European Commission AI Act overview

Regulation (EU) 2026/1744 changed the application dates for Chapter III, Sections 1–3, except Article 6(5): 2 December 2027 for systems classified under Article 6(2) and Annex III, and 2 August 2028 for those under Article 6(1) and Annex I. Other provisions and transitional cases have separate dates. Amending regulation, Article 1(40)

This guide offers an original inventory method for France and wider EU operations. The Act does not require the particular spreadsheet or fields proposed here, and an inventory does not by itself establish compliance.

Inventory use cases, not just vendors. Record purpose, users, affected people, geography and decision effect. Map provider, deployer, importer or distributor roles for each use. Keep unresolved legal questions visible and revalidate the record when the system or use changes.

Use the deployed use case as the primary record: for example, “rank customer-service tickets for the France support queue.” Link that record to the product, model, version and supplier, but do not merge different uses simply because they rely on one platform.

Describe the intended purpose and actual operating context. Record who initiates the system, who receives the output, whether the output influences a decision and which people or groups may be affected. Include pilot, embedded and externally hosted tools.

Distinguish an AI feature from the wider process. A generative summary used as a draft may have a different effect from the same model used to screen applicants. The inventory should expose that difference before classification.

Ask who develops the system, places it on the market, deploys it under authority, imports it or distributes it. A company can hold different roles for different systems, and contract labels may not decide the legal position.

Record where the system is offered, used and affects people. Include group services operated outside France when they support EU decisions. Flag cross-border data, customer or employment contexts for the relevant legal teams.

Add the first-use date, current status and planned retirement date. Different obligations and guidance apply at different times. A record saying only “AI Act applies” is too coarse to manage that timeline.

Link supplier documentation, system instructions, data description, human-oversight design, testing and incident contacts. Record the source and date of every classification decision. If information is missing, use a status such as “assessment blocked” rather than guessing.

Include prompts for prohibited practices, high-risk use cases, transparency obligations and general-purpose AI dependencies, but have competent reviewers interpret them. The Commission's public overview describes categories and dates; the current regulation and official guidance remain the controlling sources.

Use the EU AI Act Service Desk as an official route to current resources. Do not copy an old checklist into the inventory and freeze it while implementation guidance changes.

Assume a fictional Paris employer uses an AI-enabled product to draft job descriptions and, separately, to rank applicants. The supplier and model are the same, but the purpose, affected people and decision effect differ.

The inventory therefore creates two records. The drafting use records a human editing step and publication route. The ranking use records the employment decision context, data, oversight, supplier evidence and an unresolved high-risk assessment requiring legal review. Procurement cannot close the second record by pointing to the lower-impact first use.

This example is hypothetical and does not classify a real product or determine compliance.

The following entries complete the fictional Paris example. They are proposed inventory decisions, not legal classifications of a real system.

The practical output is two accountable assessments, even when purchasing has only one supplier line. Add the actual product configuration and supplier evidence reference to each before deciding whether their roles and obligations are the same. A human editing step is a process fact, not a general exemption from the Act.

Record application dates in a separate provision-level field. A date for high-risk obligations should not overwrite the dates for other duties. The Commission's consolidated Article 113 presentation identifies the deferred provisions and exceptions. Have the responsible reviewer connect the relevant provision to the particular use and any transitional case; do not turn this illustrative table into an automatic legal classifier.

Assign a business owner and technical contact for every active record. Revalidate when the purpose, model, data, geography, user group or decision authority changes. Connect procurement and access management so new tools do not remain invisible.

Use ISO/IEC 42001 preparation that starts with clear AI boundaries when building a broader management-system scope. The AI Act inventory and an ISO management-system boundary can support each other, but they are not the same decision.

Retire records visibly. Record when use stopped, what data or access remains and how evidence is retained. Do not delete the history that explains past decisions unless the authorised retention programme requires it.

Use a level that preserves meaningful differences in purpose, role and effect. Grouping is reasonable only when one record still supports accurate decisions and ownership.

No. It organises facts and evidence for competent assessment. Treat automated labels as suggestions that require review.

Yes, when discovered. Record the use and risk, then decide whether to prohibit, contain or authorise it through the appropriate governance route. Do not hide it because procurement was bypassed.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.