ISO/IEC 22989

What the standard covers

ISO/IEC 22989 is the shared vocabulary layer for AI. It defines the terms and concepts that let architects, auditors, policy teams, and developers talk about AI systems, capabilities, roles, and lifecycle ideas without using inconsistent wording.

That matters because AI programmes often fail at the language level before they fail at the technical level. If teams do not agree on what counts as an AI system, a capability, a role, or a lifecycle stage, governance decisions become harder to compare, audit, and enforce.

Why a common AI vocabulary matters

A vocabulary standard does not prescribe how to build or secure AI, but it shapes every downstream discussion about design, assurance, and oversight. It helps different functions use the same terms for system boundaries, intended use, stakeholders, and lifecycle stages, which reduces ambiguity in reviews and policy documents.

That shared language is especially important when AI is embedded into broader enterprise controls. The concept of an AI system, for example, may need to line up with risk assessments, procurement language, operating procedures, and governance records so that everyone is describing the same thing.

For organisations building an AI control stack, ISO/IEC 22989 sits upstream of control selection. A clear vocabulary makes it easier to connect concepts such as risk treatment, accountability, and operational oversight to the same AI artefacts and decisions.

Where ISO/IEC 22989 fits in AI governance

ISO/IEC 22989 is a foundational reference rather than an assessment or certification scheme. It supports AI governance by giving boards, risk teams, technical leads, and auditors a common reference point for the terms they use when discussing scope, responsibilities, and lifecycle control.

It is most useful when paired with standards and guidance that do prescribe actions. In practice, a vocabulary standard helps translate policy intent into operational language, while risk, management-system, and control standards determine what should actually be done.

Because its role is definitional, the standard is also helpful in cross-functional review. It reduces the chance that one team is discussing an AI model, another is discussing an AI-enabled product, and a third is discussing an AI service contract as if they were the same object.

For governance teams, the value is consistency, traceability, and less room for interpretive drift. That makes later assurance, audit, and control mapping more defensible.

How to use the standard well

Use ISO/IEC 22989 as the language baseline before you write policy, classify use cases, or map controls. It is most effective when the organisation agrees on the vocabulary first, then uses that vocabulary consistently across risk assessments, architecture reviews, procurement, and audit evidence.

It is also useful as a translation layer between business and technical stakeholders. The standard helps teams avoid using overlapping terms loosely, which is a common source of confusion when AI projects move from ideation into operational oversight.

For readers who want a risk-oriented companion to this vocabulary layer, ISO/IEC 23894 AI Risk Management Guide is the natural next stop, because it shows how AI terminology connects to structured risk management.

Risk and Threat Considerations

When organisations use AI vocabulary loosely, they can mis-scope controls, understate accountability, or compare unlike systems as if they were equivalent. That creates governance risk even before any technical failure occurs, because the wrong artefact may be reviewed, approved, or monitored.

Failure mechanism: Ambiguous terms let teams describe the same AI capability differently across policy, architecture, procurement, and audit records, which weakens traceability and can hide control gaps.

Impact: Poor terminology can lead to inconsistent approvals, incomplete evidence, and unreliable assurance over what the organisation actually built or deployed.

Practitioner Guidance

Why practitioners should care: Treat ISO/IEC 22989 as the reference point for naming AI artefacts before you assess them. A stable vocabulary makes later risk decisions, ownership assignments, and control mappings much easier to defend.

Governance implication: Use the standard to align business, legal, security, and engineering teams on the same definitions in policies, registers, and review templates, so that each group is governing the same AI subject.

Practitioner takeaway: If your AI programme cannot describe its systems consistently, it will struggle to govern them consistently.

Related resources from NHI Mgmt Group

• Who is accountable for ISO/IEC 42001 evidence and AI access control?
• Why does ISO/IEC 27001:2022 matter for IAM and NHI programmes?
• Why do organisations choose ISO/IEC 27001 when they already have other security frameworks?
• What is the difference between ETSI TS 119 461 and ISO/IEC 30107 in identity proofing?