ISO/IEC 42001: Why an AI Policy Alone Is Not Enough

Questions like these reveal whether AI governance works in day-to-day operations. Rules alone are not enough. What is needed are clear lines of responsibility, transparent decisions, and processes that do not end with the approval of a system. ISO/IEC 42001 provides an internationally recognized framework for this. It considers not only individual AI systems but also the organization behind them: How are AI applications selected, evaluated, monitored, and improved? And how can this be integrated with existing processes and the requirements of the AI Act?

AI rarely enters an organization as a single, centrally managed large-scale project. It often begins in an unspectacular way: as a new feature in existing software, as an external service, as a pilot project in a department, or as a tool that employees have long been using. Governance structures often fail to keep pace with this development.

A guideline provides direction. However, it does not yet resolve the organizational issues that hold up AI projects in practice:

• Who decides whether a use case is approved?
• Who assesses professional, legal, and technical risks?
• When should data protection, information security, procurement, or employee representatives be involved?
• After the system is implemented, how will it be verified that it continues to operate reliably?
• How are changes, complaints, and incidents handled?

If these questions remain unanswered, the guideline will have little effect. In the worst-case scenario, departments will use new tools without involving the appropriate authorities. At the other extreme, every decision will end up in the hands of just a few central figures. Neither approach will work in the long run.

ISO/IEC 42001:2023 is the international standard for Artificial Intelligence Management Systems (AIMS). It is intended for organizations that develop, deploy, or use AI systems, regardless of size, industry, or legal form. The standard is therefore relevant not only to technology providers but also to government agencies, consulting firms, industrial companies, and nonprofit organizations.

The basic idea is pragmatic: Responsible AI must not depend on whether a project team happens to consider all relevant questions. Responsibilities, reviews, and documentation must be permanently embedded within the organization.

To this end, the standard combines areas that are often handled separately in practice:

• The organization’s goals and guidelines,
• Roles, responsibilities, and decision-making authority,
• Assessment of risks and impacts,
• Guidelines for procurement, development, and use,
• Skills, documentation, and communication, as well as
• Monitoring, internal evaluation, and continuous improvement.

The main chapters follow the harmonized structure of modern ISO management system standards. Anyone already working with ISO 9001 or ISO/IEC 27001 is familiar with the basic framework: organizational context, leadership, planning, support, operations, performance evaluation, and improvement.

The standard does not prescribe the same process for every organization. It requires organizations to determine their own context and derive appropriate measures based on that context. An internal tool for summarizing non-critical texts therefore requires a different level of scrutiny than a system that pre-screens job applications or prepares decisions regarding public services.

Appendix A is normative and contains reference objectives and reference controls. Among other things, they address AI-related guidelines, internal responsibilities, resources, impact assessments, the lifecycle of AI systems, data, and relationships with customers and external providers. Appendices B through D are informative. They explain the controls, describe possible organizational objectives and sources of risk, and classify the application of the standard into different areas and domains.

The reference controls are not a checklist that must be completed in full and without modification. The organization determines which controls are necessary based on its scope and risks, and documents this selection in a statement of applicability. This helps avoid both blanket overregulation and unjustified gaps.

Even with traditional software, responsibility does not end with release. This point is particularly important when it comes to AI: models, data, provider services, and usage patterns can change. For example, an external service may replace its model, enable new features, or use different data for processing. The original assessment may then no longer be accurate.

An AI management system must therefore establish procedures for evaluating changes, monitoring performance, reporting incidents, and decommissioning systems. For external AI services, this also includes vendor evaluation, contract drafting, and ongoing monitoring. The organization may not control the model itself; nevertheless, it remains responsible for the conditions under which it is used.

Documentation is not just for the next audit. It must later make it possible to trace why a system was implemented, what risks were known, what measures were decided upon, and who made the decision. The most reliable evidence is that which is generated directly within existing processes—such as procurement, approval, product documentation, risk registers, and change management.

There are numerous overlaps between ISO/IEC 42001 and the AI Act, such as in risk management, data, documentation, human oversight, and monitoring. Nevertheless, they serve different functions.

The AI Act is directly applicable EU law. The specific obligations that apply depend primarily on the organization’s role and the classification of the respective AI system. Article 17 requires providers of high-risk AI systems to have a documented quality management system. Among other things, it must cover procedures for regulatory compliance, development and testing, data and risk management, post-market monitoring, and the handling of serious incidents.

