The certification trap: Why ISO 42001 won't save you from the EU AI Act

29 October 2026

Emma Di iorio | CEO & Co-founder, Spriggun

In a recent conversation, an organisation told me it would align its AI governance with ISO standards rather than the EU AI Act. It had already established that it was caught by the Act. When I asked what that looked like in practice, it considered checking whether a vendor held an ISO certification to be sufficient.

The position is not unusual, but it is also concerning. The Act is not a technical standard, but a regulation concerned with risk of harm to people AI systems affect. Certification addresses management systems; the Act addresses the risk of, and what happens when those systems cause real damage. An organisation that treats the two as interchangeable has made a strategic miscalculation; particularly where the decision to pursue certification was taken by a technology leader that does not shoulder the regulatory liability.

Certificate coverage

ISO/IEC 42001 certifies that the organisation has established and maintains one or more AI management systems: that policies exist, roles are defined, a risk assessment methodology is in place, and internal audit and management reviews happen. It does not certify that those policies are sufficient to meet any external regulation, or that the resulting risk of harm is manageable for the specific business and sector.

An organisation can hold ISO/IEC 42001 with no AI inventory, no prohibited practices review, no fundamental rights impact assessment, and no record of the data its AI systems were trained on. A regulator will not be moved by the certificate; it will ask for evidence that sufficient steps were taken to prevent harm, against the Act's requirements. The certificate generates neither the factual situation needed, nor the supporting evidence.

The NIST AI Risk Management Framework has genuine value for the risk discipline, with its govern, map, measure, and manage approach; it is not mapped to the EU AI Act and does not meet its requirements.

Certification also runs on a three-year audit cycle. The Act's obligations are continuous: ongoing risk management, post-market monitoring, and transparency requirements that shift as use cases evolve. A system used for candidate screening today may be applied to performance review tomorrow; the risk classification and obligations shift with the use. A three-year snapshot does not meet a continuous obligation.

We have been here before: readiness was promised and bought ahead of GDPR, and the promises fell away once enforcement began. With AI, the risk is greater. A certificate presented as evidence of regulatory compliance is a liability amplifier: a discoverable record that the organisation knew the obligation existed, invested in something that looked like compliance, and did not meet minimum requirements. This is riskier than an openly acknowledged gap being steadily addressed; it produces only false confidence.

Who is deciding this?

In most organisations, the decision to pursue AI certification is not taken at board level. A technology leader recommends it; procurement processes it; the board is told it is handled. The technology leader carries delivery risk, not regulatory liability under the Act; when the position unravels, the mess falls on the legal team and the general counsel, and ultimately, accountability falls on the board. The board imports a risk appetite it did not examine or agree to with its eyes open.

The Act defines distinct roles in the AI supply chain: provider, deployer, and others; each with its own obligations. A vendor's certification covers the vendor's management system; it does not discharge deployer obligations, and one organisation meeting its requirements does not mean the other meets the Act's requirements for its own role. What the deployer does with the model, the data it feeds in, and the decisions it acts on remain the deployer's responsibility; contractual indemnity is not evidence of compliance. Relying on an indemnity following a crisis event does not help much in the context of a hit to share price and reputational damage. The safety evaluation breaches disclosed in mid-2026 underscores the point: three frontier labs discovered that their AI models had compromised external systems during cybersecurity testing by a shared vendor. Each lab pointed to the vendor; the vendor pointed back. Outsourcing AI does not lead to outsourced accountability.

Board action

The argument that the organisation should wait for further guidance before acting is an undue delay dressed as a necessity. Prohibited practices, AI literacy, and transparency obligations are already in force. The classification framework and the role definitions are in the text; almost all of the work can be done. Knowing which AI systems the organisation has, and what role it plays for each, is not dependent on further external information, and is the first, sometimes painful, start.

The Act is interested in risk of harm, not good intentions. Fines for infringement of the prohibited practices alone run to €35 million or 7% of global annual turnover. The revised Product Liability Directive brings software and AI within strict product liability for the first time; non-compliance with the Act is evidence of fault in civil claims. A board that treats administrative fines as the ceiling of its exposure is not considering the risk in the whole, including reputational risk.

Shadow AI is the fastest-growing source of exposure: AI systems the organisation does not know it has. A department trialling a free model on customer data; someone using their company card for a cheap product (meaning their data is the product). If the organisation does not know what AI it is using, it is not meeting the Minimal Defensible Position. The inventory is not a technology artefact, but a governance baseline, without which you are building on quicksand.

