Black Bay Security
Get your no-cost assessment deepcurrent login
Insights

Your AI Governance Policy Is a PDF Nobody Has Opened Since the Kickoff Meeting

There is a difference between having a policy and having a program. One of them costs money.

Todd Neilson, CISSP 4 min read
Your AI Governance Policy Is a PDF Nobody Has Opened Since the Kickoff Meeting

Somewhere in your document management system is an AI governance policy. It has a version number. It was reviewed by legal, socialized with a working group, and approved by a committee that met four times and then stopped meeting. It runs eleven pages and uses the word "appropriate" nineteen times.

It is not doing anything.

That is not a shot at whoever wrote it. The document is probably well written, and that is precisely the problem. It was graded on whether it read well. Nobody has since graded it on whether anything changed.

The Test

Four questions. Ten minutes.

  1. Name every AI system in production. Not the sanctioned ones. All of them.
  2. For each, name the accountable business owner. A person, not a department.
  3. For each, name the data it can reach. Not the data it was designed to use. The data it can reach.
  4. For each, name the control that would stop it, and the last time anyone confirmed that control fires.

If assembling those answers takes more than a day, you have a document rather than a program. If it takes more than a week, you have a document that is actively creating exposure, because the policy asserts a degree of control you cannot evidence, and that assertion is in writing with a signature on it.

Why this keeps happening

Policy is cheap and enforcement is expensive. Organizations do the cheap thing first and then declare the work finished.

The two artifacts differ in kind, which is the part that gets missed. A policy is a set of nouns and adjectives: appropriate safeguards, approved tools, sensitive data. A control is a verb with an owner, a trigger, and an observable outcome. Translating the first into the second is the actual job, it is unglamorous, and it gets scheduled after the policy and then never scheduled again.

Three failures show up almost every time.

The policy has no subject. Users must not submit confidential data to unapproved AI tools describes a preference. Who detects a violation? What signal do they see? What happens next? A requirement with no answer to those three questions is a wish with a version number.

The inventory was a survey. Someone circulated a form asking teams to self-report AI usage, and teams reported the tools they were proud of. What comes back is a list of sanctioned pilots. The real estate, browser extensions, personal accounts, AI features that arrived in a routine SaaS update, an agent someone stood up in a sandbox that now holds production credentials, is missing by construction rather than by accident.

Nothing changed for anyone. No workflow gained a step. No approval gate moved. No dashboard appeared. Governance that is invisible inside the operating environment is indistinguishable from no governance, and the people whose behavior it was meant to change are behaving rationally when they ignore it.

What to do instead

Three moves. None of them requires a new committee.

  1. Build the inventory from telemetry, not from a survey. Ask the questions your systems can already answer. What AI-related spend appears in expense reports and cloud bills. What non-human identities were created in the last ninety days, and by whom. What egress destinations look like model API endpoints. Which SaaS applications shipped AI features in the last two quarters under an existing contract. Which managed endpoints have a local inference runtime installed. Every one of those is a query someone in your organization can run this month, and none of them depend on a colleague volunteering an inconvenient truth. The picture will be worse than the survey. That is the point of doing it.
  2. Rewrite every policy statement as a control with a name attached. Go line by line. For each requirement, write the control that enforces it, the person accountable when it fails, and the test that proves it fires. Where you cannot fill in all three, you have two honest options: fund the control, or delete the sentence. Leaving an unenforceable requirement in a governance document is not caution. It is a documented gap in your own handwriting.
  3. Instrument one thing and report it monthly. Not a maturity score. One number that moves. Count of AI systems with a named owner. Count of agent identities you could revoke inside an hour. Share of the inventory with a completed data classification. Pick the one you can measure without a purchase order, publish it every month, and let the trend line carry the argument. A metric that gets worse for three consecutive months in public will unlock more budget than any assessment you can commission.

The Monday morning version: open the policy, count the requirements, and mark each one with the control that enforces it. Most people who try this get through fewer than a third of the lines before they run out of controls. That ratio is the honest maturity score, and unlike the one on the slide, it tells you exactly what to fix first.

The policy was not wasted effort. It was the easy half, completed, and then mistaken for the whole job.