ISO/IEC 22989: ISO/IEC 22989 – Tutorial (about 60 minutes)

ISO/IEC 22989 is the international standard that sets out the shared vocabulary and core concepts of artificial intelligence: what an AI system is, how machine learning fits in, which roles people and organisations play, how an AI system moves through its life, and what makes it trustworthy. Engineers, product owners, risk and compliance teams, auditors, buyers and policy people use it so that everyone means the same thing when they say "model", "AI provider" or "explainability". After this tutorial you will be able to read AI standards, contracts and policies with confidence, describe any AI system in the standard's terms, and set up a consistent AI glossary and role map for your own organisation.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC 22989:2022, Information technology — Artificial intelligence — Artificial intelligence concepts and terminology, the first edition, published in July 2022 by ISO and IEC through their joint committee ISO/IEC JTC 1/SC 42 (Artificial intelligence). It is in force (stage 60.60, "standard published"), and a corrected version of the 2022 text was issued in December 2025. Europe adopted it unchanged as EN ISO/IEC 22989:2023 through CEN/CENELEC JTC 21. Two amendments are in development: Amendment 1, "Generative AI", was registered as a final draft (FDIS) for formal approval in September 2026 but is not yet published, and Amendment 2 is at committee-draft stage. This tutorial teaches the published 2022 text and points out where the generative AI amendment is expected to add terms. Verified 2026-10-29.

Who it is for: software and data engineers, product managers, architects, quality, security, privacy, risk and compliance professionals, procurement teams and auditors who work with AI systems and are new to formal AI standards. It is also the natural first step before studying ISO/IEC 42001 (AI management systems) or ISO/IEC 23894 (AI risk management), because both build on this vocabulary.

Prerequisites: none. You do not need to know how to train a model. A general idea of what software systems and data are is enough; every AI term is explained when it first appears.

Learning objectives. After this tutorial you will be able to:

Explain why a terminology standard for AI exists and what ISO/IEC 22989 does and does not cover.
Define the core terms – AI system, model, machine learning, training and test data, AI agent, narrow and general AI – in your own words.
Describe the structure of the standard and find where concepts such as autonomy, trustworthiness and stakeholder roles are treated.
Place a real AI system on the life cycle stages and on the scale from no automation to autonomy.
Assign the AI stakeholder roles (provider, producer, customer, partner, subject, relevant authorities) in a concrete project.
Explain how the standard is used in assessments even though nobody is certified against it.
Relate ISO/IEC 22989 to ISO/IEC 23053, ISO/IEC 42001, ISO/IEC 23894, the NIST AI Risk Management Framework and the EU AI Act.

Lesson 1 – Origins, purpose and scope

Why AI needed a common vocabulary

Few fields use words as loosely as artificial intelligence. Marketing material calls a simple rules engine "AI"; a data scientist uses "model" to mean a set of trained parameters; a lawyer uses "AI system" with a definition taken from regulation; and a risk manager talks about "bias" meaning unfair outcomes while a statistician means a systematic error in an estimate. When these people sit in the same project, write the same contract or audit the same product, the confusion is expensive. Requirements are misread, responsibilities fall between organisations, and test reports cannot be compared.

Standards bodies faced the same problem one level up. In 2017 ISO and IEC created a joint subcommittee for artificial intelligence, SC 42, under their joint technical committee for information technology, JTC 1. The subcommittee planned a whole family of AI standards – on risk, management systems, data quality, life cycle processes, trustworthiness and more. A family of standards only works if every member uses words in the same way, so one of the first projects was a foundational document that would define the terms and describe the concepts everything else could rely on. That document is ISO/IEC 22989, published in 2022 together with its close companion ISO/IEC 23053, which describes a framework for AI systems that use machine learning.

What the standard is for

ISO/IEC 22989 has two jobs. First, it establishes terminology: a numbered list of terms with definitions, grouped by theme (general AI terms, data, machine learning, neural networks, trustworthiness, natural language processing and computer vision). Second, it describes concepts: in longer explanatory clauses it explains what the terms mean in practice and how they relate – for example how autonomy differs from automation, what the stages of an AI system's life are, and which kinds of organisations take part in an AI ecosystem.

