Building an AI System Inventory 2026: 8-Step Guide

1. Why an AI inventory is mandatory

Even though the EU AI Act contains no explicit "inventory" article, an inventory is the operational minimum standard for several obligations:

• Art. 4 (since 2 February 2025) — AI literacy requires staff to be trained on the AI that is in use. Without an inventory, you cannot train. Infringements of Art. 4 are not covered by the fine catalogue of Art. 99(4) — penalties follow national law pursuant to Art. 99(1).
• Art. 5 — Prohibited practices must be ruled out. That is only possible with an overview.
• Art. 26 — Deployer obligations for high-risk AI. Without classification, no compliance.
• Art. 99 — Fines are tiered: up to EUR 35 million / 7 % (prohibitions under Art. 5), up to EUR 15 million / 3 % (paragraph 4 — obligations of providers Art. 16, authorised representatives Art. 22, importers Art. 23, distributors Art. 24, deployers Art. 26, notified bodies Art. 31/33/34 and the transparency obligations of Art. 50), up to EUR 7.5 million / 1 % (incorrect information supplied to authorities) — the burden of proof lies with the controller.

The reason lies in the structure of the regulation: the AI Act (Regulation (EU) 2024/1689) follows a risk-based approach — the type and content of the rules are tailored to the intensity and scope of the risks (recital 26). This produces prohibited practices (Art. 5), high-risk AI systems (Art. 6 et seq.) and AI systems subject to specific transparency obligations (Art. 50). Each of these tiers attaches to the individual AI system, not to the company. If you do not know which systems are running in your organisation, you can neither determine the tier nor assign the obligations attached to it.

On top of this comes the transparency layer of Art. 50 AI Act, which is separated by addressee: providers must ensure that AI systems intended to interact directly with natural persons inform those persons that they are interacting with AI (paragraph 1), and must mark synthetic audio, image, video or text content in a machine-readable format as artificially generated or manipulated (paragraph 2). Deployers of emotion recognition or biometric categorisation systems inform the persons concerned (paragraph 3); deployers who generate or manipulate deep fakes disclose that the content has been artificially generated or manipulated (paragraph 4). Which of these obligations apply to you depends on your role for each application — the inventory is the list you work through.

2. The 8-step guide

The build follows eight steps: first record, then check whether an AI system exists at all, then determine the model and risk class, followed by the FRIA trigger, role, training and ongoing updates. The "Basis" column names the provision that each step attaches to; where no provision prescribes the step itself, it is expressly marked as a practitioner recommendation.

Step 1 — Discovery: collect first, do not assess

The aim is an unfiltered raw list of all tools actually in use. What to do: survey each business unit individually, review IT systems and licence or billing data, and consolidate the results into a single list — without passing judgement at this stage. Why: every subsequent check attaches to a specific system; whatever is missing here will also be missing from classification, training and oversight. Source: for discovery itself the AI Act prescribes no specific provision — this step is a practitioner recommendation. Only the steps built on top of it become binding.

Step 2 — AI system yes/no: the Art. 3 test

Each tool is tested against the legal definition. Under Art. 3 no. 1 AI Act, an AI system is a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment and that, from the input it receives, infers how to generate outputs — such as predictions, content, recommendations or decisions — that can influence physical or virtual environments. Why this belongs in the documentation: the classification decides whether the regulation applies to that tool at all. Practitioner recommendation: record for each tool which element of the definition you affirmed or rejected — the traceable assessment is your evidence, not the outcome alone.

Step 3 — GPAI marking: separating the model level from the system level

Mark which systems are built on a general-purpose AI model. Under Art. 3 no. 63 AI Act, this is a model displaying significant generality, capable of competently performing a wide range of distinct tasks and that can be integrated into a variety of downstream systems. Why the marking matters: separate provider obligations apply at model level under Art. 53 AI Act — technical documentation under Annex XI, information for downstream providers under Annex XII, a copyright policy and a public summary of training data — and they have applied since 2 August 2025 (Chapter V, Art. 113(b) AI Act). For you as a deployer, the column separates the systems built on a third-party model from the rest: for those, a change of model by the provider can alter functionality and data flow without any visible change to the tool.

