The AI Inventory Problem Nobody Warns You About
Every EU AI Act guide teaches you the same thing: how to classify your AI systems. Decision trees, high-risk categories, Annex III, the difference between a provider and a deployer. The classification logic is well covered.
None of them tell you how to get a complete list of AI systems in the first place.
And that’s the part that actually eats your quarter — because you can’t classify what you haven’t found. Classification is a question you answer once you’re holding a system. The real work is everything that comes before that: finding every AI system your organization actually uses, getting accurate details about each one, and keeping that list current as it all keeps changing. That’s not a classification problem. It’s a collection problem. And it’s where most AI inventories quietly fail.
Why finding them is harder than it looks
When you start, you assume you know your AI systems. You don’t. They’re scattered in ways that resist a single view:
- Shadow AI. A marketing team running prompts through a tool you’ve never approved. A developer who wired an API into a side project. Nobody filed a ticket.
- Embedded AI. The CRM that quietly added “AI insights.” The HR platform that now scores candidates. You bought a SaaS product; you inherited an AI system.
- Vendor models. Systems you don’t run but are still accountable for as a deployer.
- Distributed ownership. The person who knows what a model does, what data it touches, and who oversees it is rarely the person building the inventory. The knowledge lives in twenty heads across the org — not in yours.
So the inventory isn’t something you write down. It’s something you have to pull out of other people — and they’re busy, they don’t know your fields, and they don’t share your deadline.
The default approach, and why it breaks
Faced with this, most teams reach for the obvious tool: a spreadsheet and a round of emails.
You build a template. You send it around. You wait. Half the teams ignore it. The ones who reply fill it in differently — same field, three interpretations. You chase the rest. You copy their answers into the master sheet by hand, fixing formats as you go. Three weeks later you have something that looks like an inventory.
Then someone deploys a new model, a vendor updates theirs, an owner leaves — and your master sheet is wrong again. There was never a moment where it was both complete and current. You didn’t build an inventory; you built a snapshot that started decaying the day you finished it.
The transcription step is the quiet killer. Every time data passes through a human re-keying it from an email into a sheet, you add latency, errors, and a single point of failure: you. Scale that across an organization and across time, and the spreadsheet doesn’t just fail an audit — it fails to stay true long enough to be useful.
The reframe: it’s a collection mechanism, not a storage place
Here’s the shift that changes everything: the bottleneck was never where you keep the inventory. It’s how the data gets in — and stays current — without going through you.
A good inventory isn’t a document you maintain. It’s a system where:
- the people who know about an AI system are the ones who enter it,
- they’re guided so the data comes in consistent, not in twenty formats,
- and it updates in place, where work already happens — not in a sheet you have to reconcile.
Solve collection, and storage takes care of itself. Keep treating it as a document you own, and you’ll be chasing the same spreadsheet next quarter.
How Model Inventory for Jira approaches it
This is exactly the problem Model Inventory for Jira (MIFJ) is built around — and the design choice that follows from it: the collection happens where your teams already work, in your Jira.
Instead of a spreadsheet and a chase, you share one link. Anyone with access to the project can open the wizard and register the AI systems they own — guided through what’s needed: what the system does, what data it touches, who oversees it — with classification handled as they go. The data lands directly in your Jira as work items: one source of truth, no email round-trips, no re-keying, no master sheet to reconcile.
Because it lives in Jira, it behaves like the rest of your work: ownership is clear, changes are tracked, and the inventory stays current as people update their own entries — not when you find time to chase them. The collection is distributed; the record is centralized.
The approach is grounded in real practice. MIFJ’s governance model comes from seven years running model governance inside a European Tier-1 bank — an environment where an inventory that’s merely mostly current isn’t good enough. The same discipline, now in your Jira, without the team or the consultant a bank has behind it.
What to do next
If you’re staring down an AI inventory, resist the urge to start with the spreadsheet. Start with the question that actually decides whether this works: how does the data get in, and stay in, without routing through one person?
Get that right and the EU AI Act inventory you need becomes something your organization maintains — not something you rebuild every quarter. Classification is the part everyone teaches. Collection is the part that decides whether you ever finish.
You can see how distributed, self-service collection works in your own Jira with a 30-day free trial. The hard part doesn’t have to be hard.
Try FreeModel Inventory for Jira gives you a compliance-ready AI registry inside your existing Jira — distributed, self-service collection with structured fields mapped to EU AI Act and SR 11-7, dynamic risk tiering, and governance workflows. Learn more →