AI System Inventory for EU AI Act Compliance: The Complete Register Guide

You cannot classify, risk-assess, or govern what you have not catalogued. That sentence is the entire case for building an AI inventory before you touch anything else in EU AI Act compliance.

An AI inventory — also called an AI register — is a structured, organisation-wide record of every AI system you develop, deploy, import, or distribute. It is the foundational control under Regulation (EU) 2024/1689. Every downstream obligation — risk classification under Article 6, technical documentation under Article 11, the risk management system under Article 9, conformity assessment under Article 43, Article 49 registration in the EU database, post-market monitoring under Article 72 — depends on knowing which systems exist and which role your organisation holds in relation to each one. Without the inventory, you are building compliance on air.

---

What an AI Inventory Is (and Is Not)

An AI inventory is an internal control document. It lists every AI system in scope, records key facts about each one, and tracks the compliance obligations that attach to it. It belongs to your organisation, lives in your systems, and is not submitted to any authority.

It is distinct from the EU database registration required by Article 49 for high-risk AI systems. That registration is a public-facing filing with the European Commission's centralised database — a regulatory act, not an internal record. Your inventory is the prerequisite that makes an accurate Article 49 filing possible. You cannot file what you have not first catalogued and classified. The two instruments serve different purposes and operate at different layers; both are required, but they are not the same thing (see the dedicated section below).

An AI inventory is also not a data processing record under GDPR Article 30 — though there is significant overlap and the two should be aligned (covered later in this guide).

In scope for the inventory: every system that meets the Article 3 definition of an AI system — a machine-based system that, for defined objectives, generates outputs such as predictions, recommendations, decisions, or content that influence real or virtual environments. In practice this includes third-party SaaS tools with AI features, custom-developed models, AI components embedded in larger software products, and GPAI-based tools built on top of foundation models. Out of scope: rule-based decision-support tools that operate purely on explicit if-then logic without any learning component, and basic automation (robotic process automation that executes fixed scripts). If you are uncertain, include the system and classify it — the documentation cost of being wrong is low; the compliance cost of missing a high-risk system is not.

---

Why the Inventory Is Step One

Classification, technical documentation, risk assessment, audit readiness, and registration all depend on a complete, accurate inventory. Remove it and the rest of the compliance stack collapses.

Classification depends on it. Article 6 requires you to determine whether each system falls under Article 5 (prohibited), Annex III (high-risk), Article 50 (limited/transparency risk), or minimal risk. You cannot run that analysis without a list of systems to analyse.

Technical documentation depends on it. Article 11 requires providers to compile an Annex IV technical file for every high-risk system. You cannot start the file until you know which systems are high-risk — which you learn from classification, which you learn from inventory.

The risk management system depends on it. Article 9 requires a continuous risk management process covering the full lifecycle of each high-risk system. "Full lifecycle" requires knowing what systems exist and where they are in their lifecycle.

The Article 49 EU database registration depends on it. Providers must register high-risk Annex III systems before placing them on the market. The registration fields map directly to inventory fields: system name, intended purpose, Annex III category, conformity status. The inventory feeds the filing.

Audit and inspection readiness depends on it. Supervisory authorities conducting market surveillance under Articles 74–85 will ask for evidence that your compliance programme is systematic, not reactive. A complete, timestamped inventory is that evidence.

A common mistake is to treat inventory as a late-stage documentation task — something you clean up before a certification or an audit. It should be the first task, because everything else is blocked without it.

---

The Shadow-AI Problem

Before you can build an inventory, you have to find the AI. This is harder than it sounds.

In most organisations above 20 people, AI tools are adopted at team level, without IT or compliance sign-off. A recruiter signs up for a CV-screening tool. A finance team adopts an invoice-processing system. A sales team connects a lead-scoring model to their CRM. None of these show up in the official software register. None are in the IT asset list. The compliance team has no visibility.

This is shadow AI, and it is the number-one source of inventory gaps. It matters for EU AI Act compliance in two ways. First, if any of these tools falls into an Annex III category — and a CV-screening tool does, under the employment heading — the obligations apply regardless of whether compliance knew about the deployment. Ignorance is not a defence. Second, deployers have specific obligations under Article 26: using a high-risk system in a professional context requires implementing the provider's instructions for use, ensuring human oversight under Article 14, maintaining logs under Article 12, and — for certain public-sector and regulated-sector deployers — running a Fundamental Rights Impact Assessment under Article 27. None of that can happen if the system is invisible.

Practical discovery steps:

• Software licence audit. Pull a complete list of SaaS subscriptions and cloud spend. Flag anything with "AI", "ML", "scoring", "screening", "prediction", or "automation" in the product description.
• Procurement review. Check contracts and purchase orders from the last 24 months for AI-adjacent vendors.
• Structured departmental intake. A short questionnaire to department heads: "Do you use any tool that makes recommendations, scores, ranks, or automates decisions about people or processes?" The phrase "AI system" will not prompt disclosure; the functional description will.
• Quarterly repeat. Shadow AI is a continuous problem, not a one-time find. Build the discovery process into your compliance calendar.

Once found, every system goes into the inventory for classification — even if the initial assessment is "minimal risk, no specific obligations." The record of that assessment is itself part of your compliance evidence.

---

What to Capture: The Inventory Fields

An AI inventory entry should answer the questions a regulator would ask about the system and the questions you need to answer to run compliance. The following table sets out the recommended fields, with brief notes on why each matters.

Two fields deserve extra attention.

Organisation's role is frequently wrong. Most SMBs using a third-party AI tool are deployers under Article 26 — the provider obligations (Articles 9–18) belong to the vendor, not to them. But if the SMB has modified the system's intended purpose, put its name on it, or made substantial modifications, Article 25 shifts provider obligations onto them. Recording the correct role is not administrative tidiness; it determines the entire compliance workplan.

Art 6(3) filter is often skipped. An AI system that nominally falls in an Annex III area may still not be high-risk if it performs a narrow procedural task, improves the result of a previously completed human activity, or does preparatory work without replacing or influencing a human assessment. Systems that profile natural persons are always high-risk regardless. The filter must be assessed and documented; simply noting "not high-risk" without the reasoning does not satisfy the Act.

---

How to Build the Inventory: Five Stages

1. Discovery

Run the shadow-AI discovery process described above. Cast the net wide. Include tools that teams would describe as "automation" or "analytics" — these often meet the Article 3 definition of an AI system even if the vendor does not market them as AI. Document every system found, even those you are confident are minimal-risk.

2. Intake and field capture

For each discovered system, populate the inventory fields. The goal at this stage is completeness, not perfection. A partly complete entry for a system is better than no entry. Assign the owner field immediately — someone must be accountable for completing and maintaining the record.

For third-party tools, request the vendor's documentation: intended purpose, model type, known Annex III implications, any existing Art 49 registration. Do not rely on vendor marketing materials. Request the technical documentation or a summary of it under Art 13 (transparency and information obligations to deployers).

3. Classification

For each system, run the Article 6 classification:

1. Is it an AI system as defined in Article 3? If not, it does not belong in the AI inventory (though it may belong elsewhere).
2. Does it fall under Article 5 (prohibited practices)? If yes, immediate action required — prohibited since 2 February 2025.
3. Is it a safety component of a product covered by Annex I Union harmonisation legislation? If yes, high-risk under Art 6(1).
4. Does it fall within one of the eight Annex III use-case headings? If yes, provisionally high-risk — then apply the Art 6(3) filter.
5. Does it trigger Art 50 transparency obligations (chatbot, deepfake/synthetic media, emotion recognition, AI-generated content)?
6. If none of the above: minimal risk, no mandatory obligations.

Document the classification reasoning, not just the outcome. Regulators want to see the analysis.

For step 4, the eight Annex III headings that catch most SMB AI tools are as follows. This is where most misclassification errors occur, because the headings are broader than they appear in vendor marketing.

Employment (Annex III heading 4) covers AI used for recruitment and selection, for making decisions about terms and conditions of employment (promotion, task allocation, termination), and for monitoring performance or behaviour of workers. A CV-ranking tool, a video-interview scoring system, a workforce-monitoring dashboard that scores productivity — all of these fall here if they feed into decisions about individuals. The key test is whether the system influences a decision that has legal or similarly significant effects on a natural person.

Access to essential services (Annex III heading 5) covers creditworthiness assessment and credit scoring (except AI used purely for fraud detection, which is explicitly excluded), risk assessment and pricing for health and life insurance, benefit eligibility assessment, and emergency service dispatch. A small lender using a model to score loan applications is deploying a high-risk Annex III system, regardless of the model's sophistication or the size of the loans.

