ISO/IEC 42001: The Framework That Moves AI Projects from Pilot to Production

Why pilot projects often stall

Many companies now have an AI pilot project behind them. A chatbot, a document assistant, a model for data analysis. The teams are motivated. Early results are convincing.

And then comes the moment when the pilot is supposed to become a production system. This is exactly where many projects fail. Not because of the technology. But because of missing answers to simple questions.

Who is accountable when the system produces errors? Which risks were actually assessed? Who decides when an update changes the model's behaviour? These questions can be ignored in a pilot project. In production, they cannot.

This is precisely where ISO/IEC 42001:2023 comes in. The standard provides no technology requirements. It provides a structure for accountability.

What ISO/IEC 42001 actually governs

ISO/IEC 42001 is an international management system standard. It describes how an Artificial Intelligence Management System (AIMS) is established, operated, monitored and continuously improved.

An important distinction: the standard does not assess an individual AI model. It assesses the organisational governance of AI as a whole. Much like ISO 27001 does not certify a single IT system, but the security management of an entire organisation.

The standard follows the Plan-Do-Check-Act logic established across ISO management systems. Seven domains form the backbone: context, leadership, planning, support, operation, performance evaluation and improvement.

Two points are central for companies:

• The standard is voluntary. Certification is possible, but not a prerequisite for applying its principles.
• Certification confirms the management system. It does not replace a legal assessment of individual AI applications — for example with regard to the EU AI Act or data protection law.

This distinction matters. ISO/IEC 42001 is no substitute for legal advice. It is a structural framework that systematises governance.

The governance model: who decides what

At the core of every AIMS is a clear role model. The standard does not prescribe org charts. It does require that certain functions are substantively covered. In smaller companies, one person can hold several roles. What matters is that no one is left in doubt about who is responsible for what.

In practice at SMEs, the same pattern shows up again and again: the role of top management is usually clear. The role of AI system ownership is not. No one has an explicit mandate to be accountable for a single system across its entire lifecycle. This gap is exactly what causes problems later, when an incident occurs and no one is responsible.

The operational core process: governing an AI system across its lifecycle

The practically most important part of the standard is the process by which an individual AI system is introduced and operated under control. Eight steps form this process.

Step 1: Record. Every AI system is inventoried. Name, ownership, purpose, models and data used, user groups. Without this entry, the system does not exist from a governance perspective.

Step 2: Determine requirements. Business, technical, legal and contractual requirements are documented. If purpose or accountability is unclear, there is no approval for production use. This single rule prevents a large share of later problems.

Step 3: Assess risks and opportunities. Reliability, information security, transparency, data quality, bias, impact on individuals, and dependencies on external providers. This assessment is not a one-off; it repeats at defined intervals.

Step 4: Assess impact. What does deploying the system mean for affected individuals and groups? This question is often overlooked because it is uncomfortable. But it is a mandatory part of the approval decision.

Step 5: Implement controls. Concrete organisational and technical measures are derived from the risk and impact assessment. Who implements what, by when, with what evidence of effectiveness?

Step 6: Validate and approve. A documented approval by the responsible role — not by coincidence or time pressure.

Step 7: Operate, monitor, change. Material changes to the model, data, provider or deployment context trigger a re-assessment. An AI system is never finally verified.

Step 8: Decommission. The end of a system is planned too: data handling, access termination, retention of evidence.

This process is the real value of the standard. It forces companies to document decisions before a system goes live. Not afterwards.

Evidence and effectiveness: making control visible

Governance that is not documented does not exist when it matters. An AIMS lives on evidence that can be produced when in doubt.

Core artefacts include: the documented scope and AI policy, the AI system inventory, risk and impact assessments, approval and change records, supplier assessments, and a register for incidents and corrective actions.

Effectiveness measurement matters. Examples of meaningful metrics: share of inventoried systems with a clear owner, share of risk assessments updated on time, number and severity of incidents, processing time for corrective actions. Every metric needs a clear definition, a data source and an owner. Blanket targets without reference to your own context are of little use.

For deviations, a systematic approach applies: record, analyse root cause, determine measure, implement, verify effectiveness, update documentation. Critical impacts or uncontrolled risks are escalated to a predefined authority. It is precisely this clarity that many companies lack when an AI system shows unexpected behaviour.

Your own management system — without certification

Full certification to ISO/IEC 42001 is too costly for many SMEs. External audits, extensive documentation, ongoing management reviews. That is out of proportion for a company with three or four AI applications.

Which is exactly why I use the standard differently in practice. Not as a certification target, but as a blueprint. The structure of the standard — governance, risk assessment, approval process, evidence trail — can be scaled down and tailored to your own organisation without losing substance.

Concretely: a company defines a short AI policy, determines who is accountable for which AI system, keeps a simple inventory of deployed systems, assesses risks using a fixed, repeatable scheme, and documents approvals in writing. No hundred-page manual. A few clear templates, applied consistently.

The effect is nevertheless the same as with a full implementation: risks are assessed transparently, accountabilities are clarified, decisions are traceable. That is exactly what a company needs to move from a single pilot project to scalable, responsible AI deployment.

The ISO standard is therefore not a bureaucratic instrument. It is a proven thinking framework you can put to work for yourself — even without a seal.