We'd like to set analytics cookies to measure which pages are useful. They are not needed to run the site, and declining changes nothing about what you can do here. Privacy Policy.
An inventory is where compliance starts, because you cannot classify, document or monitor systems you have not enumerated. Building it on Annex VIII columns turns a shadow-AI discovery exercise into filing preparation.
Every template on this page is readable in full right here, copyable as Markdown, and downloadable as a PDF. No sign-up, no e-mail address, no click-to-reveal.
Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
Who fills this in
Whoever owns AI governance — typically the same person who runs the classification. Each row needs a named business owner, because that is who answers the questions the columns raise.
When it has to exist
Continuously. The registration duty attaches before a high-risk system is placed on the market or put into service, and the EU database entry must be kept accurate afterwards.
Applies from
Registration obligations run with the high-risk regime, which applies to Annex III systems from 2 December 2027. The inventory itself is worth keeping from today — it is what every later document is built on.
The Act does not oblige anyone to keep an internal inventory in so many words. It obliges providers of Annex III high-risk systems to register them in the EU database before market (Article 49(1)), providers relying on the Article 6(3) self-assessment to file a simplified registration (Article 49(2)), and public-authority deployers to register their use (Article 49(3)–(4)). Annex VIII lists the data points. Structuring your inventory on those fields means the register you keep is the register you file from.
How this document usually fails
An inventory of models rather than of systems. The Act attaches obligations to an AI system placed on the market or put into service for an intended purpose; three products built on one model are three rows, not one.
The template, section by section
5 sections. Each one carries what to write and — the part templates normally leave out — what an assessor is looking for when they read it.
1. Identification
What to write
Enough to point at exactly one system and one version. These columns map to Annex VIII, Section A/B points 4 and 5.
What an auditor looks for
That the trade name and reference in your register are the same strings as in the technical file, the declaration of conformity and the EU database entry. Version drift between them is the first thing that gets picked up.
Column
What to enter
System name / trade name
The name the system is placed on the market under.
Unambiguous reference
Version, model number or other reference allowing identification and traceability of this exact system (Annex VIII, Section A/B, point 4).
Intended purpose
What the system is intended to do, plus the components and functions supported by AI — written for a regulator, not a sales page (Annex VIII, Section A/B, point 5).
Business owner
The named person accountable for this system, not the team.
Vendor / built in-house
Who built it, and the contract reference if bought.
Underlying models
The models or third-party APIs it depends on, with versions.
2. Role and classification
What to write
Your role for this specific system and the risk tier that follows from it. One organisation routinely holds different roles for different systems.
What an auditor looks for
A recorded reason, not just a verdict. Article 6(4) lets an authority ask a provider who self-assessed an Annex III system as not high-risk to produce the documented assessment — a register that says 'not high-risk' with an empty rationale column is the exposure.
Column
What to enter
Role
Provider, deployer, importer, distributor — or several. Article 25 can turn a deployer into a provider.
Risk classification
Prohibited, high-risk, limited (transparency), minimal, or out of scope.
Classification basis
The Annex I product or the Annex III use case relied on, or the reason none applies.
Article 6(3) relied on?
If the system is in an Annex III area but assessed as not high-risk, record which Article 6(3) condition applies and confirm it does not profile natural persons.
Classification date and assessor
When the call was made and by whom — classifications go stale when the system changes.
Article 50 duties?
Whether the system interacts with people, generates content or reads people, and therefore carries transparency duties.
3. Deployment footprint
What to write
Where the system runs, who it touches, and which Member States it is available in.
What an auditor looks for
Consistency with the Member State list you would file under Annex VIII, Section A point 10, and whether the affected-persons column is specific enough to have driven a FRIA decision.
Column
What to enter
Status
On the market, in service, no longer on the market or in service, or recalled (Annex VIII, Section A point 7 / Section B point 8).
Member States
Every EU Member State where the system is placed on the market, put into service or made available (Annex VIII, Section A point 10 / Section B point 9).
Affected persons
The categories of natural persons and groups the system's outputs bear on — the input to the FRIA decision.
Data categories
What the system consumes, flagging personal and special-category data.
Human oversight arrangement
Who reviews or can override the output, and with what authority.
4. Conformity and registration
What to write
The documentary state of the system: what exists, what is missing, and where it is filed.
What an auditor looks for
That every 'yes' in this block resolves to a document with a date and a location. An inventory that asserts a declaration of conformity exists but cannot produce it is worse than one that admits the gap.
Column
What to enter
Technical documentation
Whether the Annex IV file exists, its version and where it is stored.
Conformity assessment route
Internal control (Annex VI) or notified body (Annex VII), and the certificate details where one was involved (Annex VIII, Section A points 8–9).
Declaration of conformity
Date drawn up and signatory — it is kept for ten years after the system is placed on the market.
EU database registration
Registration status and the entry URL once filed. Public-authority deployers need the provider's entry URL under Annex VIII, Section C point 3.
FRIA
Whether an Article 27 assessment was required, and its date if so.
DPIA
Whether a GDPR Article 35 assessment exists; the FRIA can complement it.
5. Lifecycle and review
What to write
The dates that make the register a living document rather than a snapshot.
What an auditor looks for
Whether anything has been reviewed since it was first entered. A register where every row has the same creation date and no review date tells an assessor the governance is nominal.
Column
What to enter
Date added
When the system entered the register.
Last reviewed
When the row was last checked against reality, and by whom.
Substantial modification log
Changes assessed as substantial, which trigger a fresh conformity assessment.
Incidents
Link to any Article 73 serious incidents raised for this system.
Retirement date
When the system was withdrawn, and whether the EU database entry was updated.
Take it with you
The same document in two portable forms. The Markdown pastes into Notion, Confluence, Google Docs or a repository; the PDF is laid out to be printed and written on, with ruled fill-in areas and a sign-off block.
Full template as Markdown — select it, or use the button
# AI system inventory and register
**Legal basis:** Article 49, Annex VIII, Article 6, Article 16, Article 26 — Regulation (EU) 2024/1689 (EU AI Act).
> Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
**Who fills this in:** Whoever owns AI governance — typically the same person who runs the classification. Each row needs a named business owner, because that is who answers the questions the columns raise.
**When:** Continuously. The registration duty attaches before a high-risk system is placed on the market or put into service, and the EU database entry must be kept accurate afterwards.
| Field | Value |
| --- | --- |
| Organisation | |
| AI system | |
| Version / reference | |
| Document owner | |
| Date | |
| Version of this document | |
## 1. Identification
*What to write:* Enough to point at exactly one system and one version. These columns map to Annex VIII, Section A/B points 4 and 5.
*What an auditor looks for:* That the trade name and reference in your register are the same strings as in the technical file, the declaration of conformity and the EU database entry. Version drift between them is the first thing that gets picked up.
| Column | What to enter | Your entry |
| --- | --- | --- |
| System name / trade name | The name the system is placed on the market under. | |
| Unambiguous reference | Version, model number or other reference allowing identification and traceability of this exact system (Annex VIII, Section A/B, point 4). | |
| Intended purpose | What the system is intended to do, plus the components and functions supported by AI — written for a regulator, not a sales page (Annex VIII, Section A/B, point 5). | |
| Business owner | The named person accountable for this system, not the team. | |
| Vendor / built in-house | Who built it, and the contract reference if bought. | |
| Underlying models | The models or third-party APIs it depends on, with versions. | |
## 2. Role and classification
*What to write:* Your role for this specific system and the risk tier that follows from it. One organisation routinely holds different roles for different systems.
*What an auditor looks for:* A recorded reason, not just a verdict. Article 6(4) lets an authority ask a provider who self-assessed an Annex III system as not high-risk to produce the documented assessment — a register that says 'not high-risk' with an empty rationale column is the exposure.
| Column | What to enter | Your entry |
| --- | --- | --- |
| Role | Provider, deployer, importer, distributor — or several. Article 25 can turn a deployer into a provider. | |
| Risk classification | Prohibited, high-risk, limited (transparency), minimal, or out of scope. | |
| Classification basis | The Annex I product or the Annex III use case relied on, or the reason none applies. | |
| Article 6(3) relied on? | If the system is in an Annex III area but assessed as not high-risk, record which Article 6(3) condition applies and confirm it does not profile natural persons. | |
| Classification date and assessor | When the call was made and by whom — classifications go stale when the system changes. | |
| Article 50 duties? | Whether the system interacts with people, generates content or reads people, and therefore carries transparency duties. | |
## 3. Deployment footprint
*What to write:* Where the system runs, who it touches, and which Member States it is available in.
*What an auditor looks for:* Consistency with the Member State list you would file under Annex VIII, Section A point 10, and whether the affected-persons column is specific enough to have driven a FRIA decision.
| Column | What to enter | Your entry |
| --- | --- | --- |
| Status | On the market, in service, no longer on the market or in service, or recalled (Annex VIII, Section A point 7 / Section B point 8). | |
| Member States | Every EU Member State where the system is placed on the market, put into service or made available (Annex VIII, Section A point 10 / Section B point 9). | |
| Affected persons | The categories of natural persons and groups the system's outputs bear on — the input to the FRIA decision. | |
| Data categories | What the system consumes, flagging personal and special-category data. | |
| Human oversight arrangement | Who reviews or can override the output, and with what authority. | |
## 4. Conformity and registration
*What to write:* The documentary state of the system: what exists, what is missing, and where it is filed.
*What an auditor looks for:* That every 'yes' in this block resolves to a document with a date and a location. An inventory that asserts a declaration of conformity exists but cannot produce it is worse than one that admits the gap.
| Column | What to enter | Your entry |
| --- | --- | --- |
| Technical documentation | Whether the Annex IV file exists, its version and where it is stored. | |
| Conformity assessment route | Internal control (Annex VI) or notified body (Annex VII), and the certificate details where one was involved (Annex VIII, Section A points 8–9). | |
| Declaration of conformity | Date drawn up and signatory — it is kept for ten years after the system is placed on the market. | |
| EU database registration | Registration status and the entry URL once filed. Public-authority deployers need the provider's entry URL under Annex VIII, Section C point 3. | |
| FRIA | Whether an Article 27 assessment was required, and its date if so. | |
| DPIA | Whether a GDPR Article 35 assessment exists; the FRIA can complement it. | |
## 5. Lifecycle and review
*What to write:* The dates that make the register a living document rather than a snapshot.
*What an auditor looks for:* Whether anything has been reviewed since it was first entered. A register where every row has the same creation date and no review date tells an assessor the governance is nominal.
| Column | What to enter | Your entry |
| --- | --- | --- |
| Date added | When the system entered the register. | |
| Last reviewed | When the row was last checked against reality, and by whom. | |
| Substantial modification log | Changes assessed as substantial, which trigger a fresh conformity assessment. | |
| Incidents | Link to any Article 73 serious incidents raised for this system. | |
| Retirement date | When the system was withdrawn, and whether the EU database entry was updated. | |
---
Template by Conformly — getconformly.com/templates/ai-system-inventory. Free to copy and adapt. Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
Questions people ask
Does the EU AI Act require an AI inventory?
Not as a named obligation. It requires registration of high-risk systems in the EU database under Article 49, documented classification decisions, and per-system duties that presuppose you know which systems you have. An inventory is how organisations satisfy those in practice.
What is the difference between an inventory and the EU database registration?
The inventory is yours and covers every system at every risk tier. The Article 49 registration is a filing in the Commission's database and only covers Annex III high-risk systems, Article 6(3) self-assessments, and public-authority deployer use.
Should minimal-risk systems be in the register?
Yes. Classification is a decision that has to be recorded and revisited, and a system's tier can change when its purpose does. A register that only holds high-risk systems cannot show why the others were left out.