Ask an organisation how many AI systems it operates and the answer that comes back is usually a list of projects. The real number is higher, and the difference is rarely anyone’s fault. It is a side effect of how AI now arrives: not as a procurement decision, but as a feature added to software already in use.
The customer platform gained summarisation last quarter. The recruitment tool ranks applicants. The service desk suggests resolutions. The spreadsheet add-in drafts formulas. None of these went through an AI approval process, because none of them was bought as AI.
Why the count is always low
The Bank of England and FCA survey of AI in UK financial services asked firms which risks they expected to grow most over three years. Alongside third-party dependencies and model complexity, firms named embedded or “hidden” models — AI inside systems the organisation did not think of as AI systems. The same survey found 75% of firms using AI and only 34% reporting a complete understanding of the AI they use.
The 34% figure is usually read as a knowledge problem. It is more often an inventory problem. It is difficult to understand a population you have not enumerated, and most organisations are trying to govern from a list that was assembled by asking around.
A working example, at national scale
The idea that you can simply publish the list was tested in public. Amsterdam and Helsinki launched municipal algorithm registers in 2020, recording what each system was for, what data it used, how a person was involved and how it had been assessed for risk. Amsterdam’s register has since folded into a national one.
The Algorithm Register of the Dutch Government launched in December 2022 and now lists over 1,500 algorithms, focused on high-impact systems including high-risk AI, published by ministries, agencies and municipalities. Whatever one thinks of publishing such a register, the exercise proves a narrower and more useful point: enumerating algorithmic systems across a large, federated organisation is achievable. It has been done, at national scale, in public, by bodies with far less commercial freedom than a private firm.
A private organisation will almost never publish. The internal version of the same artefact is still the most valuable governance document most firms do not have.
What an entry needs
An inventory is only useful if each line answers the questions that get asked under pressure. Nine fields cover almost every case.
- What it does, in operational language. Not “machine learning platform” but “ranks inbound claims for handler assignment”.
- Who owns it. One named person with authority to change or stop it — not a team, and not a committee.
- What decision it affects, and whether a person reviews before the outcome takes effect.
- What data goes in, including whether it is personal data and on what lawful basis.
- Where the model runs, and who the provider is.
- What version is in use, and how a change to it would reach you.
- What evidence exists that it works — an evaluation, a sampling exercise, a supplier’s claim, or nothing, which is an acceptable answer as long as it is written down.
- What happens if it is wrong, described as a consequence to a person or the business rather than a severity rating.
- When it was last reviewed.
Resist the urge to add a risk score at the start. Scores invite arguments about calibration before the list is even complete, and the list is the thing with value.
How to find what you already run
Asking teams to self-declare produces the list you already had. Five sources produce the rest.
- Procurement and finance records. Search the last twenty-four months of supplier spend for AI tooling, and for renewals where an existing product added AI features.
- Vendor release notes. For the twenty systems most central to operations, read what shipped in the past year. This is where most unrecorded AI is found.
- Identity and access logs. Single sign-on and expense data show which services people actually authenticate to, including the ones nobody registered.
- Change records. Integrations added to core systems tend to be documented even when the capability behind them is not.
- A conversation with each operational lead. Not a form. Ask what in their process now produces a suggestion, a ranking, a score or a draft, and who acts on it.
Expect the first honest pass to surface between two and five times the number of systems people expected. That is the normal result, and it is the point of doing it.
What to do with the list
Do not govern everything equally. Sort by consequence: what happens to a customer, an employee or an obligation when this system is wrong. Most entries turn out to be low-consequence conveniences that need an owner and a review date and nothing more. A small number will affect decisions about people — credit, employment, eligibility, pricing, access to a service — and those deserve real work.
That sorting is also the input to almost everything else. It determines what falls inside the scope of the EU AI Act, which attaches obligations to the use rather than the technology. It determines what an ISO/IEC 42001 management system would cover. It is the Map function of the NIST AI Risk Management Framework, which puts enumeration and context before measurement and management for the straightforward reason that the other two are undefined without it.
It is also the document that answers a due diligence questionnaire, an insurer’s proposal form, a client security review or a regulator’s first question. Those requests are arriving more often, and the organisations that answer them quickly are the ones that did this before they were asked.
A fortnight, not a programme
This does not need a steering group. One person with access to procurement records and permission to ask direct questions can produce a defensible first inventory in about two weeks. Version one will be incomplete; publish it internally anyway, because an incomplete list attracts the corrections that a blank page never does.
Then set a review date and hold it. An inventory that is accurate once is a document. An inventory that is accurate quarterly is a control.
If you would like this done independently and quickly, it is the usual first step in AI estate work, scoped as an assessment.
