AI System Inventory & Risk Register for the EU AI Act

The hardest part of EU AI Act readiness is not the conformity assessment or the technical documentation. It is the question that comes before all of them: which AI systems do we actually have, and what are they doing? In every readiness engagement we run at CC Conceptualise, the inventory is where the programme either gets traction or quietly stalls.

This post is a practitioner's guide to building two linked artefacts — an AI system inventory and an AI risk register — that hold up under regulatory scrutiny, work at enterprise scale, and can be operated rather than refreshed by hand every quarter.

TL;DR / Key takeaways

• You cannot do conformity assessment, EU-database registration, or post-market monitoring without a complete, classified AI system inventory — it is the load-bearing artefact for everything else.
• High-risk (Annex III) obligations apply from 2 August 2026; GPAI obligations already applied from 2 August 2025. Discovery and classification take longer than teams expect, so start now.
• The right unit of inventory is usually the use case, not the model — one model can power several systems with very different risk profiles.
• An AI risk register must track AI-specific harms (bias, drift, hallucination, poisoning, weak human oversight), each linked to a system, an Article, and a concrete risk management measure.
• In Azure you can assemble most of the inventory from signals you already emit — Resource Graph, Azure OpenAI, Azure ML, AI Foundry, Purview, Defender for Cloud — instead of buying a tool on day one. ISO/IEC 42001 gives you the governance frame.

Why the inventory is the keystone obligation

Read the Act carefully and a dependency chain appears. Conformity assessment requires you to know a system is high-risk. Registration in the EU database requires you to have identified the system and its provider. Post-market monitoring requires you to know what is in production and who owns it. Human-oversight obligations for deployers require you to know which systems make or assist consequential decisions.

None of these can be done well against an estate you have not enumerated. That is why we treat the inventory as the keystone: pull it out and the rest of the compliance arch collapses. For the broader sequence of deadlines and tasks, our EU AI Act August 2026 readiness checklist sets the timeline; this post zooms into the artefact that everything else hangs from.

The uncomfortable reality is that most enterprises underestimate their AI surface area by a wide margin. AI now arrives through three doors: systems you build, models and platforms you consume (Azure OpenAI, third-party APIs), and AI quietly embedded in SaaS your business units already bought. An inventory that only counts the first door is not an inventory.

Step 1 — Discover the full AI estate

Discovery is the part teams want to skip and the part that decides whether the programme is credible. Cast a wide net across at least these sources:

• Built systems — application repositories, Azure ML registered models, AI Foundry projects, Databricks model registries.
• Consumed models — Azure OpenAI deployments, third-party LLM API keys, embedded vendor models.
• Procured AI — SaaS tools with AI features (HR screening, CRM scoring, support copilots). Mine your procurement and SSO logs.
• Shadow AI — browser extensions, personal API usage, departmental scripts. Network and CASB signals help here.

In Azure, Resource Graph queries plus tag conventions surface cognitive-services and ML resources quickly, and Microsoft Purview can anchor the data lineage. The goal of this phase is a candidate list — breadth over precision. You will classify and prune next.

Step 2 — Define the unit of inventory

Before you fill anything in, settle a deceptively important question: what is one AI system?

Unit of inventory	What it means	When to use it	Trade-off
Model	A single trained or hosted model	Rarely as the primary unit	One model can serve many use cases with different risk; misses the regulatory frame
Use case	A purpose-bound application of AI in a business context	Default choice for the AI Act	Maps cleanly to Annex III, provider/deployer role, and risk tier
Deployment	A specific environment instance	For ops/monitoring detail	Too granular for governance; explodes the register

The Act reasons in terms of intended purpose and use, so the use case is almost always the right primary unit. One GPT-4-class model behind both an internal knowledge assistant (minimal risk) and a CV-ranking tool (high-risk, Annex III) is two entries, not one. Getting this wrong is the most common reason inventories produce misleading risk pictures.

Step 3 — Capture the classification metadata

Each inventory entry should carry enough metadata to drive classification and downstream obligations. A workable minimum schema:

1. Identity — name, owner, business unit, system ID.
2. Purpose — intended use, decision it makes or assists, affected persons.
3. Role — are you the provider (you place it on the market / develop it) or the deployer (you use it under your authority)? Obligations differ sharply.
4. Technical — models used, GPAI involved, data sources, hosting (e.g. Azure OpenAI, on-prem), integration points.
5. Regulatory — Annex III category if any, risk tier, conformity route, EU-database registration status.
6. Lifecycle — status (proposed, in dev, production, retired), last review date, next review date.

To work out the Annex III hooks precisely, pair this step with our deep dive on Annex III high-risk classification. Capturing the provider vs deployer role early matters enormously: a bank deploying a vendor's credit-scoring model has monitoring and human-oversight duties, while the vendor carries the heavier conformity and documentation burden.

Step 4 — Classify each system

With metadata in place, assign a risk tier to every entry. Keep the decision and its rationale on the record — regulators and auditors care as much about how you decided as what you decided.

