ISO/IEC 22989 Terminology Needs an Operational Dictionary

ISO/IEC 22989:2022 gives AI teams a shared conceptual vocabulary. The hard part starts when architecture diagrams, vendor inventories, risk registers and audit events use the same words for different objects. A team can call a hosted model an AI system while another team uses that label for the entire application, retrieval layer, model and human review process. I want to turn the standard's terminology function into an operational dictionary with stable IDs and evidence rules.

TL;DR

• Use ISO/IEC 22989 as the vocabulary baseline, then define the organization's system, component, use-case and actor records explicitly.
• Preserve regulatory definitions beside the standards dictionary because legal scope can differ by jurisdiction and obligation.
• Give each defined object a stable ID, owner, lifecycle state and evidence source so logs and risk records can join reliably.
• A routed LLM decision record proves one HTTP event. The full AI system still needs inventory and lifecycle context.

The standard supplies a common conceptual base

The official ISO/IEC 22989:2022 publication record identifies the standard as Artificial intelligence concepts and terminology. ISO published the first edition in 2022 through ISO/IEC JTC 1/SC 42, the joint technical committee responsible for artificial intelligence standards. The standard gives other AI standards and practitioners a common set of concepts rather than prescribing a management system or a product architecture.

National standards bodies adopt the same source into their catalogues. The DIN publication record for EN ISO/IEC 22989 identifies the underlying international edition as ISO/IEC 22989:2022 and the European adoption as EN ISO/IEC 22989:2023. DIN marks its German national edition as current and applicable to organizations of all types.

Clause-level wording belongs in the licensed standard. The practical pattern below avoids reproducing its definitions and shows how to govern a local dictionary anchored to that source. Teams implementing a formal standards crosswalk should verify each local entry against their licensed copy and record the edition used.

The terminology standard has a different job from ISO/IEC 42001 implementation. ISO/IEC 22989 supplies concepts and terms. ISO/IEC 42001 establishes an AI management system with organizational processes and controls. Mixing those jobs leads to a glossary that promises controls with no operating mechanism.

Define the AI system boundary before assigning controls

An operational dictionary should start with the organization's unit of governance. Define what qualifies as an AI system in the inventory, then separate the system from its components and uses. A single foundation model can support several systems. One system can call several models. The use case explains the business context and affected people, while the deployment identifies the running instance and environment.

The NIST AI Risk Management Framework 1.0 explicitly adapts its AI-system definition from the OECD recommendation and ISO/IEC 22989:2022. NIST describes an engineered or machine-based system that, for stated objectives, generates outputs such as predictions, recommendations or decisions that influence physical or virtual environments. It also says AI systems operate with varying levels of autonomy.

A local record should answer concrete questions:

• What objectives and outputs place this object inside the AI inventory?
• Which application, retrieval, model, policy and human-review components form the system boundary?
• Which use case and deployment are under review?
• Who provides, develops, deploys, operates, monitors and uses it?
• Which external services and data sources affect its behavior?

I would reject an inventory row named customer-service AI with one owner and no component map. It looks tidy in a spreadsheet and collapses during an incident because nobody can tell whether the affected object is the agent, retrieval index, model endpoint or ticketing action.

Actors and lifecycle states need local role definitions

A standards term becomes operational after the organization assigns a role and evidence source. NIST uses the term AI actors for organizations and individuals active across the AI system lifecycle. Its framework separates planning and design, data collection and processing, model building, verification and validation, deployment, operation and monitoring. Different people can own each task.

Create local role codes that map back to the standards vocabulary. For example, a provider supplies the external model service. A deployer configures and releases the application for the approved use. An operator supervises the production service, while a risk owner accepts residual risk. Users invoke the system, and a human reviewer can approve, reject or change an output. Legal and privacy roles remain explicit rather than hiding inside a generic governance owner.

