AI Inventory Template: Field-by-Field Guide for EU AI Act Compliance

Template19 January 2026· 16 min read

EU AI Act AI inventory template — every field explained: role, risk tier, Annex III category, GPAI dependency, and key dates. Deadline 2 Dec 2027.

Every organisation that builds or uses AI systems needs to know what it has, who owns it, and whether it triggers obligations under Regulation (EU) 2024/1689. An AI inventory is how you answer those questions at scale. It is not itself a statutory form — the Act does not prescribe a single template — but it is the prerequisite for the Article 6 risk classification, the Article 9 risk management system that high-risk systems require, and the Article 49 registration of high-risk systems in the EU database. Without a maintained inventory you cannot do any of those reliably.

This guide walks through every field a complete AI register should contain, explains what each one serves, and covers the governance questions: discovery, classification triggers, and ownership.

The high-risk deadline under the Digital Omnibus agreed in May 2026 is 2 December 2027 for stand-alone Annex III systems (and 2 August 2028 for high-risk AI embedded in regulated products under Annex I). An inventory still incomplete at that point is a liability, not a foundation.

What the inventory is — and what it is not

An AI inventory is an internal operational record of every AI system your organisation develops, deploys, imports, or distributes. "AI system" has a specific meaning under Article 3(1): a machine-based system that infers, from inputs, outputs such as predictions, recommendations, decisions, or content. If your tool meets that definition and you use it in a professional context in the EU, it belongs in the register.

It is not the Article 9 risk management system, the Article 11 / Annex IV technical documentation pack, the Article 49 EU database registration, or the GDPR Article 30 record of processing activities — though it feeds all four. Each is a separate obligation; the inventory is the operational layer that makes them tractable.

The complete field set

The table below covers every field a well-structured AI register should carry. Fields are grouped by function. For each field, the "Serves" column names the provision it supports; where an obligation applies specifically to high-risk systems, that is noted.

Group 1 — System identity

Field	What to capture	Serves
System name	The internal name your teams use, plus any commercial or product name. One row per distinct system.	All obligations
Description / intended purpose	What the system does and who it does it to or for. Be precise about the decision type (ranking, prediction, classification, generation) and the affected population. This language feeds directly into the Article 11 / Annex IV technical documentation.	Art 6, Art 11 / Annex IV
Vendor / provider name	The organisation that developed the system or the underlying model. For internally built systems, your own organisation's name.	Art 23, Art 24, Art 26
Model / version	The specific version or release. Needed because a substantial modification — defined in Article 3(23) — can change the risk classification and restart conformity obligations. Track every version that reaches production.	Art 3(23), Art 11

Group 2 — Ownership and governance

Field	What to capture	Serves
Business unit	The department that operates or is the primary user of the system. This is where you direct queries, monitoring duties, and escalation.	Art 26
System owner (name / role)	The named individual accountable for this entry's accuracy and for triggering reviews when the system changes. Not a team; a person.	Art 9, Art 26
Human-oversight owner	The specific person or role responsible for the human oversight mechanism required by Article 14 for high-risk systems. May be the same as the system owner or a separate operational lead.	Art 14 (high-risk)

Group 3 — Role determination

The EU AI Act assigns different obligation stacks depending on your role — this is one of the most consequential fields and the one most often left vague.

Field	What to capture	Serves
Your role	Select from four roles: Provider (Article 16) — you develop and place the system on the market or put it into service under your name; Deployer (Article 26) — you use a system in a professional capacity; Importer (Article 23) — you bring a non-EU provider's system into the EU; Distributor (Article 24) — you make a system available on the EU market without placing it under your name. Under Article 25, if you brand a third-party system as your own, substantially modify it, or change its intended purpose, you become the provider.	Art 16, 23, 24, 25, 26

Most organisations using third-party AI tools are deployers. SaaS companies shipping AI features to customers are providers of those features. Record the role at the system level — the same organisation can hold both roles across different systems.

Group 4 — Risk classification