Education (Annex III heading 3) covers AI used in admission decisions, evaluation of educational outcomes, exam-cheating detection, and assessment of students in learning contexts. EdTech providers and universities need to assess their assessment tools carefully against this heading.

Biometrics (Annex III heading 1) covers remote biometric identification, biometric categorisation, and emotion recognition — but emotion recognition in workplace or educational settings is also now a prohibited practice under Article 5(1)(f). The distinction matters: the Article 5 prohibition needs immediate action; the Annex III obligations apply from 2 December 2027 for systems that are not already prohibited.

The remaining four headings (critical infrastructure, law enforcement, migration/border control, administration of justice) apply to a narrower set of SMB operators, though any public-sector contractor or regulated-sector firm should check them carefully.

4. Ownership and obligation mapping

Once classified, map the obligations that follow. The table below summarises the core requirements by role for high-risk systems.

This table belongs in your inventory process, not just in a separate policy document. Each inventory entry for a high-risk system should map directly to the relevant row for your role, with a status and an owner for each obligation.

Assign each obligation to a named owner with a due date. The inventory now functions as a compliance task tracker, not just a catalogue.

5. Review cadence

The inventory is not a point-in-time snapshot. Establish a minimum annual review, with triggered updates whenever a system changes materially: new training data, change of intended purpose, new deployment context, vendor update that alters functionality. Post-market monitoring under Article 72 requires providers to collect and review performance data continuously; the inventory is the mechanism for tracking what requires monitoring.

In practice, many organisations find that the first inventory pass takes four to eight weeks — the discovery phase alone consumes most of that time. The subsequent classification and obligation-mapping work is faster once you have a template and a clear process. Build for repeatability: an intake form that any business unit can complete, a classification checklist anchored to the Article 6 questions, a standard review cycle tied to your annual risk calendar. The second and third annual reviews should take a fraction of the time the first one did.

---

AI Inventory vs Article 49 EU Database Registration

This distinction matters because the two instruments are frequently conflated, and confusing them produces both under-compliance and over-compliance.

The internal inventory is your operational control. It covers all AI systems — prohibited, high-risk, limited-risk, and minimal-risk. It captures every system by design. It is not submitted anywhere. It is the evidence base for your compliance programme.

Article 49 registration is a regulatory filing obligation for providers of high-risk AI systems before placing them on the EU market. The EU database distinguishes two sections:

• Publicly accessible section: Registration entries for Annex III high-risk systems (other than systems in law enforcement, migration/asylum/border control, and national-security contexts). Anyone can search this.
• Restricted access section: Entries for high-risk systems in law enforcement, migration, asylum, and border management — accessible only to relevant authorities.

Providers of Annex III high-risk systems must complete the registration. Deployers of Annex III high-risk systems must also register their use in the database (Article 49(2)), but the registration fields for deployers are narrower than for providers. Deployers of high-risk systems in law enforcement or migration/border control carry specific registration obligations under Article 49(3) and (4).

The deadline for Annex III registration, under the Digital Omnibus agreed in May 2026, is 2 December 2027 for stand-alone high-risk AI systems. High-risk AI that is a safety component of an Annex I regulated product follows the 2 August 2028 date. The original August 2026 deadline has been deferred.

Your inventory should track the Article 49 registration status as a field (not filed / in progress / filed / registration ID recorded). The registration itself requires the information you have already captured in your inventory — system name, intended purpose, Annex III category, conformity assessment status, provider details — so maintaining a complete inventory makes the registration filing straightforward rather than a scramble.

---

Keeping It Current: Change Triggers and Post-Market Monitoring

A stale inventory is worse than no inventory. It suggests a compliance programme that was active once and is now on autopilot — which is exactly what enforcement actions target.

Change triggers that require an inventory update:

• System is retrained on new or expanded data
• Intended purpose is modified or extended
• A new deployment context is added (e.g. a tool previously used only for internal HR is now offered to customers)
• Vendor releases a material update that changes capabilities
• A system is decommissioned
• Your organisation's role shifts (e.g. you were distributing a third-party system and have now substantially modified it, triggering Art 25 provider obligations)
• A system that was Art 6(3)-exempt is applied to a new use case that does not qualify for the exemption

Post-market obligations under Article 72 require providers to collect data on the performance of high-risk systems in their deployed state and review it against the system's intended purpose and risk profile. The inventory is the logical place to record post-market findings, flag performance drift, and trigger documentation updates when the risk profile changes.