Its scope statement makes three points worth remembering. It can be used when developing other standards; it can support communication among diverse interested parties; and it applies to every type of organisation, whether a company, a government agency or a not-for-profit. That last point matters: the standard is not just for large technology vendors. A hospital buying a diagnostic tool, a city using a traffic prediction service and a start-up fine-tuning a language model can all use the same terms.

What it is not

ISO/IEC 22989 is a descriptive standard. It contains no requirements that an organisation must meet, no controls to implement and no maturity levels to reach. It does not tell you whether a particular AI use is ethical, legal or safe, and it does not prescribe how to build models. Those questions are handled by other documents that use its vocabulary: management system requirements in ISO/IEC 42001, risk guidance in ISO/IEC 23894, life cycle processes in ISO/IEC 5338, data quality in the ISO/IEC 5259 series, and so on. Thinking of 22989 as the dictionary and grammar book of the family – rather than as a rulebook – is the most useful mental model.

Figure 1 – ISO/IEC 22989 is the shared foundation that the other SC 42 standards build on; only the management system standard leads to certification.

Narrow AI and general AI

One of the first conceptual clarifications in the standard concerns the old debate between "strong" and "weak" AI. Philosophers used those words to ask whether a machine could truly think. The standard moves the discussion to a more practical pair. Narrow AI (sometimes called weak AI) refers to systems designed to perform specific, defined tasks – recognising objects in images, translating text, detecting fraud. General AI (artificial general intelligence) refers to systems meant to handle a broad range of tasks with satisfactory performance, rather than one defined task. The point of the new pair is that it describes the scope of capability a system is designed for, not whether a machine really thinks. Whether today's large multi-purpose language models should count as general AI is debated, and the standard does not settle that question for you. The distinction keeps discussions grounded: requirements, tests and responsibilities are written for what a system was designed to do, not for speculation about machine minds.

Lesson 2 – Key concepts and vocabulary

This lesson explains the terms you will meet most often. The wording below is a plain-language paraphrase, not the official definition text; when precision matters for a contract or an audit, use the exact definitions in your licensed copy of the standard.

Artificial intelligence (the discipline) – the field of research and development concerned with the mechanisms and applications of AI systems. In the standard, "AI" names a discipline, while the thing you deploy is an AI system.
AI system – an engineered system that produces outputs such as content, forecasts, recommendations or decisions in pursuit of a set of objectives defined by humans. The definition is deliberately technology-neutral: it covers machine learning, rule-based reasoning and combinations of both.
Model – a simplified representation – mathematical, logical or even physical – of something real, such as a process, a phenomenon or a body of data. In AI, the model is the part that turns inputs into outputs; it can be learned from data or written down by experts.
Machine learning (ML) – a way of building a model in which computation adjusts the model's parameters until its behaviour captures patterns in example data or experience. ML is one way to build the model of an AI system, not a synonym for AI.
Training – running a learning algorithm over training data so that the parameters of a machine learning model are set or improved. The result is a trained model.
Training data, validation data and test data – three roles a dataset can play. Training data is used to fit the model; validation data is used to tune choices such as hyperparameters and compare candidate models; test data is held back and used only to estimate how the final model performs on data it has not seen. Data seen in operation is often called production data.
Hyperparameter – a setting chosen by people before or during training (for example the learning rate or the number of layers) that shapes how training happens, as opposed to the parameters the training process learns itself.
AI agent – an automated entity that perceives what is around it, reacts and acts in pursuit of its goals. The agent view is a convenient way to think about systems that act, such as robots, trading bots or software agents.
Knowledge – in the AI sense, facts, concepts and rules – and the links between them – organised in a form a system can use for reasoning or decisions. Knowledge-based systems encode it explicitly.
Symbolic and subsymbolic AI – symbolic approaches represent knowledge explicitly with symbols and rules that people can read (for example an expert system); subsymbolic approaches represent it implicitly in numbers, such as the weights of a neural network. Many modern systems are hybrids.
Neural network – a network of simple processing units (neurons) connected by weighted links whose values are adjusted during training; deep learning uses neural networks with many layers.
Autonomy, heteronomy and automation – an autonomous system could alter its own goals or the domain it is meant to work in with nobody outside controlling or overseeing that change; a heteronomous system works within goals and limits set from outside. Automation describes how much of a task the system performs without a human, from none to full.
Trustworthiness – how far a system can be shown, with evidence, to live up to what its stakeholders expect of it. The standard discusses several characteristics that contribute to it, covered in Lesson 3.
AI stakeholder – an organisation or entity that is involved in, or affected by, an AI system. The standard groups stakeholders into named roles, covered in Lesson 4.

