THE TECH SHOWCASEBy Chris Keon, an active sworn law enforcement officer and UAS program leader who has spent 20+ years in environments where a confident wrong answer wasn’t an inconvenience: it was a liability, and now advises organizations on AI governance and compliance.
Last week’s field guide on counter-UAS compliance ended with a line I want to pick up here: regulated capability is regulated capability. Named accountability, enforced controls, records nobody can quietly edit, verification before trust. The domain changes; the discipline doesn’t. AI governance is the same problem wearing a different uniform.
“We use AI responsibly” is a sentence. It is not a control.
An auditor doesn’t accept sentences. Neither does a regulator, a board, or opposing counsel in a deposition. They ask three questions, in this order: What is your AI allowed to do? How do you know that’s all it did? Who signed off?
If the answers to those questions live in someone’s head, you don’t have governance. You have good intentions.
Years ago, before AI tools existed for this kind of work, I was teaching military students how to fly UAVs. My team was inbound to a site with four separate team locations, each at a different elevation. The week before we arrived, a different team had been operating out of those same four locations, each entering its assigned flight altitude independently. Nobody cross-checked how one team’s altitude related to another’s once you accounted for the elevation difference between sites. For about a week it hadn’t mattered, because the flight paths simply hadn’t crossed. Then they did. Two aircraft ended up at the same actual altitude at the same time and collided, destroying both.
That habit doesn’t turn off when the output comes from a machine instead of a person. This is the field guide I wish more organizations had before they needed it, not after.
The Audit Log Is the Most Underrated Governance Artifact You Own
Nobody enjoys reading logs. That’s not the point. The log is what turns “trust me” into “here’s the record.”
Something will eventually go wrong: a bad output, a bad decision made on top of a bad output, a customer who notices before you do. When it does, the difference between an incident and a crisis is whether you can reconstruct what actually happened: what the system was asked, what it returned, who reviewed it, what they decided.
If your AI tooling doesn’t produce a reviewable record, that’s not a gap you’ll find on your own timeline. It’s a finding waiting to be written by someone else.
AI Advises. Humans Decide.
That’s not a slogan. It’s the architecture AI governance runs on, and it has to be built on purpose.
The moment an AI’s output flows into action without a named human approving it, you’ve delegated a decision to something that can’t be held accountable for it. Not because the model is untrustworthy. Because accountability requires a person who can be asked “why did you approve this,” and a model can’t answer that question in any way that holds up.
The fix isn’t complicated, which is exactly why it gets skipped: define which decisions require human sign-off, name the approvers by role, and log the approvals. Boring. Effective. Defensible. That’s what governance is supposed to be: not a mission statement, but a control that survives being questioned.
By the time my class started the following week, the fix was already in place: the site lead over my teams now had to review every team’s assigned altitude before anyone flew, not just each team checking its own math in isolation. I taught under that requirement for the rest of the rotation, and it worked exactly the way it was supposed to: a second, independent set of eyes catching what four separate teams working in isolation couldn’t be trusted to catch on their own.
That incident predates AI by years, and I wasn’t there for it. I only inherited the fix. But the fix maps exactly onto what AI governance is supposed to do now: a system that actually cross-references every team’s logged altitude against every other team’s, flags the conflict, and requires a named human to clear it before anyone flies. The technology to catch that exists today. Whether an organization builds the sign-off step around it is still a choice. At that site, it stopped being optional the week before I arrived.
Questions to Ask Before You Buy AI
A vendor tells you their product is “fully compliant.” That sentence should trigger more questions, not fewer.
Compliant with what framework, specifically, and can you see the actual assessment, not a summary of it? Who owns liability when the output is wrong: the vendor, or you? What gets logged on their end, and can you access those logs, or are you taking their word for what happened inside their system? What happens to your data once it’s in their pipeline? Is it used for training, and can you opt out in writing?
A vendor who answers all four cleanly is a partner. A vendor who gets vague on any of them is a risk you’d be importing into your own governance posture, whether you write it down or not.
Define AI Incidents Before You Have One
“What counts as an AI incident?” is a question worth answering on a quiet Tuesday, not in the middle of one.
Biased output that reached a real customer. A hallucinated citation that made it into a regulatory filing. An employee who pasted client data into a public tool because it was faster than the approved one. If your AI governance program’s incident definition doesn’t explicitly cover AI failure modes, those events don’t get flagged as incidents at all. They fall through the cracks, unreported and unreviewed, and because nobody reviewed them, they repeat.
Updating the definition is a paragraph of work. It changes what your organization is capable of noticing.
The 80/20 of AI Governance Readiness
Most organizations think governance requires a platform, a committee, and a budget line before anything can start. It doesn’t. From the assessments I’ve run, the baseline that actually matters comes down to five things:
- An acceptable-use policy people have actually read: not one that exists, one that’s been read.
- A defined, named list of approved AI tools, so “which tools are we even allowed to use” has one answer, not five.
- A named owner for AI decisions: a person, not a department, not “leadership.”
- An incident definition that explicitly covers AI failure modes, per the section above.
- A log. Not a perfect one. A real one.
None of that requires a platform purchase or a committee charter. It requires a decision that governance is someone’s actual job, this week, not a someday initiative. Most organizations I’ve evaluated are one focused week away from a defensible baseline. They just haven’t spent the week yet.
Start With the Paragraph, Not the Platform
Every item above can be written down this week. None of it requires new software, new headcount, or a vendor contract. What it requires is treating “we use AI responsibly” as a claim you’ll eventually have to defend (because you will) and building the five things above before someone asks you to prove your AI governance is real.
If that list reads like a counter-UAS compliance checklist with the nouns swapped out, that’s not a coincidence either. Named accountability, enforced controls, an evidence trail, verification before trust. I said it last week and it’s just as true here: the domain changes, the discipline doesn’t.
Want the AI tools I actually use to run this kind of work? Grab AI Prompt Vault Vol. 2: 81 practitioner-built prompts for governance, compliance, audit prep, incident response, and regulated operations, written for the people who have to make this defensible, not just describe it.
Chris Keon is an active sworn law enforcement officer and unmanned systems practitioner who has trained roughly 2,000 students across military, public safety, and commercial sectors. He writes field notes and builds practical tools at TheTechShowcase.com.