The lifecycle dictionary needs controlled states and transition evidence. Candidate states might include proposed, assessed, approved, deployed, suspended and retired. The organization should define each state and the authority that changes it. Attach the risk assessment and acceptance result to approval. Attach a deployment record to the deployed state. Retirement needs evidence for traffic shutdown, access removal, data disposition and retained records.

The AI model inventory guide covers the inventory process. ISO/IEC 22989 terminology gives the records a shared language, but the local operating model decides which person can move a system between states.

Legal definitions should remain visible beside the standards baseline

Statutory definitions stay visible beside the standards glossary. The EU AI Act, sector rules and contract terms may define an AI system, provider, deployer or operator for a specific legal purpose. Store those definitions as scoped references beside the ISO-based dictionary. Record the jurisdiction, instrument, provision, effective period and legal owner.

The European Commission's AI Act regulatory framework page organizes obligations by risk and identifies duties for providers and deployers. Those legal roles determine who performs compliance work under the regulation. An internal architecture role with the same everyday name may carry different duties.

Use a term register with fields for the canonical term, local meaning, source and edition, legal overlays, prohibited synonyms, owner and review date. Add examples and counterexamples from the organization's systems. The counterexample is useful because it stops category drift. A deterministic routing rule may be a software component inside an AI system without becoming a separate AI system in the inventory.

When two definitions differ, preserve both and declare which one governs the decision. A legal classification should cite the relevant instrument. An architecture diagram can use the standards baseline. The risk register should link them through stable IDs rather than flattening them into one sentence.

Stable identifiers connect terminology to evidence

Give every AI system, component, use case, deployment, actor assignment and policy a stable identifier. Human-readable names change too often. A model marketed under one name can receive a new version, while a product team renames an application without changing its risk profile.

A practical identifier set could include:

• ais-0042 for the governed AI system
• use-0187 for the approved customer-support purpose
• dep-eu-prod-03 for the production deployment
• cmp-model-12 and cmp-rag-07 for model and retrieval components
• role-deployer-team-platform for the assigned deployer role
• pol-route-31-v6 for the active request policy

Print one inventory record on a single sheet of paper. The system ID should lead to its component map, owner, approved use and latest risk decision without requiring a reviewer to search four naming schemes.

Runtime events then reference those IDs. The AI audit-log schema guide explains request fields and correlation. For terminology governance, the event should identify the system, use case, deployment and model component represented by the call. It should also record the authenticated actor and role, active policy, classification, decision and timestamp.

A request event remains one event in the AI system record. Training evidence, model evaluation, source provenance, human-review disposition and downstream business action may live in different systems of record. Stable IDs let investigators join them.

Review terminology when architecture or law changes

Assign a dictionary owner and review cadence, then add event triggers. Review terms when ISO publishes a replacement edition, a regulator changes a definition, the organization adopts a new AI architecture or an incident exposes ambiguity. A merger or major supplier change can trigger the same review because actor roles and system boundaries may move.

Version the dictionary with the effective date and change rationale for each term. Existing evidence should continue to resolve against the version active when the event occurred. Rewriting old logs to use the newest term destroys historical meaning.

Test terminology with records rather than a vocabulary quiz. Select one production use and ask engineering, security, legal and procurement to identify the AI system, provider, deployer, model component, data source and human reviewer. Compare their IDs and boundaries. Resolve disagreements in the dictionary and architecture record.

My preferred test takes 30 minutes around one diagram on a wall. If four teams point at four different boxes when asked for the AI system, the glossary is still editorial. An operational dictionary produces the same identifier and explains the components inside it.

DeepInspect

DeepInspect can attach controlled terminology to authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. The calling application supplies the system, use-case and identity context. DeepInspect evaluates that context with the model destination, prompt and response classification, role and active policy before allowed traffic proceeds.

Each per-decision record can preserve the local AI-system ID, use-case ID, deployment, model route, actor identity, policy version, outcome and timestamp. That event supports the operational dictionary at the request boundary. Training, model evaluation, local execution, vendor-internal processing, human disposition and downstream business actions stay with their designated evidence owners. Book a technical deep dive at deepinspect.ai.