Step 4 — Determining risk: Art. 5 first, then Annex III

Risk classification runs in two passes. First, the prohibition screening: Art. 5(1) AI Act prohibits, among other things, social scoring, the exploitation of vulnerabilities due to age, disability or a social or economic situation, emotion recognition in the workplace and in education institutions, and biometric categorisation to infer sensitive attributes. Then the Annex III check across the eight areas: biometrics; critical infrastructure; education and vocational training; employment and workers management; access to essential private and public services; law enforcement; migration, asylum and border control; administration of justice and democratic processes (Art. 6(2)). The filter mechanism of Art. 6(3) is narrow: a listed system exceptionally does not qualify as high-risk if it does not pose a significant risk to health, safety or fundamental rights — but not if it performs profiling of natural persons. Practitioner recommendation: when in doubt, classify high.

Step 5 — FRIA trigger: only for the group of deployers named in the law

The fundamental rights impact assessment is not automatic for every high-risk AI system. Under Art. 27(1) AI Act, it applies to deployers that are bodies governed by public law or private entities providing public services, as well as to deployers of high-risk AI systems under Annex III no. 5(b) (evaluation of creditworthiness and credit scoring of natural persons) and (c) (risk assessment and pricing in life and health insurance). Why the column is nevertheless filled in for every high-risk system: it also documents the reasoned "not required". A private company that provides no public services and uses high-risk AI in workers management (Annex III no. 4) does not belong to this group — the data protection impact assessment may exist independently of this (see section 3).

Step 6 — Provider/deployer role: per tool, not per company

For each system, record whether you are a provider (Art. 3 no. 3 AI Act) or a deployer (Art. 3 no. 4 AI Act) — a provider develops or places on the market, a deployer uses under its own authority. Most SMEs are pure deployers and not providers. Why the entry is kept per tool: the role can differ from system to system and it can change. Under Art. 25 AI Act, a deployer becomes a provider if it substantially modifies the purpose or the functionality, or places the system on the market under its own name — for example a RAG system on a GPAI interface that is marketed as a product of its own. Which obligations attach to which role is shown in section 7.

Step 7 — AI literacy training per tool

Training is not about "AI in general" but about the specific use. Art. 4 AI Act has applied since 2 February 2025 and requires staff to be trained on the AI in use; the content that has proven effective covers the AI definition, risk classes, prohibited practices, transparency obligations and human oversight. Why this attaches to the inventory row: without a mapping of tool → user group → training date, the evidence cannot be produced. On the penalty position, see section 1: Art. 4 does not fall under Art. 99(4). Practitioner recommendation: document the training date, the participants and a knowledge quiz for each tool.

Step 8 — Embedding the update cycle

The final step turns the snapshot into a maintained register: named responsible owners, fixed review dates and defined triggers. A quarterly review date is a practitioner recommendation and not a statutory deadline (see section 5). What is binding, by contrast, are the obligations attached to individual systems: putting a new high-risk system into use as a deployer triggers the obligations of Art. 26 AI Act. Which events should trigger an update is likewise set out in section 5.

3. Excel template columns (minimum standard)

Twelve columns are enough for the minimum standard — each of them serves a specific check from the eight steps:

1. Tool name + version
2. Provider (manufacturer)
3. Use case (one short sentence)
4. GPAI yes/no (model ID if known)
5. Data categories processed
6. Annex III area (1-8 or "none")
7. Risk class (prohibited / high / limited / minimal)
8. FRIA status (not required / open / completed)
9. AI literacy training (date)
10. Approved by / date
11. Responsible business unit
12. Last update + next review

