AI System Inventory 2026: The Register Five Laws Assume You Already Keep

Five Things That Ask For It Without Naming It

The EU framework asks it as a classification question

Every obligation in the EU AI Act attaches to a role and a risk tier: provider or deployer, prohibited, high-risk, limited-risk with transparency duties, or minimal. You cannot answer 'which of your systems are high-risk' without a list of your systems, and the answer has to be per system rather than per company. The registration, documentation and human-oversight duties all sit downstream of that classification.

US state AI statutes ask it as a scope question

Colorado's AI Act and the statutes modelled on it turn on whether a system is a substantial factor in a consequential decision — employment, lending, housing, insurance, education, healthcare, essential services. That is a use-case test, not a technology test, so the unit of analysis is the decision each system participates in, which is exactly the column most inventories lack.

Privacy regulators ask it as a triage question

California's automated decision-making and risk-assessment rules, and the assessment duties in the newer state privacy acts, apply to defined processing activities. Deciding which activities are in scope, and producing the assessments for them on request, presumes a list of processing activities that names the models. The records of processing you already keep are the natural parent record.

Sector supervisors ask it as a model-risk question

Banking, insurance and healthcare supervisors have asked for model inventories for years, with validation status, owner, and materiality tiering. Where an organisation already has one of those, the mistake is to build a second AI list beside it rather than extending the field set — two registers disagree within a quarter, and the disagreement is discoverable.

Insurers and acquirers ask it as a plain question, first

The AI questions on a renewal application and the AI section of a diligence request list both open with a request to enumerate systems and use cases. An organisation that answers from a maintained register answers in a day. One that answers by emailing department heads produces a list that is optimistic, incomplete, and now written down.

The Fields That Make a Row Defensible

Seven columns. Everything else is decoration, and decoration is what makes a register too heavy to maintain.

The decision, not the tool

One row per use case, phrased as the decision or output it produces: 'ranks inbound applicants for the recruiter queue', not 'Acme Copilot'. The same vendor product used for two decisions is two rows with different risk answers, and the same decision supported by two models is still one row. Rows named after tools are why inventories fail to answer the questions regulators actually pose.

Role, tier, and the reasoning behind them

Provider or deployer; the risk tier under each framework in scope; and — this is the part that ages well — a sentence recording why. A tier with no reasoning is a claim; a tier with two lines of reasoning is a record you can defend, revisit and correct when the system changes.

Personal data in, personal data out

What categories go in, whether special-category or sensitive data is among them, what the system infers, and whether an inference is itself sensitive data. The inference column is where privacy and discrimination exposure concentrate, and it is almost never filled in because it requires asking what the model has learned to predict rather than what it was given.

Humans, and what they actually do

Who reviews an output, at what point, with what authority to overturn it, and how often they do. 'Human in the loop' as a checkbox is worth nothing; a note reading 'reviewer sees the score and the top three factors, overturns it roughly once a week, and the override is logged' is a real control and evidence for an oversight duty.

Vendor, model, version, and the chain behind it

The supplier, the model family and version, and a pointer to the subprocessor position for that system. Model versions roll, and the version in the row is what makes an incident reconstructable months later when the vendor has moved on twice.

Evidence pointers, not evidence

Links to the assessment, the bias audit, the DPIA, the vendor documentation, the notice text shown to affected people. The register is an index. When it tries to be the archive it becomes too heavy to maintain and stops being updated, which is the failure mode that kills most of them inside a year.

An owner who exists, and a review date

A named accountable person per row and the date the row was last confirmed. Rows with no owner are the ones found stale, and a register in which every row was last confirmed on the day it was created is treated by an auditor as a one-off exercise, which it was.

How Registers Go Wrong

The shadow rows are the ones that matter

The register assembled by asking department heads collects the systems that went through procurement. The exposure is concentrated in the ones that did not: a subscription on a personal card, an AI feature switched on inside a tool you already own, a script calling a model API with a developer's key. Discovery has to include expense data, identity-provider application lists, egress to model endpoints and the feature flags of your existing SaaS estate.

Features inside products you already bought

The largest single source of unregistered AI is a vendor enabling an AI capability in a product you licensed years ago. No purchase order is created, no security review is triggered, and the decision to turn it on was made by a product manager at the vendor. Contract change-notification terms and a quarterly sweep of enabled features are the only realistic controls.

The inventory that only counts models

Scope creeps in both directions. Registers built by data-science teams list models and miss purchased systems; registers built by procurement list vendors and miss internal builds and prompt-based automations in workflow tools. Either half alone produces a confident, wrong answer to 'is that everything'.

A tier assigned once and never revisited

A system moves tier when its use changes, not when its code changes. A drafting assistant that starts being relied on to score candidates has migrated into a consequential decision without a deployment. The review trigger should therefore be on the decision the system feeds, which is why the row is named after the decision.

Two registers that disagree

Security keeps an asset list, privacy keeps records of processing, model risk keeps a model inventory, and someone starts an AI register beside all three. They diverge immediately. Extend the record that already has an owner and a maintenance rhythm, and reference it from the others rather than copying rows between them.