Field	What to capture	Serves
Risk tier	One of four values: Prohibited (Article 5) — banned since 2 February 2025; High-risk (Article 6 + Annex III or Annex I) — full obligation stack, deadline 2 December 2027; Limited risk (Article 50) — transparency disclosure duties from 2 August 2026; Minimal risk — no mandatory obligations.	Art 5, Art 6, Art 50
Annex III category	If high-risk via Article 6(2)(b), record the specific Annex III heading (1–8) and sub-point. The eight headings are: (1) biometrics; (2) critical infrastructure; (3) education and vocational training; (4) employment, workers management and self-employment; (5) access to essential private and public services (credit scoring at point 5(b); life/health insurance at point 5(c)); (6) law enforcement; (7) migration, asylum and border control; (8) administration of justice and democratic processes. Getting the sub-point right matters — recruitment is Annex III point 4(a), not "Category 4" generically.	Art 6(2)(b), Annex III
Article 6(3) exemption claimed?	If you are asserting that a system falling in an Annex III area is NOT high-risk under the Article 6(3) filter — because it performs a narrow procedural task, improves a previously completed human activity, detects patterns without replacing human assessment, or does preparatory work — record that claim, the supporting rationale, and the date of the assessment. Note: a system that profiles natural persons does not qualify for the Article 6(3) exemption; it is always high-risk. Providers claiming the exemption must still register the system under Article 49.	Art 6(3), Art 49
Classification rationale	A brief note explaining why this system lands in this tier. This is what you hand to a competent authority if your classification is questioned.	Art 6

Group 5 — Personal data and GDPR intersection

Field	What to capture	Serves
Personal data processed?	Yes/No. If yes, describe the categories (name, biometric data, health data, location, behavioural data, etc.).	GDPR Art 30 cross-ref
GDPR legal basis	The Article 6 GDPR basis for processing (consent, contract, legal obligation, legitimate interests, etc.), and the Article 9 GDPR basis where special categories are involved.	GDPR
DPIA required?	GDPR Article 35 requires a Data Protection Impact Assessment where processing is "likely to result in a high risk." Automated decision-making on a large scale, systematic evaluation of individuals, and new technologies routinely trigger this. Note whether a DPIA has been completed and link to it.	GDPR Art 35
FRIA required?	The Article 27 Fundamental Rights Impact Assessment is distinct from a DPIA. It applies to: public-body deployers of high-risk systems, and private deployers of high-risk systems in Annex III category 5(b) (creditworthiness/credit scoring) or 5(c) (life/health insurance risk and pricing). Private employers deploying recruitment or HR systems do not automatically owe a FRIA. Article 27(4) allows the FRIA to build on an existing DPIA.	Art 27 (high-risk deployers)

Group 6 — GPAI dependency

If the system is built on or uses a general-purpose AI model — an LLM, a multimodal foundation model, a large image model — record the following.

Field	What to capture	Serves
GPAI model / provider	Name and provider (e.g. GPT-4o / OpenAI, Gemini 1.5 / Google, Mistral Large / Mistral).	Art 53, Art 55
Annex XII documentation received?	Under Article 53(1)(b), GPAI providers must supply downstream users with training data summary, copyright policy, and energy consumption data. Record whether you have received this and where it is stored.	Art 53, Annex XII
Your classification when building on GPAI	If you build and deploy a system on top of a GPAI model under your own name, you are the provider of that downstream system under Article 25 and Article 16, classified by what your system does (Art 5 / 6 / 50). The model vendor's Article 53 obligations stay with the vendor.	Art 25, Art 16

Group 7 — Lifecycle and status

