How to build an EU AI Act AI inventory from your enterprise architecture

The EU AI Act doesn't ask for an inventory by name, but you can't comply without one. Its duties attach to AI systems by your role and the system's risk tier, so first you need to know which systems you run. Enterprise architecture already holds most of that list. Build the register from the EA repository, the CMDB, procurement records and each agent platform's inventory, classify every entry from what the system does, and keep it current with change triggers and scheduled sweeps.

What the Act asks of you

Regulation (EU) 2024/1689, the AI Act, entered into force on 1 August 2024. The prohibited practices in Article 5 and the AI literacy duty in Article 4 have applied since 2 February 2025. Obligations for general-purpose AI models followed on 2 August 2025.

The rest depends on two facts about each system. The first is its risk tier: prohibited, high-risk under Article 6 (through Annex I or Annex III), subject to the transparency obligations in Article 50, or minimal risk. The second is your role. A provider develops a system and places it on the market. A deployer uses it under its own authority; Article 26 sets out what deployers owe, including human oversight, monitoring and keeping logs. Certain high-risk systems must also be registered in the EU database under Articles 49 and 71.

The timetable for high-risk obligations was under revision through 2025 and 2026, so check the current dates before you plan against them. The inventory doesn't wait on that answer: no tier applies to systems you haven't found.

Where AI systems hide

The AI projects you know about are the easy part. The rest sit in four places:

• SaaS features switched on by default. A licensed HR or service desk product ships a scoring feature in a routine release. Nobody bought "AI", so procurement has no record of it.
• Agents on several agent platforms. Each department builds on its own platform, and each platform keeps its own list.
• Models embedded in vendor products. A fraud engine or document reader has a model inside. The application is in the repository; the AI isn't described.
• Shadow use. Teams use public assistants on work data. Proxy logs and expense claims know; the architecture doesn't.

Why EA should own the inventory

The EA repository knows applications, owners, capabilities and the data they handle. The CMDB knows what actually runs, and where. Procurement records know which contracts cover which products, and when they renew. Agent platform inventories know which agents exist and what they can touch. An AI register is the join across all four.

Joining records across systems, linking them to capabilities and chasing owners is what EA already does for the application portfolio. That makes EA the function that can find the systems and keep the list honest.

What each register entry needs

Each entry should answer what an auditor or your risk committee will ask:

The role field matters more than it looks. Under Article 25, a deployer that puts its name on a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk takes on the provider's obligations.

How to classify an AI system from what it does

Classify from the use case, not the label. The owner's recorded class and the vendor's description are inputs, not answers.

1. Check Article 5 first. Social scoring and emotion recognition at work or in education are examples. Escalate any possible match at once.
2. Check the product route. If the AI is a safety component of a product covered by the EU legislation listed in Annex I, it may be high-risk through Article 6(1).
3. Check Annex III against the actual use. Recruitment, worker management, creditworthiness, life and health insurance pricing, education and biometrics are among the listed areas. A CV-screening feature in an HR product is an Annex III use, whatever the product is called.
4. Record any Article 6(3) exception with its reasoning. An Annex III system can fall outside high-risk when it doesn't pose a significant risk, for example when it performs a narrow procedural task. A system that profiles people does not qualify. Write the reasoning down.
5. Check Article 50. Systems that talk to people, or that generate or alter content, carry transparency duties even when they're not high-risk.
6. Record the tier, the reason, the date and the person. A tier without a reason can't be reviewed later.

Confirm classification decisions with legal counsel. The register's job is to put the right facts in front of them.

Three traps that make the register wrong

The same product counted twice. One product deployed as "Claims Assist EU", "Claims Assist US" and "Claims Assist Pilot" is one system with three deployments. Split the records and one of them misses a review. Track the product once, with its deployments under it.

An agent counted as registered because it names an application. If the repository holds no such application, or one with a slightly different name, the agent is unregistered. The AI-agent governance checklist makes this its own check.

A vendor's "not high-risk" label taken at face value. A provider classifies its product against the intended purpose it describes. Use a general analytics tool to rank job applicants and that classification no longer describes your system.

How to keep the inventory current

A register starts drifting the day it's finished. Two mechanisms keep it current.

Change triggers. A new contract, a new agent on any platform, a change to a model, prompt or tool set, a new data source or a new user group each reopens the entry's tier. Wire these into procurement intake, architecture review and change management.

Scheduled sweeps. Each month or quarter, rerun the joins: agent platform inventories against the repository, procurement records against the AI register, CMDB services against application records. Each sweep should list what it found and the records it read. These joins are hard to do well, which is why EA-Bench includes an EU AI Act classification question and an AI inventory reconciliation question among its 17. The question kit says what a right answer contains.

Who owns what

• Enterprise architecture owns discovery, the register's structure, the links to applications and capabilities, and the sweeps.
• Risk and compliance own the classification method, the tier on each entry, and oversight of high-risk systems.
• Legal confirms role and tier on the hard cases, and interprets the timetable as it changes.
• Business owners own each system's purpose, oversight and status, and tell EA when they change.

Start with the join you can run this month: agent platform inventories and procurement records against the EA repository. List every system that touches personal data and has no linked application, give each one an owner, and set its tier with a reason. That list is the start of your register, and it will show you which source you trust least.