In brief
A practical data model and review workflow for connecting AI systems, risks, owners, controls, evidence, and review dates under ISO 42001.
An AI system inventory is the list of every AI system an organization develops, provides or uses, with an owner, purpose, data inputs and review status for each. Under ISO/IEC 42001 it feeds the AI risk register and impact assessments; both records should share one system ID instead of living in separate spreadsheets.
What fields belong in an AI inventory?
| Area | Fields to retain |
|---|---|
| Identity | ID, system name, description, status, owner |
| Purpose | Use case, users, affected decisions, automation level |
| Technology | Model, version, provider, environment, API |
| Data | Sources, categories, rights, sensitive data, retention |
| Controls | Human review, testing, monitoring, logging, rollback |
| Governance | Approval date, last review, next review |
Include internally developed AI and third party services. Inventory a tool when it can receive source code or customer data, or influence an in-scope decision.
Where does ISO 42001 require an AI inventory?
ISO/IEC 42001 does not have a clause titled "inventory", but several requirements cannot be met without one. The AIMS scope (clause 4.3) has to say which AI systems are covered. AI risk assessment (clause 6.1.2), risk treatment (6.1.3) and AI system impact assessment (6.1.4) all work per system. Annex A group A.4 asks for documented resources, including data, tooling and computing resources, and group A.5 asks for a repeatable impact assessment process. The NIST AI RMF Core is more explicit: its Govern function calls for mechanisms to inventory AI systems and resource them according to risk priorities. An auditor will usually start from the inventory and sample systems from it, so gaps there show up everywhere else.
How should the AI risk register connect to the inventory?
Each risk should reference the system ID and record:
- The scenario, cause, and affected parties.
- Consequence, likelihood, and scoring method.
- Existing controls and supporting evidence.
- The treatment decision and required actions.
- Owner, deadline, residual risk, and approver.
- Reassessment triggers such as model, data, or purpose changes.
Avoid a generic entry such as "the AI may be wrong" across every system. Describe where an incorrect result matters, who may be affected, and which control detects or limits the consequence.
What does a workable review cycle look like?
- Update the inventory when proposing a use case or material change.
- Assess impacts and record system specific risks.
- Obtain deployment and residual risk approval.
- Retain testing, monitoring, incident, and change evidence.
- Reassess on schedule and when a trigger occurs.
- At retirement, confirm data, access, and dependencies are handled.
What does pTrackly do here?
pTrackly keeps an organization-wide AI system inventory for the ISO 42001 framework: system name, provider, intended purpose, output type, deployment environment, data inputs, business owner, impact assessment status and an approval step. Connectors such as the OpenAI API can propose candidate systems from observed model usage; a person still confirms ownership, purpose, inputs and approval, because usage data cannot prove the list is complete. Risks live in the risk register with likelihood and impact scoring and treatment plans. pTrackly does not decide whether a residual risk is acceptable; that stays with your approvers, and the certification body runs the audit.
Related reading: the ISO 42001 implementation checklist, how to integrate ISO 27001 and ISO 42001, how long ISO 42001 certification takes and the ISO 42001 framework workflow.
Frequently asked questions
Does ISO 42001 require an AI system inventory?
The standard has no clause named "inventory", but scope (clause 4.3), AI risk assessment (6.1.2) and AI system impact assessment (6.1.4) are all done per AI system. In practice an auditor expects a maintained list of in-scope systems with owners.
Should third-party AI tools like ChatGPT or Copilot be in the inventory?
Yes, when they can receive source code, customer data or personal data, or influence an in-scope decision. Record the provider, the approved use cases and the data that may be sent to it.
How often should the AI inventory be reviewed?
Review it on a fixed schedule set in your AIMS (many teams choose quarterly) and whenever a model, data source or purpose changes. ISO/IEC 42001 asks for review at planned intervals rather than a specific frequency.
What is the difference between an AI risk assessment and an AI impact assessment?
Under ISO/IEC 42001 the risk assessment (clause 6.1.2) looks at risks to the organization's AI objectives, while the impact assessment (clause 6.1.4) looks at consequences for individuals, groups and society. Both should reference the same system ID in the inventory.
References
This article provides general implementation information, not legal advice or a certification guarantee.
