Every conversation I have about AI governance starts in the wrong place. Leadership asks "should we allow AI on this program?" as if the answer is still theirs to give. It isn't. By the time that question reaches a steering committee, the analyst has already been using a chatbot to draft test cases for a month, the PMO lead has been summarizing meeting notes with one, and someone in finance has pasted a budget variance into a free tool to get a cleaner write-up. The decision was made — just not by anyone accountable for it.
The numbers say this isn't an edge case, it's the baseline. In a 2025 report on the state of shadow AI, the cyber-risk firm UpGuard found that more than 80% of workers — and nearly 90% of security professionals — use AI tools their employer hasn't approved. Half use them regularly. Fewer than one in five stick to only company-sanctioned tools. And the people using unapproved tools the most regularly weren't the interns — they were executives. The same study found fewer than half of workers actually understood their own company's AI policy, while 70% were aware of colleagues feeding sensitive data into these tools.
Read that again from a program seat. The work product flowing across your program — requirements, status, risk language, client data — is already passing through models nobody on your governance structure has reviewed, under a policy most of the team can't recite. That is the actual starting condition. "Should we allow it" is a question about a world that no longer exists.
Why a ban makes it worse, not safer
The instinct, especially in regulated work — government, financial services, healthcare, the sectors I live in — is to prohibit. No AI. Put it in the policy, brief it at kickoff, move on. I understand the instinct and I've watched it fail every time, because a ban doesn't change behavior under deadline pressure. It only changes where the behavior happens. The tool moves from a sanctioned, logged, enterprise account to a personal phone and a free consumer login. You didn't eliminate the risk. You drove it somewhere you can't see, can't audit, and can't defend when the client asks.
This is the oldest pattern in security, just wearing a new face. Shadow IT taught us that when the official path is slower than the unofficial one, people take the unofficial one and stop telling you. AI has made that gap enormous: the sanctioned process is a two-week tooling request, and the shadow process is a tab that's already open. A prohibition you can't enforce isn't governance. It's a paper shield that lets leadership feel covered while the exposure compounds underneath it.
Where shadow AI actually bites a program
The risk isn't abstract "AI is dangerous" hand-waving. It lands in three specific, concrete places on a delivery program.
1. Data walks out the door in a prompt
The most common failure is the most boring one. Someone pastes a client's data — a defect list with system details, a roster with names, a contract clause — into a consumer tool to get help summarizing it. On a program under NDA or handling protected data, that single paste can be the reportable incident. Nobody meant harm; they meant to hit the deadline. But intent doesn't appear in the breach notification.
2. Unverified output enters the system of record
Shadow AI doesn't just leak data outward — it pushes unchecked content inward. A confidently-worded, AI-drafted risk summary gets pasted straight into the register. A generated status paragraph lands in the report. Because it reads clean, nobody scrutinizes it, and now your record contains claims no human actually stands behind. I've written before that AI launders a dishonest record into polished fiction; shadow AI is how the fiction gets in without anyone deciding to put it there.
3. The accountability trail goes dark
When the tool is sanctioned, you can answer the questions that matter after the fact: which model, what was shared, who reviewed the output before it shipped. When it's shadow, every one of those answers is "we don't know." That's the real cost. AI on a program is survivable; AI that nobody owns the output of is not. You can delegate the labor to a model. You cannot delegate the signature — and a signature on work you can't trace is worthless.
A no-AI policy doesn't produce no AI. It produces ungoverned AI. The choice in front of leadership was never whether the team uses these tools — it's whether that use happens in the light, where it can be secured, or in the dark, where it can only be discovered.
Govern it into the light
The Army taught me that you don't write a rule you can't enforce, because an unenforceable rule trains people to ignore the ones that matter too. The same logic applies here. The goal isn't to stop AI; it's to make the safe path the easy path, so nobody has a reason to go around it. On the programs I run, that means four things, in order. Sanction real tools — give the team an enterprise-grade option with the data protections in place, because "use this approved tool" only works if the approved tool actually exists and isn't painful. Write rules of engagement people can recite — not a fourteen-page policy, but a short, blunt list: what data never goes in, what output always gets human review, where the logging lives. Protect the data boundary — the line isn't "AI or no AI," it's what may cross into a prompt and what may never, and that line has to be specific to the program's classification. And keep the human signature explicit — every AI-touched artifact still has a named owner who reviewed it and stands behind it, same as any other control.
None of this is exotic. It's the same governance discipline you already apply to vendor access or change control, pointed at a capability that arrived faster than the policy did. The programs that do it get the speed of AI with an audit trail they can defend. The ones still relying on a prohibition get the same AI usage — minus the visibility, minus the protections, minus any honest answer when the client asks what their data touched.
- Assume it's already happening. Start from "the team uses AI," not "should they" — the second question is already answered.
- Replace the ban with a sanctioned path. An enforceable rule needs a real, usable alternative to the shadow tool; without one, the policy is theater.
- Draw the data boundary explicitly. Define what may enter a prompt and what never may, tied to the program's classification — not a vague "be careful."
- Keep a named owner on every AI-touched artifact. Traceability is the whole point; output nobody will sign is output nobody should trust.
- Make the policy short enough to recite. If the team can't repeat the rules from memory, the rules aren't governing anything.
The bottom line
Shadow AI isn't a future threat to plan for — it's the current operating condition of nearly every program, including yours. The leadership failure isn't allowing AI or banning it; it's pretending the choice is still open while the team quietly settles it under deadline. You can't govern what you refuse to admit is happening. Bring it into the light, give people a safe path, hold the data line, and keep a human name on the output. The alternative isn't a program without AI. It's a program using AI exactly as much, with the lights off.