Your AI Policy Is Not a Control Until Someone Can Fail It

Note: now that I have some content up, I will be moving to publishing every two weeks so as to ensure that I am putting out quality work and to keep from flooding readers.

A financial analyst has a board deck due in the morning. She has three years of program data in a spreadsheet, a narrative to write, and ninety minutes before she has to leave. She opens a chatbot, pastes in a block of figures, and asks it to find the trend and draft two tight paragraphs. It does, and it does it well. She cleans up the output, drops it into the deck, and goes home.

Somewhere in a shared drive, her organization has a fourteen-page AI policy. It says, among many other things, that confidential data should not be entered into external generative tools without review. She read it once, during onboarding, eight months ago. Tonight she did not think about it. There was no prompt, no warning, no approval step, and no one to ask at nine in the evening. She made a judgment call alone, and no one will ever know she made it.

Nothing went wrong this time. That is the most dangerous part.

Here is what I have come to believe after watching this same pattern repeat across organizations of every size and budget. We keep saying we have governed AI when what we have actually done is written about it. A policy and a control are not the same thing, and the distance between the two is exactly where incidents are born.

A control is something a person can fail. It can be tested. It can be violated in a way that is detectable. And when it is violated, the violation traces back to a specific moment, a specific system, and an accountable owner. A policy that no one can fail is not protecting anything. It is describing an intention. The analyst tonight could not fail the AI policy, because the policy never touched her decision. It sat in a drive while she did her job the only way the night allowed.

This is not a failure of the analyst, and it is not a failure of whoever wrote the policy. It is a failure of where the work stopped. In most organizations AI governance lands on legal, and legal does what legal does well. It produces a document that states the organization's position, manages liability, and can be shown to a regulator or a board. That document is necessary. It is also, on its own, inert. Legal's instinct is to define what is permitted. A security practitioner's instinct is to ask a different and less comfortable question: when someone does the thing we said not to do, how would we know, and what happens next? If the honest answer is that we would not know and that nothing happens, then we do not have a control. We have a hope with a cover page.

The shift from document to control is not a matter of writing a stricter policy. Strictness on paper changes nothing when the paper never enters the moment of decision. A control requires three things the policy alone does not have. It requires a point of contact with the actual work, so the guidance reaches the analyst at nine in the evening and not only in an onboarding slideshow. It requires observability, so that the use of these tools produces a signal someone can see rather than a silence everyone has agreed to trust. And it requires an owner who is accountable not for having written the rule, but for the rule functioning in the world where the work is done.

Consider the difference in practice. A policy says do not paste confidential data into external tools. A control routes the organization's sanctioned AI traffic through an approved gateway, logs what categories of data move through it, and gives the analyst a fast, blessed path so that the safe option is also the easy one. The policy depends on memory and willpower at the worst possible hour. The control depends on instrumentation and a sensible default. One of these can fail in a way you can see and respond to. The other can only fail in a way you discover much later, in a postmortem, when the question "how did this happen" has a one-word answer: quietly.

I want to be precise about the people in this story, because the language we use about them shapes the budget we approve for them. The analyst is not careless. She is competent, on deadline, and was handed a powerful tool with no rails and no help. When we treat the eventual incident as a discipline problem, we are blaming a person for a system we declined to build. The kind thing and the effective thing turn out to be the same thing here. Put the guidance where the decision happens. Make the safe path the fast path. And stop asking people to personally be the control we never got around to implementing.

There is a sentence that gets said in the room after an AI incident, and it is worth listening for, because it tells you everything about whether the organization governed anything at all. The sentence is "but we have a policy." It is said with real surprise, as though the existence of the document should have changed the outcome. It did not, because it could not. The policy was never in contact with the work. The surprise in that room is the sound of an organization discovering, too late, that it confused writing about a risk with managing one.

So if you are an executive trying to find out whether your organization has actually governed AI, you do not need to read the policy. Ask three questions instead. First, when an employee is genuinely uncertain whether a use case is allowed, where do they go, and can they get a real answer in minutes rather than days? Second, if someone put sensitive data somewhere they should not have last week, would anyone know by now? Third, who owns the answers to the first two questions, and is that ownership written down with a name or title attached? If the room goes quiet on any of the three, you have found your real governance gap, and it is not in the document.

The analyst will be back at her desk tomorrow, and the night after that there will be another deadline and another judgment call made alone. The policy will not have changed. The only thing that can change is whether her organization decided to meet her in that moment or leave her to guess. We did not govern AI when we wrote the policy. We govern it the moment a person can actually fail a control we built on purpose, and we are standing there to catch it when they do. The question worth sitting with is a short one. In your organization, can anyone fail your AI policy? If the answer is no, you have not made it safe. You have only made it silent.

Robert Keefer is a security executive with 25+ years building and leading security programs across healthcare, global enterprise, and mission-driven organizations. He writes about security leadership, board communication, and AI governance. For advisory inquiries, reach him at robert@rmkeefer.com. Subscribe to get each new piece by email.