ISO/IEC 42001 FAQ Generative AI

Treat each generative AI use as a system in context, not as a model name or vendor account. Document the intended purpose, users and affected parties, prohibited or foreseeable misuse, decisions influenced by outputs, deployment environment, model and service versions, system prompts, retrieval sources, connected tools, input and output data, and supplier-imposed limits.

Classify the relationship before selecting controls. An organisation that trains or fine-tunes a model controls different lifecycle evidence from one that calls an external API, adds retrieval and tools to a supplied model, enables a feature inside business software, or permits staff to use a public service. For each case, record which controls the organisation operates, which evidence the supplier provides, which evidence is unavailable, and whether the remaining limitation is accepted, mitigated, or blocks the use.

Use the AI system impact assessment and risk assessment to select evaluation and oversight. Examples can include testing grounded answers against approved sources for a retrieval assistant, checking whether a coding assistant introduces insecure dependencies, testing demographic and language performance for a customer service tool, and preventing a content generator from exposing confidential prompts or producing prohibited impersonation. These are examples; the intended use and affected parties determine the actual tests.

Generative AI is not a separate ISO/IEC 42001 certification class, and it is not automatically a general-purpose AI model under the EU AI Act. Where EU law applies, assess the model, downstream system, operator role, and Chapter V or other obligations separately. ISO/IEC 42001:2023 is voluntary unless a contract, policy, or law requires its use. The standard has no universal statutory implementation deadline.

Evidence should match the selected controls and the released use case. Keep an inventory record; owner and approved users; model, service, prompt, retrieval, data, tool, and hosting versions; supplier documentation and accepted limitations; risk and impact assessments; test sets and acceptance criteria; release decision; user instructions; human-review samples; event logs; monitoring results; complaints and incidents; provider change notices; and reassessment decisions.

Preserve enough detail to reproduce the conclusion. Record the evaluation date, system configuration, sample source and limits, relevant user or affected group, metric and threshold, result, reviewer, exceptions, and approval. A vendor benchmark or model card may support the record but does not prove that the configured application works for the organisation's data, users, tools, and decisions.

Assign a business owner for the use and its outcomes, technical owners for integration and monitoring, data and security owners where relevant, procurement for supplier commitments, and an authority able to restrict, suspend, or retire the use when controls fail.

The designated management authority approves the risk-treatment plan and residual AI risk. Legal, privacy, security, safety, employment, intellectual-property, records, or sector owners should decide issues within their own authority; AIMS approval cannot waive a binding requirement or replace those decisions.

For supplier services, assign who reviews terms and documentation, approves data sent to the service, receives model or policy changes, controls accounts and integrations, monitors the configured use, reports incidents, and executes exit or data-return arrangements.

Review at planned intervals and when the model or service version, terms, data sources, system prompt, retrieval design, tools, moderation, intended use, user population, deployment context, output reliance, supplier evidence, incidents, or applicable requirements change.

A supplier's model update can change behaviour without an application-code release. Route provider notices, silent evaluation drift, new limitations, changed usage, and unexpected tool behaviour through the same risk, impact, approval, and monitoring controls as an internal significant change.

Reassess before a pilot becomes production, a low-consequence drafting aid begins influencing decisions about people, an internal tool becomes customer-facing, new data categories are entered, or a component gains access to external actions. Restrict or retire the use when required evidence is unavailable or residual risk no longer meets the approved criteria.