Field	What to capture	Serves
Lifecycle stage	Development / Pilot / Production / Retired. High-risk systems under development should already be tracked — the Article 11 documentation must be ready before you place the system on the market, not after.	Art 11, Art 72
Deployment date	When the system entered production. Relevant for assessing when obligations crystallised.	Art 49, Art 72
Substantial modification date	If a system was substantially modified (Article 3(23): a change that affects the system's compliance with the requirements or alters its intended purpose), record the date. A substantial modification can restart the conformity and registration clock.	Art 3(23), Art 43

Group 8 — Conformity and registration

Field	What to capture	Serves
Conformity assessment status	Not started / In progress / Complete / Lapsed. The Article 43 conformity assessment — the EU's term for demonstrating, before launch, that a high-risk system meets the requirements — must be completed before the system is placed on the market. For most Annex III categories (points 2–8), this is an internal self-assessment under Annex VI. For Annex III point 1 (biometrics), it generally requires the Annex VII notified-body route.	Art 43 (high-risk providers)
EU database registration (Article 49)	Yes/No and date. High-risk providers must register in the EU database before placing the system on the market. Providers claiming the Article 6(3) exemption must also register. The database itself is established under Article 71.	Art 49, Art 71
Declaration of Conformity (Article 47)	Date signed and link to the document. A provider must draw up an EU Declaration of Conformity — based on Annex V — when placing a high-risk system on the market.	Art 47, Annex V

Group 9 — Key dates and review cadence

Field	What to capture	Serves
Next classification review	A scheduled date for re-assessing the risk tier. Set this at deployment, and revisit whenever the system is substantially modified, when the Annex III list is amended under Article 7, or when the system's operating context changes.	Art 6, Art 9
Technical documentation last updated	Date. Article 11 documentation must stay current. A system that has been updated but whose documentation has not been revised is non-compliant.	Art 11
Last monitoring review	Date. Providers must maintain a post-market monitoring system under Article 72; deployers must monitor operation and keep logs under Article 26.	Art 72, Art 26
Log retention — deployer	Note whether logs are retained for at least 6 months as required under Article 26 (the article, not a specific sub-paragraph — cite the article).	Art 26
Technical documentation retention	10 years from placing on the market, under Article 18. Record the scheduled deletion date.	Art 18
Next full review date	Annual at minimum; immediately on any substantial modification or serious incident.	Art 9, Art 72

How to build and maintain the inventory

Discovery: finding what you have

AI enters organisations through three routes. Internally built systems are the easiest to locate — sweep your development backlog, model registry, and cloud AI services (Azure AI, Vertex AI, AWS Bedrock). Third-party tools with AI features require a questionnaire to each business unit: "Where does automated analysis, scoring, prediction, or content generation influence a decision?" HR systems, CRM tools, and customer-service software routinely embed AI. If you put a consultant's or outsourced partner's system into service under your authority, you are the deployer. Shadow AI — tools adopted without IT or compliance sign-off — needs a brief self-disclosure window without consequences; the goal is the full picture.

Once you have the list, apply the four-step Article 6 filter: (1) safety component of an Annex I product? (2) Annex III use case? (3) Article 50 limited-risk trigger (chatbot, synthetic content, emotion recognition, biometric categorisation)? (4) Minimal risk if none of the above. Document the answer to each question, not just the conclusion.

Classification triggers

Five events require a re-classification review:

Substantial modification (Article 3(23)) — a change to the system's intended purpose or one that affects compliance. A recruiter's shortlisting tool repurposed to rank promotion candidates is a new intended purpose; re-classify.
Change in operating context — the Act classifies by use, not technology. The same system is minimal-risk for internal drafting and potentially high-risk for assessing loan applications.
Annex III amendment — the Commission can expand the high-risk list under Article 7. Monitor the Official Journal.
New GPAI dependency — routing outputs through a new foundation model requires the Annex XII documentation check (Group 6) to run again.
Serious incident — Article 3(49) defines a serious incident as causing death, serious health harm, significant infrastructure disruption, or a fundamental-rights violation. An Article 73 report triggers a full review of classification and conformity status.

Who owns the inventory

Distributed ownership fails. Appoint one accountable owner at the organisation level — the head of compliance, the DPO, or a dedicated AI governance lead — responsible for completeness, review cadence, and regulatory readiness. System owners in each business unit certify their entries at each quarterly review and report any changes. Every entry needs an immutable change log: who updated the field, when, and why. That log is what a competent authority reads first.

Quarterly reviews are the minimum. For high-risk systems in production, a monthly operational check — performance metrics, incident log, oversight records — feeds into the lifecycle fields.

How Confir helps

Confir auto-builds the inventory as you onboard systems. You answer plain-English scenarios about each system; Confir's deterministic, rule-based engine derives your role (Provider Article 16 / Deployer Article 26 / Importer Article 23 / Distributor Article 24) and your risk tier (Prohibited / High / Limited / Minimal) in two to three steps, not a 40-question legal questionnaire. The same intake populates the Article 9 risk register, generates the Article 11 / Annex IV technical documentation pack, and prepares the Article 49 registration data.

No consultants, no implementation project.

Frequently Asked Questions

Is an AI inventory a legal requirement under the EU AI Act?

The Act does not prescribe a specific inventory form, but the obligations it creates make one practically mandatory. Providers must draw up technical documentation under Article 11 before placing a high-risk system on the market; deployers must keep monitoring records under Article 26; all parties must demonstrate compliance to competent authorities under Articles 74–77. You cannot meet any of those obligations across multiple systems without a structured register.

What is the difference between the AI inventory, the Article 9 risk management system, and the Article 49 registration?

The inventory is your internal catalogue of every AI system you have — scope, classification, ownership, status. The Article 9 risk management system is a documented, continuous process for identifying and mitigating the risks of a specific high-risk system; it is required per system, not per organisation. Article 49 registration is a one-time (and update-triggered) submission to the EU's public database, required before placing a high-risk system on the market. All three are distinct obligations; the inventory is the prerequisite for the other two.

Do I need to include minimal-risk and limited-risk systems, or only high-risk ones?

Include all AI systems. Limited-risk systems (Article 50) carry disclosure obligations that apply from 2 August 2026. Minimal-risk systems still require you to know they exist — the classification is a conclusion, not a starting point. An unreviewed system is not a confirmed minimal-risk system; it is an unreviewed one. Discovery precedes classification.

What happens when a system is substantially modified under Article 3(23)?

A substantial modification — defined as a change affecting the system's compliance with requirements or altering its intended purpose — effectively restarts the provider clock. The modified system is treated as a new high-risk system: it needs a fresh Article 11 documentation set, a new Article 43 conformity assessment, and a new Article 49 registration. Your inventory should record the modification date and link to the updated documentation. If you are a deployer repurposing a third-party system, Article 25 may convert you into a provider.

How does the inventory interact with our GDPR Article 30 record of processing?

Complementary, not duplicative. The GDPR Article 30 record tracks every processing activity — purpose, legal basis, retention, processor relationships. The AI inventory tracks AI systems — intended purpose, risk tier, role, conformity status, lifecycle. An AI system processing personal data appears in both; link the two records cross-way. The AI Act FRIA under Article 27 can build on an existing GDPR DPIA under Article 27(4), which is another reason to keep them connected.

What should the inventory look like for a company that only deploys third-party AI tools?

A deployer's inventory records: which tools are in use; the specific use case (not "ChatGPT for productivity" but "vendor X's scoring tool for credit applications"); whether any use triggers Annex III; monitoring records under Article 26; and whether the vendor has supplied Annex XII downstream documentation for any GPAI model involved. Most deployers of general productivity AI end up in the minimal or limited-risk tiers. The inventory confirms that — it does not assume it.

Can I use a spreadsheet?

Yes, at the start. A spreadsheet works for an organisation with a small number of systems, none high-risk. The limitations show when you scale: spreadsheets do not enforce classification logic, do not link to documentation or assessment records, and do not generate the structured outputs — technical documentation pack, Declaration of Conformity, registration data — that high-risk compliance requires. For organisations with high-risk systems or a growing AI footprint, a dedicated tool with an immutable audit trail reduces the risk of error and the time to respond to a competent authority.

Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.

Start free trial →