Building an EU AI Act-compliant AI inventory: a step-by-step guide

By PowerQuant | Updated June 2026 | Reading time: ~11 minutes

Step 1: Define what you are inventorying (the scope question)

The EU AI Act supplies its own definition in Article 3(1): an AI system is a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.

In operational terms for an HR organisation: if a tool produces a score, ranking, recommendation, classification, generated text, or auto-decision based on inference rather than a fixed rules engine, treat it as AI for inventory purposes. The boundary cases — a rules-based shortlisting filter that uses no statistical inference — may not fall within the Act's definition, but they belong in the inventory as “out of scope — deterministic rule” so that the decision is documented.

Scoping decisions to make explicitly, and document:

• Which legal entity is designated as deployer for each system (Article 3(4)). In a multi-entity group, the entity that uses the system under its own authority is the deployer — the parent company cannot absorb the obligation by default.
• Which GPAI use-cases are included — each use of a foundation-model API (ChatGPT, Claude, Gemini, Copilot) where the output enters an HR decision should be an inventory entry, with the model identity and version recorded.
• Which embedded features are included — AI capabilities bundled inside existing SaaS (ATS AI matching, performance-platform sentiment scoring, learning-platform recommendation engines) should appear as system entries, not as sub-features to be noted and forgotten.

Step 2: Design the field schema before you collect anything

Resist the temptation to start collecting data before you have agreed on the fields. Merging inconsistently formatted lists later costs more time than agreeing on the schema upfront.

A minimum viable schema for an AI Act deployer inventory:

A spreadsheet is fine to start. Do not buy a GRC platform before the inventory is populated — the tool should be selected based on what you learn from the first pass of data, not before it.

Step 3: Discovery — finding systems you do not know about

The single biggest risk in inventory building is incomplete discovery. Modern HR AI does not arrive through the IT asset register — it arrives via SaaS features enabled by default, shadow procurement, expired pilots, and internally built tools. Run three parallel discovery passes:

Pass A — IT and security exports

Pull the sanctioned SaaS register, SSO login logs, network egress to known AI-vendor domains, and the corporate App Store / approved-software list. This will find the corporate-licensed tools, but it systematically misses shadow procurement and GPAI use via personal accounts.

Pass B — Finance and procurement exports

Filter expense claims, accounts-payable records, and purchasing-card data against a working list of HR AI vendors and tool categories. Flag any vendor that appears in finance records but not in the IT list — these are candidate shadow-procurement entries.

Pass C — Structured stakeholder interviews

Run a 20-minute structured conversation with each of: Talent Acquisition lead, HRBP lead, People Analytics, Learning & Development, Workforce Management, and Internal Communications. Ask the same five questions every time:

1. What AI tools does your team use?
2. Which AI features are enabled in your existing platforms (including features you did not switch on yourself)?
3. Are there any AI pilots running or recently concluded?
4. Has your team built or commissioned any internal AI tools or dashboards?
5. Do you send any candidate or employee data to a third-party service to produce a score, recommendation, or output?

Systems that appear in only one of the three passes are the highest-priority items to validate — a tool that finance pays for but no one will own, or one that an HRBP describes but IT has never heard of, carries a disproportionate risk of being the most sensitive system in the portfolio.

Step 4: Classify each system

For each candidate entry in the merged discovery list, apply the classification workflow:

1. In scope as AI? Does the system meet the Article 3(1) definition? If it is a deterministic rules engine with no inference, classify as “out of scope — deterministic” and document the reasoning.
2. Annex III point 4? Does the intended purpose fall within point 4(a) (recruitment / evaluation) or 4(b) (terms of employment / allocation / performance / monitoring)? If yes, provisionally classify as high-risk.
3. Article 6(2) exception? Is the system a narrow procedural tool, an improvement layer over completed human activity, a pattern-detection tool without decision influence, or a preparatory tool only? If yes, and if it does not materially influence the outcome for the affected individual, classify as non-high-risk and document the specific condition and reasoning.
4. Provider vs. deployer designation: have you modified the system substantially enough to trigger Article 25 co-provider status? Document the analysis.
5. Article 50 obligations: regardless of high-risk classification, does the system interact directly with candidates or employees (Art. 50(1)), use emotion recognition (Art. 50(3)), or produce deep-fake or public-interest content (Art. 50(4))? Mark the applicable sub-paragraphs.

