ISO/IEC 22989 – AI Concepts and Terminology for Consistent Governance

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated November 2025 • ISO/IEC 42001, ISO/IEC 23894, ISO/IEC TR 24028 • Governance, Quality, IT, Manufacturing, Compliance

ISO/IEC 22989 is the foundational vocabulary standard for artificial intelligence. It defines the core concepts, relationships, and terminology used across the AI standards family—so that governance, risk, quality, IT and vendors all mean the same thing when they say “AI system”, “training data”, “model”, “bias” or “human oversight”. In regulated manufacturing, this shared language is what prevents audit findings, misaligned procedures, and confused responsibilities.

“Before you can govern AI consistently, everyone has to be talking about the same thing.”

1) Where ISO/IEC 22989 Sits in the AI Standards Stack

ISO/IEC 22989 is not a risk or governance standard in itself. Instead it acts as the conceptual foundation for the AI ecosystem of standards. Documents such as ISO/IEC 42001 (AI Management System), ISO/IEC 23894 (AI risk management) and ISO/IEC TR 24028 (AI trustworthiness) build on its definitions. By using 22989 as a reference, organisations ensure that policies, risk registers, design documents, validation protocols and vendor contracts all point back to the same stable set of concepts.

2) Regulatory Anchors & Why Vocabulary Matters

Regulators rarely care which buzzwords a vendor uses; they care whether those terms are defined and applied consistently. ISO/IEC 22989 makes it easier to align your AI documentation with expectations from GxP, the EU AI Act, medical-device regulations and data-protection laws because it traces AI terminology back to a recognised international standard. When your SOPs, risk assessments and system descriptions all quote definitions from 22989, you reduce ambiguity in audits and inspections and make it clear that governance is anchored in an accepted reference, not marketing language.

3) The Core Concept Groups in ISO/IEC 22989

The standard organises its vocabulary around several key concept families. It defines what constitutes an AI system and distinguishes it from components and supporting IT. It describes data types (training, validation, test, input and output data), models and learning approaches, tasks such as classification or prediction, and operational properties such as robustness, explainability and fairness. It also introduces concepts for lifecycle stages, human involvement (human-in-the-loop, on-the-loop, in-command) and stakeholders (providers, deployers, users, impacted persons). These definitions become the building blocks for all further AI-design and governance discussions.

4) Linking Terminology to Governance & Management Systems

When you implement an AI Management System under ISO/IEC 42001, ISO/IEC 22989 supplies the vocabulary for every policy and SOP. Governance charters can explicitly reference 22989’s definitions of AI system, provider, deployer and operator. Risk matrices built on ISO/IEC 23894 can differentiate harms associated with data, model, task or context using standardised terms. Even board-level summaries benefit from a short, stable set of definitions attached as an appendix, preventing reinterpretation over time or across departments.

5) Data, Models & Lifecycle – Avoiding Confusion

In complex environments, people often mix up “algorithm”, “model”, “system” and “solution”. ISO/IEC 22989 separates these clearly. The model is the learned mathematical object; the AI system is the operational assembly of model, data pipelines, interfaces and controls; the application or use case is the business context in which the system operates. Likewise, the standard clarifies the difference between training data, validation data and test data, and how they relate to the lifecycle. For regulated MES, QMS and manufacturing execution environments, this precision is vital when writing validation plans, user requirements and technical specifications.

6) Human Oversight & Responsibility Language

ISO/IEC 22989 provides terminology for different styles of human involvement—human-in-the-loop, human-on-the-loop and human-in-command. These distinctions are directly relevant to regulated operations where oversight is a formal requirement. When procedures describe who can override an AI recommendation in an eBR or eMMR workflow, using 22989 terms helps show that your oversight design is deliberate and aligned with current AI governance thinking—not improvised language in each SOP.

7) Bias, Fairness & Trustworthiness Concepts

While ISO/IEC 24027 focuses on bias, ISO/IEC 22989 lays the conceptual groundwork. It defines terminology for bias, discrimination, fairness and related trustworthiness properties that are later expanded in ISO/IEC TR 24028. For sectors such as pharma, devices and food, these terms are relevant where AI affects sampling strategies, patient groups, supplier selection or quality decisions. Aligning internal risk language with 22989 avoids having one definition in quality, another in IT and a third in legal.

8) Using ISO/IEC 22989 in SOPs, Specifications & Validation

One of the most practical uses of ISO/IEC 22989 is as a master reference in your documentation. System requirement specifications, functional designs, validation plans and risk assessments can include a short glossary section citing 22989 definitions for AI-related terms. When quality teams review those documents, they do not have to renegotiate language case-by-case. In GMP contexts, this also aligns with expectations from 21 CFR Part 11, Annex 11 and CSV, where consistent terminology for systems and records is a basic prerequisite for defensible validation.

9) Vendor, Contract & Procurement Language

When contracts describe “AI capabilities”, “models” or “autonomous decision-making”, loose language can create gaps in responsibility. Referencing ISO/IEC 22989 in procurement templates and supplier questionnaires helps you ask clearer questions: Is the vendor providing an AI system or only a model? Who acts as the provider versus the deployer? How is training data sourced and governed? When regulators or auditors review third-party arrangements, being able to point to 22989-backed terminology strengthens your argument that responsibilities were deliberately assigned.

10) Training & Competence Frameworks

ISO/IEC 22989 can also underpin training materials. Introductory AI training for operations, quality and IT can borrow definitions directly from the standard so that everyone learns the same vocabulary. This supports competence frameworks in ISO 9001 or ISO 13485-aligned QMS environments, where roles must demonstrate understanding of the systems they use. When AI functionality is added to MES or QMS workflows, 22989-based terminology helps show that training was structured, repeatable and aligned to recognised guidance.

11) Documentation, Evidence & the Internal AI Glossary

Most organisations will not implement ISO/IEC 22989 verbatim; instead they will build an internal AI glossary that selects and adapts relevant terms. The key is traceability: mapping each internal definition back to 22989 and documenting any deliberate deviations. This creates evidence for auditors that terminology was not improvised but curated from a recognised standard. The same internal glossary can be referenced by deviation reports, non-conformance investigations, CAPA records and change-control logs whenever AI features are involved.

12) Metrics & KPIs for Terminology Adoption

Although ISO/IEC 22989 does not prescribe KPIs, management systems built on ISO/IEC 42001 often track adoption of standardised terminology. Typical metrics include the percentage of AI-related SOPs and specifications that reference the internal AI glossary, the number of documents updated during a terminology harmonisation campaign, training completion rates on AI basics, and the number of audit or inspection observations related to unclear AI terminology. When those numbers improve, it is evidence that 22989 is actively supporting governance, not just sitting on a shelf.

13) Implementation Steps in Regulated Environments

Implementing ISO/IEC 22989 usually follows a lightweight but structured path. First, identify which AI-related projects, vendors and systems exist (or are planned) across MES, QMS, LIMS and analytics. Second, build an internal AI glossary drawing from 22989, aligned with existing corporate terminology and Validation Master Plan (VMP) language. Third, update key templates—risk assessments, URS, design specs, test protocols, supplier questionnaires—to reference the glossary. Finally, embed those terms into training and governance documents under GxP expectations, closing the loop between vocabulary and practice.

14) How ISO/IEC 22989 Fits Operationally Across Systems

Governance & Quality: Steering committees and quality councils use 22989 concepts when classifying AI systems, defining risk tiers and documenting responsibilities. IT & Data: Architecture diagrams, data-flow maps and model registries all describe components using common terminology, reducing hand-off friction between teams. Operations & Manufacturing: Work instructions, batch records and exception workflows refer to AI outputs and recommendations using stable, defined terms, making it easier to explain to operators and inspectors what the system does. Vendors & Procurement: RFPs and contracts anchored in 22989 language reduce ambiguity and make it clearer which party is responsible for which part of the AI lifecycle.

15) FAQ

Q1. Do we need to implement ISO/IEC 22989 formally to benefit from it?
Not necessarily. Many organisations simply adopt 22989 as a reference for their internal AI glossary and templates. The value comes from using consistent, standard-backed definitions across policies, specifications, validation and contracts, even if you do not claim formal conformity.

Q2. How does ISO/IEC 22989 relate to ISO/IEC 42001 and 23894?
ISO/IEC 22989 defines the language; ISO/IEC 42001 defines the AI Management System; ISO/IEC 23894 defines AI risk management. Using 22989 alongside those standards ensures that governance and risk processes are built on a clear, shared conceptual foundation.

Q3. Should every term from ISO/IEC 22989 appear in our internal glossary?
No. The standard is intentionally broad. Most organisations select a subset that is relevant to their use cases and systems, document those definitions, and maintain a mapping back to ISO/IEC 22989 for traceability. Over time, new terms can be added as AI capabilities expand.

Q4. How does ISO/IEC 22989 interact with existing IT or data glossaries?
Ideally, AI terminology extends—not replaces—existing information-systems glossaries used for CSV and enterprise IT. When conflicts appear, organisations typically harmonise definitions, document the decision, and keep a single, master list that references both AI and non-AI standards.

Q5. What is the first practical step to adopt ISO/IEC 22989?
Start by identifying all documents where AI is already mentioned—strategy decks, roadmaps, RFPs, URS, validation plans, SOPs—and list the terms being used. Then map those terms to ISO/IEC 22989 definitions, decide which ones become your internal standard, and publish a controlled glossary that all new documents must reference.

Related Reading
• AI Governance & Risk: ISO/IEC 42001 | ISO/IEC 23894 | ISO/IEC TR 24028 | GxP
• Quality & Systems: ISO 9001 | ISO 13485 | CSV | VMP
• Execution & Records: MES | eBR | eMMR | Deviation/NCR | CAPA