Tier	Trigger	Primary obligations	Inventory action
Prohibited	Article 5 practices	Cease	Flag and escalate to leadership immediately
High-risk	Annex III or safety component	Conformity assessment, EU-database registration, technical documentation, post-market monitoring, human oversight	Full risk-register entry; assign accountable owner
Limited	Interacts with people, generates content	Transparency / disclosure	Lightweight register entry
Minimal	Everything else	Voluntary good practice	Inventory only

Treat classification as a documented decision with a named decision-maker, not a spreadsheet guess. When a system is high-risk, the path forward runs through our conformity assessment guide.

Step 5 — Build the AI risk register

The inventory tells you what exists; the risk register tells you what could go wrong and what you are doing about it. For every high-risk and otherwise material system, open register entries that go beyond generic enterprise risk and capture AI-specific failure modes:

• Bias and discrimination in outputs affecting individuals.
• Performance drift as data distributions shift post-deployment.
• Hallucination / factual error in generative systems.
• Data poisoning and prompt injection against the pipeline.
• Insufficient human oversight — automation bias, rubber-stamping.
• Robustness and security failures, including model supply-chain risk.

Each entry should link to (a) the system in the inventory, (b) the relevant Article or Annex III category, and (c) one or more concrete risk management measures with an owner and a review cadence. This is where an AI Act risk register diverges from a financial one: the unit of mitigation is a technical or procedural control, not a provision.

Operating the inventory in Azure

A register that is built once and never touched is worse than none — it creates false assurance. The pattern we deploy makes the inventory self-maintaining:

• Tagging standard — enforce ai-system-id, risk-tier, and owner tags via Azure Policy on cognitive-services and ML resources.
• Resource Graph queries — scheduled queries detect new AI resources and flag any untagged or unregistered deployment as drift.
• Purview catalogue — anchors data lineage so you can answer "what trained this model" during an audit.
• CI/CD and procurement gates — a pipeline check and a purchasing checkpoint require an inventory entry before an AI system ships or is bought, closing the shadow-AI gap at the source.
• Defender for Cloud — feeds security posture and AI-workload findings back into the register.

Layer ISO/IEC 42001 over this and you get an auditable AI management system: its controls expect exactly this documented set of systems, impact assessments, and lifecycle governance, so the same artefacts evidence both the standard and your AI Act diligence. In our delivery work, the teams that wire governance into pipelines and procurement — rather than running an annual manual census — are the ones that still have an accurate inventory twelve months later.

A pragmatic sequence

Loading diagram...

1. Run discovery across built, consumed, and procured AI; produce a candidate list.
2. Fix the unit of inventory (use case) and the metadata schema.
3. Populate entries and assign accountable owners.
4. Classify every system and record the rationale.
5. Open risk-register entries for high-risk and material systems.
6. Automate detection, tagging, and gates so the register stays live.

Start this now, not in July. With Annex III obligations live from 2 August 2026 and penalties reaching EUR 15M or 3% of global turnover for high-risk non-compliance (and EUR 35M or 7% for prohibited practices), the inventory is the cheapest insurance you can build.

FAQ

What is an AI system inventory under the EU AI Act? An AI system inventory is the authoritative list of every AI system your organisation develops, deploys, or procures, together with the metadata needed to classify and govern it. It records purpose, role (provider or deployer), risk classification, data sources, models, owners, and lifecycle status. It is the foundation on which conformity assessment, registration, and post-market monitoring depend.

Is an AI inventory legally required by the EU AI Act? The Act does not name an inventory as a standalone artefact, but you cannot satisfy its obligations without one. High-risk providers must maintain technical documentation, register systems in the EU database, and run post-market monitoring; deployers must ensure human oversight and monitor operation. All of these presuppose that you know which systems exist and how they are classified.

How is an AI risk register different from a normal risk register? An AI risk register tracks AI-specific harms such as bias, performance drift, hallucination, data poisoning, and lack of human oversight, alongside the conformity and fundamental-rights risks the Act emphasises. It links each risk to a specific system in the inventory, to the relevant Article or Annex III category, and to concrete risk management measures rather than only to financial or operational impact.

When do EU AI Act high-risk obligations start? Obligations for high-risk systems listed in Annex III apply from 2 August 2026. General-purpose AI model obligations applied from 2 August 2025, and GPAI models already on the market before that date must comply by 2 August 2027. Building the inventory and register now is what makes those deadlines achievable.

Can we build an AI inventory in Azure? Yes. Most enterprises already have the signals in Azure: Azure OpenAI deployments, Azure ML registered models, AI Foundry projects, Azure Resource Graph, Microsoft Purview, and Defender for Cloud. We typically aggregate these into a single governed register with Azure tags, a Purview-backed catalogue, and Resource Graph queries, rather than buying a separate tool on day one.

How does ISO/IEC 42001 relate to the AI inventory and risk register? ISO/IEC 42001 is the AI management-system standard. Its controls expect a documented set of AI systems, an impact and risk assessment process, and lifecycle governance, which map almost one-to-one onto an inventory and risk register. Aligning to 42001 gives you an audit-ready governance frame that also evidences EU AI Act diligence.

---

Building or pressure-testing your AI inventory and risk register before August 2026? Our AI governance and engineering practice helps European enterprises stand up a defensible, Azure-native AI register and the controls behind it. We are practitioners, not slideware — happy to compare notes.