Deployer logging requirements under Article 12 — specifically the obligation to keep the automatically generated logs of high-risk system operation where the deployer has control over that logging — should be referenced in the inventory entry with a pointer to where logs are stored and the retention schedule.

A worked example of how this plays out in practice: a fintech firm deploys a third-party credit-scoring model as a deployer. Version 1.0 of the model is documented in the inventory. The vendor releases version 2.0 twelve months later, with an expanded feature set that now includes income-stability prediction based on transaction patterns. That is a material capability change. The inventory entry must be updated: the model version field, the data-categories field (new input types), and the Art 6(3) filter analysis (the expanded feature set may no longer qualify for any exemption that version 1.0 had). The conformity status field resets to "in progress" until the deployer has reviewed the vendor's updated documentation and confirmed that the Article 14 human-oversight arrangement still operates correctly under the new version. Miss that update and you are deploying a materially different system under a stale compliance record — which is the kind of gap that surfaces badly in an audit.

Record retention under Article 12 runs from deployment, not from when documentation was created. The inventory should store the deployment date of each version and the calculated retention deadline (deployment date plus five years, or ten years if the provider's sector-specific rules require it). Automate that calculation; do not rely on a human to remember it.

---

Overlap with the GDPR Article 30 Record of Processing

Many AI systems process personal data. When they do, two parallel record-keeping obligations apply: the EU AI Act inventory and the GDPR Article 30 Record of Processing Activities (RoPA).

The overlap is substantial. A high-risk AI system used to screen job applicants processes personal data, is subject to both regimes, and will feature in both records. Rather than maintaining duplicate entries, align the two. Practically this means:

• The AI inventory entry should note whether the system processes personal data, which categories (including any Article 9 GDPR special categories: racial or ethnic origin, health data, biometric data for identification purposes, etc.), and a cross-reference to the corresponding RoPA entry.
• The RoPA entry should cross-reference the AI inventory entry and flag that the processing uses an AI system subject to the EU AI Act.
• Any GDPR Data Protection Impact Assessment (DPIA) carried out for the system should be referenced in the AI inventory, since it will contain a risk analysis that partially overlaps with what Article 9's risk management system requires for high-risk AI.
• Where Article 27 FRIA obligations apply (certain high-risk deployers in public administration, regulated sectors), the FRIA can partially draw on the DPIA if one exists — note this in both records.

This alignment also matters for the ownership model: your Data Protection Officer, if you have one, should be a stakeholder in the AI inventory process, not a parallel actor.

---

A Realistic SMB Worked Example

Consider a 45-person recruitment process outsourcing firm based in Berlin. The firm uses three AI tools:

1. A CV-screening SaaS tool from a US vendor. The firm receives candidates' CVs, passes them through the tool, and presents ranked shortlists to client companies. The tool was sold as "smart search."

2. A customer-facing chatbot on the firm's website, powered by a third-party conversational AI, for handling candidate queries.

3. An internal scheduling automation tool that proposes interview slots based on calendar availability. No decisions about candidates — purely logistics.

CV-screening tool: Falls squarely in Annex III, employment heading (Category 4: recruitment, selection, promotion, termination). The firm is a deployer under Article 26 — the US vendor is the provider. The firm must: confirm the vendor has an Article 49 registration for the system (or is on track to file before 2 December 2027); obtain the vendor's Article 13 transparency information and instructions for use; implement the human-oversight arrangement under Article 14 (a human must review the shortlist before it is presented to clients, not just rubber-stamp it); maintain Article 12 logs of the system's outputs where it has control over logging; check whether an Article 27 FRIA is required (likely yes if the firm's clients include public bodies or if the firm itself falls in a regulated sector). This system gets a full inventory entry with all fields completed.

Chatbot: Triggers Article 50 — users must be informed they are interacting with an AI. The inventory entry notes the Art 50 disclosure obligation and records where/how the disclosure is implemented. No conformity assessment required. Minimal additional burden.

Scheduling tool: Likely minimal risk — it does not make decisions about natural persons, only proposes times. The inventory entry records the Art 6 analysis (not Annex III, not Art 5, no personal-data-based ranking of people) and the conclusion: minimal risk, no mandatory obligations. The record of that conclusion is the compliance evidence.

Total AI inventory: three systems, three different risk profiles, three different obligation sets. Without the inventory, the firm has no way to know which of the three requires urgent action and which can be left alone.

---

How Confir Helps

Confir registers every AI system your organisation builds or deploys, walking you through the intake fields described above — system name, owner, vendor, role, data categories, lifecycle stage, model type, human-oversight arrangement. The intake is a plain-English questionnaire; you do not need to know the Article numbers to answer it. Once intake is complete, the rule-based classification engine applies the Article 6 logic — including the Annex III category check and the Art 6(3) filter — and derives your role (Provider / Deployer / Importer / Distributor) from your answers. The engine is deterministic: the same intake always produces the same finding, explainable by the rule that fired, with no generative AI involved.

Each high-risk system then feeds directly into the risk register and triggers generation of the Annex IV technical documentation pack. Your inventory is not a separate spreadsheet you manually translate into compliance tasks — it is the starting point for the whole workflow, with obligations derived and tracked automatically.

Pricing starts at €600/year. No implementation project, no consultants, no enterprise sales cycle.

---

Frequently Asked Questions

What is the difference between an AI inventory and an Article 49 EU database registration?

Your internal AI inventory is a complete record of every AI system your organisation operates — covering all risk tiers, maintained by you, never submitted to any authority. Article 49 registration is a mandatory regulatory filing for providers (and, to a lesser extent, deployers) of high-risk Annex III AI systems before market placement. The inventory is the prerequisite: you cannot file an accurate registration without having first catalogued and classified the system. The deadline for Annex III registration is 2 December 2027 for stand-alone systems (2 August 2028 for Annex I product-embedded AI), under the Digital Omnibus agreed in May 2026.

Who must maintain an AI inventory — providers, deployers, or both?

Both, but for different things. Providers maintain documentation covering technical design, training data, risk management, and conformity evidence under Articles 9–15 and 17. Deployers maintain records of their specific use context, logging under Article 12, human-oversight implementation under Article 14, and — where Article 27 applies — a Fundamental Rights Impact Assessment. The inventory captures both: each entry records the organisation's role and flags which obligation set applies.

Does a minimal-risk AI system need to be in the inventory?

Yes. The EU AI Act does not require specific documentation for minimal-risk systems, but a well-run compliance programme inventories them anyway, because the compliance evidence is the documented analysis showing they are minimal-risk. If a regulator asks "did you assess that scheduling tool?" you want a dated inventory entry with an Art 6 reasoning note, not a verbal recollection.

How does the AI inventory relate to the GDPR Article 30 record of processing?

They overlap wherever an AI system processes personal data — which many do. Best practice is to cross-reference the two records rather than duplicate them: the AI inventory entry notes the relevant RoPA reference, and the RoPA entry flags that the processing involves an AI system in scope of Regulation (EU) 2024/1689. Where an Art 27 FRIA is required, any existing DPIA can be drawn on as a starting point.

What is the Article 6(3) filter and when should I apply it?

Article 6(3) provides that a system falling within an Annex III area is not automatically high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights. Specific circumstances: the system performs a narrow procedural task; it improves a previously completed human activity; it detects decision patterns without influencing human assessment; it does preparatory work only. The exception does not apply to systems that profile natural persons — those are always high-risk. If you claim the filter, document the analysis in the inventory entry. The burden of proof sits with the provider or deployer claiming it.

When does the high-risk deadline apply?

Under the Digital Omnibus agreed between Parliament and Council in May 2026, obligations for stand-alone high-risk Annex III AI systems apply from 2 December 2027. High-risk AI embedded as safety components of products covered by Annex I Union harmonisation legislation applies from 2 August 2028. The original 2 August 2026 date has been deferred. Prohibited practices under Article 5 apply now — since 2 February 2025.

How often should the inventory be reviewed?

At minimum, annually. But the more important discipline is change-triggered review: any material modification to a system, its training data, its deployment context, or your organisation's role in relation to it should prompt an immediate update to that inventory entry. Article 72 post-market monitoring obligations for providers effectively require continuous attention to high-risk systems — the inventory is the place to record what that monitoring finds.

---

Start your AI inventory now: catalogue your systems, classify each one, and you will have a clear picture of what requires action before 2 December 2027 and what does not. Everything else in your EU AI Act compliance programme follows from that list.

Build your AI inventory with Confir

---

Related guides

• compare EU AI Act compliance software
• Article 11 technical documentation requirements
• AI governance software comparison