How machine learning is described

The standard explains the main families of machine learning in a neutral way, without favouring any vendor or library:

Supervised learning learns from examples that carry the correct answer (labels), such as emails marked spam or not spam.
Unsupervised learning finds structure in data without labels, for example clusters of similar customers.
Semi-supervised learning combines a small amount of labelled data with a larger amount of unlabelled data.
Reinforcement learning learns by trial and error: an agent acts in an environment and receives rewards or penalties.
Transfer learning reuses knowledge from a model trained on one task to speed up learning on a related task – the idea behind fine-tuning a pre-trained model.

It also describes continuous learning (also called continual or lifelong learning), where a system keeps updating its model during operation. This matters for governance: a model that changes after deployment needs ongoing validation, which shows up in the life cycle in Lesson 4.

The functional view of an AI system

To make these terms concrete, the standard gives a functional overview: an AI system receives input (data from sensors, users or other systems), uses a model to process it, and produces output – predictions, recommendations, decisions or generated content. Outputs may lead to actions that change a physical or virtual environment. The model itself can come from two sources: it can be learned from training data by a machine learning algorithm, or it can be engineered by humans who encode knowledge as rules, ontologies or logic. Many systems mix both. Feedback from the environment can be used to improve the model later.

Figure 2 – In the functional view, a model built by learning, by human engineering or both turns input into outputs that can act on the environment.

A useful habit: when someone says "the AI", ask which part they mean. Is it the trained model file, the whole deployed system with its data pipelines and user interface, or the organisation's AI capability? ISO/IEC 22989 gives you separate words for each.

Lesson 3 – Structure of the standard

ISO/IEC 22989 follows the usual shape of an ISO/IEC document: introductory clauses first, then terms, then the substantive concept clauses. The table below paraphrases what each clause covers; it is a reading guide, not the clause text.

Clause	Title (short form)	What you find there
1	Scope	Terminology and concepts for AI, usable by any organisation and by other standards.
2	Normative references	None are needed to use this document.
3	Terms and definitions	The numbered vocabulary, grouped by theme: AI in general, data, machine learning, neural networks, trustworthiness, natural language processing, computer vision.
4	Abbreviated terms	Acronyms used in the text, such as ML and NLP.
5	AI concepts	The longest clause; topics include narrow and general AI, agents, knowledge, cognition, symbolic and subsymbolic approaches, data, machine learning concepts, autonomy and automation, IoT and cyber-physical systems, trustworthiness, verification and validation, jurisdictional and societal issues, and stakeholder roles.
6	AI system life cycle	A generic sequence of life cycle stages for AI systems.
7	AI system functional overview	How data, knowledge, learning and models combine to turn inputs into outputs.
8	AI ecosystem	A layered picture of the technologies and services that AI systems rely on.
9	Fields of AI	Areas such as computer vision and image recognition, natural language processing, data mining and planning.
10	Applications of AI systems	Illustrative examples such as fraud detection, automated vehicles and predictive maintenance.

Autonomy and automation in clause 5

One of the most practical parts of clause 5 is its treatment of autonomy. Public debate often treats "autonomous" as meaning "runs without a human". The standard separates two questions. The first is who sets the goals: a heteronomous system works towards goals and within a domain defined from outside, while an autonomous system could change its own goals or domain of use without external control. The second is how much of the work is automated, described as a graded scale for heteronomous systems:

