ISO/IEC 42001 AI System Inventory Workflow

Open or update an inventory record before an AI system is developed, procured, deployed, materially changed, transferred, or retired. Include internally built systems, third-party services with embedded AI, AI features added to an existing product, and AI used by staff where those activities can fall inside the AIMS boundary. The intake owner should identify the business purpose, intended use, prohibited or unsupported uses, lifecycle stage, system owner, users and affected parties, the organisation's lifecycle roles, and whether the activity sits within the approved AIMS scope.

Record the system as a complete operational arrangement, not only a model. Include relevant data, tooling, system and computing resources, human resources and competence, supplied services, customer or partner dependencies, deployment context, documentation, support, monitoring, and incident routes.

Inventory registration is an intake and traceability control. It does not by itself complete AI risk assessment, AI-system impact assessment, risk treatment, approval, or operating-control evidence.

A complete record lets a reviewer identify what the system does, where and by whom it is used, the lifecycle roles the organisation performs, the people or groups that may be affected, the resources and third parties it depends on, and the decisions that allow it to operate.

Assign field ownership. A product owner can maintain intended use and lifecycle status, while data, supplier, security, risk, impact, legal, and monitoring owners maintain the records within their authority. Preserve version history and links rather than copying stale evidence into the inventory.

At intake, create a draft record and classify the organisation's role, intended use, scope status, lifecycle stage, and dependencies. Assign the system owner and specialist field owners. If the activity is outside the approved AIMS boundary, record the exclusion rationale, boundary interface, and owner instead of silently dropping the record. Route an in-scope record to the risk and impact processes before approval when the organisation's criteria require them.

An approval authority should decide whether the system may proceed, proceed with conditions, remain blocked, or be retired. Record the basis, conditions, evidence gaps, expiry or review date, and the event triggers that reopen the decision.

The workflow fails when discovery depends only on voluntary registration, when one team owns every field in name only, or when a model catalogue omits the surrounding service, data, people, deployment context, and external dependencies. Reconcile intake with procurement, expense, identity-access, architecture, product, supplier, and support records so unregistered use can be investigated.

Do not copy legal roles or risk labels into the record without the facts and source that support them. ISO/IEC 42001 structures the management system; applicable law, contracts, and sector rules can create separate inventory fields, classifications, or approvals.

Review records at planned intervals and when intended use, deployment context, data, model or tooling, supplier, customer allocation, performance, affected parties, legal requirements, or lifecycle state changes. Define 'significant change' in the organisation's procedures so teams know when risk and impact assessments must be repeated.

When a system is retired, close active access and support, preserve required documented information, update the AIMS scope and dependencies where necessary, and retain a final decision record.