Define management-system scope
ISO/IEC 42001:2023 specifies an AI management system. Its public overview describes that scope; it does not provide the full licensed requirements. Confirm the clauses and controls applicable to your organisation with the standard and your assessor. This guide does not quote or invent normative inventory wording.
Record boundaries and responsibilities
For each in-scope system list purpose, accountable owner, operating environment, data and tools. Distinguish systems you provide from those you use. Keep exclusions and outsourced dependencies visible. An inventory should help your team locate the assessment, approval and monitoring evidence for a system.
Worked boundary example
A company uses a hosted summariser for customer-support drafts and develops an internal invoice workflow. They are different inventory records, even if both use the same model provider. The support owner can approve data handling; the finance owner can explain posting permissions and controls.
Maintain supporting records
Attach references to impact/risk work, change approvals, testing and incident processes in your maintained register. Update the inventory when a component or owner changes. The local CSV can serve as a starter record, but an exported file alone does not demonstrate an effective management system.
Prepare an audit trail
Keep the dated population, change history and evidence of owner review. Explain how a selected system moves from the inventory to its controls and monitoring records. Leave unknowns visible and track them to an accountable person. Validate exact obligations with the licensed standard rather than a public webpage summary.
Translate scope into a useful asset register
An ISO 42001 asset register is most useful when it helps the organization understand which AI systems fall within its management-system boundaries and where supporting evidence lives. Start by recording the system or deployment name, purpose, provider or internal team, accountable owner, operating environment and boundary. Explain whether a record describes a model, a deployed service, an AI-enabled product or a workflow that combines several components. Do not treat the word “asset register” as an exact clause name unless you have checked the licensed standard.
Scope decisions affect what an inventory needs to include. A hosted service used by one team may have different data, access and human oversight from a system developed internally with the same model. Record outsourced components, third-party models, data sources and tools that affect operation. If the boundary is uncertain, document the question, owner and evidence needed rather than silently omitting the dependency.
Connect records to operational evidence
A register should point reviewers to the current risk assessment, impact work, approvals, monitoring plan, testing results, incident handling and change history. These references may live in other controlled systems; the local inventory tool does not contain dedicated evidence-link or risk-register-ID fields. Use stable identifiers consistently and preserve the date and source of each owner confirmation. Keep the original record and later versions so a reviewer can see what changed.
Assign a responsible owner for each record and a process owner for completeness. Define review triggers that fit your organization's processes, such as a change in purpose, data, model, tool, access scope, environment or affected population. A calendar reminder alone will not detect these changes. Reconcile inventory entries with procurement, configuration and service-owner records that your team is authorized to review.
Worked review example
Suppose a support team uses a hosted assistant to draft replies from customer cases, while finance uses an internally configured workflow to prepare invoice postings. Even if both call the same model provider, record them separately when their purposes, owners, data or permissions differ. The support record might point to a human-reviewed draft process and a restricted case-data source. The finance record might point to an invoice API, a write permission and a human approval checkpoint. These are illustrative records, not claims about a deployed organization.
During review, ask the support owner to confirm whether outputs leave the organization and ask finance to verify which identity can write invoices. Link each answer to its evidence and record open questions. If an owner cannot confirm a field, leave it unknown and assign follow-up. Do not treat a populated spreadsheet or a passing internal checklist as proof that the management system is effective.
Use sources carefully
The ISO public overview describes ISO/IEC 42001 as an AI management-system standard, but it is not a substitute for licensed requirements. The NIST AI RMF Map Playbook offers voluntary context for documenting intended purpose and deployment setting; it is not an ISO crosswalk. The EU AI Act may create separate duties depending on the system and operator. Have a qualified reviewer determine applicable obligations instead of inferring them from an inventory field.
For field-level starting points, see the AI inventory template, AI agent inventory template, and manual inventory builder. The builder exports CSV and a browser print summary; it does not create an ISO-compliant register or verify system completeness.