Step 5: Gather per-system evidence for high-risk systems

For every Annex III high-risk system, send the provider a structured evidence request covering: instructions for use (Article 13), EU declaration of conformity or CE-marking timeline (Article 47), EU database registration reference (Article 49), human-oversight capability documentation (Article 14), and log retention configuration.

Track each request with a deadline. A vendor that does not respond within two weeks is giving you information about their own readiness. Escalate; if necessary, document the gap and begin risk assessment of whether continued use is appropriate.

Concurrently, build the deployer-side evidence per system:

• Standard operating procedure — how the system is used, by whom, with confirmation that use follows the provider's instructions.
• Oversight role record — named individual, authority to intervene, training records.
• Worker information notice — before deploying in the workplace, written notice to workers and their representatives (Article 26(7)). This has the longest lead time if works-council consultation is required.
• DPIA integration — if a GDPR Article 35 DPIA is required, the provider's Article 13 information should be incorporated (Article 26(9)).
• Affected-person disclosure — standard text for candidates and employees confirming they are subject to a high-risk AI system (Article 26(11)).

Step 6: Integrate with GDPR Records of Processing Activities

The AI inventory and the GDPR Records of Processing Activities (RoPA) overlap but are not the same document. Every Annex III high-risk HR AI system will process personal data, so it should appear in the RoPA. Link the inventory entry to the RoPA entry — do not merge them. The RoPA answers “what personal data is processed and under which legal basis?” The AI inventory answers “what AI decision does this data feed, and what AI Act obligations does that trigger?”

Practical cross-references to maintain:

• Each AI inventory entry should include the RoPA reference number for the corresponding processing activity.
• Where a DPIA is required under GDPR Article 35, the AI inventory entry for the same system should link to the DPIA document.
• Log retention periods in the AI inventory should be cross-referenced against the GDPR retention periods in the RoPA — where they conflict, take legal advice.

Step 7: Governance — keeping the inventory live

An AI inventory that is six months out of date is worse than no inventory. SaaS vendors ship AI features continuously; procurement happens without central visibility; models are updated. You need a governance structure that keeps the inventory current without turning it into a full-time role.

• Assign a single owner who has the authority and the calendar time to maintain the inventory. Name the person in the document.
• Quarterly review cadence: a 60-minute check each quarter against the IT SaaS register, a mini-finance scan, and a standing question to the HR leads about new tools or features.
• Event-triggered updates: new system procurement, material provider update, significant process change, Article 73 serious incident. Any of these triggers an out-of-cycle inventory update for the affected system.
• Procurement gate: HR procurement checklists should include an AI inventory question as a standard step before contracting any new SaaS tool.
• Annual full refresh: once per year, repeat the three discovery passes from Step 3. Shadow AI creeps back in; the annual full refresh catches it.

What “done” looks like

• A single, versioned file or register — every system has an entry.
• Every entry has: intended purpose, provider/deployer designation, Annex III classification with reasoning, evidence links (or pending status), oversight role, and Art. 50 obligations.
• A methodology note explaining how the inventory was built (sources, dates, interviewees) so an auditor can validate the method.
• A named owner and a blocked quarterly review date.
• An open vendor-evidence request tracker with deadlines.
• A link from each high-risk entry to the corresponding RoPA reference.

Sources

• Regulation (EU) 2024/1689 (AI Act), Articles 3, 6, 13, 14, 25, 26, 27, 47, 49, 50 and Annex III — eur-lex.europa.eu/eli/reg/2024/1689/oj
• European Commission — AI Act Service Desk, Annex III guidance — ai-act-service-desk.ec.europa.eu
• European Commission — draft guidelines on classification of high-risk AI systems — digital-strategy.ec.europa.eu
• Regulation (EU) 2016/679 (GDPR), Articles 30, 35.