You often hear the line: “Let’s get ISO 42001 and we’re sorted for the AI Act.” It’s wrong. But the conclusion many people draw from it — then let’s wait for the right standard — is even more wrong. And if you build products with AI inside them, it costs you twice: once on the legal side, and once on what actually matters to you, namely the product.
What ISO 42001 does not give you
Let’s start with the legal side, because it’s clear-cut.
The presumption of conformity with the AI Act — that mechanism whereby a system is presumed compliant if it follows a recognized standard — arises only from harmonized standards published in the Official Journal of the Union (Article 40). ISO/IEC 42001 is not one of these. It is an international standard, valuable and widely recognized, but it is not a European harmonized standard born of a Commission mandate.
The standard that will grant that presumption, on the management-system side, is prEN 18286, under development at CEN-CENELEC. It is still being drafted and is evolving continuously — we’ll come back to it in a dedicated article.
Translated: today an ISO 42001 certificate strengthens your position, it is not a legal shield. Anyone selling it to you as a shield either doesn’t know that, or is hoping you don’t.
Why waiting is the mistake
Here’s where the flawed reasoning kicks in: if 42001 doesn’t make me compliant, I’ll wait for the harmonized standard. Two reasons why that makes no sense.
The first is about positioning. prEN 18286 doesn’t come out of nowhere: it rests on the controls of 42001. Anyone who structures their governance on 42001 today won’t throw the work away when the standard arrives — they’ll reuse it. Anyone who waits will start from zero exactly when the timeline gets tight.
The second, and more important: the value of 42001 isn’t that piece of legal paper. It’s operational, and it’s available now.
I see it in very concrete terms. For one client — a large services company — we analyzed over eighty AI use cases before touching any certification: technical feasibility, data actually available, process implications, cost of implementation and maintenance, expected return. And we didn’t measure the return only in hours saved — the most common mistake — but along four axes: hours, efficiency in responding to the end customer, perceived image, and the risk the solution itself introduces.
That analysis became the starting point of the 42001 journey, not a consequence of it. No one waits for a harmonized standard to decide, with this level of clarity, where to put AI and, above all, where not to.
Data governance is a product decision
And here I get to the point that, if you build products, should interest you more than any legal discussion.
Among the controls in 42001, the most underrated and the most decisive are those on datasets: provenance, quality, preparation, traceability of the data. They look like compliance box-ticking. They are not.
In a medical startup I work with, we’re structuring the acquisition of datasets so they can train models for medical diagnostic purposes. Here 42001 serves a very practical end: governing and controlling the data so it can be used inside a certification pathway. Put the other way around — which is the way it should be put: if you manage that data badly, you risk not being able to use it at all. A proprietary dataset without traced provenance and without documented quality control is a dataset that, downstream, you cannot defend before a certification body. You spent money to collect it, and you can’t build the product’s certification on top of it.
This doesn’t apply only in the medical field. It applies to every industrial project built on a proprietary dataset: a predictive-maintenance model trained on a machine’s data is worth exactly as much as the discipline with which that data was collected and traced. Data governance isn’t the paper you show the auditor. It’s what makes the model defensible and the product certifiable — or what fails to.
And it plugs into what you already do
If you design industrial products, you probably already have — or are building — a secure development discipline under IEC 62443. 42001 doesn’t replace it: it grafts onto it. The 62443 ensures the “box” and its communication channels are secure; the 42001 ensures the “brain” inside the box operates transparently, under control, and without degrading invisibly.
The most immediate point of attachment is part 4-1, on the secure development lifecycle: training, testing and validation of the AI model are not a separate track, they go inside the same lifecycle you use to develop the rest of the product. But the integration runs deeper. One example makes it concrete: an adversarial attack on a model driving an actuator isn’t just an “AI quality” problem — it can translate into physical damage. And that’s why AI impact assessments (42001) have to become OT security requirements (62443): the risk is no longer merely a matter of software.
This is the difference between doing 42001 as an isolated compliance exercise and doing it as part of how you build. The first way produces paper. The second improves — and secures — the product.
Where to start
Three moves, valid whatever the regulatory timeline does:
- Take stock of your AI use cases — those in your processes and those inside the product, official and shadow. You can’t govern what you haven’t mapped.
- Decide who owns AI governance: R&D, IT or the business. The answer “everyone” means no one.
- Treat data controls as part of the 62443/27001 lifecycle you already have, not as a new silo.
None of these requires waiting for prEN 18286. All of them put you ready and ahead when it arrives.
ISO 42001 is not the legal shield you were told about. It’s the discipline that moves you forward — on the product, even before compliance. And it starts with understanding where you’re really exposed.
If you want a concrete map of your exposure, the Regulatory Spark is a 45-minute call: we map your AI use cases, product included, and you leave with a written summary and a direction. No fluff.