No automation – a human operator does the task fully; the system does not act on its own.
Assistance – the system helps the operator, for example by highlighting likely problems, but the human performs the task.
Partial automation – some sub-functions run automatically while the human stays in control of the whole.
Conditional automation – the system performs the task in a sustained way within limits, with a human ready to take over when needed.
High automation – the system performs parts of its mission without any intervention.
Full automation – the system performs its entire mission within its defined domain without intervention.

Above these sits autonomy in the strict sense. The practical lesson is that almost every system an organisation deploys is heteronomous: even a fully automated loan pre-screening service pursues goals that its owners chose. Calling it "autonomous" in a policy or contract blurs accountability. Saying "fully automated within a defined domain, goals set by the credit department" is precise.

Trustworthiness characteristics

Clause 5 also describes characteristics that contribute to trustworthiness. They give teams a shared checklist of qualities to specify, test and monitor:

Robustness – keeping an acceptable level of performance under varied or unexpected conditions, including noisy or slightly unusual inputs.
Reliability – performing the required function consistently over time under stated conditions.
Resilience – recovering quickly to an operational state after an incident or disruption.
Controllability – a human or another outside agent can step in while the system is working, for example to stop or override it.
Explainability – being able to tell people, in terms they can follow, which factors mattered most for a given result.
Predictability – stakeholders can form dependable expectations about what the system will output.
Transparency – appropriate information about the system (its purpose, data, limitations, how it is operated) being available to relevant stakeholders. Transparency is about the system and the organisation; explainability is about particular results.
Bias and fairness – bias means that some people, groups or objects are treated in a systematically different way from others; not all bias is harmful, but unwanted bias can produce unfair outcomes. Bias is analysed in much more depth in a separate SC 42 technical report, ISO/IEC TR 24027.

Next to these, the standard explains verification (confirming that specified requirements have been fulfilled – "did we build it right?") and validation (confirming that the system meets the needs of its intended use – "did we build the right thing?"). For AI, both are harder than for ordinary software because behaviour emerges from data and may change over time.

The AI ecosystem

Clause 8 places an AI system inside the technology stack that supports it. At the bottom are shared resource pools – compute, storage and networking – often delivered through cloud and edge computing. Above them sit big data and data sources. Machine learning and other engineering approaches use that data to build the AI functions, and at the top are the AI systems that serve users in specific sectors. The picture helps when you divide responsibilities among suppliers: a company might rent compute from a cloud provider, buy labelled data from a data vendor, use a platform provider's training tools and then build its own application on top.

Fields and applications

Clauses 9 and 10 are short tours. Fields of AI include computer vision and image recognition (finding and classifying things in images and video), natural language processing (understanding and generating human language, including speech recognition, machine translation and question answering), data mining (finding patterns in large datasets) and planning (computing sequences of actions to reach a goal). The application examples show how these fields combine in real systems. They are illustrations, not a complete taxonomy, and you should not read them as the only places AI is used.

Lesson 4 – How it works in practice

The AI system life cycle

Clause 6 describes a generic life cycle. It is a model, not a process standard: it names the stages so that people can talk about where a system is and what activities belong there. The detailed processes are in ISO/IEC 5338, which builds on this model.

Inception – identifying the problem, the objectives, the stakeholders and whether AI is the right approach at all; first look at feasibility, data availability, cost and risk.
Design and development – designing the system, acquiring and preparing data, choosing and training models, and building the surrounding software.
Verification and validation – checking that the system meets its requirements and is fit for its intended use, including tests for robustness, bias and other trustworthiness characteristics.
Deployment – installing and releasing the system into its target environment, with the configuration, documentation and training users need.
Operation and monitoring – running the system, watching its performance, its inputs and its effects, and handling incidents.
Continuous validation – for systems that keep learning in operation, repeatedly checking that the changing model still meets requirements.
Re-evaluation – a deliberate review of whether the objectives, risks or environment have changed enough to require redesign, retraining or a decision to stop.
Retirement – withdrawing the system, handling its data and models responsibly, and moving users to a replacement if there is one.

