How to build an AI system inventory, and why your ROPA isn't one

AI Act duties attach per system. Before you can classify anything, assign oversight, or retain logs, you need a list of what you are actually running. What to record, and where the unlogged systems hide.

Every substantive obligation in the EU AI Act attaches to a system: classify this one, oversee that one, retain logs for a third. The Digital Omnibus moved the high-risk deadline to December 2027, which changed the timetable and not the sequence. The inventory is still the first step, and it is the step most organisations have not started.

Why your Article 30 record isn't the same thing

A Record of Processing Activities is organised by processing activity and by personal data. An AI system inventory is organised by system, and asks a different set of questions: what it does, who provides it, what it was designed for, what you use it for, and how it classifies. The two overlap, and there are three things a ROPA structurally cannot hold:

• AI systems that process no personal data at all. Out of ROPA scope, in AI Act scope.
• The intended purpose the provider declared, which is the baseline Article 25 measures a modification against.
• A classification decision and the reasoning behind it, with a date.

If you keep a good ROPA it is still the best starting list you have. Start there, then look specifically for what its structure cannot contain.

What each entry should record

Where the systems you don't know about are

• Features switched on inside tools you already pay for: the summariser in the ticketing system, the meeting notetaker, smart-compose in the mail client.
• Browser extensions installed by individuals for their own workflow.
• Anything reached through an API key paid for on a corporate card.
• Models inside a product your own team built, where the AI arrived as a library call rather than a purchase.
• Recruitment, credit and performance tooling bought outside IT procurement.

The last one matters most. Annex III concentrates on employment and worker management, access to essential services, creditworthiness, and education. Those systems are typically bought by HR, finance or operations, which means the highest-risk category in the Act is the one least likely to appear on an IT asset list.

How to run the exercise

1. 1Start from the ROPA and the software asset list, and treat both as incomplete.
2. 2Ask each department head what they use that writes text, ranks people, scores anything, or answers questions. Avoid the phrase 'AI system' - it produces false negatives.
3. 3Check card expenditure and SaaS subscriptions for anything that arrived without a procurement record.
4. 4Check what your existing platforms have enabled by default. Vendors have been switching AI features on rather than selling them separately.
5. 5Capture the fields above for each system, accepting gaps rather than delaying the list until it is perfect.
6. 6Classify each one against Article 6 and Annex III, and record the reasoning even when the answer is an easy no.
7. 7Set a review trigger: any change of purpose, any provider version change that alters what the system does, and a fixed annual pass.

The unstructured data problem underneath it

Two fields in that table depend on knowing what data reaches a system: input data governance under Article 26(4), and the source of the personal data involved. Where staff paste from spreadsheets, exports and local files into a tool, the answer is not held in any system of record. Endpoint and file-share discovery gives you the population of personal data on the estate, which is the same input that makes an Article 30 record accurate and an access request answerable.

Classification against Annex III is a legal determination and this post is not legal advice. The inventory is the part you can build now without one; the classification column is where to involve someone qualified.