Your AI inventory is probably larger than your chatbot list

Ask a management team which AI they use and you get a short list. ChatGPT. Copilot. Maybe Claude or Gemini. Someone mentions a pilot in marketing.

Then look at what the organisation actually runs. The security platform scores alerts with a model. The recruitment tool ranks candidates. The service desk drafts replies. The CRM predicts which accounts will churn. A supplier added a summarisation feature in their last release and told you in a changelog nobody read.

None of that arrived as a decision. It arrived as a feature.

You cannot govern AI you do not know you are using. That is not a governance slogan; it is the reason most AI governance programmes stall in month two. The policy is written, the committee meets, and nobody can answer the first question an auditor asks: where is it, and what does it do?

Most of your AI was never a decision

This matters more than it sounds. When AI enters through procurement, there is a moment where someone can ask questions. When it enters through a release note, there is no such moment.

The result is an AI landscape that grew without a risk assessment, without an owner, and often without anyone in security knowing it changed. Your own security tooling is a good place to look first — it is frequently the most AI-heavy software in the building, and the least likely to be on anyone's AI list.

Stop inventorying tools. Start inventorying use cases.

There is a real difference between two questions. “Do we use Microsoft Copilot?” gives you a licence count. “Where is AI influencing data, people, decisions or operations?” gives you something you can govern.

One tool can host five use cases with wildly different risk. The same assistant that drafts internal meeting notes might also draft customer correspondence and summarise HR cases. Same licence, same vendor, three conversations you should be having separately.

Inventory the use case, not the logo on the invoice.

What belongs in an AI inventory?

A useful inventory answers four questions per use case. Not eighteen fields because a template said so — four questions that, answered honestly, tell you whether you have a problem.

Who owns it, and who uses it

Every material use case needs a named owner: someone accountable for its purpose, its risk and whether it keeps running. Not a department. A person. Also record who actually uses it, which is often broader than intended, and which processes depend on it.

What data it touches

What goes in, and where does it come from? Personal data, customer data, source code, contract text, incident details. The input determines most of your privacy and confidentiality exposure, and it is the field people fill in most casually.

Where the data goes

Which model or provider processes it, whether it leaves your organisation, which third parties receive it, and where the output ends up. More on this below, because it is the section most inventories get wrong.

How far it can go on its own

Does it inform, recommend, decide or act? Can its output trigger another system? Is there a human between the output and the consequence — and does that human have the information and the authority to say no?

The full field list is longer, and it belongs in a document you fill in rather than an article you read. That is what the Quick Check is for.

Follow the data, not the model

Most AI governance discussions fixate on the model. The interesting risk is usually in the pipeline around it. Trace it end to end: input → processing → model or provider → output → decision or action.

At each step, one question:

• What data enters, and where did it come from?
• Where is it processed, and does it leave the organisation?
• Which third parties see it, including subprocessors you never contracted with directly?
• What comes back, and where is that output used?
• Can that output trigger another system without a person touching it?

That last one is where governance and security meet. An AI system that writes into a ticketing system, sends an email, changes a firewall rule or updates a record has moved from advice to action, and the risk profile moved with it.

Autonomy is what changes the risk

Here is a simple progression we use in practice. It is a CyberBusters model for explaining increasing autonomy, not ISO terminology and not a classification any standard requires.

• Inform — summarises, retrieves, explains. Risk: someone acts on a wrong summary.
• Recommend — proposes a course of action. Risk: the recommendation is followed without scrutiny.
• Decide — makes the call within set bounds. Risk: a wrong decision, at speed and at scale.
• Act — triggers something in another system. Risk: the consequence lands before anyone reviews it.

Two systems can use the identical model and sit two levels apart. The question is never “how good is the model” but what can it do without asking.

The same technology, four different risks

Take one summarisation model and put it in four places. Summarising internal meeting notes is mostly a quality problem. Summarising customer complaints for a regulator-facing report is a compliance problem. Summarising CVs into a shortlist touches employment law and fairness. And summarising security alerts to decide what gets escalated is operational — because what it drops, nobody sees.

