There is a gap at the center of most AI governance programs, and naming it precisely is the first step to closing it. Frameworks like the EU AI Act, the NIST AI Risk Management Framework, ISO 42001, and ISO 23894 are valuable. They give you risk categories, outcomes to achieve, documentation requirements, risk tiers, accountable roles, and audit expectations. What they do not give you is how.

I sit at both seats that make this gap obvious. On the engineering side, I hold deployment-approval authority over infrastructure at Akamai scale, where controls behave differently in production than they do on paper. On the audit side, I review ISACA’s Advanced AI Risk certification, serve on the IT Audit and Assurance Advisory Group, and contributed to the IT Audit Framework. Translating between what frameworks require and what technical controls actually do is the work most organizations are stuck on.

What frameworks give you, and what they do not

Line up the two columns and the gap is unmistakable. Frameworks give you risk categories; they do not tell you how to detect each risk in your specific system. They give you outcomes; not how to instrument the system to produce them. They require documentation; not how to keep that documentation synchronized with live code, prompts, and model versions. They define risk tiers and high-level controls; not which technical control fires at which lifecycle stage. They name accountable roles; not how those roles operate across engineering and security teams. They set audit expectations; not what evidence stream satisfies them at scale.

The right-hand column is the entire job. Every organization has to do this work itself, because it is specific to how your system is built.

Why static risk models do not fit dynamic systems

Traditional risk models were built for static, single-step software: inputs reviewed at design time, decision logic visible in code review, predictable outputs, audit through document review. AI systems are the opposite: dynamic, multi-step, often autonomous, with inputs that change per request, decision logic that emerges from billions of weights, probabilistic outputs, and an audit that must operate over runtime telemetry.

If your AI risk register reads like a software risk register from 2018, it probably is not engaging with how the system actually behaves. Real enforcement instruments the system to produce evidence that the risk register can map to, rather than describing risks the system never reports on.

Closing the gap: a reference architecture

The bridge is the same architecture that works for any modern control problem, applied to AI:

Policy as code. Each governance requirement becomes a machine-readable rule, written once and evaluated against every change. A single rule can map to an EU AI Act article, a NIST RMF function, and an ISO control at the same time, so one control feeds multiple compliance reports.

CI/CD as the control plane. The pipeline is where most controls can actually fire, at merge and at deployment, gating promotions on risk tier, conformity evidence, and required approvals. Every change passes through it by construction.

Runtime observability. Because AI behavior is probabilistic and changes after deployment, the evidence layer has to run continuously: decision logs, drift detection, and anomaly detection that surface conformance, behavior, and anomalies in real time.

Different patterns need different controls

A single AI control model does not cover the field, because the patterns fail differently. Retrieval-augmented generation makes data access dynamic, so its controls are source attestation, per-document access control, and retrieval logging. Tool-using agents take actions, so their controls are per-role tool allowlists, action logging, and approval gates on consequential operations. Agentic systems chain decisions, so a bad assumption early cascades, and the controls have to govern the chain, not just the step. Mapping the right control to the right pattern is what separates a governance deck from a governance system.

The takeaway

Frameworks define the destination. Enforcement is the road, and it is the part you have to build. The organizations that succeed at AI governance are not the ones with the most frameworks on the shelf; they are the ones that translated those frameworks into executable controls, wired into the pipeline and the runtime, producing evidence continuously.

I write about cloud security, DevSecOps governance, and AI risk, and I speak on governing AI systems at scale. Connect with me on LinkedIn.