The common language every SC 42 standard is built on
The first questions an organization hits when it starts preparing for ISO/IEC 42001 are surprisingly abstract. Which of our systems should we classify as AI systems? Are we an AI provider, or an AI producer? Which lifecycle stage does this control map to? ISO/IEC 22989:2022 is the standard that gives standardized answers to those questions. Try to interpret ISO/IEC 42001's clauses without it, and you end up using the same words with different definitions while believing you have reached agreement. That is why this series takes 22989 first: every SC 42 standard runs on its vocabulary.
Scope note
This overview is based on the published text of ISO/IEC 22989:2022. Where a different term is more common in industry practice, it is given alongside the standard's wording. For formal citation or document submission, refer to the official standard text.
What is ISO/IEC 22989?
ISO/IEC 22989:2022 — Information technology — Artificial intelligence — Artificial intelligence concepts and terminology — is the foundational standard of the AI field, published by ISO/IEC JTC 1/SC 42 in July 2022. It imposes no controls or requirements of its own, but provides the reference for the terms and concepts other standards use. ISO/IEC 42001, 23894, 42005, and 5338 all draw on its vocabulary. Its AI system definition also aligns closely with the definitions used by the OECD and the EU AI Act, so the vocabulary travels beyond the ISO world.
The standard has nine clauses:
| Clause | Content |
|---|---|
| 1 | Scope |
| 2 | Normative references |
| 3 | Terms and definitions — AI, data, ML, neural networks, trustworthiness, NLP, computer vision |
| 4 | Abbreviated terms |
| 5 | AI concepts — 19 sub-topics |
| 6 | AI system life cycle |
| 7 | AI system functional overview |
| 8 | AI ecosystem |
| 9 | Fields of AI |
Key point 1 — The definition of an AI system
In ISO/IEC 22989 (3.1.4), an AI system is an engineered system that generates outputs — such as content, forecasts, recommendations, or decisions — for a given set of human-defined objectives.
Two things in the definition matter. First, it has to be an engineered system: a natural phenomenon or a human brain is not an AI system. Second, it generates outputs — and not just any data processing, but output that is content, a forecast, a recommendation, or a decision. The standard adds in a note that an AI system is designed to operate with varying levels of automation, so partially automated systems, not only fully automated ones, fall within the category.
Key point 2 — The four characteristics of an AI system
Clause 5.1 defines the distinguishing characteristics of an AI system — the line between an AI and a non-AI system:
- Interactive — takes input through sensors or human interaction and produces output through actuator stimuli or responses.
- Contextual — draws on diverse information sources at once: structured and unstructured digital information, sensory input.
- Oversight — operates with varying levels of human oversight and control depending on the application (the levels of driving automation are the classic example).
- Adaptive — uses dynamic data in real time and updates its operation by retraining on new data.
A system that exhibits none of these four is generally not regarded as an AI system. This is the practical line between a simple if-then automation and an AI system.
Key point 3 — Narrow AI and General AI
Clause 5.2 divides AI along two poles:
- Narrow AI — a system that handles a specific problem with defined tasks. It may do so far better than a human, but its scope of tasks is bounded.
- General AI — a system that handles a broad range of tasks at a satisfactory level of performance.
The standard classifies all currently existing AI systems as narrow, and notes it is not yet known whether general AI will prove technically feasible. General-purpose LLMs such as ChatGPT or Gemini are, in the standard's terms, narrow AI. So using "general AI" loosely when setting a certification scope clashes with the standard's vocabulary — worth being careful about.
Key point 4 — The five types of machine learning
Clauses 3.3 and 5.11 classify ML by learning method:
| Term | Core idea |
|---|---|
| Supervised machine learning | Uses labeled data only |
| Unsupervised machine learning | Uses unlabeled data only |
| Semi-supervised machine learning | Uses a mix of labeled and unlabeled data |
| Reinforcement learning (RL) | Learns reward-maximizing behavior through interaction with an environment |
| Transfer learning | Reuses the results of prior learning for a different task |
Data requirements, validation methods, and risk characteristics differ by learning method. ISO/IEC 23894 (AI risk management) and the ISO/IEC 5259 series (data quality) call for controls differentiated by method, so 22989's classification is their starting point. Clause 5.12 also names example ML algorithms: neural networks, Bayesian networks, decision trees, and support vector machines (SVM).
Key point 5 — Autonomy, heteronomy, automation
Clause 5.13 distinguishes levels of autonomy:
- Autonomy — the characteristic of a system that can modify its intended domain of use or goal without external intervention, control, or oversight (3.1.5).
- Heteronomy — the characteristic of operating in dependence on external control.
- Automation — the characteristic of a process or system that operates without human intervention under specified conditions (3.1.7).
Autonomy and automation are clearly separated in the standard: automation is "operates without a human under defined conditions," while autonomy is the stronger notion of "can modify its own goal." This distinction is central when you assess the level of autonomy in an ISO/IEC 42005 impact assessment.
Key point 6 — The eight-stage AI system lifecycle
Clause 6.2 defines the AI system lifecycle in eight stages:
| Stage | Core activity |
|---|---|
| Inception | Identify objectives, requirements, and risks; assess feasibility |
| Design and development | Architecture decisions, code and training-data processing, risk treatment |
| Verification and validation | Functional verification, acceptance decision |
| Deployment | Install, release, and configure in the target environment |
| Operation and monitoring | Normal operation and incident monitoring; repair, update, support |
| Continuous validation | Applied where incremental training runs in operation; re-validate on production data |
| Re-evaluation | Evaluate operating results; revisit objectives and requirements |
| Retirement | Retire or replace, including disposal of data |
This lifecycle is the most important reference model when designing ISO/IEC 42001 Clause 8 (operation) controls. Without mapping which control applies at which stage, and what verification a stage transition needs, the control set becomes scattered. ISO/IEC 5338 defines these eight stages in finer SDLC detail.
Key point 7 — The six stakeholder roles
Clause 5.19 defines the stakeholders related to an AI system as six high-level roles, each with sub-roles:
| Role | Main sub-roles |
|---|---|
| AI provider | AI platform provider; AI service or product provider |
| AI producer | AI developer — model designer, implementer, computation/model verifier |
| AI customer | AI user |
| AI partner | AI system integrator; data provider; AI auditor; AI evaluator |
| AI subject | Data subject; other subjects |
| Relevant authorities | Policy makers; regulators |
One organization can hold several roles at once, and the roles can differ by system. A company running an internal customer-service chatbot on an external LLM API is an AI customer for that chatbot and an AI provider to its own customers. (These roles map onto the EU AI Act's provider/deployer split, which makes 22989 a useful bridge between ISO and the regulation.)
The starting point for setting an ISO/IEC 42001 scope is identifying which role you play for which system. ISO certification bodies and auditors correspond, in the standard, to the AI partner sub-role of AI auditor — consistent with the ISO 19011 and 17021 audit framework.
Key point 8 — The eight attributes of trustworthy AI
Clause 5.15 decomposes trustworthiness into eight attributes. This classification is the basis for the trustworthy-AI follow-on standards such as ISO/IEC TR 24028, TS 6254, TS 8200, and TR 24027:
| Attribute | Core idea |
|---|---|
| AI robustness | Maintaining consistent performance across diverse environments |
| AI reliability | Performing required functions under stated conditions |
| AI resilience | Recovering operational state quickly after an incident |
| AI controllability | The ability of an external agent to intervene in functioning |
| AI explainability | Expressing decision factors in a human-understandable way |
| AI predictability | Letting stakeholders make reliable assumptions about outputs |
| AI transparency | Appropriate disclosure of system, data, and decision information |
| AI bias and fairness | Minimizing unwanted bias; preventing discrimination and favoritism |
ISO/IEC 42001's Annex B controls map almost directly onto these eight attributes, and an ISO/IEC 42005 impact assessment draws on this classification directly when deriving its assessment items.
How it connects to ISO/IEC 42001
ISO/IEC 22989 is referenced in nearly every clause of ISO/IEC 42001. The key mappings:
- Clause 4 (context) — scope and interested-party identification through the AI system definition (3.1.4) and stakeholder roles (5.19).
- Clause 6 (planning) — using ML types (3.3) and the trustworthiness attributes (5.15) when classifying systems for risk assessment.
- Clause 8 (operation) — control design based on the eight lifecycle stages (6.2).
- Clause 9 (performance evaluation) — defining the systems under evaluation and standardizing measurement terminology.
- Annex B — direct mapping between the eight trustworthiness attributes and the controls.
If 22989 is not read closely at the start of an ISO/IEC 42001 program, terminology mismatches accumulate through every later output and can be raised as a nonconformity at audit.
From an audit perspective — five points to watch
(These are situations that can arise in practice, not assertions of frequency.)
1. "Is this system an AI system too?" — a question that can come up at the scoping stage, and a missed system at audit can be a direct nonconformity. If the output is content, a forecast, a recommendation, or a decision, and the system has at least one of the four characteristics (interactive, contextual, oversight, adaptive), classify it as an AI system. A simple if-then automation is excluded.
2. Confusing provider and producer — where an external model is used, you may not be the producer. Responsibility and the depth of control applied differ, so the distinction has to be clear. Integrating an external model into your own service usually makes you an AI provider (an "AI service or product provider").
3. "Is federated learning in 22989?" — no. The ML types 22989 defines are the five: supervised, unsupervised, semi-supervised, reinforcement, and transfer learning. Federated learning is handled in other standards or separate annexes.
4. Skimping on the back half of the lifecycle — it is easy to treat post-deployment monitoring, continuous validation, and re-evaluation only formally. Mapping control activities to all eight stages 22989 specifies is what avoids an omission finding at audit.
5. Mixing autonomy and automation — the two concepts differ in the standard. When recording a "level of autonomy" in an impact-assessment report, distinguish automation, heteronomy, and autonomy per the 5.13 definitions.
The bottom line
ISO/IEC 22989 is the constitution of the SC 42 standards system. With no controls or requirements, it looks light on the surface, but the interpretation of every other standard depends on its definitions. At any stage — consulting, training, or certification preparation — reading its nine clauses once before you start the work pays off.
Next in this series: ISO/IEC 23053:2022 — Framework for AI Systems Using Machine Learning. If 22989 is the dictionary of abstract concepts, ISO/IEC 23053 is the structural blueprint of an ML system.
📚 SC 42 AI Standards Series
← Previous: ISO/IEC JTC 1/SC 42 — The AI Standards Landscape
📍 Current: ISO/IEC 22989:2022 — AI Concepts and Terminology
→ Next: ISO/IEC 23053:2022 — Framework for ML-based AI Systems (forthcoming)