Artificial intelligence management

STANDARD SUMMARY

The starting point

Give AI decisions an accountable owner, a defined purpose and evidence that can be reviewed. ISO/IEC 42001 specifies requirements for an artificial intelligence management system, commonly called an AIMS.

It applies to organisations developing, providing or using AI-based products and services. This guide offers practical implementation questions without treating certification as proof that every model is safe, accurate, lawful or suitable for every use.

Who it is for. Organisations developing, providing or using AI, from software businesses to professional practices and public bodies adopting AI-enabled services.

Define the AI activities you are managing

ISO/IEC 42001 provides a framework for managing risks and opportunities associated with the responsible development, provision or use of AI. The focus is the organisation’s management system.

Our recommended first step is an inventory of actual AI uses, including purchased services, embedded features and internal experiments that affect work. Name the business purpose, accountable owner, users, affected people, supplier and lifecycle stage. Record what is known and what still needs investigation. A short accurate inventory is more useful than an impressive catalogue that cannot distinguish a live service from an abandoned trial.

Clarify roles and decision authority

An organisation’s role can differ between AI activities. It may build one system, configure another supplier’s service and simply use a third. A clear scope makes those differences visible.

For implementation, identify who can approve a use case, change its purpose, accept residual risk, release a new version and suspend operation. Give review responsibilities to people who understand both the application and its context. Do not assign all accountability to a model supplier when the organisation controls how the output affects customers, staff or other people. Keep the decision record connected to the inventory entry.

Assess risks and effects on people

The AIMS should provide a structured way to consider AI risks and the effects associated with AI activities. Use the standard to determine the organisation’s required assessment processes and controls.

Our suggested assessment begins with the intended use and the consequences of a wrong, misleading, unavailable or misused output. Consider who could be affected and how the harm would be noticed. Distinguish a technical limitation from its operational consequence. A model performance figure needs context: the test population, task, conditions and decision threshold may determine whether it is meaningful for the proposed use.

Where personal information is involved, coordinate with privacy and information security work. Reuse factual evidence while retaining the different questions each assessment must answer. Record uncertainties explicitly and assign the work needed to reduce them. A high confidence label on a dashboard should not substitute for a documented decision.

Make lifecycle decisions reviewable

Our practical recommendation is to define review points appropriate to the organisation’s role: selection or design, testing, approval, deployment, monitoring, significant change and retirement. The controls needed for an internal drafting tool will differ from those for a service that materially affects an individual’s opportunities.

At each review point, identify the evidence required and the person authorised to decide. Evidence may include evaluation results, dataset provenance information, supplier documentation, access arrangements, user instructions or monitoring plans. These are examples rather than a mandatory universal document list. Where a supplier changes a model or service without your direct control, agree how you will learn about the change and reassess the affected use.

Design human oversight around real work

A statement that a human remains involved is incomplete unless the person has time, competence, information and authority to intervene. Our recommended review asks what the human can see, which warning signs they can identify and what happens when they disagree with the output.

Test the process with realistic exceptions. Can the user decline a result, escalate a concern or pause the activity? Will the surrounding workflow pressure them to accept it anyway? Record what those exercises reveal and change the operating design where necessary. Avoid promising that a review step eliminates all risk; its effectiveness needs evidence in the actual context.

Monitor performance and keep claims precise

Suggested monitoring combines relevant technical measures with operational outcomes, incidents, complaints and changes in use. Define when a result requires investigation, restriction or reassessment. Keep enough context to distinguish a changed system from a changed user population or task.

Use internal audits and management review to test whether the organisation follows its own approval and monitoring arrangements. Confirm the certification scope before making a public claim. ISO/IEC 42001 certification does not itself establish compliance with every AI law, certify the safety of each individual model or approve every use of a product. Any claim about a particular legal obligation or system performance needs its own basis.

IMPLEMENTATION ADVICE

Evidence to prepare

• An AI inventory with purposes, owners, roles, users and lifecycle status.
• A defined AIMS scope and decision authority for approvals, changes and suspension.
• Risk and impact assessment records with assumptions, affected groups and treatment decisions.
• Evaluation evidence appropriate to the use case and meaningful acceptance criteria.
• Supplier responsibilities, change arrangements and relevant monitoring information.
• Human oversight procedures tested through realistic scenarios.
• Incident learning, internal audit findings and management decisions that improve the system.

Common pitfalls

• Equating a management system certificate with a guarantee about every AI output.
• Using a generic risk register that does not distinguish different use cases and affected people.
• Relying on human review without checking whether reviewers can meaningfully intervene.
• Assuming a supplier’s assurance removes the organisation’s responsibility for its own use.
• Claiming universal compliance with AI legislation from certification alone.

FICTIONAL WORKED EXAMPLE

Fictional example: reviewing a supplier's AI model change

A fictional professional-services team uses an AI drafting tool whose supplier changes the underlying model. This educational scenario describes no real product or client engagement.

An AIMS review does not guarantee accurate outputs or determine compliance with every AI-related law. The scenario is not a model-safety certification.

Related guidance and practical next steps