Column 5 (data categories) is the bridge to data protection and the most frequently underestimated one. It records whether personal data and, in particular, special categories under Art. 9(1) GDPR are processed — health data, biometric data for the purpose of uniquely identifying a natural person, data on racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, sex life or sexual orientation. The data protection impact assessment attaches to this: under Art. 35(1) GDPR it must be carried out in advance where processing — in particular using new technologies — is likely to result in a high risk to the rights and freedoms of natural persons. The DPIA and the FRIA have different triggers and must be kept separate; the distinction is covered in detail in GDPR + EU AI Act: the dual obligation.

Practitioner recommendation for two further fields that no provision prescribes: a reference to the data processing agreement where the tool provider processes personal data on your behalf — under Art. 28(1) and (3) GDPR only with processors providing sufficient guarantees and on the basis of a contract with the statutory minimum content — and a free-text field for the reasoning behind the risk classification.

4. 12 SME examples of typical AI tools (as at 04/2026)

The following examples show how columns 4, 6, 7 and 8 interact. The tool and market details are those of the first edition (04/2026) and are reproduced here unchanged; check product status and model changes before adopting them into your own inventory.

Two rows are deliberately different: for credit scoring, the FRIA applies directly under Art. 27(1) AI Act because Annex III no. 5(b) is expressly named there. For the HR recruiting software that is not the case — Annex III no. 4 triggers the FRIA only where the deployer is at the same time a body governed by public law or a private provider of public services. That an evaluative HR system is nevertheless high-risk follows from Annex III no. 4 itself: CV match scoring, performance scoring and workforce planning with promotion or termination recommendations evaluate persons; a pure HR FAQ chatbot does not.

5. Update cycle + triggers

• Quarterly: review all entries, add new tools, remove obsolete ones
• Trigger-based: changes to Annex III, amendments to the AI Act such as those made by Regulation (EU) 2026/1744 (Digital Omnibus AI) (in force since 27 July 2026), new FAQs from the supervisory authorities
• Whenever a tool is procured: AI check before purchase, IT must mark "AI yes/no"
• On contract renewal: check the provider's AUP, update the data flow

The quarterly review and the triggers named are practitioner cycles, not statutory deadlines: the AI Act contains no inventory article of its own (see section 1) and therefore no prescribed interval for keeping it up to date either. What is fixed in law, by contrast, are the dates of Art. 113 AI Act (see section 8) and the obligations triggered by a new system.

The Digital Omnibus on AI has been adopted: Regulation (EU) 2026/1744 of 8 July 2026 has been in force since 27 July 2026. Since then, the high-risk obligations of Chapter III Sections 1–3 apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028; the general date of application of 2 August 2026 (including Art. 50) remains. Even so, check the current position against the primary source before any scheduling. A further practitioner recommendation on triggers: a change of model at the tool provider (for example a change of model generation behind an assistant) changes your inventory row — data flow, GPAI marking and training content then have to be reassessed.

6. Audit preparation

1. Inventory <6 months old
2. Per tool: approval workflow traceable
3. FRIAs prepared for the deployers covered by Art. 27(1) AI Act — Art. 27 belongs to Chapter III Section 3 and covers only high-risk AI systems under Art. 6(2) and Annex III; for these, the obligations of Chapter III Sections 1–3 apply, under Regulation (EU) 2026/1744, in force since 27 July 2026, only from 2 December 2027 (Art. 113(3)(c) AI Act)
4. AI literacy training log with knowledge quiz
5. Acceptable use policy <12 months old
6. Data breach procedure documented for AI tools as well

The age requirements in points 1 and 5 are practitioner recommendations and not statutory deadlines. What must be produced on the basis of a provision depends on your role: as the deployer of a high-risk system, these are the relevance check of the input data (Art. 26(4)), the retention of the automatically generated logs for at least six months (Art. 26(6)) and the information of the workers concerned (Art. 26(7)). Practitioner recommendation: record for each high-risk row where the logs are stored and who can hand them over.

For point 6, the data protection side continues to apply unchanged: a personal data breach must be notified to the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, where it is likely to result in a risk to the rights and freedoms of natural persons (Art. 33(1) GDPR); where a high risk is likely, the persons concerned must additionally be informed without undue delay (Art. 34(1) GDPR).

7. Obligations by role: what sits behind the role column

The role column determines the scope of obligations: providers bear the product obligations, deployers the use obligations, and GPAI providers additionally the model obligations of Chapter V. The following overview names, for each row, the obligation, who it applies to and the source.

The threshold for systemic risk is a cumulative amount of computation used for training of more than 10²⁵ floating point operations; high-impact capabilities are then presumed (Art. 51(1) and (2) AI Act). Supervision of Chapter V lies with the European Commission, which entrusts implementation to the AI Office (Art. 88(1) AI Act) — the national market surveillance authorities are therefore not competent for the GPAI provider obligations. Until a harmonised standard is published, providers may rely on codes of practice under Art. 56 AI Act to demonstrate compliance (Art. 53(4), and Art. 55(2) in the case of systemic risk) — only a harmonised European standard expressly gives rise to the presumption of conformity.

8. Statutory dates at a glance

What counts for planning are the dates of the AI Act — they apply identically in Germany and Austria. The following overview names statutory dates only, no practitioner recommendations.

For the inventory, this means: rows with an Annex III link carry the high-risk deployer or provider obligations of Chapter III Sections 1–3 from 2 December 2027. For systems that only become high-risk via Art. 6(1) — safety components in Annex I products with third-party conformity assessment — the corresponding obligations only apply from 2 August 2028; practitioner recommendation: create these rows today anyway and flag them with the date.

9. Germany and Austria

The AI Act is a directly applicable EU regulation: definitions, Annex III, the exception in Art. 6(3), the provider and deployer obligations and all dates apply in Austria in identical wording to Germany. The inventory structure of the eight steps is therefore transferable one to one; no rebuild around national provisions is needed for it. Only the authority structure and the penalty regime within the framework of Art. 99(1) AI Act are governed nationally.

Authorities: each Member State shall establish or designate at least one notifying authority and at least one market surveillance authority; one market surveillance authority is to be designated as the single point of contact, whose contact details had to be made publicly available by 2 August 2025 (Art. 70(1) and (2) AI Act). In Germany, the market surveillance authority has been the Federal Network Agency (Bundesnetzagentur) since 29 July 2026 (§ 2(1) KI-MIG), unless sectoral authorities — such as BaFin — are competent. As at the date of this article (17 August 2026), Austria has not designated a market surveillance authority under Art. 70 AI Act; the RTR's AI service point is an information and advisory body without supervisory powers. Practitioner recommendation: record the point of contact competent for your location on the inventory cover sheet before you have to look for it in an emergency.

Discrimination liability in HR cases: here the two legal systems diverge, and they do so independently of the AI Act. In Germany, § 22 AGG applies: where one party proves indicia giving rise to a presumption of discrimination on a ground named in § 1 AGG, the other party bears the burden of proving that there was no infringement. In Austria, this is replaced by the standard of prima facie evidence (Glaubhaftmachung) under § 12(12) GlBG (discrimination on grounds of sex) and § 26(12) GlBG (ethnic origin, religion or belief, age, sexual orientation): the person concerned establishes the discrimination on a prima facie basis, after which it is for the defendant party to prove that, weighing all the circumstances, it is more likely that another motive was decisive or that a justification exists. These are different standards — the Austrian rule is not a reversal of the burden of proof of the German kind. In Austria, the Ombud for Equal Treatment (GAW) and the Equal Treatment Commission (Gleichbehandlungskommission) as well as the labour and social courts are competent; in Germany, the Federal Anti-Discrimination Agency (Antidiskriminierungsstelle des Bundes) (§ 25 AGG). For the inventory this means: with HR systems, the legal system belongs in the row, because the evidence position depends on it.