Figure 4 – The generic AI system life cycle: operation loops through continuous validation, and re-evaluation leads back to redesign or on to retirement.

Two features distinguish this life cycle from a classic software life cycle. First, data is a first-class concern at every stage, not just an input to development. Second, the life cycle is explicitly iterative after deployment: model performance can drift as the world changes (for example customer behaviour shifts after a price change), so monitoring and re-evaluation are planned activities, not emergency reactions.

AI stakeholder roles

Clause 5 describes the roles that organisations and individuals play around AI. A role is not a type of company: one organisation often plays several roles at once, and the same organisation may be a provider for one system and a customer for another.

AI provider – an organisation that provides products or services that use one or more AI systems. Sub-roles include the AI platform provider (offers services, such as training platforms, that let others build AI) and the AI product or service provider (offers AI-based products or services directly to customers).
AI producer – an organisation that designs, develops, tests and deploys AI systems; the AI developer sub-role covers those who build models and system components.
AI customer – an organisation or individual that uses an AI product or service, directly or by providing it to others; the AI user sub-role is the one actually operating it.
AI partner – an organisation that supports the others with services: AI system integrators, data providers, AI auditors and AI evaluators.
AI subject – an individual or organisation affected by an AI system, such as a data subject whose personal data is processed, or a person about whom a decision is made.
Relevant authorities – policymakers and regulators with authority over the system's development or use.

Figure 5 – The six stakeholder roles and their main sub-roles; one organisation can hold several roles for the same AI system.

The value of the role model shows in contracts and governance. When a bank buys a credit-scoring service, who must explain a rejected application to the applicant? Who monitors drift? Who is notified when the training data is found to be flawed? Naming roles first and then mapping obligations to them makes these answers explicit instead of leaving them to an argument after something goes wrong.

Putting the standard to work: implementation steps

Because ISO/IEC 22989 has no requirements, "implementing" it means adopting its language and concepts in the way your organisation works. A practical sequence looks like this:

Build an AI glossary. Start an internal glossary that takes its core entries from the standard (with references to the term numbers in your licensed copy rather than copied text) and adds organisation-specific terms only where needed. Mark where a law you are subject to uses a different legal definition.
Inventory AI systems with consistent descriptions. For each system record its purpose and objectives, its inputs and outputs, how its model was built (learned, engineered or hybrid), its automation level and its current life cycle stage.
Map stakeholder roles. For each system, list who is provider, producer, customer, partner and subject, and which authorities are relevant. Feed this into contracts, RACI charts and supplier questionnaires.
Use life cycle stages as governance gates. Define what must be true to leave inception, to deploy and to keep operating; schedule re-evaluation.
Specify trustworthiness using the shared characteristics. Turn robustness, explainability, controllability and the rest into measurable requirements and tests appropriate to each system's risk.
Train people. Short training on the vocabulary for engineers, product owners, buyers and reviewers pays for itself the first time a misunderstanding is avoided.

The artefacts that result – a glossary, an AI system register, role maps, life cycle gate criteria and requirement templates – are exactly the documents that management system and risk standards later ask for, which is why many organisations start here.

Where generative AI fits

Systems that generate text, images, code or audio fit the 2022 concepts already: they are AI systems whose output is content, usually built with subsymbolic models trained by machine learning, often adapted to a task by transfer learning. What the 2022 text does not provide is a dedicated set of generative AI terms (for example for foundation models or prompts). That is what Amendment 1, titled "Generative AI", is being developed to add. Until it is published, define such terms carefully in your own glossary and note that they are provisional.

Lesson 5 – Assessment, certification and compliance

No certification against ISO/IEC 22989

There is no certification scheme for ISO/IEC 22989, for organisations or for people, and there cannot meaningfully be one: the document states no requirements, so there is nothing for an auditor to find conforming or non-conforming. If you see a product or a company advertised as "certified to ISO/IEC 22989", treat the claim with suspicion and ask what exactly was assessed and by whom. Training providers may offer courses and certificates of attendance on the standard – like this one – but those certify that a person learned the material, not that anything conforms to the standard.

