The AI system inventory: what it must contain and how to keep it current

If you look at most companies' AI system registers right now, assuming one even exists, you'd find pretty much the same scene: a handful of rows untouched for months, systems long decommissioned still marked active, two or three tools the sales team uses every day that nobody ever logged because they didn't look like "real AI". It happened to us too, before we cleaned it up.

The inventory is the document everything else in an AI management system rests on. Risk assessment needs to know what to assess, the impact assessment needs a perimeter, the training plan needs to know who uses what. When the inventory is wrong, every document built on top of it inherits the same error without anyone noticing until the audit.

The definition comes before the fields

The question that stalls most inventory projects in week one isn't which column to add. It's what counts as an AI system.

ISO/IEC 42001 and the AI Act both start from a broad definition aligned with the OECD one: a system that, from a set of inputs, generates outputs such as predictions, content, recommendations or decisions, with some degree of autonomy. Applied to the reality of an operating company, that definition takes in quite a few things nobody would spontaneously call artificial intelligence.

The four cases that generate the most debate in our assessments are always the same. The spreadsheet with a scoring model built in-house by someone who no longer works there. The AI feature switched on inside software you already owned, added by the vendor in an update nobody chose. The chatbot on the website, usually treated as marketing and therefore never reviewed by IT. And the model bought through an API, wired into an internal workflow by a product team, appearing nowhere on any org chart.

The working rule we suggest: if an output from that system influences a decision affecting a person, a customer or a supplier, it goes in the inventory. Risk classification comes afterwards, and exists precisely to separate the trivial cases from the serious ones. Excluding something before registering it means deciding without the information needed to decide.

One row per tool or one row per use

This choice determines whether the inventory stays useful or becomes unmanageable, and it needs making early because redoing it later is expensive.

The same generative assistant used by marketing to draft copy and by HR to do a first pass on job applications is, technically, the same tool. From a risk standpoint they are two different worlds: the first is a low-impact use, the second falls into the category of cases Annex III of the AI Act treats as high-risk.

An inventory organised by tool flattens that difference and produces rows that say nothing useful. An inventory organised by system-plus-purpose pairs makes it visible: two rows, two owners, two risk classifications, two review paths. It costs a few extra rows and saves months when the time comes to show that critical purposes were treated as such.

Provider or deployer, the field almost nobody fills in

Most companies assume they are deployers of somebody else's systems, and therefore subject to lighter obligations. That assumption holds until it meets Article 25 of the AI Act, which sets out three situations where an entity using a system becomes its provider outright, taking on the obligations under Article 16.

The first is putting your own name or trademark on a high-risk system already placed on the market, typically in white-label or resale arrangements, absent a different contractual allocation. The second is making a substantial modification to a high-risk system that remains high-risk: Article 3(23) defines this as a change not foreseen in the initial conformity assessment that affects compliance or the intended purpose. The third is changing the purpose of a system not classified as high-risk in a way that makes it high-risk.

The second one catches the most companies off guard, because the boundary of "substantial modification" is wider than it looks: fine-tuning on proprietary data, changing a decision threshold in a classifier, restructuring a retrieval pipeline can all fall inside it. The reclassification doesn't run through a notification or a registration, it happens by the conditions being met.

This is why the inventory needs to carry the role assumed for each row, and the date that role was last assessed. It's the field that turns the register from a descriptive list into something that flags an exposure before it becomes a problem.

What an auditor looks for in each field