Same technology. Four different assessments. This is why a risk register organised by tool tells you almost nothing, and one organised by use case tells you where to spend your attention.

Assess consequences across people, operations, security, privacy, legal and regulatory exposure, reputation, financial impact, safety where it applies, and continuity — what happens to the process if the AI is simply unavailable on Monday.

Human oversight is a control, not a slogan

“There's a human in the loop” is the most-repeated and least-tested statement in AI governance. Being in the loop is not the same as being able to stop the loop.

Oversight is operational when you can answer:

• When is review required — always, above a threshold, on exceptions?
• Who performs it, and do they have the standing to disagree?
• What do they see: the output only, or the input and the reasoning?
• Can they reject the output, and does rejecting it actually block it?
• Can an action be overridden after it has started?
• Can the system be stopped — and who has that button?
• Is the decision recorded, so you can reconstruct it later?

A reviewer who sees only the output, under time pressure, with no route to escalate, is a rubber stamp with a job title.

You do not control the model you depend on

AI governance extends past your own perimeter. External models, AI features inside SaaS, APIs, model providers and their subprocessors are all part of the picture, and almost none of it moves on your schedule.

What happens when the model, provider or AI functionality changes without your organisation initiating that change?

A provider deprecates a model version. Output quality shifts. A feature you depend on moves behind a higher tier. A supplier changes their subprocessor list. An API is unavailable for six hours during your busiest week.

None of those are your decisions, and all of them are your problem. Record the dependency the same way you would record any other supplier concentration risk — because that is exactly what it is.

What changes, and who notices

AI systems drift in ways traditional software does not. Keep two questions apart: does it still do what it was supposed to do — quality, errors, drift — and has someone changed it — model, prompts, integrations, autonomy, intended use.

The second is the quiet one. A system approved to recommend, later configured to act, is a new system wearing the old system's approval. Significant change should trigger reassessment, and someone has to own noticing it.

From inventory to governance

The flow we use is deliberately unglamorous: discover → classify → assess → control → monitor → review. Discover what exists. Classify by use case, data and autonomy. Assess the risk per use case. Put controls in proportion to that risk. Monitor whether it still behaves. Review when something changes.

An inventory is step one. It is not a governance system, and a spreadsheet is not an answer to a regulator. But nothing after step one works without it.

Where ISO/IEC 42001 comes in

ISO/IEC 42001 is a management-system standard for artificial intelligence. It describes how an organisation establishes, operates and improves a system for governing AI — the same family of thinking as ISO/IEC 27001 for information security, applied to AI-specific concerns.

It becomes relevant at a specific moment: when you have more AI use cases than one person can hold in their head, when someone external starts asking how you govern them, or when you need the answer to survive a change of staff.

Some honest boundaries. The standard does not prescribe the inventory fields in this article, the autonomy model above, or any particular scoring method — those are practical choices, not requirements. And an inventory, however good, is not an AI management system. It is one input to one part of it.

Ten questions to ask this week

1. Do we know where AI is being used, and for what purpose?
2. Does every material use case have a named owner?
3. Do we understand the data flows in and out?
4. Do we know how autonomous each use case is?
5. Have risks been assessed for the use case, not the tool?
6. Is human oversight defined in proportion to risk and autonomy?
7. Do we understand our dependency on models, platforms and suppliers?
8. Do we check whether the system still performs as intended?
9. Are significant changes controlled and reassessed?
10. Can we demonstrate how the system is governed, with evidence?

If more than three make you uncomfortable, that is useful information, and it is the normal starting position rather than a failing grade. Fill it in with someone from a different discipline in the room: answered alone it becomes a self-assessment, answered together it becomes a conversation.

Where to go from here

Start with discovery, and start smaller than feels satisfying. Pick the ten use cases where AI touches customers, personnel decisions, money or security, and answer the four questions for each. You will learn more in an afternoon than from a quarter of policy work.

Want to move from individual AI controls to a structured AI management system? ISO/IEC 42001 is the framework you would be working towards, and it starts from the same discovery. That is how we approach it in AI governance and ISO 42001; if you would rather talk it through against your own situation, get in touch.