Building an EU AI Act system inventory
The EU AI Act requires organisations to know which AI systems they deploy and which tier each one falls into. Building that inventory is harder than it sounds when AI is embedded in SaaS, vendor products, and internal tooling.
Before any EU AI Act obligation can be addressed, an organisation must answer a deceptively simple question: which AI systems do we actually have? The question sounds administrative. In practice, it is one of the harder exercises in AI governance — because AI is embedded in enterprise software at a depth that most inventory processes were not built to surface.
This piece describes how to build a structured AI system inventory: what to look for, where to look, how to classify each system, and how to keep the inventory accurate as systems change. The inventory is the prerequisite for every downstream EU AI Act obligation. None of the compliance work makes sense without it.
Why inventory comes before everything else
The EU AI Act assigns obligations by tier and by role. High-risk systems require risk management documentation, technical documentation, and human oversight measures. Deployers of high-risk systems have their own obligations distinct from providers. None of this can be addressed without knowing which systems you have, which tier each falls into, and whether you are acting as a provider or a deployer.
The inventory is also the foundation for proportionate resourcing. Most organisations that have begun EU AI Act preparation have discovered that the number of in-scope systems is both larger and more varied than they expected. Systems that were procured as productivity tools have AI features that touch employment processes; vendor products have updated their architectures to include AI without explicit disclosure in procurement documentation; internal teams have built data pipelines that now include model inference steps.
What counts as an AI system
The EU AI Act defines an AI system as a machine-based system designed to operate with varying levels of autonomy that may exhibit adaptiveness, 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.
This definition is broad. It covers:
- Machine learning models, including deep learning and transformer-based models
- Large language models accessed via API, whether hosted internally or externally
- Rule-based systems with learned components (hybrid systems)
- Recommendation engines and ranking systems
- Scoring and classification models embedded in SaaS products
- Computer vision systems used for quality control, security, or content moderation
- Agentic systems that plan and execute multi-step tasks
It does not cover deterministic rule-based systems that apply only rules explicitly defined by humans without inference or learning — though the boundary between rule-based and ML-assisted systems is increasingly blurred in commercial software.
The definition question that matters most in practice is not “is this AI?” but “does this system infer outputs from inputs in a way that influences decisions affecting people?” That framing catches the systems that matter under the Act.
The discovery process
A structured AI system discovery covers six sources. Each source surfaces a different category of system. Relying on only one or two will produce an incomplete inventory.
Discovery sources — where assessed systems are typically found
| Source | What to review | Discovery signal |
|---|---|---|
| Enterprise software catalogue | Review every licensed SaaS product and enterprise application for AI-powered features. Vendors embed AI into productivity tools, CRM, HRIS, and ERP without prominent disclosure. | Product release notes, vendor AI feature pages, embedded ML scoring, recommendation engines, natural language interfaces |
| Vendor contracts and procurement records | Review contracts for AI, machine learning, automated decision-making, or algorithmic processing clauses. Many vendors updated their terms silently when adding AI features. | DPA schedules, AI addenda, sub-processor lists, automated processing disclosures |
| Internal development teams | Survey engineering and data science teams for internally built models, fine-tuned versions of commercial models, or pipelines that call external AI APIs. | Python notebooks, model registries, MLOps infrastructure, API keys to AI providers, data science team backlogs |
| IT service management records | Review ITSM tickets, change management records, and integration logs for AI-related deployments. AI is often deployed as part of a broader system change without its own ticket. | API gateway logs, service mesh configuration, deployment pipelines that reference AI model endpoints |
| Procurement and finance records | Review purchase orders and software subscriptions for AI platform, LLM API, or model serving spend. Shadow AI is common — employees subscribing to AI tools on personal or team budgets. | Subscriptions to OpenAI, Anthropic, Azure OpenAI, Cohere, Mistral, Hugging Face, AWS Bedrock |
| Business process owners | Interview business unit owners about decisions that affect external parties — customers, employees, applicants. Ask whether any part of those decisions is assisted or automated by software. | Screening tools, scoring systems, routing logic, automated triage, recommendation outputs used in decision-making |
The discovery process is not a one-time exercise. It should be run as an initial comprehensive review and then embedded into the change management and procurement processes so that new systems are captured as they are deployed.
Classification for each discovered system
Each system discovered must be classified against the EU AI Act tier structure. Classification is not a global exercise — it is per-system and per-deployment-context. The same underlying model may be minimal-risk in one use and high-risk in another.
The classification process for each system involves three questions:
- Does the system fall within Article 5? If yes, it is prohibited regardless of any other consideration. Review against the eight prohibited categories before proceeding to tier classification.
- Does the system fall within Annex III or Annex I? Work through each of the eight Annex III categories. If the system is a safety component of an Annex I product requiring third-party conformity assessment, it is high-risk.
- Does the system trigger Article 50 transparency obligations?Even if the system is not high-risk, it may have limited-risk obligations if it interacts with humans without disclosure, generates synthetic content, or performs emotion recognition.
The classification rationale — the reasoning for why a system is or is not in each category — should be documented alongside the classification result. This rationale is the evidence that the classification was made deliberately and is defensible if challenged by a regulator or auditor.
For a detailed walkthrough of each tier and the criteria that define them, see the EU AI Act AI system inventory hub and the accompanying risk tiers guide.
Maintaining the inventory as systems change
An inventory that was accurate at a point in time and has not been maintained is worse than no inventory — it creates false assurance. The EU AI Act's obligations are ongoing, not one-time, and the inventory must reflect the current state of the organisation's AI estate.
Practical maintenance requires integrating the inventory into three existing processes:
- Change management — any material change to an assessed system (new training data, new use case, new user population, new integration) should trigger a re-classification review. The change management process should include an AI inventory check as a standard step.
- Software procurement — new software procurement should include a structured AI disclosure question. Vendors should be asked whether the product includes AI features, what those features do, and whether the product has been assessed against EU AI Act requirements by the provider.
- Vendor management — existing vendor contracts should be reviewed periodically for AI feature additions. Vendors that are actively embedding AI into their products (which is most enterprise software vendors) should be reviewed at least annually.
What the inventory must evidence
An AI system inventory serves two purposes: operational governance (knowing what you have) and regulatory evidence (demonstrating that you have assessed your systems systematically). For the second purpose, the inventory must be structured to function as documentary evidence.
Inventory fields — what each entry must capture
| Field | Required | Notes |
|---|---|---|
| System name | Required | The name used by the business, not the vendor product name where they differ |
| System description | Required | What the system does, in one paragraph, from the user's perspective |
| Intended purpose | Required | The specific use case — not 'AI assistant' but 'screens inbound job applications for keyword match' |
| Risk tier | Required | Unacceptable / High-risk / Limited / Minimal, with classification rationale |
| Provider / vendor | Required | Who supplies the system. If internally built, the internal team responsible |
| Provider vs deployer role | Required | Whether your organisation is a provider, a deployer, or both for this system |
| Deployment context | Required | Which business process, which teams, which external populations (customers, employees, applicants) the system affects |
| Personal data processed | Required | Whether and what personal data flows through the system, for GDPR intersection |
| Classification date and reviewer | Required | When the classification was made and by whom — audit trail for the tier assignment |
| Last review date | Required | When the inventory entry was last verified as accurate |
| High-risk obligations status | Recommended | For high-risk systems: which of the six obligation areas have supporting documentation |
| Known control gaps | Recommended | Areas where the system's documentation or controls are incomplete |
For high-risk systems, the inventory entry is the index to a larger documentation set — the risk management record, technical documentation, data governance documentation, and evidence of human oversight measures. The inventory does not contain that documentation itself; it provides the structured record that links each system to where that documentation lives and what its current status is.
The inventory is not the evidence — it is the map to the evidence. Its value is in making the full evidence set navigable and demonstrating that assessment has been systematic rather than ad hoc.
When a regulator, notified body, or internal auditor asks for evidence of EU AI Act preparedness, the inventory is the first document they should receive — not because it contains the answers, but because it shows that the organisation knows which systems it has, which tier each falls into, and where to find the supporting documentation for each one.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Build your AI system inventory with structure
Drel's AI security review process maps assessed systems to EU AI Act tiers and produces the classification rationale and control gap documentation that regulators and auditors ask for.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.