Your AI Policy Is Not a Control: The Gap Between Intent and Enforcement

AI governance programs typically start with a policy, sometimes a framework on top of it. The next step - controls that enforce what the policy commits to - is where the program gets operationally tested. The distance between intent and enforcement is where AI risk runs without controls in place.

A policy states what the organization intends; a control enforces it. One produces a document. The other changes what happens when AI is deployed, what data it can access, who reviews its outputs, and what happens when something goes wrong. Until an organization has controls, it has intentions.

Why AI Controls Are Structurally Different

‍Traditional IT controls work because the systems they govern are deterministic. A firewall rule permits or denies traffic. An access control grants or revokes a permission. When the outcome is testable the failure mode is observable - meaning the control either worked correctly or didn't. The work of the control environment for traditional IT controls is simply identifying and actioning gaps.

AI systems don't behave that way. The same model can produce different outputs from the same inputs because they are non-deterministic by nature, and what counted as acceptable performance at deployment can drift below acceptable six months later as the world the model is operating in changes. It's common for models to be entirely provided by vendors or third parties, which adds another layer: the underlying system can change without the organization knowing and this can change the outputs in undesirable ways. The control is out of the organization's hands in most cases.

This means AI controls have to be designed for uncertainty in a way traditional IT controls don't. They need to define not just what the system is allowed to do, but what human intervention looks like when it does something unexpected. They need monitoring for drift, not just uptime. They need auditability of decisions, not just system logs. The complexity is much deeper than any AI policy can begin to outline.

That's the design problem AI governance programs are now organizing around, and most are anchoring to one of two frameworks to do it.

What NIST AI RMF and ISO 42001 Require

NIST AI RMF organizes AI risk management across four functions: Govern, Map, Measure, and Manage. Govern is the cross-cutting foundation that establishes accountability structures, risk tolerance, and organizational culture around AI. Map, Measure, and Manage are how organizations operationalize against specific AI use cases.

Crucially, however, it's a risk management framework, not a prescriptive control catalog. It defines categories of consideration including: accountability, transparency, reliability, and fairness, but requires the organization to determine what specific controls map to those categories in their context.

ISO 42001 is more prescriptive: it follows the management system pattern organizations will recognize from ISO 27001: documented policies, defined roles, risk treatment plans, and operational controls. Where ISO 27001 governs information security, ISO 42001 governs AI management systems. Certification is possible, but like ISO 27001, the standard defines the structure while the organization fills it with controls that reflect its actual AI risk profile.

Where AI Governance Programs Start

Both frameworks share the same prerequisite: before defining controls, programs have to map where AI is in use, what risk each use case carries, and what acceptable performance looks like for it. Controls built before that mapping is done are controls built against the wrong profile, they protect the wrong things and miss the parts of the AI environment that matter most.

An organization that implements oversight thresholds without knowing which of its AI use cases carries the most consequence will protect the wrong things. One that defines access controls without mapping its vendor AI footprint will leave a significant portion of its AI environment ungoverned.

Mapping isn't a one-time exercise. AI footprints change as vendors ship new features, internal teams adopt new tools, and use cases expand beyond their original scope. The risk picture and the control environment have to evolve together.

What Internal AI Controls Look Like

Controls for AI governance aren't abstract. They're decisions that get documented, enforced, and tested.

Human oversight thresholds define when AI output requires human review before action. A fraud-flagging model gets reviewed before an account is suspended; a contract-drafting model gets reviewed before language goes to a counterparty. The control isn't "human oversight matters"; it's the specific threshold, who owns the review, and the enforcement path when the threshold is hit.

Access controls define who can deploy AI, in what contexts, and on what data. Which employees can use which tools, which data categories can be processed by which models, which use cases require approval before deployment. Enforced technically where possible, procedurally where not.

Output auditing ensures AI decisions are logged and reviewable after the fact. When an AI system influences a consequential decision, the record has to cover what the system produced, what data it acted on, and what the human did with it. Without that, accountability for AI-driven outcomes is impossible to establish.

Incident response for AI defines what happens when a system produces a harmful, incorrect, or unexpected output (model drift, hallucinated output, discriminatory decision). AI failure modes are different from traditional security events, and incident response designed for the latter doesn't automatically cover the former. Extending the process so it does is part of the control environment.

For organizations building toward ISO 42001 certification or demonstrating NIST AI RMF alignment to regulators and customers, this is the operational core. Policies and frameworks show intent. Controls tested against evidence show practice. The distance between them is what auditors examine, what boards are starting to ask about, and what separates a documented AI governance program from an operational one.

Complyance gives organizations the infrastructure to close it: continuous controls monitoring that flags gaps against AI oversight thresholds, configurable questionnaire frameworks for evaluating vendor and internal AI systems, and AI Agents that review control evidence, flag gaps, and surface vendor findings as your AI footprint evolves.

Unlike point-in-time assessments that can't account for a vendor's shipped model changes or an internal team's expanded use cases, Complyance keeps the risk picture aligned with how the environment actually changes.

See how Complyance operationalizes your AI governance program.