Five Things to Put in Place

Start from spend and traffic, not from a survey

Pull card and invoice lines against a list of AI vendors, the applications registered in your identity provider, and outbound traffic to known model endpoints. Reconcile that to what teams tell you. The difference between the two lists is the finding, and it is worth capturing before it is tidied away.

Write the first pass at the level of decisions

Aim for a page of rows that each name an output someone relies on. Resist the urge to be exhaustive about models in week one; a register with thirty honest decision rows is more useful than one with three hundred tool rows nobody can classify.

Classify once per framework, with reasoning

For each row, record the role and tier under each regime that applies to you and one line of why. Where a classification is genuinely uncertain, say so in the row and note what would resolve it. A documented uncertainty is a governance artefact; a confident wrong answer is a liability.

Attach the register to a moment that already happens

New vendor onboarding, security review, change management, or the quarterly business review. A register maintained by a reminder decays; one maintained by a gate that blocks a purchase stays current because someone else needs it to move.

Rehearse the three questions it exists to answer

Which systems touch consequential decisions, which process personal data and under what basis, and who owns each. If pulling those three answers takes more than an afternoon, the register is not yet doing its job — and the afternoon is a cheaper way to find that out than an enquiry.

Questions Governance and Legal Teams Ask

Is an AI inventory legally required, or just good practice?

No framework in force says 'keep an AI inventory' in those words, and that is precisely why it gets skipped. What the frameworks do is impose per-system duties whose first step is identification: the EU AI Act allocates obligations by role and risk tier, which has to be decided system by system; Colorado-style state statutes apply to systems that are a substantial factor in a consequential decision, which is a per-use-case determination; the California automated decision-making and risk-assessment rules apply to defined processing activities; and sector supervisors in banking, insurance and healthcare have long expected model inventories with owners and validation status. Each of those is answerable only from a list. Treat the inventory as the load-bearing record beneath the named obligations rather than as a separate compliance chore, and it stops feeling optional — it is the thing every other artefact indexes into.

How do we find the AI systems nobody told us about?

Do not start with a survey, because a survey returns the systems people are comfortable telling you about. Start with four data sources you already own. Finance: card and invoice lines matched against a list of AI vendors, which catches personal-card subscriptions at renewal. Identity: the applications registered against your SSO or OAuth consent grants, which catches tools employees signed into with work accounts. Network or egress logs: traffic to known model API endpoints, which catches code calling a model with a developer key. And your existing SaaS estate: the AI features your current vendors have enabled, which is the largest category and the one with no purchase trail at all because the decision was made by the vendor. Reconcile all four against what teams report. The delta is the interesting part of the exercise, and it is worth writing down honestly before anyone starts tidying it, because the size of that gap is the argument for the gate you are about to ask for.

What is the right unit for a row — the model, the tool, or the use case?

The use case, expressed as the decision or output someone relies on. The reason is that every legal test is framed that way. Risk tiering asks what the system is used for, not what architecture it has. Consequential-decision statutes ask what decision it substantially influences. Transparency duties ask who is affected and what they are told. A row named after a tool cannot answer any of those, because the same tool used to draft marketing copy and to rank job applicants carries completely different obligations. The practical rule is one row per decision: if the same product supports two decisions, that is two rows, and if two models support one decision, that is one row listing both. Keep a separate technical model list if your engineers need one, and link the two — but classify on the decision.

How detailed does the risk classification need to be?

Detailed enough that a reader who was not in the room can see why. A tier alone is an assertion. A tier plus two lines naming the decision it feeds, the population affected and the framework provision relied on is a record that survives a change of staff and can be revisited when the use changes. Where a classification sits on a genuine edge — a derogation argument, an unclear substantial-factor call, a system that might make you a provider rather than a deployer — write the uncertainty into the row along with what would resolve it, such as a counsel opinion or a vendor confirmation. Auditors and regulators respond well to documented uncertainty that is being actively worked and poorly to confident classifications with nothing behind them, because the second pattern is indistinguishable from guessing.

How do we keep it from going stale the month after we build it?

Attach maintenance to an event that happens for reasons other than compliance. The registers that survive are the ones wired into vendor onboarding, security review or change management, so that a row is created because a purchase or a deployment cannot proceed without it. The ones that die are maintained by a calendar reminder owned by one person. Add two cheap mechanics on top: a named owner per row, since unowned rows are the first to go stale, and a last-confirmed date, since a register where every row carries the creation date tells an auditor immediately that it was a one-off exercise. Finally, put a review trigger on use rather than on code. The most common way a row becomes wrong is not a new model version — it is the same system quietly being relied on for a more consequential decision than the one it was registered against.

The Afternoon Test

Pick the three questions every enquiry opens with: which systems touch a consequential decision, which process personal data and on what basis, and who owns each one. Give yourself one afternoon to answer all three from records you already keep.

If the afternoon runs out, you have learned the thing the register exists to fix — and you have learned it on a day of your choosing rather than on a deadline set by someone else.

The Register Every AI Law Assumes, and Almost Nobody Keeps