ISO/IEC 42001

The fields, ownership decisions, and review triggers that make an AI inventory useful beyond an initial assessment.

Explore ISO/IEC 42001 advisory

Inventory uses, not just model names

A single model can appear in several products or workflows with different users and impacts. Record the AI system and each material use in its actual context. Include internally built applications, purchased AI services, embedded AI features in existing software, pilots, and employee-facing tools where they fall within the AIMS scope. Mark uses that are proposed, testing, live, suspended, or retired.

ISO/IEC 42001 provides the management system context for identifying and governing AI. NIST’s AI Risk Management Framework explicitly calls for mechanisms to inventory AI systems according to risk priorities. The inventory is useful only if it helps teams make and revisit decisions, not merely count tools.

Which fields make the record actionable?

Begin with a stable identifier, business purpose, accountable owner, operating team, supplier or model, version, and deployment status. Add inputs and data categories, outputs, users and affected groups, locations or markets, human oversight, critical integrations, and relevant contracts. Link the risk and impact assessment, test results, approval, incidents, monitoring owner, and next review date.

Separate facts supplied by a vendor from facts verified by your team. Note unresolved information rather than filling gaps with assumptions. For an externally supplied system, the register should also show who can obtain change notices and who will act if the supplier has an outage or alters the model.

How do you find systems that procurement missed?

Start with product and engineering portfolios, software procurement, cloud accounts, data science repositories, automation platforms, and staff workflows. Ask business owners which tools generate content, recommend actions, classify people or events, or automate decisions. Review existing vendor features that gained AI functionality after purchase.

Use a short intake form that people can complete before a pilot begins. Route answers to the appropriate reviewers based on use and impact, rather than asking every low-impact experiment to pass the same review as a consequential production system. Give each record an owner who can confirm whether it remains accurate.

When should a record be reviewed?

Trigger review when a system changes purpose, model, data source, supplier, target population, geography, level of autonomy, or route into a customer service. A significant incident or recurring poor performance should also reopen the decision. Periodic review catches quiet changes that were never routed through procurement or release management.

Regional obligations can be attached as separate assessments. A European deployment may need an EU AI Act role and classification analysis; an Australian use can be assessed against the National AI Centre’s practices; a Singapore deployment may use local governance and testing guidance. The inventory connects those decisions without asserting that one standard resolves every jurisdiction’s requirements.

Put it into practice

  • Define one record per material AI use and give it a stable identifier.
  • Collect ownership, purpose, provider, data, affected groups, oversight, and status.
  • Link the register to risk assessments, tests, approvals, incidents, and monitoring.
  • Make procurement and product changes trigger inventory review.
  • Sample the register against real tools and workflows to find omissions.

Primary sources

Normstone resources are general information, not legal advice or an independent assessment.

All resources