ISO/IEC 42001 AI System Inventory

Inventory systems the organisation develops, provides, uses, or otherwise governs within the AIMS boundary. Include supplied AI services and embedded capabilities where the organisation's activities, responsibilities, risks, or impacts depend on them; do not limit discovery to internally trained models.

Use one stable record for the operational system: its business process, intended use, users, affected parties, deployment environment, model or tooling, data, infrastructure, people, suppliers, customer interfaces, documentation, support, monitoring, and lifecycle state.

A system can involve several organisation roles across its lifecycle. Record actual development, provision, deployment, operation, monitoring, procurement, and customer relationships instead of forcing one generic role label. Keep legal classifications in separate sourced fields when they are needed.

The register should let a reviewer identify the system, understand what it does and where it operates, find accountable owners, locate the evidence used to approve it, and see whether the record is current. The precise fields can vary by organisation and system; ISO/IEC 42001 does not provide a mandatory inventory form.

Assign ownership by field group. The system owner maintains purpose and lifecycle state, while specialist owners maintain data, supplier, risk, impact, security, legal, monitoring, or incident information within their authority.

Use the same controlled inventory, but change the evidence fields and responsibility handoffs to match how the AI system is obtained and operated. The examples below are Sorena implementation patterns derived from ISO/IEC 42001 lifecycle, resource, supplier, customer, and responsible-use controls; they are not ISO classifications or automatic approval outcomes.

A single system may match several patterns. For example, a team can configure a supplied generative-AI service with internal retrieval data and embed it in a customer-facing workflow. Keep the supplier service, internal configuration, connected data, user experience, human review, and customer allocation visible in one system record or explicitly linked records.

Use explicit states such as draft, under assessment, approved with conditions, approved, suspended, and retired. Define the evidence needed to enter each state, who can approve the transition, and which missing fields block deployment or continued operation.

Keep decision history. An approval record should identify the authority, date, basis, conditions, evidence gaps, review trigger, and linked risk or impact treatment. A field value without its source or owner is not reliable evidence.

A model list is too narrow when it omits the business process, deployment context, intended use, users and affected parties, externally supplied components, customer responsibilities, human oversight, or lifecycle state. Duplicate records are also risky when teams cannot tell which one controls decisions.

Do not import legal roles, classifications, or approval labels without recording the facts, jurisdiction, instrument, and decision owner. ISO/IEC 42001 is a management-system standard; it does not replace separate legal inventories or determine compliance with every applicable rule.

Review each record at a planned interval and when intended use, deployment context, data, model or tooling, supplier, customer allocation, performance, affected parties, legal requirements, or lifecycle state changes. Define which changes trigger renewed risk and impact assessment.

Reconcile the inventory against procurement, product, architecture, access, supplier, and incident records. Investigate mismatches because they can reveal an unapproved system, stale owner, missed change, or incomplete retirement.