The Foundation: AI Inventory, Classification, and Ownership

The usual first move is to write an AI policy. It is visible, it can be approved at a board meeting, and it produces a document. It also governs nothing, because a policy is a set of rules about a population you have not yet identified.

The ordering that works is the reverse. Find out what you run. Classify it. Assign someone to each thing. Only then write the rules, because now they can be specific enough to follow.

The test of a governance framework is not whether it exists but whether it can answer four questions on demand: what AI systems do we operate, what does each one decide, who is accountable for it, and what would we do if one of them failed. Most frameworks that exist as documents cannot answer the first.

This lesson builds the foundation those questions rest on. The next covers the policy, decision rights and risk register that sit on top, and the third covers documentation and the evidence trail.

Discovery is harder than it sounds because AI has stopped arriving as a distinct purchase. Five channels, in rough order of how badly they are usually covered.

Deliberately procured AI tools. The assistant, the transcription service, the code completion tool. These are known, and they are the smallest category.

AI features switched on inside existing software. Lead scoring in the CRM, CV ranking in the HR platform, suggested replies in the helpdesk, anomaly detection in the finance system. The contract was signed for something else and the feature arrived in a release note. This is the largest blind spot in most organisations.

Models built in-house, including the analyst's scoring spreadsheet that quietly became a production input. These matter disproportionately because they may make you a provider rather than a deployer.

AI inside a vendor's service delivery, where an outsourced provider uses AI to do work on your behalf. Their systems, your accountability as the one deciding.

Shadow use. Tools adopted by individuals without approval. An amnesty produces a far more accurate picture than a policy reminder does.

Each channel needs a different instrument, and using only one produces a confident and wrong inventory.

The expense and procurement sweep finds paid subscriptions. Search vendor names and categories in accounts payable. It is quick and it catches the procured tier, and nothing else.

The vendor questionnaire covers embedded features. Ask every material software supplier a direct question: which of your features use AI or machine learning, what do they do, and are any of them within an Annex III use case. Suppliers answer this now, because they need the answer for their own compliance.

Network and identity telemetry finds shadow use. Single sign-on logs and outbound traffic to known AI service domains reveal what people actually adopted. Treat what it surfaces as a signal to bring tools inside the tent rather than as grounds for discipline, or the next round of discovery gets harder.

The structured survey covers everything the other three miss, particularly in-house builds and vendor service delivery. Ask process owners what decisions in their area are informed by a tool that produces a score, a ranking, a prediction or generated text. Avoid the word AI in the question, because people answer it by thinking about chatbots.

An inventory listing tool names is a procurement record, not a governance artefact. The fields that make it work are the ones describing consequence.

IDENTITY      name, vendor, internal owner, business unit,
              date added, date last reviewed

FUNCTION      what it does, what decision it informs,
              is the output advisory or automatic,
              volume of decisions per month

EXPOSURE      who is affected: staff / customers / public,
              are decisions about individuals,
              does it process personal or special-category data

REGULATORY    our role: provider or deployer,
              risk tier assessed, reasoning for that assessment,
              placed on market before the high-risk date?

OPERATIONAL   human oversight arrangement,
              known limitations, escalation route,
              what happens if it is unavailable

Two fields do more work than the rest. Reasoning for that assessment turns a classification into something defensible. And is the output advisory or automatic separates the systems needing genuine oversight design from those where a human is already deciding, which is the distinction that drives most downstream effort.

The pipeline each system runs through, once, on entry, and again whenever a trigger fires.

Discovery surfaces a candidate. The first gate is whether it is an AI system in the Act's sense, meaning it infers outputs rather than executing rules a person wrote. Things that fail this gate leave the pipeline and should be recorded as excluded with the reason, because that judgement will be questioned.

Then classification: our role, the risk tier, and for anything landing in an Annex III area, whether the derogation is being relied on and on what basis.

Then ownership assignment, then the controls that the tier and exposure actually require.

The loop back matters more than the forward path. A system that entered the inventory two years ago and was never revisited is an entry, not a governed system.

Classification is where inventories stall, usually because the team treats every entry as a legal question. Most are not.

A three-pass approach clears the volume.

