All Case Studies
AI Governance
Case Study

EU AI Act & ISO/IEC 42001 Readiness

Operationalize readiness for the EU AI Act and ISO/IEC 42001 through an AI Management System with policy-as-code enforcement, distributed ownership, and evidence that's a byproduct of running the system, not a periodic compliance exercise.

Public reference: Iberdrola certifies its AI Management System with AENOR
EU AI Act & ISO/IEC 42001 Readiness

Executive Outcome

01

Policies became versioned and testable, so teams could validate them early in delivery instead of hitting a late-stage surprise or a waiver pile-up.

02

Runtime enforcement got consistent through the declared enforcement points — unapproved traffic stopped reaching models by policy, not by luck.

03

Audits got easier because the evidence was already there — a byproduct of enforcement and tracing running normally, not something rebuilt from scratch before every review.

Engagement focus

AIMS implementation and runtime governance for EU AI Act and ISO/IEC 42001 in a federated delivery landscape: policy-as-code, distributed ownership, and continuous evidence.

What this covers
  • AI Management System (AIMS) with scope, ownership, and control taxonomy
  • Policy-as-code enforcement with versioned definitions and exception handling
  • Continuous evidence generation for audit sampling and incident analysis

Context

In a regulated, federated organization, AI delivery was moving faster than manual review and checklist-based governance could keep up with. The goal was to push governance into the runtime itself, so control enforcement and evidence generation happened systematically instead of by hand. ISO/IEC 42001 frames this as an AI Management System (AIMS) with defined scope, ownership, and continuous improvement — useful language, but the actual work was making it hold up across multiple delivery teams, cloud providers, and model vendors, each with its own tooling and release cadence, without turning the central team into a bottleneck everyone routed around.

The Challenge

  • 01Manual reviews couldn't keep pace with AI delivery — they created bottlenecks and inconsistent outcomes depending on who was reviewing that week.
  • 02Policy enforcement varied team to team and provider to provider: uneven controls, inconsistent exception handling, and drift that crept in over time.
  • 03Audit trails got reconstructed from disjointed logs after the fact, which meant evidence gaps and a lot of scrambling before every review.
  • 04Decentralized model access raised shadow AI risk and cut visibility into usage, data exposure, and tool permissions.
  • 05There was no shared language for control applicability, exception handling, or evidence requirements across the federated landscape — every team argued from a different starting point.

Approach

  • →Translated AIMS scope, organizational context, and leadership commitments into an actual control taxonomy and operating model, not just a policy document.
  • →Wrote governance as code — versioned policy definitions, a control taxonomy, and clear ownership for the policy lifecycle.
  • →Declared explicit policy enforcement points for model and tool traffic, with standardized exception handling and escalation paths.
  • →Designed a policy-stamped request envelope that binds request context, the applicable policy version, enforcement decisions, and key signals into one traceable record.
  • →Built a control evidence model linking each control to enforcement signals, decision records, and evidence that's ready for sampling without extra work.
  • →Set evidence retention patterns so enforcement decisions and runtime signals land in immutable, joinable form for audit sampling and incident analysis.
  • →Built reporting and sampling views that map obligations to controls, evidence sources, and exception handling for both the EU AI Act and ISO/IEC 42001.
  • →Split ownership deliberately: the central team owns policy definitions and enforcement infrastructure, delivery teams own local implementation and exception documentation.

Key Considerations

  • Policy discipline needs real upfront alignment with application teams and clear change management, or you get friction and quiet bypass patterns.
  • The shared enforcement layer becomes a critical service the moment teams depend on it — it needs real reliability, latency, and availability guarantees.
  • Policy authoring and maintenance need a dedicated capability and controlled rollout, or drift creeps back in exactly where you started.
  • A central team can't enforce everything directly under a distributed ownership model — influence, good defaults, and exception governance end up mattering more than any mandate.

Alternatives Considered

  • ✕Manual approval gates don't scale, and outcomes get inconsistent fast once volume picks up.
  • ✕Library-based controls can be bypassed and drift across implementations — and they don't produce central evidence on their own.
  • ✕A central mandate without adoption support generates resistance and shadow workarounds — the same failure mode as everywhere else in a federated org.
Representative Artifacts
01AIMS Scope and Context Statement (boundaries, roles, decision rights)
02Control Taxonomy Mapping (EU AI Act, ISO/IEC 42001)
03Statement of Applicability (control register with applicability, status, evidence sources)
04Policy Repository Structure and Taxonomy
05Policy-Stamped Request Envelope Specification
06Evidence Retention and Audit Record Model
07Exception Management and Waiver Workflow
08Compliance Reporting and Sampling Dashboard
09Distributed Ownership Model (central vs. delivery team responsibilities)
Acceptance Criteria

Policy enforcement applied consistently to production model and tool traffic through declared enforcement points.

Policy changes versioned, reviewable, and promotable through defined release discipline.

Blocked or flagged requests generate complete enforcement records suitable for audit sampling.

Developers receive actionable feedback on policy violations in the delivery workflow.

AIMS scope, ownership, and control applicability documented, versioned, and linked to evidence sources.

Exception paths governed with documented rationale, ownership, and review cadence.

Continue Exploring

Other Case Studies