We’ve been helping a SaaS client establish a robust AI governance program, including ISO 42001 certification and NIST AI Risk Management Framework compliance. Then they landed a new enterprise customer that attached an EU AI Act requirement to their contract.

Because their product is used in higher education to support student decision-making, it falls squarely into Annex III high-risk territory. Fortunately, thanks to the EU’s Digital Omnibus agreement, the high-risk obligations don’t apply until 2 December 2027.

So, they don’t need to be high-risk compliant on day one. But it would have been a mistake to architect as if those obligations would never come. The goal we set was to meet the new client’s EU AI Act expectations now and build the program so that flipping on full high-risk rigor in 2027 is a configuration change, not a rebuild.

ISO 42001 as the foundation

ISO 42001 provides our client with a real AI management system: policies, defined roles, risk and impact assessment processes, Annex A controls, and a continual-improvement loop. NIST AI RMF layers on a shared language for Govern, Map, Measure, and Manage. Both are genuinely valuable, and I’d recommend starting any AI governance program with one, the other, or both.

ISO 42001 and the EU AI Act are both fundamentally about good processes, though the latter is far more prescriptive. They both ask, “Do you have a method for managing AI system risk through its full lifecycle?” Where they differ is that the EU AI Act is law, not a voluntary framework. For high-risk systems, it asks a more prescriptive question: “Show me the documented, attributable, time-stamped artifact for this specific system, from concept through post-market.” It also adds obligations that a “naked” ISO 42001 program simply doesn’t force you to produce at the same granularity. This includes an AI Quality Management System (QMS), a technical file built to Annex IV, automatic event logging, conformity assessment before market, registration, a formal post-market monitoring plan, and serious incident reporting.

The gap between the two standards isn’t structural—it’s evidentiary. You can pass an ISO 42001 audit with strong processes and a limited sampling of evidence. You cannot satisfy an EU high-risk conformity assessment without the per-system full-lifecycle artifact trail, and you cannot retroactively manufacture that trail once a system is already in production.

Make auditable artifacts tied to stage gates the basis of your AI Risk Management System

Rather than treat EU AI Act compliance as something to bolt on in 2027, we are updating the lifecycle itself to produce auditable artifacts at every gate, each one versioned and attributable (who decided what, when, on what evidence): Concept and intake → Risk review & approval → Design → Pre-production testing → Post-market monitoring.

In this model, no stage gate changes are required after December 2, 2027.  What changes is that some new artifacts will be required, and the extent and rigor of some current artifacts will be increased to meet the EU High Risk requirements.

The key design move is keeping the heavier high-risk requirements behind the classification gate. When a system is flagged high-risk, we switch on the deeper obligations: logging designed for traceability, human-oversight measures built into the UX, and Annex IV-grade documentation depth, without re-plumbing the program for everything else. Minimal additional overhead now, minimal rework later.

Educating the build teams

Policy and process don’t ship software; engineers do. For this use case, the bias/fairness and explainability requirements pose a challenge because they are essentially net-new requirements that didn’t exist in the pre-generative AI world.

There are no single fairness or explainability metrics that work for every AI system context. Hand a delivery team a simple policy PDF outlining these requirements, and you are likely to get one of two failure modes: paralysis, or box-ticking that doesn’t survive contact with an auditor.

Success requires treating dev team enablement, ideally just-in-time enablement, as a core responsibility. The right resource at the right lifecycle moment beats training at project onset:

• At requirements (after risk classification, before design). Teams learn what made the system high-risk, which obligations relate, and what “good” looks like, so requirements for bias, human oversight, and traceability are “front of mind.”
• During design. Providing archetype guidance and tooling choice to help development teams select representative data and the right fairness metric for this use case; how to design logging for traceability; and what effective human oversight looks like in the interface.
• Ahead of testing. How to evidence accuracy, robustness, and bias, appropriate test design, acceptance thresholds, and artifact capture, to ensure results are audit-ready.
• Ahead of production. Provide an observability and monitoring strategy. How do we monitor drift, explainability, and performance? How do we address incident reporting requirements?

It’s common to see approval gates in an AI governance workflow. It’s less common, but equally important, to build enablement gates of this nature. A team shouldn’t enter the design phase without knowing how it will handle explainability and shouldn’t enter production without a monitoring plan it understands.

Your EU AI Act Journey

If you’re starting from a ISO 42001 certification baseline, you’re closer than you think to EU AI Act compliance. It isn’t about reinvention. It’s about deciding, deliberately and early, where to add the required depth so that the changes required in December 2027 are relatively simple.

If you’re starting from a less formal place, start with a basic governance workflow. First, develop the stages and their associated approval gates necessary to address your current risk and compliance needs. Second, build placeholders for the more comprehensive approval gates that you can update and enable ahead of future requirements. Finally, layer on the enablement gates your AI governance team needs to put in place to ensure that your development team has the guidance it needs to manage your AI and compliance risks.