First pass, mechanical: anything that does not infer leaves the list. Anything with no connection to individuals, no personal data, and purely internal effect goes to minimal risk. This typically removes a large majority.

Second pass, screening: for what remains, ask whether the use case touches any of the eight Annex III areas, and whether the system interacts with people, generates content, or performs emotion recognition or biometric categorisation. The second question routes to the transparency tier and is usually clear-cut.

Third pass, judgement: the small set left over. These are the Annex III candidates and the derogation questions, and they deserve real attention and often legal advice.

The common failure is treating pass three as the method and applying it to everything, which produces a stalled inventory and a large bill. The other failure is skipping pass three, which produces a fast inventory with the hard cases silently classified as low risk.

Record the pass at which each system exited, so the depth of scrutiny each received is visible.

Every system needs a named accountable owner, and the word accountable has to carry weight or the field is decoration.

An owner is not the person who uses the system most, nor the person who bought it, nor an IT administrator. An owner is the person who would be answerable for a bad outcome and who has the authority to stop the system running.

That second half is the test. Authority to stop it is what separates ownership from a name in a spreadsheet. If the nominal owner cannot pause a system without escalating to three other people, they do not own it, and the framework should record whoever can.

Ownership should sit in the business function whose decisions the system affects, not in IT or compliance. The head of talent acquisition owns the CV screening tool. IT owns its operation, compliance advises on its classification, but the person answerable for who gets shortlisted is the person answerable for the tool that shortlists.

Assign it to a role rather than an individual, so it survives turnover, and record the individual currently holding the role separately.

Where a system genuinely has no owner willing to claim it, that is a finding rather than an administrative gap.

An inventory decays from the moment it is completed, and annual review is the wrong instrument because the thing that invalidates an entry is a change, not elapsed time.

Bind re-classification to events that already occur somewhere in the organisation.

A new tool is procured, or a new supplier is onboarded. The strongest trigger, because it catches systems at entry.

A supplier ships an AI feature into existing software. Requires a standing question in supplier release review, which most organisations do not have and should.

A system is applied to a new use. The most consequential trigger and the least visible, because nothing procures anything. The lead-scoring model repointed at employee attrition has moved from minimal risk into an Annex III area, and no purchase order records it.

A model or vendor changes materially, which may affect both documented limitations and grandfathering status.

An incident occurs, internally or at a comparable organisation.

The regulatory position changes, as it did in 2026.

Make each trigger someone's existing step. A trigger that depends on a person remembering to consult the framework will fire late or not at all.

A recurring question is whether to buy a governance platform. The answer depends on scale, and the honest version is less flattering to the software category than its marketing.

Below roughly thirty systems, a spreadsheet with the fields above, kept in version control or a document system with history, is entirely adequate and considerably more likely to be maintained. The binding constraint at this scale is attention, not tooling, and buying a platform does not supply attention.

Between thirty and a few hundred, the constraint shifts to keeping entries current across many owners, and a purpose-built tool with workflow, reminders and integration into procurement starts to earn its cost.

Above that, and particularly where a provider must maintain a quality management system and technical documentation for high-risk systems, tooling is effectively required because the documentation obligations themselves are substantial.

Two cautions regardless of scale. A platform that nobody outside the compliance team touches will hold a stale copy of reality, so integration into procurement and change management matters more than feature count. And no tool classifies systems for you. The judgement in pass three is the expensive part, and it does not come in the box.

A foundation is working when four things are true, and they are all observable rather than documentary.

Someone can produce the current list of AI systems within a day, without a project to assemble it.

Every entry has a named owner who would recognise that they own it if asked, and who could stop the system.

The reasoning behind each classification is recorded, including for the systems assessed as out of scope, and a reader who was not present could follow it.

New systems arrive in the inventory through a trigger rather than through a periodic sweep, which means the register reflects the organisation rather than the last time someone looked.

Notice what is not on that list: a policy, a committee, a maturity score, or a platform. Those come later or not at all, and several organisations with all four still cannot answer the first question.

With the foundation in place, the next lesson adds the parts that make decisions rather than record them: the policy, the decision rights, and the risk register.