How to map your AI systems for EU AI Act compliance

Estimated reading time: 5 minutes

If you are serious about EU AI Act compliance, you need an accurate EU AI Act system inventory rather than a spreadsheet full of guesses. In this guide we show CIOs, CISOs and heads of architecture how to build a single, living EU AI Act system inventory, map it to your enterprise architecture, and use that inventory as the anchor for all EU AI Act mapping, risk and governance work.

Most organisations today have:

• Scattered AI pilots and proof-of-concepts
• Embedded models hidden inside SaaS tools and data platforms
• Internal data science work that never made it into a central CMDB
• No single view of which systems fall under high-risk, limited-risk or minimal-risk obligations under the EU AI Act

The EU AI Act is already in force, with phased obligations running from 2025 onwards, including bans on prohibited AI practices and obligations for high-risk AI systems.

For the legal text and official timelines, see the European Commission’s EU AI Act page or the EUR-Lex entry for Regulation (EU) 2024/1689

If you do not have a clean, defensible AI system map, you will:

• Miss systems that are in scope
• Underestimate integration and data-flow risk
• Scramble to retrofit governance when regulators or customers ask questions

This article shows you, step by step, how to map every AI system you run so that you can comply with the EU AI Act in a structured way that fits your architecture.

Why an EU AI Act system inventory is the foundation of compliance

Every obligation in the EU AI Act starts with one question: what AI systems do you run? You cannot classify what you have not found, you cannot meet transparency duties for a chatbot nobody recorded, and you cannot prepare a high-risk system for its deadline if it is not on a list. The inventory is not paperwork before the real work. It is the real work, and everything else depends on it.

The deadlines make this concrete. Under the Act as amended by the Digital Omnibus in June 2026, the dates that bind you are these:

Notice that every row ends in an inventory question. That is the point of this article, and the template below answers the search most readers arrived on: it is a complete, copyable AI system inventory template, with worked examples, current to the Act as amended.

Step 1 – Define your AI system scope

Before you build an inventory, you must decide what you will treat as an “AI system” for your internal catalogue.

Use a broad and practical definition that aligns with the EU AI Act but is understandable to your teams. The regulation covers machine-learning, logic-based and statistical approaches that produce outputs such as content, predictions, recommendations or decisions.

For your programme, include at least:

• Standalone AI systems
  • Internal models (NLP, CV, recommendation engines, forecasting models)
  • Deployed models running on cloud ML platforms
• AI-enabled features in existing products and SaaS
  • “Smart” features in CRM, ERP, HR, SCM and marketing tools
  • AI analytics and decision support in BI platforms
• General-purpose AI and copilots connected to your data
  • LLM-based assistants integrated with internal knowledge or operational systems
• Third-party AI services integrated into your workflows
  • Risk-scoring APIs, identity checks, fraud detection, medical image analysis, etc.

If in doubt, include it. You can filter later. Missing systems is more dangerous than cataloguing too much.

Step 2: Build a structured EU AI Act system inventory (the template)

You need a single inventory rather than scattered spreadsheets in different teams. Depending on your tooling, add an AI dimension to your CMDB or architecture repository, create an AI register in your GRC platform, or start with a well structured spreadsheet and migrate later. The structure matters more than the tool, and this is the structure we use in client work:

The AI system inventory template

Worked examples

Three rows filled in the way we fill them for clients, using common situations rather than real client systems:

Copy the structure exactly if it helps: the fields are the ones regulators, auditors and customers keep asking about, and the two date-carrying fields are what turn a list into a plan. If you want it as a working document, any spreadsheet reproduces it in ten minutes, and the discipline is in the filling rather than the format.

Step 3 – Map operator roles and responsibilities

The EU AI Act places different obligations on different operator roles: provider, deployer, importer, distributor, product manufacturer and others.

For each AI system in your inventory, decide:

• Are you the provider?
  • You developed the system or you have it under your name or trademark.
• Are you the deployer?
  • You use the AI system in your organisation under your control.
• Are you an importer or distributor?
  • You bring AI systems into the EU market or distribute them further.