Important for context: The AI Act is generally applicable as of August 2, 2026. However, Regulation (EU) 2026/1744 has amended the timeline for the key provisions regarding high-risk AI: For systems covered by Article 6(2) and Annex III, the relevant sections apply as of December 2, 2027; for systems covered by Article 6(1) and Annex I, the relevant sections apply as of August 2, 2028. These deadlines are law and are set forth in Article 113 of the amended AI Act.

ISO/IEC 42001, on the other hand, takes an organization-wide approach and is not limited to high-risk AI. It can provide a framework upon which individual legal obligations are based. However, ISO/IEC 42001 certification does not replace the legal review of a specific use case or a required conformity assessment. Nor does it prove, across the board, that all requirements of the AI Act are met.

In practice, this means that an AIMS can specify who is responsible for the legal classification, what documentation is required, and how compliance is monitored. However, whether a specific system meets the relevant regulations must still be assessed separately.

You don’t have to start with a certification project. It often makes more sense to first gain clarity on actual AI usage and test the planned process in a manageable area.

1. Inventorying AI Applications: Consider not only officially procured systems, but also AI capabilities of existing software, pilot projects, and services used on a decentralized basis. Useful minimum information includes purpose, area of responsibility, provider, data used, affected individuals, and approval status.
2. Prioritize use cases: Assess systems that affect people, involve sensitive data, impact critical business decisions, or provide public services first. Simple internal tools do not require the same level of scrutiny as critical applications.
3. Define Responsibilities: Clarify who is technically responsible, who assesses risks, who grants approval, and who monitors subsequent use. For contentious or high-risk cases, a clear escalation process is required.
4. Complement existing processes: Procurement, data protection reviews, information security, product development, and quality and contract management usually provide suitable points of integration. AI-specific issues belong where the relevant decisions are made anyway.
5. Test it using a real-world case: A pilot project reveals more quickly than an abstract framework which roles are missing, what documentation is needed, and where the process is unnecessarily cumbersome.

Organizations with established quality or information security management systems do not have to start from scratch. Risk and approval procedures, supplier management, training, and internal audits can often be reused.

However, simply renaming existing controls is not enough. An information security audit primarily examines whether data and systems are protected. With AI, other questions come into play:

• How reliable are the figures?
• What are the possible consequences of a mistake?
• Can people be disadvantaged?
• Does the planned human oversight work even under time pressure and in real-world workflows?

The common ISO structure facilitates this integration. Therefore, it is not necessarily required to establish a new committee for every AI decision. Often, it is sufficient to supplement existing processes with clear AI-specific checkpoints and escalation procedures.

ISO/IEC 42001 contains certifiable requirements. ISO/IEC 42006:2025 supplements these with specific requirements for bodies that audit and certify AI management systems; it builds upon ISO/IEC 17021-1. Certification may be beneficial if customers, clients, or solicitations require independent evidence of AI governance.

Nevertheless, it should not be an end in itself. A management system that is formally complete but circumvented in day-to-day operations offers little protection. The standard can be used as a frame of reference even without the immediate intention of seeking certification. The key factor remains whether the defined processes are actually being implemented.

In digital projects, technical capabilities, business requirements, and legal protection interests intersect directly. Particularly in government, the judiciary, and other regulated sectors, it is not enough for an AI system to save time or deliver good results in testing. Equally important is the data on which it operates, how its results are verified, and what level of responsibility remains with humans.

In digital projects, it regularly becomes apparent that governance cannot be added as an additional legal review only shortly before implementation. Issues related to data, responsibilities, oversight, and documentation already influence the design phase, the selection of technical solutions, and the structuring of processes. ISO/IEC 42001 provides a common language for business units, IT, management, data protection, information security, and compliance.

An AI policy remains important: it clarifies expectations and sets boundaries. However, it will only be effective once it is determined who will review new use cases, document decisions, and monitor ongoing use.

ISO/IEC 42001 provides a framework specifically for this purpose. It integrates policies, risk assessments, approvals, training, and controls into a single management system. While this does not automatically demonstrate compliance with the AI Act, it facilitates the ongoing implementation of legal and organizational requirements.

The first step, therefore, is usually not certification, but an honest assessment: Where is AI already being used, for what purposes—and who is responsible?

ISO/IEC 42001 – An AI guideline alone is not enough