• Name and purpose, described in language someone who didn't build the system can follow. If the purpose is lifted from the vendor's marketing material, an auditor spots it on first reading and treats it as a signal about the quality of the whole register.
• Owner, a named person accountable for the decisions the system makes. A department is not an owner: when responsibility belongs to everyone, in an audit it belongs to no one.
• Data processed and its source, which doubles as the direct link to the mapping a DPIA already requires and to the data requirements in Annex A of ISO/IEC 42001. Filling in the same information twice in separate documents is the most common reason they drift apart.
• Lifecycle status: development, pilot, production, decommissioned. Status is what makes the inventory readable at a glance, and the move from pilot to production is where the update most often gets skipped.
• Role assumed, provider or deployer, with the date of last assessment.
• Risk level, aligned with AI Act classification where it applies, with the reasoning behind the classification, not just the outcome. Auditors rarely challenge the level chosen, they challenge the absence of reasoning behind it.
• Origin: built in-house, purchased, or built on an external foundation model. It determines which information you can produce yourself and which you have to request from someone else, which translates directly into contract clauses.
• Vendor and model version, where the system rests on third-party components.
• Date of last review, the field most often missing and the first one anyone checks.

On that last point it's worth being explicit about what it signals. If every row carries the same review date, the register describes an exercise done in bulk to prepare for something, not a living process. Dates that differ and spread across time say the opposite.

Finding what you don't know you have

Asking department heads which AI systems they use produces incomplete lists, and not out of reticence. Someone using a tool to work faster doesn't mentally file it as an AI system, they file it as how they do their job. Which is why five different sources beat a questionnaire.

Expense reports and corporate card statements, searched against known vendor names, surface the individual subscriptions that never went through procurement. Identity provider logs show which applications people actually authenticated into, which is a fact rather than a self-declaration. A browser extension inventory across managed devices catches a category that almost always slips through. Re-reading SaaS contracts already in place surfaces the AI features a vendor switched on inside products you have had for years, often without any explicit decision on your side. And asking teams directly, framed as "what do you use to move faster" rather than "do you use AI tools", gets far more accurate answers.

The vendor that changes the model without telling you

A SaaS product can swap the underlying model between releases. The stated purpose stays the same, so does the interface, and the system's behaviour changes without anything in the inventory recording it.

This is a risk you govern where it originates, which is the contract. The clauses we see working ask for three things: notice when the model changes or the system's behaviour is materially altered, access to the technical documentation needed to keep your own assessment current, and an explicit statement of the role the vendor takes on under the AI Act. Without those clauses the inventory stays accurate only until the first silent update.

When a new row is needed

A change of purpose always opens a new row, because it changes the risk classification and potentially the role assumed. A change of model version for the same purpose updates the existing row and triggers a review. A new department adopting the same system for the same purpose gets added to the existing row. A new department adopting it for a different purpose opens a new one.

Decommissioned rows stay, with a date and a reason. A register with no history is a register someone rewrites each time instead of maintaining, and the difference shows immediately.

Who keeps it current, and what triggers the update

An inventory that depends on someone remembering to update it doesn't survive one quarter. The triggers that hold over time are the ones attached to processes that already exist and that nobody can skip.

The first is procurement: every software purchase runs through a question checking for AI components, and a positive answer generates a row. The second is go-live: the release procedure updates the status of the matching system before deployment, not after. The third is a periodic review, quarterly for the most exposed organisations and half-yearly for everyone else, catching whatever slipped past the first two.

Above those three triggers you need someone accountable for the register as a whole, separate from the owners of individual systems. Their job isn't filling in rows, it's noticing when rows stop being updated.

Spreadsheet or platform

Below twenty or thirty rows, a spreadsheet with version control and restricted write access works well and takes an afternoon to build. The point where a dedicated tool starts paying for itself is when you need change traceability, automatic links between the inventory, the risk register and the impact assessment, or when the number of owners involved makes manual coordination more expensive than the licence.

Starting from the tool is the mistake we see most often at this stage. A platform populated with badly collected data produces the same problems a spreadsheet does, plus the cost of the licence and the false comfort of having solved something.

Before building the next document

Without a current inventory, the impact assessment covered in the previous piece ends up evaluating systems that may no longer exist, or missing others that have since gone live. The next piece in this series starts exactly here, with what changes when a system is designed knowing from day one that it will end up in this register, instead of discovering that fact after launch.