Can you govern AI you do not know you have?

AI does not enter an organisation only through major procurement exercises. It may already be embedded in the systems, subscriptions and updates your teams use every day.

In today’s governance note, I want you to consider a question that should come before new policies, controls or assurance processes: can you identify every AI system already operating within your organisation? The answer may be less straightforward than it appears.

AI does not enter only through a procurement labelled “artificial intelligence”. It may arrive as a new feature in your customer management platform, recruitment software, analytics service, productivity suite, or security system. A supplier may enable it during an ordinary product update. A department may purchase a specialist tool using its own budget. Staff may begin a pilot before anyone decides whether it belongs on the organisation’s formal systems register. If your inventory includes only the AI projects approved centrally, it may describe your governance process without describing your actual organisation.

I would therefore establish the inventory before attempting to categorise risk or assign assurance requirements. You cannot determine which systems need testing, transparency, human oversight or contractual protection until you know that they exist. Begin with a practical definition of what must be declared and not rely solely on whether the supplier markets the product as AI. Include systems that generate, predict, classify, rank, recommend, summarise or materially influence a decision. Include embedded features, trials, internally developed models and AI accessed through third-party services.

Discovery should not be limited to one team. Procurement can identify contracts and suppliers. Finance can find departmental subscriptions. IT and security can identify integrations and network activity. Data teams may know where models are operating. Staff can identify informal tools and features that appeared within existing software.

The objective is not to punish disclosure. If employees believe that reporting an unapproved tool will automatically lead to disciplinary action, your inventory will remain incomplete. You need a route through which uncertain or experimental uses can be recorded, assessed and either approved, restricted or retired. Each entry should tell you enough to govern the system rather than merely name it.

Inventory field	Governance question
Purpose and decision	What does the system do, and what can its output influence?
Owner and users	Who is accountable, and who operates or relies on it?
Data and affected people	What information enters the system, and who experiences the consequences?
Supplier and version	Who provides it, which model or feature is active, and can it change?
Controls and review	What testing, oversight and escalation arrangements apply?
Lifecycle status	Is it proposed, piloted, live, paused or decommissioned?

An inventory must also be maintained. A system recorded at procurement may become materially different after a model change, new integration or additional use case. Require suppliers and internal owners to notify you when capabilities, data processing or intended uses change. Link updates to review rather than waiting for the annual audit.

NIST places AI-system inventories within the Govern function of its AI Risk Management Framework. Its guidance recommends inventorying all organisational models where possible, assigning responsibility for maintenance and including documentation, data dictionaries, incident plans and relevant contacts. NIST AI RMF Govern guidance.

The UK Government’s AI Playbook similarly recommends a live AI and machine-learning inventory containing each system’s purpose, use, risks, data, ownership and key dates. It explains that inventories support oversight of data quality, accuracy, bias, security and regulatory compliance. UK Government AI Playbook.

Before asking whether your AI controls are adequate, make sure they cover the systems your organisation actually has.