ISO/IEC 42001 · Implementation

The ISO/IEC 42001 AI system inventory

Updated 12 July 2026 · 6 min read

Key takeaway

The AI system inventory is the foundation an AIMS rests on. Every other artefact — Statement of Applicability, risk assessments, impact assessments, human-oversight design, supplier assessments, incident register — depends on knowing which AI systems are in scope, who owns them and how they are used. The most common reason organisations fail readiness assessments is shadow AI: systems in genuine business use that the register does not know about. Uncovering them, not documenting the ones already known, is the real work.

The register is the single source of truth every other AIMS artefact depends on.
A complete entry names purpose, owner, users, data, suppliers, lifecycle stage and risk classification.
The most common Stage 1 failure is an incomplete register — shadow AI missing.
Discovery must be active: procurement records, expense reports, developer sandbox reviews — not a passive form.
Register accuracy is a continuous obligation, not a one-off exercise.
General information, not legal advice. Current as of July 2026.

Why the register is foundational

You cannot apply controls to systems you have not identified. Every other artefact in the AIMS references entries in the register: the SoA proves it covers all in-scope systems; risk and impact assessments are per-system; human-oversight design is per-system; supplier controls attach to the third-party systems the register lists. An incomplete register makes every downstream artefact incomplete.

What a complete entry contains

System identifier and name.
Purpose and business context — what it does and for whom.
Owner (the person accountable) and users (the people or teams operating or relying on it).
Data — categories of input and training data, personal-data classification, provenance.
Supplier — vendor, model, hosting arrangement; whether the system is built, bought or embedded in a larger product.
Lifecycle stage — proposed, in development, in production, retiring.
Risk and impact classification — the outcome of the AI risk assessment and impact assessment.
Human-oversight design — how a person can meaningfully intervene.

Shadow AI is the biggest blocker

In every readiness assessment we see, the register the client hands over is materially incomplete. Business teams have adopted AI tools directly — a copilot in a spreadsheet, a chatbot in a support workflow, an image generator on the marketing team's laptop. None of these are on the register. All of them are AI systems in genuine business use, in scope for the AIMS, and visible to a certification body if they look.

Active discovery, not a passive form

A form on an intranet that asks teams to declare their AI use will not surface shadow AI, because the teams using it either do not think of it as 'AI' or do not want to be told to stop. Active discovery works: reviewing procurement records for AI vendors, expense reports for AI SaaS subscriptions, browser and endpoint telemetry for LLM domains, and developer sandbox environments for model API keys. The register is the output of that discovery, not the input.

Keeping it current

The register is a continuous obligation. New systems arrive; existing systems change purpose, owner or data; retired systems must be marked retired, not deleted. An auditor sampling six months out will look at the entries and the dates on them; a register with every entry dated the week of the audit tells them everything they need to know.

The free readiness check

If you want a rapid, no-signup view of how your inventory maturity sits against enterprise buyer expectations, use the Hael readiness check — it maps directly to the CAIQ and SIG Lite AI-module questions on AI inventory.

Key terms

Shadow AI: AI systems in business use that the organisation's AIMS does not know about.
Register entry: One row in the AI system inventory, describing a single AI system in scope for the AIMS.

References

Related guides