ISO/IEC 42001:2023, published 18 December 2023, does not name a mandatory document called an AI inventory or AI register. Its clauses still depend on one: clause 4.1 requires you to consider the intended purpose of every AI system you develop, provide or use, and clauses 4.3, 6.1 and 8 need to know which systems are in scope and assessed.
A register with one row per AI system is the practical way to evidence those requirements. It is the first working record in an ISO 42001 implementation roadmap, and every later record (risk assessments, impact assessments, the Statement of Applicability) points back to a register entry.
Does ISO 42001 require an AI system inventory?
An AI system register evidences outcomes that ISO/IEC 42001 requires, not a document with that name: intended purpose and roles (clause 4.1), scope (4.3), risk and impact assessments (6.1.2, 6.1.4, 8.2 and 8.4) and control decisions (6.1.3). The table separates what the standard says “shall” from what is good practice, so you know what an auditor can raise as a nonconformity and what is your design choice.
| What the standard requires | Clause | Why a register is the practical evidence | Required or good practice |
| Consider the intended purpose of AI systems you develop, provide or use | 4.1 | One field per system records the purpose | Required (the list’s form is your choice) |
| Determine your roles with respect to those AI systems | 4.1 | A role field per system (provider, producer, customer, partner) | Required |
| Make the AIMS scope available as documented information | 4.3 | The register shows which systems fall inside the boundary | Required |
| Assess AI risk, in planning and again in operation, and keep the results | 6.1.2, 8.2 | The register proves no in-scope system was skipped | Required |
| Assess impacts on individuals, groups and societies, in planning and in operation | 6.1.4, 8.4 | The register links each system to its impact assessment | Required |
| Record every control decision in the Statement of Applicability | 6.1.3 | Controls point to the systems they cover | Required |
| Document resources, life cycle and third-party arrangements | Annex A controls, where your Statement of Applicability applies them | The register holds or links the data, tooling, supplier and life cycle facts | Required for each control you apply |
| A single document titled “AI inventory” | Not named in the standard | Any controlled format works: a spreadsheet, a GRC tool, a database | Good practice |
| A fixed field list and review cadence | Not set in the standard | You set them and must follow what you set | Good practice |
Source: ISO/IEC 42001:2023 official preview (clause 4.1 to 4.3 text and table of contents); clause 6 and 8 wording checked against published clause summaries. Analysis: AI Training Skool.
Outside ISO, the NIST AI Risk Management Framework is explicit. Its GOVERN 1.6 outcome reads “Mechanisms are in place to inventory AI systems”, and it says those mechanisms are resourced according to risk priorities (NIST AI 100-1, January 2023). If you work to both frameworks, one register serves both.
AI system register fields, clause by clause
A register that satisfies ISO/IEC 42001 needs about 20 fields per system. Each field below exists because a clause or an Annex A control needs the fact; if a field serves nothing, drop it. Match the control column to your Statement of Applicability, and see what each ISO 42001 Annex A area governs.
| Field | Why you need it | Clause or control it serves | Example value (illustrative) |
| System ID | One identifier that links risk, impact and control records | 7.5.3 control of documented information | AIS-014 |
| System name and version | Says exactly what was assessed | 8.2 and 8.4 change triggers | Claims triage model, v3.2 |
| Plain-language description | Lets a non-specialist see what it does | 4.1 context | Ranks incoming insurance claims for review order |
| Intended purpose and limits | What it is for and not for | 4.1 intended purpose; Annex B item B.9.4, intended use | Ordering the review queue; not for denying claims |
| Your AI role | Sets which requirements and controls apply | 4.1 roles | AI customer (vendor product) |
| Business owner | Accountable person who accepts risk | 5.3 roles and authorities | Head of Claims Operations |
| Technical owner | Person who can answer how it works | 5.3; Annex B item B.4.6, human resources | Claims platform engineering lead |
| Life cycle stage | Design, development, pilot, deployed or retired | Annex A life cycle controls; Annex B items B.6.2.5 and B.6.2.6, deployment and operation | Deployed |
| In scope, with reason | Shows the scope boundary system by system | 4.3 scope | In scope: affects customers |
| Supplier and contract reference | Who provides it and on what terms | Annex A third-party controls; Annex B items B.10.2 and B.10.3 | Vendor SaaS, contract C-2291 |
| AI technique | Shapes the risk sources | 6.1.2 risk identification | Third-party large language model through an API |
| Data used | Sources, personal data, training or input only | Annex B item B.4.3, data resources | Claim forms; contains personal data |
| Tooling, compute and hosting | Where it runs and what it depends on | Annex B items B.4.4 and B.4.5 | Vendor cloud, US region |
| People affected | Who an output can touch | 6.1.4 impact assessment | Claimants; adjusters |
| Human oversight point | Where a person reviews or can override | 6.1.3 treatment; impact assessment | Adjuster approves every routing change |
| Risk assessment reference and date | Proves 6.1.2 and 8.2 were done | 6.1.2, 8.2 | RA-014, 12 Aug 2026 |
| Impact assessment reference and date | Proves 6.1.4 and 8.4 were done | 6.1.4, 8.4 | IA-014, 19 Aug 2026 |
| Controls applied | Links to Statement of Applicability decisions | 6.1.3 | Controls marked applied for AIS-014 |
| Last reviewed and next review date | Shows the entry is current | 8.2 planned intervals | Next review 12 Feb 2027 |
| Retirement date and decommissioning record | Keeps history after a system is switched off | Annex A life cycle controls; 7.5.3 | Blank until retired |
Source: AI Training Skool register specification. Clause numbers from the ISO/IEC 42001:2023 official preview table of contents. Annex B item numbers and titles as listed in the draft-era (FDIS) crosswalk contributed by Microsoft and listed on NIST’s AI Resource Center; confirm them in your licensed copy of the published standard. Example values are illustrative, not a real system.
The Annex B items in the table are implementation guidance for the Annex A controls; Annex B is normative under the official table of contents. The resource items B.4.2 to B.4.6 are the ones the NIST AI RMF to ISO/IEC 42001 crosswalk maps to NIST’s inventory outcome. That crosswalk was contributed by Microsoft, is listed on NIST’s AI Resource Center (NIST notes that listing does not imply endorsement) and maps to the final draft (FDIS) text, not the published standard.
Keep retired entries. An auditor sampling last year’s risk assessments will look for the systems they covered, and a deleted row breaks that trail.
How to find every AI system, including shadow AI, vendor AI and agents
AI system discovery means checking records that show AI use, not only asking people what they use. A survey finds the systems people remember; logs, invoices and admin consoles find the rest.
| Source | What it finds | Who usually holds it |
| Procurement and contract records | AI products bought through the front door | Procurement, legal |
| Accounts payable and expense claims | AI subscriptions bought on a card | Finance |
| Single sign-on and identity logs | AI apps people sign in to with company accounts | IT, identity team |
| Proxy, network or browser logs | AI websites used without company sign-in | Security |
| SaaS admin consoles and vendor release notes | AI features switched on inside tools you already license | Application owners |
| Code repositories and cloud billing | Model APIs called from code, hosted models, API keys | Engineering, cloud team |
| Automation and agent platforms | AI agents, the tools they can call and the accounts they act as | IT, automation team |
| Business unit interviews | Uses that no system log shows, such as personal accounts used for work tasks | Implementer |
Source: AI Training Skool discovery method.
Three groups need their own pass. Shadow AI, meaning tools used without approval, shows up in expense claims and proxy logs; record it, then decide whether to approve, replace or block it. Embedded vendor AI arrives as a feature update, so read release notes for the tools in your scope and treat “AI feature enabled” as a new register entry. AI agents need extra fields: the tools and data they can reach and the identity they act under.
What counts as an AI system for the register?
ISO/IEC 42001 takes its AI terms from ISO/IEC 22989, which its clause 3 names as the source for terminology. In practice, record anything that uses machine learning or a model to produce outputs such as predictions, content, recommendations or decisions, plus any vendor feature marketed as AI. Fixed rules written by people, such as a spreadsheet formula, usually stay out. When in doubt, add the entry and mark it out of scope with a reason, because an auditor can then see you considered it.
When to review the AI system register
Events and the calendar both trigger a review of the AI system register. ISO/IEC 42001 sets no frequency; it asks for risk and impact assessments at planned intervals and when significant changes occur, so the register has to move at least as fast as those triggers.
Update an entry, or add one, when any of these happen:
- A new AI system is bought, built or switched on.
- An existing system gets a new intended use or a new group of affected people.
- A model version, data source or supplier changes.
- A vendor adds an AI feature to a tool you already license.
- An incident, complaint or audit finding involves the system.
- The system is retired.
Each trigger that changes risk should also reopen the risk entry, using AI risk criteria, assessment and treatment under clause 6.1. On the calendar side, a full reconciliation before each internal audit and each management review is a common convention, with quarterly checks against procurement and sign-on logs in between. Those cadences are working practice, not ISO requirements.
Public inventories show what a maintained register looks like. The US Department of Justice AI use case inventory is required under Executive Order 13960 and OMB Memorandum M-25-21. Its 2025 inventory, on a page updated 30 January 2026, lists 315 entries covering uses in every stage from pre-deployment and pilot to deployed and retired.
Who owns the AI system register?
One named person owns the AI system register as a whole, and each system owner owns the accuracy of their own entries. ISO/IEC 42001 clause 5.3 requires top management to assign responsibilities and authorities for the AIMS, so write the register owner into that assignment rather than leaving it to whoever built the first version.
The usual split, which is common practice rather than ISO wording, looks like this:
- The implementer or AI governance lead owns the register format, runs discovery and reconciles it against logs and procurement.
- Each business owner confirms the purpose, people affected and in-scope decision for their system, and accepts its risks.
- Each technical owner keeps version, data, hosting and supplier fields current.
- Procurement and IT tell the register owner about new purchases and new AI features before they go live.
The list above is also a short map of who an ISO 42001 Lead Implementer works with: business owners, technical owners, procurement and IT.
Building the first version of the register in four passes
Build the first register in passes, not in one sweep. First, pull every record source in the discovery table into one raw list. Second, merge duplicates and group features by the product they sit in. Third, send each owner their rows to confirm purpose, role and people affected. Fourth, mark each entry in or out of scope with a reason, and only then start risk and impact assessments.
Expect the list to grow during the first pass and shrink in the second. Date each pass, because the first internal audit will ask how the register was built.
How the AI system register feeds the rest of the AIMS
The AI system register is an input to almost every other ISO/IEC 42001 record. Scope (4.3) reads it to set boundaries, risk assessment (6.1.2) and impact assessment (6.1.4) use it as their list of systems, and the Statement of Applicability (6.1.3) points controls at its entries. The “People affected” field is the starting point for assessing impacts on people and society under ISO 42001.
The AI policy relies on it too. A policy that says “all AI systems are approved before use” is only provable if the register shows an approval reference for each system. Write an ISO 42001 AI policy under clause 5.2 after the first discovery pass, so its commitments match what the register can prove.
Internal audit and management review close the loop. Auditors sample from the register, and the management review should see how many systems have been added, changed or retired since the last review.
Common audit findings on AI system registers
Auditors raise the same AI system register problems again and again. These are typical patterns, not measured rates:
- A system the auditor sees in use, often a vendor AI feature, is missing from the register.
- The intended purpose is blank or too vague to assess (“productivity”).
- The owner field names someone who has left, or a team rather than a person.
- Review dates are older than the change records for the same system.
- The scope statement and the register disagree on what is in scope.
- Retired systems were deleted instead of being marked retired.
- Systems that affect people have no impact assessment reference.
- AI agents are listed without the tools and permissions they hold.
Each finding traces back to the register being built once for the project and not owned afterward. Give it a named owner and put reconciliation in the internal audit program.
If you want to practice before you build one at work, an ISO 42001 Lead Implementer course with a case study workbook has you complete an AI register for a worked case. You then carry it into the impact assessment, risk register and Statement of Applicability.
Frequently Asked Questions
Is an AI inventory mandatory under ISO 42001?
No document called an AI inventory is mandatory under ISO/IEC 42001:2023. Clause 4.1 does require you to consider the intended purpose of the AI systems you develop, provide or use and to determine your role for each, and clause 4.3 requires a documented scope. A register of AI systems is the practical way to show an auditor you met those requirements.
What fields should an AI system inventory include?
The core set of AI system inventory fields is ID, name and version, intended purpose, your AI role, business and technical owners, and life cycle stage. The register specification on this page uses 20 fields per system, adding supplier, data used, people affected, human oversight point, risk and impact assessment references, controls applied, review dates and a retirement record.
How often should an AI register be updated?
ISO/IEC 42001 sets no fixed frequency. Update an entry whenever a system is added, changes purpose, model, data or supplier, or is retired, because those changes trigger reassessment under clauses 8.2 and 8.4. Many teams also reconcile the whole register quarterly and before each internal audit and management review; that cadence is a convention, not an ISO requirement.
Should shadow AI tools go in the AI system register?
Yes. A shadow AI tool used for work inside your scope is an AI system you use, so clause 4.1 applies to it. Record it with an owner and a status such as under review, approved, replaced or blocked. Leaving it out is a common reason auditors find a register incomplete, because they can see the tool in expense claims or proxy logs.
Can a spreadsheet be an ISO 42001 AI register?
Yes. ISO/IEC 42001:2023 does not prescribe a format or tool for any record. A spreadsheet works if it is controlled documented information under clause 7.5: one current version, an owner, change history and access control. Teams usually move to a database or governance tool when the number of systems or the number of editors makes version control hard.
