Building an AI inventory and register

why the register is the foundation

The EU AI Act is written as if you already know what AI you use. Several of its duties read directly from an inventory you are presumed to hold.

Article 4, AI literacy. In force since 2 February 2025, this duty requires providers and deployers to ensure a sufficient level of AI literacy among staff who operate or use AI systems. You cannot scope that training without knowing which systems are in use and what they do. The register tells you who needs to know what.

Article 5, prohibited practices. The Act bans a specific set of uses, such as social scoring and certain manipulative or biometric techniques. To confirm that none of your systems fall in scope, you first need a list of systems to check against. A prohibited-practice review with no inventory behind it is a guess.

Article 26(6), log retention. High-risk systems must generate logs automatically, a capability Article 12 places on the provider, and the deployer must retain the logs the system produces. To know which of your systems carry that duty, you work from a register that names each system and its tier.

Article 27, the deployer Fundamental Rights Impact Assessment. Deployers of certain high-risk systems must assess the impact on fundamental rights before putting the system into use. That assessment is per system. Without a register, you do not know which systems trigger it.

Set the law aside and the case still holds. Good governance is classification plus guidelines, not prohibition. You cannot write a guideline for a tool you have not named, and you cannot classify a data flow you have not mapped. The register is where naming and mapping live. One more reason to get this right early: the penalties are tiered. Prohibited practices carry fines up to EUR 35 million or 7 percent of global annual turnover, whichever is higher. Most other obligations carry fines up to EUR 15 million or 3 percent. The register is a low-cost way to show you took the duties seriously.

the register fields, defined

A register is only as useful as its columns. Each field below earns its place by answering a question a regulator, an auditor, or your own future self will ask.

System name. The product or service as people refer to it. Record the specific edition where it matters, since the enterprise tier and the free tier of the same product can carry different terms and different data behavior.

Owner. The named person accountable for this system inside your organization. Not a team, a person. When a system has no owner, that is itself a finding worth recording.

Vendor. Who provides the system. The legal entity, not just the brand, when you can find it. This matters for data residency and for the provider-versus-deployer question later.

Data it touches. What categories of data flow into or out of the system. Personal data, source code, financial data, customer records, internal strategy. Keep this at the category level. Precision here drives both the lawful-basis field and the tier decision.

Role you hold. Provider or deployer under the Act. In most cases you are the deployer, using a system someone else built.

Risk tier. Prohibited, high-risk, limited-risk, or minimal-risk. This is the field the Act's obligations key off.

Lawful basis. If the system processes personal data, the GDPR lawful basis. Consent, contract, legitimate interest, legal obligation, and so on. Leave blank where no personal data is involved, and say so explicitly rather than leaving an ambiguous gap.

Article 50 transparency flag. A yes or no on whether the system triggers a transparency duty under Article 50. This covers systems that interact with people as a chatbot, that generate synthetic content, or that produce deepfakes. Where the flag is yes, you owe a disclosure.

Classification rationale. One or two sentences explaining why you assigned the tier and role you did. This is the field auditors value most, because it shows the reasoning, not just the result.

Review date. When you last reviewed the entry, or when the next review is due. A register without dated reviews drifts out of date and quietly stops being defensible.

Status. Where the system stands. In use, piloting, retired, blocked, pending review.

how to populate it

No single source shows you everything. You assemble the picture from several, and you accept that some AI use leaves no trace at all.

The IdP and SSO app list. Start with your identity provider. The list of applications connected through SSO surfaces the AI tools that went through a sanctioned path. This is the cleanest source and the natural first pass.

OAuth grants to AI tools. Pull the full list of OAuth grants and filter for AI-related apps. This catches connector apps that received permission to read company email or documents, including ones IT never deployed. OAuth grants are where a surprising amount of real AI access lives.

SaaS admin consoles. Many SaaS products you already pay for have added AI features. The admin console of each major platform tells you whether AI capabilities are switched on and what data they reach. A tool you classified a year ago as non-AI may now carry an AI feature.

A short staff survey. Ask people directly which AI tools they use for work, including personal accounts. Keep it short and make it safe to answer honestly. The survey reaches the use that leaves no directory footprint.

Expense and card data. Subscriptions paid on a personal card and expensed, or on a team card outside procurement, show up in finance records before they show up anywhere in IT. A scan of expense lines for AI vendors often surfaces tools no directory knows about.

Here is the honest part. Some AI use will not appear in any of these. A personal account opened on a home device, used for work, paid for personally and never expensed, leaves no trace you can pull. That is why the survey matters, and why the register is a living document. You will not reach perfect coverage. You aim for current, defensible coverage that improves with each review cycle.

how to classify each entry

Two fields need a method behind them: tier and role. Both have traps that catch people who rush.

the tier decision path

Work through these in order and stop at the first that fits.