AI literacy, already a live obligation, is the second gap most boards have not looked at closely enough. This is not a half-hour e-learning module. The aim is ongoing fluency: knowing when to trust an AI output; understanding what decisions are delegated to a system; recognising when a call exceeds the caller's remit. That fluency serves the Act and the organisation; people who do not know how to use their tools cannot do the job, and will not be comfortable trying. Without it, human-in-the-loop oversight is a legal fiction; operators rubber-stamp outputs rather than exercise genuine judgement, much as approval fatigue plays out in cyber security. A regulator will ask whether the human had the capability to override the system, not whether a human was sitting in the chair.

The Act does not stand alone

The Act adds to the patchwork of regulation. Data protection, fundamental rights, intellectual property, and consumer protection obligations all continue to apply. An AI-driven candidate screening tool, for instance, activates the Act's high-risk classification; the GDPR; and equalities legislation.

Compliance and enforcement vary across Member States, without a GDPR-style one-stop-shop mechanism. Meeting the Act's requirements establishes the bare floor of compliance; the Minimal Defensible Position. Organisations outside the EU are not insulated; the Act follows the impact of the technology, not the location of incorporation.

Where standards help

Standards have a clear place, once the minimums are in place. The clearest way to explain it: the EU AI Act is the boss; it sets what has to be achieved. ISO/IEC 42001 and the NIST AI RMF are the implementation team: both help operationalise parts of what the Act requires; neither sets the requirements. The OECD and UN principles sit above the operational detail: the direction to act responsibly, whether or not a regulator is watching. None of these instruments can shield leaders that have not met the Minimal Defensible Position.

The first harmonised standard, EN 18286, was cited in the Official Journal on 14 October 2026, giving a presumption of conformity for the quality management system requirement; that is one requirement among many. ISO/IEC 42001 gives no presumption of conformity with the Act at all. The starting point is what the Act requires; standards support specific elements of that, not replace the exercise.

Towards Minimal Defensible Position

The starting point is what we call the Minimal Defensible Position: meeting the minimum requirements of the legislation the organisation is subject to, in a form that withstands regulatory scrutiny today, while the wider programme matures. It is directional; organisations work towards it. Minimal does not mean light; it means effort and resources go first to what the organisation actually has to meet.

For an organisation caught by the Act, that means scoping against the Act itself: which systems are in scope; what role the organisation plays for each; which obligations already apply. That scoping depends on the core disciplines: Know Your Data and Know Your AI (KYData and KYAI). Standards come in once that picture exists. Taken the other way round, certification spend ends up pointed at the wrong requirements, with no return on investment against the actual regulatory exposure. Governance is business, not a separate function; where it sits outside the strategy, it is decoration.

Board decisions

The board must define the standards of success and rigorously oversee delivery. That requires a named executive with the budget, the authority, and the mandate to drive the work; a committee does not equal accountability. Boards that passively accept standard certifications without scrutinising them against the mechanics of the Act are quietly accumulating compliance debt: the widening gap between what has been built and what regulation requires, growing more costly as enforcement matures. Without genuine executive ownership, a funded roadmap, and governance embedded in business strategy, an AI compliance programme is merely expensive decoration.

To protect the organisation, boards must have evidence, not passive assurance, in response to three critical questions:

• Scope: Is the organisation caught by the Act? This includes a comprehensive inventory of systems in scope and the regulatory role for each. Relying on a vendor's certification rather than the Act's criteria is a non-answer. If open-source models pulled in by engineering teams are missing, the inventory is blind to actual risk exposure.

• Evidence: Can the executive produce verifiable proof of compliance today? While the board does not review granular documentation, it must verify that the capability to produce it exists. Evidence must be mapped to the Act's requirements: data lineage, impact assessments, and human override capability. A certificate proves a process was purchased, but a regulator will ask whether the governance framework actively prevents real-world harm.

• Authority: Who owns this, and what power do they carry? This is not a passive name on a governance chart. It requires a designated executive with the budget, the direct reporting line, and the explicit mandate to halt a deployment if the risk of harm outweighs the business benefit.

A certificate is not a shield against harm, liability, or operational failure. Frameworks make a programme easier to manage, but do not replace legal requirements. Begin by clarifying what systems are in use, and what outcomes they produce. Without this full visibility, managing risk is impossible.

Emma Di Iorio is Co-Founder and CEO of Spriggun, a UK-based RegTech and AI governance advisory firm. A qualified solicitor with senior in-house and advisory experience, she writes and speaks internationally on AI, data, privacy, and web compliance.

Not sure if this is for you, find out more about: