AI system register: what must it contain?

Updated 10 July 2026 · Regulation (EU) 2024/1689 · 8 min read

What is an AI system register?

An AI system register — also called an AI inventory or AI usage map — is the internal document listing every artificial-intelligence system an organization develops, buys or uses. For each system it records the provider, the purpose, the people affected, the role the organization plays under Regulation (EU) 2024/1689, the risk level retained and the measures taken to meet the corresponding obligations.

It is, for AI, what the record of processing activities of Article 30 GDPR is for personal data: a governance document whose job is not merely to exist, but to prove — on the day of an inspection — that the organization knows what it uses and why.

The practical difference is significant. The GDPR record is built from processing activities that are already known, usually documented by the legal department. The AI system register faces a messier reality: AI tools enter the company from the bottom up. A developer tries a coding assistant, a marketing team generates visuals, a recruiter tests a CV screening tool. Nobody tells the DPO. That is “shadow AI”, and surfacing it is precisely what the register is for.

Is it mandatory?

Regulation 2024/1689 does not impose “a register” by that name on every organization. It imposes a set of documentation duties for which the register is the cheapest way to comply. Three provisions make it effectively unavoidable:

• Article 4 (AI literacy): providers and deployers must ensure a sufficient level of AI literacy among their staff, taking into account the systems used. You cannot train people on systems you have not listed.
• Article 26 (deployer obligations for high-risk systems): log retention, informing workers, appointing competent human oversight. These duties presuppose that high-risk systems in service have been identified.
• Article 50 (transparency): deployers must inform exposed persons. Knowing which systems trigger this duty requires an inventory.

One clarification most vendors leave out: Article 49 creates a filing in the EU database, and it probably does not apply to you. Only providers of Annex III high-risk systems and deployers that are public authorities, Union institutions, bodies, offices or agencies register there. A private company that merely uses a high-risk system has no obligation to register in the EU database. Its register is an internal governance inventory: the evidence base for Articles 4, 5, 26 and 50, and the foundation of an AI management system (ISO/IEC 42001) or of a GDPR data protection impact assessment. That is exactly what AI Act Register Pilot produces — we do not sell you an obligation that does not exist.

Across the board, Article 21 requires cooperation with authorities and the provision, upon reasoned request, of all information necessary to demonstrate conformity. Without a register, that request is unmanageable.

In short: the register is not a box to tick, it is the instrument of proof. A market surveillance authority will not ask “do you have a register?”; it will ask “which AI systems do you use, for what purpose, and how did you conclude they are not high-risk?”.

Who is concerned: deployer or provider?

The Regulation distinguishes several roles; two concern nearly every company.

The provider (Article 3(3)) develops an AI system — or has it developed — and places it on the market or puts it into service under its own name or trademark. It bears the bulk of the obligations: risk management system, data governance, technical documentation, CE marking for high-risk.

The deployer (Article 3(4)) uses an AI system under its own authority in the course of a professional activity. That is the vast majority of organizations: they buy, or use for free, systems designed by others. Their obligations are lighter but very real, and set out in Articles 26 and 50.

The line is not fixed. Article 25 provides that a deployer becomes a provider if it puts its name or trademark on a high-risk system, substantially modifies its intended purpose, or makes a substantial modification to a system already on the market. Concretely: fine-tuning a model and exposing it to your customers under your brand can move your organization into the provider regime, with its technical documentation duties. The register must therefore record, for each system, the role retained and the reason for that choice.

The fields your register must contain

The Commission has published no official template. The table below gathers the fields that follow directly from the Regulation's obligations and from what an authority will ask for during an inspection.

Field	Why
System name and provider	Identify the responsible vendor, retrieve its documentation and declaration of conformity.
Purpose within the organization	Risk follows use, not the tool. The same LLM is minimal for drafting help, high-risk for CV screening.
Role (deployer / provider)	Determines the applicable block of obligations (Art. 26 or Chapter III Section 2).
Risk level retained	Unacceptable, high, limited, minimal — with the justification.
Annex III basis where applicable	The precise Annex III point making the system high-risk (employment, credit, education…).
General-purpose AI model (GPAI)?	Triggers the Chapter V regime and upstream information duties.
Applicable transparency obligations	AI interaction, synthetic content, deepfake, emotion recognition (Art. 50).
Human oversight measures	Who checks, how, with what competence (Art. 26(2)).
Data processed and GDPR legal basis	Articulation with the Article 30 GDPR record; DPIA where needed.
Hosting / transfers outside the EU	A GDPR and sovereignty checkpoint — to be documented, not ignored.
Last review date and next due date	An unreviewed register is a false register. Quarterly, half-yearly or yearly depending on risk.
Internal owner	A row without an owner will never be updated.

Two fields are systematically forgotten and systematically requested: the justification of the risk level (a single sentence is enough, but it must exist) and the review date. A register last touched eighteen months ago, in a field where the tool landscape changes every quarter, hurts its author more than it protects them.

Classifying each system by risk level

The Regulation sorts systems into four categories, described in detail in our guide to the AI Act risk levels. Remember the logic: risk follows use, not technology.

• Unacceptable risk (Article 5): social scoring, exploitation of vulnerabilities, emotion recognition in the workplace and in education, untargeted scraping of facial images. Prohibited since 2 February 2025.
• High risk (Article 6, Annexes I and III): recruitment, worker management, access to education, creditworthiness, essential services, biometrics, critical infrastructure, law enforcement.
• Limited risk (Article 50): chatbots, generative AI, deepfakes. Information duty, no certification.
• Minimal risk: everything else. No specific obligation, good practice recommended.

A classic trap: a day-to-day tool marketed as “minimal” becomes high-risk the moment you wire it into an Annex III process. The register must therefore record the purpose at your organization, not the vendor's marketing description.

Penalties

Article 99 sets three caps, applying the higher of a fixed sum and a percentage of worldwide annual turnover (the lower of the two for SMEs and start-ups):

• €35M or 7% for using a prohibited AI practice (Article 5);
• €15M or 3% for breaching other obligations, including deployer duties (Article 26) and transparency duties (Article 50);
• €7.5M or 1% for supplying incorrect, incomplete or misleading information to authorities.

That third category deserves attention: answering a supervisory authority with an approximate inventory is a distinct, sanctionable act. An incomplete register is a risk in its own right, separate from non-compliant use.

Actionable checklist

1. Map reality before writing. Record the AI tool domains actually opened by your teams over two to four weeks.
2. One row per tool × purpose. The same assistant used for drafting and for CV screening takes two rows, with two risk levels.
3. Decide the role for each row: deployer by default, provider if Article 25 applies.
4. Justify the risk level in one sentence, citing the Annex III point where relevant.
5. List the triggered transparency duties and prepare the notices before 2 August 2026.
6. Name an owner and set a review date per row: quarterly for high risk, yearly for minimal.
7. Archive a timestamped version at each review: that history, not the current file, is what proves upkeep.
8. Cross-reference the GDPR record of Article 30 for systems processing personal data.

The free template

Get the AI system register template in XLSX and CSV, with every column from the table above, an example sheet and a deadline reminder tab.

Keep reading

This content is provided for information only. It reflects Regulation (EU) 2024/1689 as at the update date and does not constitute legal advice. The definitive qualification of your systems is yours to make, with your counsel where appropriate.