A usable sequence for building an AI management system that governs both AI products and internal use.
1. Define the AI management system boundary
ISO/IEC 42001:2023 specifies requirements for an AI management system, or AIMS, for organizations developing, providing, or using AI systems. First decide which entities, activities, products, internal tools, and outsourced AI services sit inside the proposed scope. Name interfaces and dependencies that cross the boundary. A boundary that ignores employee AI use or vendor features may omit material risk.
Identify interested parties and their expectations: users, customers, workers, suppliers, leadership, and relevant authorities. The output is a scope statement and an owner for each important activity. Do not start with a generic policy template before the actual AI footprint is known.
2. Inventory AI uses and assess impacts
Record each AI system’s purpose, provider, data, users, output, level of human oversight, and deployment context. Include experiments, embedded vendor functions, and internal productivity tools where they fall within scope. Risk and impact assessment should consider what can go wrong for the organization and affected people, along with the opportunity the system is intended to create.
Set criteria for escalation: sensitive data, consequential decisions, limited explainability, exposure to the public, or reliance on a critical third party may warrant deeper review. Preserve the rationale for risk treatment and for accepting residual risk. The inventory and assessment must be revisited when use or context changes.
3. Turn decisions into lifecycle controls
Set an AI policy and objectives that leaders can review. Assign authority across product, security, data, legal, procurement, and operations. Define checkpoints for selection, design, testing, deployment, monitoring, change, and retirement. Specify what must be recorded at each point: approvals, evaluation results, incidents, limitations, supplier commitments, and human intervention decisions.
Control design should fit the role the organization plays. A model developer may need different evidence from a business that uses a third-party system. Security controls inherited from ISO/IEC 27001 can support the AIMS, but AI-specific impact, transparency, and oversight decisions still need explicit ownership.
4. Operate, review, and improve
Put the controls into normal delivery and procurement workflows. Monitor systems against their intended use and record changes, incidents, exceptions, and corrective actions. Establish internal audit and management review so leaders can see whether the AIMS meets its objectives and where decisions need to change.
If independent certification is a goal, select a competent certification body and confirm the scope and assessment route with it. Advisory support can prepare the management system and evidence; the independent body makes any certification decision. Certification does not remove the need to assess applicable law or a particular AI system’s risks.
Put it into practice
- Write a scope statement that identifies AI products, internal uses, suppliers, and exclusions.
- Create an AI inventory with purpose, owner, data, outputs, and affected groups.
- Set risk and impact criteria before assessing individual systems.
- Insert approval, testing, monitoring, and change records into the delivery lifecycle.
- Schedule internal audit and management review as recurring work.
Primary sources
- ISO: ISO/IEC 42001 AI management systems
- ISO: AI management systems explained
- ISO: ISO/IEC 27001 information security management
Normstone resources are general information, not legal advice or an independent assessment.