How the standard still shapes assessments

Even without its own certification, ISO/IEC 22989 is present in many assessments:

ISO/IEC 42001 certification. The AI management system standard lists ISO/IEC 22989 as a normative reference, which means its terms apply when 42001 is read. When an accredited certification body audits an organisation against 42001, the auditors interpret words such as "AI system", "AI producer" or "AI customer" in the 22989 sense. An organisation that has already aligned its vocabulary finds the audit much easier.
Risk assessments. ISO/IEC 23894 also builds on 22989; risk registers that describe systems by life cycle stage, role and trustworthiness characteristic are easier to compare and review.
Supplier and procurement assessments. Buyers increasingly ask vendors to describe their AI systems in standard terms: how the model was built, what data roles were used, what automation level applies, how controllability is provided. Answers in the shared vocabulary can be compared across bids.
Internal audit and assurance. Internal auditors can check that policies, registers and contracts use the defined terms consistently – a useful early-maturity review before an external audit.

Regulation and legal definitions

Laws may define AI terms differently. The EU AI Act (Regulation (EU) 2024/1689), for example, has its own legal definition of an "AI system", modelled on the OECD description, and its own roles such as provider and deployer. These overlap with the 22989 roles but are not identical; for example the Act's "deployer" broadly corresponds to an AI customer or user that uses a system under its authority. Where you have legal obligations, the legal definition governs for that purpose. A good practice is to keep a mapping table in your glossary that shows how the standard's terms relate to each regulation you are subject to. ISO/IEC 22989 helps you talk precisely about the technology; it does not by itself make you compliant with any law.

Evidence that the vocabulary is really in use

If you want to check how well your organisation has adopted the standard, look for evidence rather than declarations: an approved glossary referenced by policies; an AI system register whose fields follow the concepts above; contracts that allocate obligations by role; life cycle gate records; test plans that address named trustworthiness characteristics; and people who can explain the difference between, say, transparency and explainability without notes.

Lesson 6 – Worked example

Northfield Mutual is a fictional mid-sized insurer with 2,000 staff. It is starting two AI initiatives at the same time: an in-house claims triage system that sorts incoming motor claims by likely complexity and fraud risk, and a purchased customer service assistant, a generative AI chatbot from a software vendor that answers policyholders' questions on the website. The chief risk officer wants both governed consistently and plans to pursue ISO/IEC 42001 certification within two years. The team starts with ISO/IEC 22989.

Step 1 – Agree what counts as an AI system

The team first asks which tools are in scope. Using the technology-neutral notion of an AI system, they include the new triage model, the chatbot and also an older rule-based fraud scoring engine that the IT department never called "AI". All three produce recommendations or decisions towards objectives the insurer set. A spreadsheet macro that sums claim amounts is excluded: it performs a fixed calculation and generates no prediction, recommendation or decision. Agreeing this boundary early stops later arguments about which systems need governance.

Step 2 – Describe each system in standard terms

For the claims triage system, the register entry reads: input – claim form data, photos, policy history; model – a neural network trained by supervised learning on five years of labelled claims (subsymbolic); output – a complexity class and a fraud-risk score; action – the claim is routed to a queue. The legacy fraud engine is recorded as an engineered, symbolic model of rules written by fraud experts. The chatbot is recorded as a system whose output is generated content, built on a large pre-trained language model that the vendor adapted by transfer learning; the insurer supplies its policy documents as a knowledge source.

Step 3 – Set the automation level and confirm heteronomy

The triage system routes claims automatically, but a claims handler reviews every high-fraud score before any action against a customer. The team records this as partial automation: routing is automated, while the decisions that matter stay with people. The chatbot answers simple questions on its own but hands over to a human agent for complaints, cancellations and anything involving payment; the team records conditional automation within that defined domain. Both systems are heteronomous – their goals are set by the insurer. A draft press release that described the chatbot as "an autonomous assistant" is reworded.

Step 4 – Map stakeholder roles

