Ask a mid-market company how many AI systems it runs, and the honest answer is usually “we’re not entirely sure.” Between vendor SaaS tools with embedded AI features, internal scripts built by individual teams, and models bolted onto existing products, most organizations have more AI in production than anyone has actually listed. That gap is the first thing an EU AI Act compliance program has to close — you cannot classify, document, or monitor a system you haven’t identified. This is the starting point every other compliance step depends on.
Why the Inventory Comes First
Every subsequent compliance task assumes an inventory already exists:
- Risk classification requires knowing what each system does and how it’s used, which requires knowing the system exists in the first place.
- Provider/deployer role assignment requires knowing whether you built, bought, or fine-tuned each system.
- Annex IV documentation is written per system, against a specific entry in the inventory.
- Post-market monitoring tracks changes to systems already catalogued — you can’t monitor drift on something that was never recorded.
Skipping straight to “let’s document our high-risk systems” without a complete inventory first is the single most common reason compliance programs stall: teams discover mid-project that the system they’re documenting has an undocumented sibling, or that a “simple automation” tool actually has an AI-scoring feature no one flagged.
What to Include — Broader Than You’d Expect
An AI system, for inventory purposes, is anything that produces predictions, recommendations, decisions, or generated content that influences a real or virtual environment with some degree of autonomy. That definition is intentionally broad. Include:
- Purpose-built AI products — the obvious ones: a resume-screening tool, a fraud-detection model, a chatbot.
- Embedded AI features inside general software — a CRM’s lead-scoring feature, a project-management tool’s “smart” task assignment, an HR platform’s sentiment analysis on employee feedback. These are frequently missed because the software wasn’t purchased as an AI product.
- Internal models and scripts — anything a data team or individual engineer built and put into a live process, even informally, even without a name or owner.
- Third-party APIs called from your own code — if your product calls an external model API to make a decision your system then acts on, that call is part of your AI footprint even though you don’t control the model.
- Fine-tuned or customized versions of vendor models — a base model you’ve adapted changes both your inventory entry and potentially your provider role for that system.
Fields Worth Capturing Per System
A usable inventory entry needs more than a name. At minimum:
| Field | Why it matters |
|---|---|
| System name and owner | Someone accountable when a question comes up |
| What it does / decision it influences | Feeds directly into risk classification |
| Provider (vendor or in-house) | Determines who owns technical documentation |
| Your role: provider, deployer, or both | Determines which obligations sit with you |
| Deployment context (department, geography, user base) | Same model can classify differently by context |
| Data inputs | Needed for data governance and DPIA overlap with GDPR |
| Last reviewed date | Flags stale entries before they become compliance gaps |
Where Mid-Market Teams Miss Systems
Shadow AI adoption. Individual teams adopting AI tools (a marketing team using a generative copy tool, a sales team using an AI meeting summarizer) without going through procurement or IT review. These rarely appear in any centralized system list.
“It’s just a feature, not an AI product.” Vendors increasingly ship AI capabilities as incremental feature updates to existing software, rather than as a distinct new purchase. A feature flag turned on in a routine software update can add an AI system to your footprint without any new contract or announcement to flag it.
Pilots and proofs-of-concept that quietly went to production. A tool tested with a small team for a few weeks sometimes never gets formally decommissioned or formally adopted — it just keeps running.
Systems owned by acquired companies or business units. M&A activity frequently imports AI systems that were never inventoried under the acquirer’s own process.
Keeping It Current
An inventory built once and never revisited becomes inaccurate within months — new vendor features activate, internal models get retrained, pilots go live. Build a light recurring process: a quarterly prompt to system owners to confirm their entries are still accurate, plus a standing requirement that any new AI-enabled tool (vendor or internal) gets added to the inventory before it reaches production, not after.
From Inventory to Compliance
Once systems are inventoried, the next steps are checking for Article 5 prohibited practices, classifying against Annex III, and assigning provider/deployer roles. Aikraft is built to hold this inventory as the single source of truth that classification, documentation, and monitoring all pull from — get started free with up to one system, or take the risk quiz if you just want a first read on a specific system today.