1. Is it a prohibited practice under Article 5? Social scoring, certain manipulative techniques, certain biometric uses, and the rest of the Article 5 list. If yes, the tier is prohibited and the use stops. This is rare in ordinary business tools, but the check is mandatory.
2. Is it high-risk under Annex III? Annex III names the high-risk use areas, including AI used in employment decisions, access to essential services, credit scoring, and certain critical functions. If the system is used for one of these purposes, it points toward high-risk. Then apply the Article 6(3) carve-out: a system that would otherwise be high-risk is not high-risk if it performs a narrow procedural task, improves the result of a prior human activity, or does similar limited work that does not materially influence the outcome. The override matters: if the system performs profiling of natural persons, the carve-out does not apply and the system stays high-risk.
3. Does it trigger limited-risk transparency under Article 50? A chatbot people talk to, a system that generates synthetic audio, image, video, or text, or one that produces deepfakes. If yes, and it is not high-risk, the tier is limited-risk and you owe the Article 50 disclosure.
4. Otherwise, minimal-risk. Most general-purpose productivity tools land here. Minimal-risk carries no mandatory obligations under the Act, though you still record the system and follow your own governance.

the role decision path

For each system, decide whether you are the provider or the deployer. You are the deployer when you use an AI system that someone else built and placed on the market. This is the common case. You are the provider when you develop an AI system, or have one developed, and place it on the market or put it into service under your own name. Building an in-house model or a custom AI feature into a product you ship puts you here.

The trap sits in Article 25. A deployer can become a provider of a high-risk system, with the heavier provider obligations that follow, in specific situations. Putting your own name or trademark on a high-risk system already on the market, making a substantial modification to it, or modifying the intended purpose of a non-high-risk system so that it becomes high-risk, can each reclassify you. If you customize, rebrand, or repurpose an AI system in a meaningful way, re-check your role rather than assuming you stayed a deployer.

the reusable template

Copy the table below into your own document, spreadsheet, or register tool. The example rows are illustrative only; replace them with your own systems and reasoning.

• General writing assistant (enterprise tier) · Owner: Head of IT · Vendor: Vendor A · Data it touches: Internal docs, no personal data per policy · Role: Deployer · Risk tier: Minimal · Lawful basis: N/A, no personal data · Art. 50 flag: No · Classification rationale: General-purpose productivity tool, not an Annex III use, no transparency trigger · Review date: 2026-06-01 · Status: In use
• Customer support chatbot on website · Owner: Support Lead · Vendor: Vendor B · Data it touches: Customer messages, contact details · Role: Deployer · Risk tier: Limited · Lawful basis: Legitimate interest · Art. 50 flag: Yes · Classification rationale: Interacts with people as a chatbot, Art. 50 disclosure required, not an Annex III use · Review date: 2026-06-01 · Status: In use
• CV-screening tool for hiring · Owner: Head of HR · Vendor: Vendor C · Data it touches: Candidate personal data, CVs · Role: Deployer · Risk tier: High-risk · Lawful basis: Consent / legitimate interest, DPIA on file · Art. 50 flag: No · Classification rationale: Annex III employment use, profiling of candidates so Art. 6(3) carve-out does not apply, FRIA under Art. 27 required · Review date: 2026-06-01 · Status: Pending review
• In-house demand-forecasting model · Owner: Data Team Lead · Vendor: Built in-house · Data it touches: Aggregated sales data, no personal data · Role: Provider · Risk tier: Minimal · Lawful basis: N/A, no personal data · Art. 50 flag: No · Classification rationale: Built and used internally, not an Annex III use, provider role because developed in-house · Review date: 2026-06-01 · Status: Piloting

Field-by-field key: system name plus edition where it changes the terms; owner as a named accountable person, not a team; vendor as the legal entity where you can find it; data it touches at the category level, which drives lawful basis and tier; role re-checked after any rebrand, modification, or change of purpose; risk tier from the decision path; lawful basis stating N/A explicitly where none; Art. 50 flag yes where the system is a chatbot, generates synthetic content, or produces deepfakes; classification rationale in one or two sentences; review date last reviewed or next due; and status as in use, piloting, retired, blocked, or pending review.

maintenance

A register is a living record. Three habits keep it accurate.

A review cadence. Set a fixed schedule to revisit every entry. Quarterly suits most organizations, since AI features and vendor terms change quickly. An annual review is the minimum. At each review you confirm the tier, the role, the data, and the status, and you update the review date.

A new-tool intake path. Decide how a new AI tool gets onto the register before it gets into wide use. Tie it to your existing AI tool vetting process so a tool is classified as it is approved, not months later. A named intake owner and a target turnaround keep the path usable.

Re-classification when a system changes. A tool that gains an AI feature, expands the data it touches, or changes its purpose may move tiers or move you from deployer to provider. Treat a material change as a trigger to re-run the tier and role decision paths for that entry. The classification rationale field is where you record what changed and why the value moved.