From AI Policy to AI Control

Many organizations begin AI governance by writing a policy. That is understandable. A policy is visible. It can be approved by leadership, circulated to staff, shown to auditors, and referenced in meetings. But a policy is only a statement of intent. It does not govern anything until it changes behavior.

The difference between policy and control is the difference between saying what should happen and proving what did happen. A policy may say that high-risk AI systems must be approved. A control defines what counts as high risk, who approves it, what evidence is required, where the decision is recorded, how exceptions are handled, and who can pause deployment when the control fails.

This distinction matters because AI risk moves through workflows, not policy documents. A team may adopt a chatbot. A department may connect retrieval to internal documents. A vendor may add generative features to an existing platform. A developer may use code generation. A service unit may test an agent. If policy is not converted into operational control, AI adoption will route around governance without appearing to violate it.

Policy-to-control conversion begins with verbs. What must be registered? What must be classified? What must be reviewed? What must be logged? What must be approved? What must be blocked? What must be escalated? What must be monitored? What must be retained? What must be tested? What must be remediated? If the policy cannot be translated into verbs, it is not ready to govern.

The second step is ownership. Every control needs an owner who can operate it and an accountable executive who can answer for it. A model inventory without an owner becomes a spreadsheet. A risk tier without decision rights becomes decoration. A logging requirement without review becomes storage. Controls require authority, not only documentation.

The third step is evidence. An AI governance control should produce a record that can be inspected later. Approval records, model cards, risk assessments, access logs, prompt/source traces, incident records, exception registers, monitoring results, and remediation evidence are not administrative clutter. They are how an institution proves that governance existed before failure.

The fourth step is testing. A control that is never tested may be imaginary. Can the organization show all high-risk AI systems? Can it identify which systems use personal or confidential data? Can it prove that a human approval gate operated? Can it reconstruct a material AI-assisted decision? Can it pause an agent? Can it show that exceptions expired? Testing separates governance from theater.

The fifth step is escalation. Controls need paths for uncertainty, disagreement, breach, drift, overreach, and harm. If an employee, model owner, risk officer, auditor, or service manager discovers a problem, where does it go? Who can decide? Who can stop the system? What happens if the business owner and risk owner disagree? Governance fails when escalation is slower than consequence.

None of this means every AI use needs heavy bureaucracy. Controls should be proportionate. Low-risk experimentation may require lightweight registration and basic data boundaries. Material decision support may require formal review, logging, quality thresholds, and human accountability. Agentic systems may require stricter action classes, approval gates, rollback, and kill switches.

The leadership challenge is to make the control system real enough to shape behavior without freezing useful adoption. That requires a library of controls that are assigned, measurable, evidenced, tested, and improved. A policy that cannot be enforced, measured, or audited is not governance. It is intention.

AI governance becomes credible when leaders can point to the control, the owner, the evidence, the exception, the remediation, and the decision authority. Until then, the organization may have an AI policy, but it does not yet have AI control.