For the triage system, Northfield is the AI producer (its data science team builds and tests the model) and also the AI customer and user (its claims department operates it). A cloud company is the AI platform provider, supplying the training environment. A specialist firm that labels claim photos is a data provider, an AI partner role. Policyholders whose claims are triaged are AI subjects. The national insurance supervisor and the data protection authority are relevant authorities.

For the chatbot, the vendor is the AI provider and the producer of the underlying model; Northfield is the AI customer that offers the service to its own clients; an integration consultancy that connects it to the policy database is an AI system integrator; website visitors are AI subjects. The procurement team uses this map to check the contract: it must say who monitors answer quality, who handles a complaint about a wrong answer and how the vendor notifies Northfield of model updates.

Step 5 – Plan the life cycle

For the triage system, inception produces a short case: the problem (handlers spend too long on simple claims), the objectives (faster settlement without missing fraud), the stakeholders and the data available. Design and development include a data review that finds older claims from one region were labelled with a different fraud definition; they are relabelled. Verification and validation test accuracy on held-back test data and check whether risk scores differ unfairly between postcode groups. After deployment, operation and monitoring track score distributions every week. The model is retrained quarterly rather than learning continuously, so the team uses scheduled re-evaluation instead of continuous validation. A retirement plan records how training data will be kept or deleted when the model is replaced.

Step 6 – Turn trustworthiness into requirements

Instead of a vague goal of "trustworthy AI", the team writes requirements under each characteristic. Robustness: performance must not fall by more than an agreed margin on photos taken in poor light. Controllability: a handler can override any routing, and a switch can send all claims to manual review. Explainability: every high fraud score shows the top contributing factors to the handler. Transparency: the customer website explains that AI helps sort claims and that people make final decisions. Bias and fairness: quarterly comparison of outcomes across customer groups. For the chatbot, the same headings produce different requirements – for example predictability of tone and a rule that it never states policy terms without linking to the source document.

Step 7 – Prepare for the management system

Six months later, when the risk team starts its ISO/IEC 42001 project, much of the groundwork exists: the glossary, the AI system register, role maps for every system, life cycle gate records and trustworthiness requirements. The gap analysis focuses on the management system itself – policy, objectives, impact assessment, internal audit – rather than on arguing what words mean. The team also notes that the generative AI amendment to 22989 is close to publication and schedules a glossary review once it appears.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 22989 is rarely used alone. The table compares it with the standards and frameworks you are most likely to meet next.

Document	Type and owner	Main purpose	Relationship to ISO/IEC 22989
ISO/IEC 23053:2022	International standard, ISO/IEC JTC 1/SC 42	Framework describing the components and functions of AI systems that use machine learning	Companion published the same year; applies the 22989 concepts to ML systems in more technical depth
ISO/IEC 42001:2023	Certifiable management system standard, SC 42	Requirements for establishing, running and improving an AI management system	Lists 22989 as a normative reference; certification audits use its terms
ISO/IEC 23894:2023	Guidance standard, SC 42	How to manage AI-specific risk, adapting ISO 31000	Uses 22989 terms for systems, life cycle and stakeholders
ISO/IEC 5338:2023	Process standard, SC 42	Life cycle processes for AI systems, extending the software and systems life cycle standards	Turns the generic 22989 life cycle stages into defined processes
NIST AI RMF 1.0 (2023)	Voluntary framework, US NIST	Managing AI risks through the Govern, Map, Measure and Manage functions	Uses its own wording for trustworthiness characteristics; many map closely to 22989 concepts
EU AI Act, Regulation (EU) 2024/1689	Law, European Union	Risk-based legal obligations for providers, deployers and others	Has its own legal definitions and roles; 22989 helps explain them but does not replace them
OECD AI Principles and AI system definition	Intergovernmental recommendation, OECD	Policy principles for trustworthy AI and a widely reused AI system description	Both describe AI systems in technology-neutral terms; useful when aligning glossaries with policy