• Are you only a customer of a third-party SaaS provider using embedded AI?

Then record:

• Primary accountability owner internally (role and name)
• Which obligations apply to that role (at a high level)
• Which external parties must cooperate with you (e.g. vendor for technical documentation or incident reporting)

This is where the architecture view matters: the same system may have different roles for different entities in the value chain. Your map needs to make that traceable.

Step 4 – Classify risk level for each AI system

The EU AI Act places different obligations on different operator roles: provider, deployer, importer, Using your inventory, assess the risk level of each system:

• Prohibited AI – systems that fall into banned practices (e.g. certain forms of social scoring or manipulative techniques)
• High-risk AI – systems that fit Annex III categories (e.g. employment, credit scoring, biometric identification, medical devices, critical infrastructure, education, essential services).
• Limited-risk AI – systems that require specific transparency duties (e.g. chatbots, emotion recognition in certain contexts).
• Minimal-risk AI – general productivity or analytics tools with limited impact on rights or safety.

For each system, record:

• The risk level, with a short justification
• Applicable Annex III category if high-risk
• Whether any general-purpose AI or foundation models are involved, particularly if they fall under the Commission’s general-purpose AI rules and Codes of Practice.

You do not need a perfect legal opinion for every system on day one. You do need a consistent methodology that you can explain and refine.

Step 5 – Connect systems to your enterprise architecture

Now link your AI inventory into your Enterprise Architecture views:

• Business capability map
  • Tag which AI systems support which capabilities (e.g. customer onboarding, demand forecasting, regulatory reporting).
• Application landscape
  • Show where AI is embedded in existing applications and which interfaces expose AI outputs.
• Data flows and integration diagrams
  • Identify key upstream data sources and downstream consumers for each AI system.
• Technology stack
  • Record which cloud services, ML platforms, orchestration tools and model registries are used.

This step is what most legal-led programmes miss. It is also why many organisations will struggle to evidence compliance when auditors and regulators start asking for concrete architecture artefacts rather than just policies.

Step 6 – Link to your risk, control and policy frameworks

Once your AI system map is stable, integrate it into your existing governance stack:

• Risk registers
  • For each high-risk system, create or update risk entries linked to the AI system ID.
• Controls library and policies
  • Map required controls (data governance, technical reliableness, human oversight, logging, incident response) to specific systems rather than only to “AI in general”.
• Assurance and audit plans
  • Plan testing, validation and periodic review at system level – especially for high-risk AI and general-purpose AI models.

Many organisations already have mature frameworks for cyber and privacy. The AI system map lets you extend those frameworks to AI, instead of inventing a parallel universe.

Step 7 – Make the map operational rather than a static document

An AI system inventory that is updated once per year and forgotten is useless.

Put simple but firm operational rules around it:

• No AI system goes into production without an inventory entry and initial risk classification.
• Significant changes (new use cases, new data sources, new regions) trigger a re-assessment.
• Decommissioned systems are marked as such, with retention plans for models, logs and documentation.
• Product, data science and engineering teams know who owns updates and how to request changes.

You can embed these rules into:

• Change-management workflows
• Architecture review boards
• Project / product gating criteria
• AI steering committee or AI governance board processes

The result is a living, auditable map – not a one-off compliance exercise.

Common pitfalls when mapping AI systems (and how to avoid them)

From enterprise architecture work we see the same traps repeatedly:

1. Only mapping “obvious” AI Teams list a few flagship projects and ignore embedded AI inside SaaS, RPA, analytics and operational tools. Fix: make “AI-enabled features in third-party tools” a mandatory category in system discovery.
2. No alignment with data and security teams System lists are built in legal or strategy silos, with no reuse of existing data inventories, DPIAs or security asset lists. Fix: start with your existing registers (CMDB, data inventories, DPIAs, cloud catalogues) and overlay the AI dimension.
3. One-size-fits-all risk labels Everything is labelled “high-risk” or “not sure”, which is not credible. Fix: use a clear, explainable risk rubric aligned to Annex III and to your own risk appetite.
4. No ownership Systems are mapped, but nobody is accountable for keeping entries up to date or for responding to incidents. Fix: assign named owners and ensure your governance bodies use the map in real decisions (funding, approvals, reviews).

