An AI system inventory: finding out which features are AI before a customer asks
A customer's questionnaire asks you to list all AI systems in your product, their purpose, and the models behind them. You know about the ticket summarisation feature. Then somebody mentions the smart search, which turns out to use embeddings. Then the support team says the chat widget has had an autocomplete for a year. Then marketing asks whether the website chatbot counts.
An ai system inventory exists because that conversation is otherwise unanswerable, and because it is the artefact every other AI compliance obligation depends on. Classification needs it. Supplier assessment needs it. The transparency obligations in the AI Act note need it. Nothing else can be done first.
Why the ai system inventory is harder than it sounds
Because AI arrived in your product through several doors and only one of them was a decision.
Features somebody built deliberately. These you know about.
Capabilities that came with a dependency. A search library that added semantic search. A support platform whose vendor switched on an AI assistant. Nobody in your company chose it and it is processing your customers' text.
Somebody's prototype that shipped. A proof of concept behind a feature flag, enabled for one customer, still enabled.
Tools your own staff adopted. Not in the product, and still in scope as a deployer question, and still processing company data.
So the inventory is a discovery exercise before it is a documentation exercise, and the discovery is the part that finds surprises.
Where to look
Six places, in order of how much they turn up.
Your dependency manifests. Search for the obvious provider SDKs and any package with a model-shaped name. This is the fastest single pass.
Outbound network destinations. Egress logs or firewall data showing calls to model provider endpoints. This catches the dependency nobody declared, because the traffic is there whether or not anyone documented the feature.
Your card statement and enterprise applications list. Same two sources as the supplier register, for the same reason: they record what was actually bought and signed into rather than what somebody remembers.
Feature flags. Especially the ones enabled for a subset of customers, which are the prototypes that shipped.
Your own product documentation and marketing. If a page says "AI-powered", that is a claim you have made publicly, and it is in scope whether or not the implementation matches the adjective.
Ask the engineers. Last, because the sources above give you a list to confirm rather than a blank page, and confirming is easier than recalling.
The eight columns worth recording
Enough to answer a questionnaire and to classify, and not so many that nobody maintains it.
Name and where it lives. The feature, and the part of the product or the internal process it sits in.
Purpose, in one sentence. What decision or output it produces. This is the column that determines classification, so write it precisely: "suggests a reply for an agent to edit" is a different system from "sends a reply".
Provider and model. Who, and which model family. Version if you pin one.
Data sent. Categories, not examples. Customer support text, user names, document contents. This is the column customers care about most.
Data retention at the provider. Whether the provider retains inputs, for how long, and whether they are used for training. This is a contractual question and the answer is usually configurable, which means somebody has to have configured it.
Human oversight. Whether output is reviewed before it has an effect, and by whom. Central to classification and to any honest description of risk.
Who owns it. A person, for the same reason every other register needs an owner: a system with no owner is a system nobody will update.
Classification and reasoning. The category you have assigned and one sentence of why. The reasoning is the valuable part, because the categories may change and the reasoning explains your position either way.
Classifying without a lawyer
Enough to triage. Anything ambiguous or commercially material goes to advice.
Prohibited. A short list including certain manipulative techniques, untargeted facial image scraping, emotion inference in workplaces and education in defined circumstances, and social scoring. If you are near any of these you already know.
High-risk. Defined by use case rather than by technology, covering areas such as employment decisions, access to essential services, education, law enforcement and critical infrastructure, plus AI as a safety component in regulated products. Most B2B SaaS is not here. If your product makes or materially informs decisions about people in those areas, take advice, and note the obligations were deferred to December 2027 and August 2028 respectively.
Transparency obligations. Where a person interacts with an AI system, or where content is generated or manipulated. This is where most ordinary product features land, and it applies now.
Minimal. Everything else. Still worth having in the inventory, because a customer asking for a complete list wants the complete list.
The Commission's AI Act service desk is the source worth checking rather than a summary, both for the category definitions and because the dates attached to them have already been amended once.
The output is not a compliance verdict, it is a triage. Most rows are minimal or transparency, a few need a decision, and one or two might need advice, and now you know which.
Where to keep it
Wherever your asset register lives, because that is what this is.
If you hold ISO 27001 the pragmatic answer is to extend the asset register with the columns above rather than starting a parallel document. One register with an AI flag beats two registers that disagree, and the review cadence you already have carries it.
The properties that matter are the same as for any register: an owner per row, a review date, and a change history. Quarterly review, and a check at the point a new supplier or feature is onboarded, which folds into the same gate as supplier onboarding.
What makes it worth doing anyway
The regulatory timeline has already moved once, by amendment, and can move again. That argues against building a programme around a date and for building the artefact that is useful regardless.
An inventory answers the customer questionnaire, which is the pressure you will actually feel first. It answers the data protection question about what leaves your estate and to whom. It tells you which providers you depend on, which is an availability and supplier question independent of AI. And it turns any future classification exercise into an afternoon.
That is a reasonable return on a day's discovery work, and it does not depend on any particular version of the rules surviving.
If the classification turns out to be the hard part rather than the discovery, that is usually a sign the question is commercial rather than technical, and the security and compliance work covers it alongside the rest of the AI regulation notes.