Should You Adopt ISO 42001 or ISO 5338?
- Raimund Laqua
- 19 hours ago
- 3 min read
ISO 42001 has quickly become a standard organizations reach for when they want to take AI seriously. It is the first international management system standard for artificial intelligence — a framework for governing AI across an organization, built in the same family as ISO 9001 for quality and ISO 27001 for information security. It is a genuine step forward, and for many businesses it can help.
But before adding it to the shelf alongside your other management systems, it is worth asking one question: does your organization use AI, or does it develop AI? The answer decides whether 42001 is the right standard for your organization.
Start with use. ISO 42001 is a management system standard. It helps you account for the AI you operate, govern how it is used, and assign responsibility for that use. If your business adopts AI built by others, this is exactly the work that needs doing, and 42001 is a reasonable choice.
Developing AI is a different kind of work. When you design, build, or substantially modify an AI system, your obligation is no longer to manage its use — it is to engineer it. And engineering is not a set of internal management controls. It is professional practice: a discipline held to a standard outside the organization, carried out by practitioners accountable for the result.
This is the line ISO 42001 anticipates but does not cross. It governs the controls an organization runs for itself, and for the engineering it points outward — to ISO 5338.
ISO 5338 defines the lifecycle processes for building an AI system: the engineering work of data and model development, verification and validation, deployment, and the ongoing monitoring a system needs once it is operating and continues to change. It builds on the established engineering standards for systems and software, and adds what is particular to AI. This is the engineering standard for AI. It is not part of 42001, and 42001 cannot stand in for it.
And this is not only about building from scratch. If you fine-tune a model, add guardrails, chain components, or integrate AI into a larger system, you have made engineering decisions, and the results are yours to stand behind. The discipline applies whether you create a system or assemble it from parts.
Regulation is beginning to make this explicit. Under the EU AI Act, AI placed in high-risk settings — including as a safety component in regulated operations — must be designed and developed to achieve accuracy, robustness, and security, and to hold those qualities throughout its life. Those are properties built into a system through engineering. A chemical plant cannot satisfy a safety case by reporting that safety happened; it satisfies it by engineering the system to be safe. When AI carries real hazard, the law is naming what engineering has always required — engineered systems.
None of this counts against ISO 42001. It is about matching the standard to the work. Manage the AI you use. Engineer the AI you build.
One is internal management. The other is professional practice — held to a standard, carried by people accountable for what they build. Building AI requires the second, and most organizations have only set up the first.
Closing that gap is increasingly what I am asked to help with. This work brings together three disciplines: engineering methodology, how AI systems are designed and built for the enterprise; project assurance, independent engineering judgment over the build; and AI compliance, obligations engineered into the system from the design stage rather than bolted on after.
If you are developing your own AI systems — from scratch or on procured services — it is worth asking whether that work is being done as engineering, or simply handed to an IT or data team to develop. The two are not the same. The difference decides which standards apply to your work, and whether the system you build can be trusted.
If you are not sure which standard to adopt, that is the conversation to have:
