Why the inventory is the starting point

You cannot govern what you do not know. The AI systems inventory serves three functions within ISO 42001:

  • Defines the AIMS scope — Determines which systems enter the certification and which remain out, with documented justification
  • Feeds risk assessment — Each inventoried system needs an AI risk assessment (§6.1) and potentially an algorithmic impact assessment (Annex A.5 + §8.2)
  • Foundation for the Statement of Applicability — The SoA maps Annex A controls to the AI systems in the inventory
Normative reference: The AI systems inventory is referenced in Annex A.4 (Resources for AI systems) and is the primary input for clauses 4.3 (scope), 6.1 (risk assessment), and 9.1 (monitoring and measurement).

The 10 fields every inventory must have

01
System name

Descriptive name of the AI system. Avoid internal codes without context — the auditor must understand what it does from the name alone.

Example: "Retail credit scoring model", "Customer service chatbot", "Payment fraud detection system"
02
Purpose and function

Concise description of what the system does, what decisions it makes or supports, and which business process it is integrated into.

Example: "Predicts 90-day default probability for personal loan applications. Output is one signal in the final advisor decision."
03
System type

Technical classification: supervised/unsupervised machine learning, neural network, natural language processing, computer vision, recommendation system, etc.

Example: "Binary classification model (XGBoost). Supervised ML trained on historical portfolio data."
04
Origin / provider

Is the system developed internally, purchased from a vendor, or contracted as a service (MLaaS)? Include the vendor name if applicable.

Example: "Internal — Data Science team", "Vendor: Experian — Credit Score module", "OpenAI API (GPT-4o)"
05
Training data / inputs

What data the system uses: origin, type, sensitivity. If it uses personal data, indicate whether it includes specially protected categories (health, ethnicity, etc.).

Example: "5-year credit history, demographic data (age, city). No special category data included."
06
Affected population

Who is impacted by the system's decisions: employees, customers, citizens, candidates. Include approximate volume if possible.

Example: "Credit applicants — approx. 8,000 decisions/month", "Job candidates — 500 CVs evaluated/month"
07
Autonomy level

Does the system recommend (human decides), assist (human confirms), or decide autonomously? This field directly determines the risk level.

Three levels: Assistance (informational output), Recommendation (human can override), Autonomous decision (no human review)
08
AI risk classification

Risk level assigned according to your internal methodology (and optionally, the EU AI Act category: prohibited / high-risk / limited-risk / minimal-risk).

Example: "High Risk (internal) — High Risk EU AI Act, Annex III §5(b): AI systems for access to financial services"
09
System owner

The role or person responsible for governing the system within the organization (not necessarily the technical developer).

Example: "Owner: Chief Credit Risk Officer | Technical contact: Head of Data Science"
10
Lifecycle stage

Which phase the system is in: in development, in testing, deployed in production, under review, or retired. Determines which Annex A.6 (lifecycle) controls apply.

Stages: Development → Testing → Production → Monitoring → Retired

How to classify the risk level of each system

ISO 42001 does not impose a single scale, but requires that your methodology be documented and applied consistently. A practical 4-level classification:

Level
Primary criterion
Priority controls
Low
Internal use with no third-party impact. Output is informational. Errors easily reversible.
Basic documentation + performance monitoring
Medium
Affects customers or employees. Human reviews the decision. Impact is limited and reversible.
Risk assessment + usage policy + annual audit
High
Autonomous or highly influential decisions over people. Impact on rights. EU AI Act Annex III category.
Full AIA + documented explainability + continuous monitoring
Critical / Prohibited
Subliminal manipulation, social scoring, biometric mass surveillance in public spaces without authorization.
Prohibited by EU AI Act Art. 5. Do not deploy.

Which third-party AI systems to include

Many organizations make the mistake of inventorying only their in-house developments. ISO 42001 also applies to AI systems that the organization uses or deploys, even if they did not build them:

  • Contracted AI APIs — OpenAI, Google Vertex AI, AWS Comprehend, Azure Cognitive Services used in processes affecting third parties
  • Software with embedded AI — Credit scoring platforms, fraud detection systems, algorithmic hiring tools
  • Internally deployed open-source models — LLMs, classification or computer vision models that the organization configures and deploys
  • AI-powered automation tools — ML-based RPA, dynamic pricing decision systems, conversational agents
For third-party AI systems, Annex A.10 (Third-party and customer relationships) requires vendor due diligence, contract review, and verification that the vendor can meet your AI governance requirements.

How to keep the inventory current

  • Annual review minimum — Review all fields at least once a year before the surveillance audit
  • Event-triggered update — Every time a new system is deployed, changes to a major version or purpose, or is retired
  • Integrated change control — Link the inventory to your change management process (ISO 42001 §6.3) so no new system enters production without going through the inventory
  • Defined owner — Each system must have a responsible person who validates information annually and notifies of changes

Frequently asked questions

Any system using machine learning, neural networks, fuzzy logic, optimization algorithms, or natural language processing to make decisions, generate predictions, or produce content. This includes internally developed systems, third-party purchased tools, and cloud AI models that your organization configures or deploys.

It depends on how they are used. If employees use them freely as productivity tools without their output affecting decisions that impact third parties (customers, citizens, candidates), it may not be required. If they are used to generate credit reports, answer complaints, or classify applications, they must appear in the inventory under "third-party AI use."

At least once a year and whenever: a new AI system is deployed, an existing system changes its major version or purpose, an AI provider changes its terms or model, or the regulatory environment changes in a way that affects a system's risk classification.

Not necessarily. It is an internal AIMS document. However, the EU AI Act (Art. 49) requires high-risk AI systems to be registered in the EU public database before deployment. For public sector organizations, the OECD AI Principles and many national AI strategies call for proactive disclosure of AI systems used in government decision-making.

ISO 42001 does not prescribe a single scale, but requires a documented methodology (§6.1.2). A practical four-dimension classification uses: impact on people's rights (low/medium/high), decision autonomy (assisted/recommended/autonomous), error reversibility (reversible/friction/irreversible), and reach (internal/external/mass-scale). The EU AI Act adds regulatory categories: prohibited, high-risk, limited-risk, minimal-risk.

Build your AI inventory with SoberanIA

The platform includes the AI Systems Inventory module with all fields required by ISO 42001, automated risk classification, and direct linkage to impact assessments.

See free demo

You might also like: ISO 42001 implementation roadmap · ISO 42001 vs ISO 27001 · ISO 42001 vs NIST AI RMF