A simple way to remember the relationships: ISO/IEC 22989 gives the words; ISO/IEC 23053 gives a technical picture of ML systems; ISO/IEC 5338 gives processes; ISO/IEC 23894 and NIST AI RMF give risk methods; ISO/IEC 42001 gives an auditable management system; and laws such as the EU AI Act give obligations. The further you move along that chain, the more each document depends on precise shared meaning – which is why the vocabulary standard is the right place to begin.

It is also worth knowing about neighbours outside SC 42. The general software vocabulary standard ISO/IEC/IEEE 24765 and the information security family ISO/IEC 27000 have their own terms; where they overlap with AI (for example "security" or "validation"), use the AI-specific meaning in AI work and note any differences. Privacy terms such as "personal data" come from privacy law and ISO/IEC 29100 rather than from 22989.

Common pitfalls and best practices

Pitfalls

Treating the standard as a rulebook. Teams look for requirements to "comply with" and, finding none, conclude it is useless. Its value is in shared meaning; the requirements live in the standards that build on it.
Claiming certification. Advertising a product as "ISO/IEC 22989 certified" is misleading because there is nothing to certify against; it can damage credibility with auditors and regulators.
Calling everything autonomous. Describing an automated, human-supervised system as "autonomous" hides who set its goals and who is accountable for its actions.
Mixing up model and system. Testing only the trained model and ignoring the data pipelines, user interface and human procedures around it leaves most real-world failures untested.
Confusing transparency with explainability. Publishing a general description of a system does not explain an individual decision, and vice versa.
Assuming one role per organisation. A company that both builds and operates a system has producer and customer responsibilities; leaving one out creates gaps.
Copying definitions verbatim into public material. The standard is copyrighted; reference the term numbers and paraphrase in public documents.

Best practices

Start with a glossary and a register. One controlled glossary and one AI system register, both aligned with the standard, give every later activity a common base.
Record how each model was built. Note whether it was learned, engineered or hybrid, and with which data roles, so that testing and explanation strategies fit the technology.
Map roles per system, not per company. Create a role map for each AI system and use it in contracts, RACI charts and incident procedures.
Plan the whole life cycle. Include monitoring, re-evaluation and retirement in the plan from inception; schedule them rather than waiting for problems.
Make trustworthiness measurable. Use the characteristics as headings and write testable requirements beneath them, scaled to the system's risk.
Keep a regulation mapping. Record how standard terms relate to the legal terms of each law that applies, and let the legal definition govern legal obligations.
Watch for amendments. Review the glossary when the generative AI amendment and later amendments are published.

Summary and key takeaways

ISO/IEC 22989:2022 is the foundational vocabulary and concepts standard of ISO/IEC JTC 1/SC 42; a generative AI amendment is in final approval and not yet published.
It is descriptive: it defines terms and explains concepts but sets no requirements, so organisations are not certified against it.
An AI system is any engineered system producing outputs such as content, forecasts, recommendations or decisions for human-defined objectives, whether its model is learned, engineered or both.
Machine learning is one way to build a model; training, validation and test data play different roles and should be kept separate.
Autonomy (changing one's own goals) is different from automation (doing work without humans); almost all deployed systems are heteronomous.
Six stakeholder roles – provider, producer, customer, partner, subject and relevant authorities – help allocate responsibilities, and one organisation often holds several.
The life cycle runs from inception to retirement, with monitoring, continuous validation and re-evaluation as planned activities after deployment.
Its terms underpin ISO/IEC 42001 audits, ISO/IEC 23894 risk work and procurement, while laws such as the EU AI Act keep their own legal definitions.

Reflection questions

Pick one tool in your organisation that people call "AI" and one they do not. Using the definition of an AI system, which of them is in scope, and why?
For an AI system you know, write the register entry: inputs, how the model was built, outputs, automation level and current life cycle stage. Which item was hardest to fill in?
Draw the role map for a system your organisation buys from a vendor. Which responsibilities are not yet allocated in the contract?
Choose three trustworthiness characteristics and write one measurable requirement for each that would fit a system you work with.
Where does a law you are subject to define AI terms differently from the standard, and how would you record that difference in your glossary?