How Intelance builds EU AI Act system inventories

Everything in this guide is work we do for clients at fixed published fees, current to the Act as amended in June 2026:

• EU AI Act Readiness Assessment: the inventory built for you in four to six weeks, every system classified, your role determined per system, and a plan showing where each fix sits. From £18,000 + VAT, fixed after a scoping call. Most firms find a third more AI than they declared.
• AI Governance QuickScan: the broader governance baseline around the inventory, from £15,000 + VAT.
• AI Governance Office: the working function that keeps the inventory alive, intake, tiering, approvals and evidence, from £30,000 + VAT.

The honest pitch: the template above is complete, and a disciplined team can run it without us. Where we earn the fee is the finding, the classifying and the arguing: surfacing the AI nobody declared, defending a tier decision a regulator might challenge, and putting the controls into real systems.

Next steps

Copy the template, name an owner, and fill the first ten rows this week: the systems everyone already knows about. Then go hunting for the ones nobody declared, because that is where the risk lives. If the 2 August 2026 transparency date touches anything you run, start there. And if you would rather have the whole inventory built, classified and defended in four to six weeks, that is the EU AI Act Readiness Assessment, from £18,000 + VAT with every price published.

AI system inventories: frequently asked questions

What is an AI system inventory?

A single register of every AI system an organisation builds, buys or uses as an embedded feature, recording what each system does, who owns it, what data it uses, its EU AI Act risk tier, the organisation’s role for that system, and the next date that binds it. It is the foundation of EU AI Act compliance because every obligation starts with knowing what you run.

What should an AI inventory template include?

Fifteen fields cover it: system name, what it does, whether it was built, bought or embedded, vendor, business owner, users and scale, data used, whether it interacts with people, whether it generates content, risk tier, your role, the obligations that apply, the next binding date, evidence location, and status with a review date. A complete template with worked examples is provided in this article.

Does the EU AI Act require an inventory?

It does not name a single document, but its obligations are impossible to meet without one: you cannot classify, disclose, document or register systems you have not listed. In practice regulators, auditors and enterprise customers all ask for the register first, and high-risk systems must additionally be registered in the EU database.

How do we find AI systems nobody declared?

Look where they hide: features switched on inside software you already own, tools bought on expense cards, browser extensions, vendor updates that quietly added AI, and pilots that never ended. Procurement records, expense data and single sign-on logs find most of it. In our assessment work, most firms find roughly a third more AI than they declared.

Who should own the AI inventory?

One named owner, usually in architecture, risk or the CIO’s office, with each system also carrying its own business owner. Committees do not update registers. The register owner runs the review cycle. System owners answer for their rows.

How often should the inventory be updated?

On trigger and on schedule: on trigger whenever a system is added, changed or switched on inside existing software, and on a scheduled review, quarterly for most organisations. The 2026 transparency dates give the first hard deadline for having it current.

Can we keep the inventory in a spreadsheet?

Yes, to start, and honestly for longer than the tool vendors suggest. A disciplined spreadsheet with named owners beats an empty platform. Move to a GRC tool or architecture repository when scale, evidence linking or multiple editors make the spreadsheet crack.

What are the EU AI Act deadlines the inventory feeds?

Under the Act as amended in June 2026: prohibitions and general-purpose AI duties already apply, transparency duties from 2 August 2026, AI content marking from 2 December 2026, stand-alone high-risk obligations from 2 December 2027, and embedded high-risk systems from 2 August 2028.

Emmanuel Olatunji

Chief Enterprise Architecture Partner

Emmanuel founded Intelance in 2017 and has led architecture, AI governance, cyber and deal engagements across the UK, Europe, the Middle East and Africa. Every Intelance engagement runs under his direction, and every guide he publishes comes from that work.

See his record on LinkedIn About Intelance