1.2 AI Concepts & ISO/IEC 22989 Terminology
Key Takeaways
- ISO/IEC 22989:2022 is the vocabulary backbone for ISO AI standards: an AI system is an engineered system that generates outputs such as content, forecasts, recommendations, or decisions for human-defined objectives, with varying levels of autonomy.
- Machine learning is a subset of AI that builds models from data; generative AI is a class of systems that produce new content (text, images, code, etc.) and often exhibits highly non-deterministic outputs for a given prompt.
- Auditor-critical 22989 terms — AI model, dataset, training/validation/testing data, inference, human oversight — each map to a different evidence package, and misusing them (calling a rules engine an “AI system,” or a training dataset a “model”) undermines nonconformity clarity and can invalidate the audit trail.
- Deterministic traditional software follows explicitly coded rules with repeatable outputs for the same inputs; many AI systems are probabilistic, data-dependent, and may change behavior after retraining or distribution shift.
- PECB names cognitive computing (imitating human reasoning to support decisions), semantic computing (ontologies and meaning), and soft computing (fuzzy logic, evolutionary algorithms, probabilistic reasoning) as AI subfields you must differentiate.
1.2 AI Concepts & ISO/IEC 22989 Terminology
Quick Answer: Use ISO/IEC 22989:2022 (Artificial intelligence — Concepts and terminology) as your dictionary. An AI system produces outputs for human-defined objectives with degrees of autonomy; machine learning learns patterns from data; generative AI creates new content. Auditors who misuse these labels write findings that certification bodies and auditees can legitimately challenge.
Domain 1 of the Lead Auditor scheme expects more than marketing slogans about “AI.” When you interview a data scientist, read a model card, or classify a nonconformity against Annex A, every party must share the same meanings. ISO/IEC 42001 deliberately aligns with the broader ISO/IEC AI vocabulary rather than inventing a private glossary.
AI, Machine Learning, and Generative AI
Think in nested sets, not synonyms:
| Concept | Working meaning for auditors | Typical evidence you might request |
|---|---|---|
| Artificial intelligence (AI) | Broader field of engineered systems that perform tasks associated with human intelligence (perception, prediction, recommendation, decision support, content generation, etc.) | Inventory of AI systems in scope; system purpose statements; intended use |
| Machine learning (ML) | Subset of AI techniques that build models by learning from data rather than only hard-coding decision rules | Training pipeline docs; feature definitions; training/validation metrics; data version IDs |
| Generative AI | Systems (often foundation-model based) that generate new content—text, images, audio, code—conditioned on prompts or inputs | Prompt/use policies, grounding/RAG controls, hallucination handling, content filters, third-party model terms |
Classic (non-ML) AI can include expert systems or heavily rule-based optimizers. They may still be AI systems under organizational scope if they meet the engineered-system definition and objectives, but their risk profile differs from deep learning models. Do not assume “no neural network ⇒ out of AIMS scope”—scope is an organizational decision under Clause 4.3, informed by context and interested parties, not by Twitter definitions of AI.
Generative AI audit twist: Outputs can vary for the “same” prompt; evaluation may use human raters, red-team results, and policy-violation rates rather than a single accuracy percentage. Your sampling plan must reflect that uncertainty.
Core ISO/IEC 22989 Terms Auditors Must Own
AI system
An AI system is an engineered system that generates outputs such as content, forecasts, recommendations, or decisions for a set of human-defined objectives. It can operate with varying levels of autonomy. That last phrase is audit gold: autonomy is a spectrum. A human-in-the-loop credit model and a fully automated content filter may both be AI systems, but human oversight design and residual risk differ.
Finding quality tip: Name the system (business capability + technical stack boundary), not a vague product family. “Customer onboarding risk scoring system v3.2 including feature service X and model endpoint Y” is auditable. “The AI” is not.
AI model
An AI model is a component—often mathematical or computational—that produces inferences from inputs based on patterns learned or designed into it. Multiple models can sit inside one AI system (ensemble, routing, guardrail classifier + generator). Auditors must not treat “model” and “system” as interchangeable: system-level controls (use policy, user training, monitoring of business outcomes) may fail even when a single model’s offline metric looks fine.
Machine learning (refined)
Machine learning is the process of optimizing model parameters using data so that performance on a task improves. Related lifecycle language you will hear:
- Supervised learning — labels guide learning (fraud / not fraud).
- Unsupervised learning — structure without labels (clustering).
- Reinforcement learning — agents learn from rewards in an environment.
- Fine-tuning / continued pre-training — adapting a foundation model with organization-specific data.
You are not examined as a research scientist, but you are examined on whether the AIMS identifies which techniques are in use and applies appropriate controls (data quality, evaluation, monitoring).
Dataset; training, validation, and testing data
| Term | Auditor meaning | Why it matters in findings |
|---|---|---|
| Dataset | Organized collection of data used for developing, evaluating, or operating AI | Ownership, consent, quality, bias, retention |
| Training data | Data used to fit / learn the model | Provenance, labeling quality, representativeness, sensitive attributes |
| Validation data | Data used during development to tune hyperparameters / select models | Leakage risk if contaminated by test data |
| Testing data (hold-out / evaluation) | Data reserved to estimate generalization before release | Optimistic metrics if test set is reused for training decisions |
Exam trap: An auditee presents “99% accuracy” with no description of the test set. Under evidence-based auditing, a metric without population definition, date, and dataset version is weak evidence—it may support an observation or a nonconformity against measurement / performance evaluation requirements depending on the criteria you are auditing.
Inference
Inference is the production of an output from a trained model given new input (a credit score, a generated paragraph, a defect probability). Operational controls often fail at inference time: missing input validation, absent confidence thresholds, no logging, or no escalation path when the model is outside its training distribution.
Human oversight
Human oversight means humans can intervene in or supervise AI system behavior according to the defined use—review queues, override rights, kill switches, escalation SLAs, and competence of the overseers. Oversight that exists only on a slide deck is not implemented oversight. Auditors sample records of intervention, not merely policy statements.
Subfields PECB Names Explicitly: Cognitive, Semantic & Soft Computing
Domain 1 asks you to differentiate between various subfields of artificial intelligence, and PECB's knowledge statements name three that almost never appear in machine-learning tutorials. Treat them as vocabulary you must recognize in a question stem, not as things you audit directly.
| Term | Working definition | Typical example | Why an auditor cares |
|---|---|---|---|
| Cognitive computing | Systems that imitate human reasoning to support a decision — combining language understanding, knowledge retrieval, and evidence weighting instead of returning one bare label | A clinical or legal "advisor" that surfaces ranked, cited evidence for a human to judge | The system advises rather than decides, so human oversight (A.9) and information for users (A.8) carry most of the risk |
| Semantic computing | Processing meaning and relationships explicitly — ontologies, knowledge graphs, semantic search, and reasoning over structured meaning | A knowledge graph resolving "AMF", "annual maintenance fee", and "maintenance charge" to one concept | The ontology is itself an AI asset: data provenance and quality (A.7) apply to who curates it and how changes are controlled |
| Soft computing | A family of techniques tolerant of imprecision and partial truth — fuzzy logic, evolutionary and genetic algorithms, probabilistic reasoning, and neural approaches | A fuzzy controller grading risk "high / medium / low" rather than applying a hard numeric threshold | Outputs are approximately correct by design, so verification and validation (A.6.2.4) need defined acceptance bands, not pass/fail assertions |
How these relate to the trio you already know. Machine learning learns a function from data; deep learning uses many-layered neural networks to learn representations; a neural network is the layered, weighted-connection architecture itself. That trio describes how a system learns. Cognitive, semantic, and soft computing describe how a system reasons about meaning and uncertainty. The categories overlap freely — a semantic search product is normally built on deep-learning embeddings, and a cognitive advisory tool may combine a knowledge graph with a large language model.
Exam trap: do not treat these as mutually exclusive boxes, and do not read any of them as a synonym for "AI" in general. A stem describing fuzzy logic handling vague inputs is testing soft computing; one describing an ontology-driven meaning layer is testing semantic computing; one describing an evidence-weighing advisory system for a human decision-maker is testing cognitive computing.
Deterministic Software vs AI Systems
| Dimension | Deterministic traditional software | Many AI / ML systems |
|---|---|---|
| Logic source | Explicit human-written rules and branches | Patterns estimated from data (+ architecture choices) |
| Same input → output | Highly repeatable | May be probabilistic or temperature-dependent; may change after retrain |
| Failure modes | Bugs, misconfiguration, integration errors | Those plus data drift, concept drift, bias amplification, hallucinations, adversarial inputs |
| Verification style | Unit/integration tests against specs | Plus offline evaluation sets, fairness slices, robustness tests, online monitoring |
| Change control | Code releases | Code and data and model weights and prompts/policies |
Critical auditor distinction: A rules engine that always returns the same decision for the same inputs is still software that may be in ISMS scope for security, but if the organization claims it as an AI system—or if it is embedded beside ML components—you must understand how the AIMS has classified it. Misclassification leads to wrong control sets (for example, demanding training-data lineage for pure rules code, or failing to demand it for a neural ranker).
Scenario: Payroll calculation software uses statutory tables hardcoded by developers. Marketing calls a new résumé-screening tool “AI-powered.” Both sit in the same application portfolio. For ISO/IEC 42001, you evaluate whether the résumé screener is identified as an AI system with impact assessment, data controls, and monitoring—while recognizing the payroll engine may be out of AIMS scope if the organization’s scope and definitions exclude it. Do not write a nonconformity that “not all software is managed as AI.” Write findings against defined AI systems in scope and the process for deciding what is in scope.
Why Terminology Matters When Writing Findings
ISO 19011 requires accurate, understandable, and complete reporting. Vague AI language breaks that duty:
- Wrong object of conformity — “The algorithm is biased” without identifying system boundary, population, metric, and requirement clause is not a usable nonconformity.
- Un-auditable corrective action — If you wrote “fix the AI,” the auditee cannot design a specific correction or corrective action.
- Criteria mismatch — Calling missing GPU patching an “AI ethics failure” confuses ISMS technical vulnerability management with AIMS fairness/impact requirements.
- Scope creep or scope escape — Vendors may claim “we only provide a model API, not an AI system.” Under 22989 thinking, the customer’s deployed system (API + prompts + workflow + human review + logging) is often the auditable AI system, while the vendor is a third-party relationship under Annex A.10-type controls.
Finding writing pattern (auditor-ready)
Weak: “AI data is messy.”
Stronger: “For AI system Claims Triage Assistant, the organization could not provide versioned training-data lineage or acceptance criteria for labeling quality for the model version deployed 2026-03-12. This does not meet the organization’s documented data-for-AI control and ISO/IEC 42001 Annex A.7 intent as stated in the Statement of Applicability.”
Notice the strong version names: system, artifact, date, requirement/SoA reference, and objective evidence gap.
Interview discipline
When auditees say “the model is fair,” ask:
- Fair for which groups and metrics?
- Measured on which dataset version?
- Who decided thresholds, and where is that decision recorded?
- What happens when monitoring shows disparity drift after deployment?
Those questions translate 22989 terms into audit trails.
Links Forward in This Study Guide
Later chapters map these terms onto:
- ISO/IEC 42001 normative requirements (impact assessment, operational control, performance evaluation)
- Annex A lifecycle, data, transparency, and third-party controls
- Evidence collection (model cards, lineage, logs) during Stage 2
If Domain 1 vocabulary is shaky, every later domain degrades. Treat 22989 as professional language, not optional theory.
Which ISO/IEC standard is the primary vocabulary reference for AI concepts used across the ISO AI management family, including ISO/IEC 42001?
During an AIMS audit, which statement best distinguishes an AI model from an AI system for finding-writing purposes?
Why should a Lead Auditor treat a single accuracy percentage without dataset version, population, and date as weak audit evidence?
A purely deterministic payroll calculator uses hardcoded statutory tables and no learned model. Marketing also deploys a machine-learning résumé screener. What is the most appropriate auditor stance?
An auditee's risk-scoring engine uses fuzzy logic so that borderline cases receive a graded "medium risk" rather than a hard pass/fail threshold. Which AI subfield does this describe, and what does it imply for verification evidence?