Most regulated institutions now have an AI acceptable use policy. Far fewer can show that it held on any given Tuesday, for a specific user, on a specific device, at the moment a request left for a provider. That gap is the position of this post: a policy document is not AI policy enforcement, and an AI governance program that ends at the document has not yet governed anything. It has described what governance would look like if it existed.
This is not an argument against the document. You need one, and writing it forces the institution to decide what it believes about AI. The argument is about what the document can do on its own, and what it takes to enforce an AI policy after the signatures are collected.
What the policy document actually does
An acceptable use policy is a statement of intent and a basis for accountability. After an incident, it lets the institution show that staff were told, trained, and acknowledged the rule. That has real value: it shapes culture, supports personnel decisions, and answers the first question an auditor asks, which is whether a policy exists.
But everything on that list happens after the fact. The document assigns blame once something has already gone wrong. It does not stand between a staff member and a paste. And in a regulated institution it cuts both ways. If client records leave through an AI tool eighteen months after the policy said they must not, the policy is not the defense. It is the exhibit that proves the institution knew the risk, named it in writing, and placed no control in the path. A documented risk with nothing attached to it reads worse in the record than ignorance would have. The remedy is not to stop documenting. The remedy is to attach the control.
Governance is a meeting. Enforcement is a decision.
Keep the two words apart. Governance is deliberation: the committee, the risk register, the review cycle, the policy itself. That work matters, and the frameworks are right to require it. NIST’s AI Risk Management Framework puts it at the center of the Govern function, which calls for AI risk policies and procedures that are “in place, transparent, and implemented” across the organization. The word carrying the weight in that sentence is implemented.
Enforcement is narrower and harder. It is a decision made at the moment a request leaves a device: this content may go to this provider, this content may go once the sensitive values are removed, this content may not go at all. A governance program can meet monthly and still be doing its job. Enforcement cannot. It has to be present at the instant of the action, every time, including Saturday night on the laptop of the contractor who never opened the PDF.
One policy line, walked to the moment it matters
Take the line nearly every AI acceptable use policy contains: no client records in AI tools. Now walk it forward to an ordinary Tuesday. A staff member is drafting a difficult letter, opens a consumer AI assistant in a browser tab, and pastes the client’s file in for context. The paste takes seconds.
Count what stands between the policy and the provider. The policy sits on the intranet. Training happened in January. The tool is a personal account, so none of the institution’s negotiated terms apply. Under OpenAI’s published data policy, content submitted through its consumer services may be used to train its models unless the individual has opted out, a default the business tiers reverse. And there is no record. The institution cannot say what crossed, when, or from which device, because nothing was in a position to see it. The policy held in exactly one sense: it will determine who gets blamed.
Run the same walk through the rest of the document; the pattern repeats.
| The policy says | The enforcement question |
|---|---|
| No client records in AI tools | What happens at the instant a record is pasted into one |
| Only approved tools may be used | What happens when an unapproved tool sends a request from a managed device |
| Agents must not act without oversight | What happens when an agent issues a request with no one at the keyboard |
What AI policy enforcement looks like
Machine-enforced policy means the document becomes a set of decisions applied at execution. Requests from AI tools and agents are intercepted on the device, before content reaches the provider, and the policy renders one of three outcomes. ALLOW, because the request is within bounds. REDACT, because it contains sensitive values that can be removed while the rest proceeds. BLOCK, because it should not leave at all. The staff member drafting that letter still gets an answer. The client’s identifiers never make the trip.
The other half is the record, and it matters as much as the decision. Every captured interaction is signed on the device and hash-chained into an append-only, tamper-evident record: who sent what, from which device, what the policy decided, and what actually crossed. Per user, per device, held by the institution under its own keys. That record is what turns “we have a policy” into “here is the policy holding,” and the second sentence is the one regulators are moving toward. CJIS Security Policy v6.0, whose audit controls map to the AU family in NIST SP 800-53, expects access to criminal justice information to be logged and the records retained for at least a year. Colorado’s revised AI law, SB 26-189, takes effect January 1, 2027 and requires records sufficient to demonstrate compliance to be kept for at least three years. The direction is consistent: the obligation is shifting from having rules to proving the rules operated.
There is more than one way to attempt this: training and attestation, network controls, data loss prevention, provider-side settings. They differ in where the decision happens and in what evidence survives, differences worth understanding before procurement rather than after. We keep a plain accounting of how the approaches compare, and a closer look at the hardest case in containing sensitive data.
Enforcement has limits, which is why the record matters
Honesty requires the caveat that sales copy tends to omit: enforcement has limits too. Detecting sensitive content in a request is best-effort. A social security number in a standard format is easy to catch. A client’s circumstances described in careful prose are not. No detection engine catches every sensitive value, and a product claiming complete recall should lower your confidence, not raise it.
That limit is not a reason to skip enforcement. It is the reason the record carries equal weight. When detection misses, a signed record of what actually crossed lets the institution find the miss, scope it precisely, and meet its notification obligations with facts instead of estimates. The decision reduces how often something goes wrong. The record bounds the cost when it does. Enforcement without evidence leaves you guessing about your own control. Evidence without enforcement is a well kept diary of incidents. They only work together.
A policy states what should happen. Enforcement decides what does happen, at the moment a request leaves a device. The record proves which one your institution actually has.
Write the policy, then make it executable
The working sequence is not policy or enforcement. It is policy, then enforcement, then evidence. Write the document with counsel and compliance, in the language of the obligations your institution answers to. Translate each line into a decision a machine applies at execution. Let the record accumulate quietly until the day someone asks. Institutions that work this way stop treating AI adoption and AI control as opposing forces, because the same layer that stops the bad paste is what makes the good use defensible.
This is the layer Verillian is built to be. Governance is a meeting; enforcement is what Verillian does. It intercepts requests from AI tools and agents on the device, decides ALLOW, REDACT, or BLOCK under your policy before content reaches the provider, and signs every captured interaction into a hash-chained, tamper-evident record the institution holds under its own keys. It is aligned to CJIS Security Policy v6.0, not certified against it, and built for HIPAA-regulated environments, where no product certification exists at all. It is live today. If the policy is written and the enforcement question is open, start with how to adopt AI within your mandate.