I Asked AI to Write My AI Policy. We Need to Talk.
I’ll admit something that might cost me some credibility before we even get started.
When a company I worked for needed an AI policy, I was the person in the room responsible for helping write it. I stared at a blank document for longer than I’d like to admit, opened a browser, and asked an AI to help me draft it.
I’m going to let that sit there for a second.
The irony is not lost on me. The person tasked with governing AI used AI to govern AI. If that sentence made your eye twitch slightly, welcome to the actual state of the industry. We are all, to varying degrees, making this up as we go.
That moment, more than anything else I’ve experienced in my career, captures exactly where we are with artificial intelligence in the enterprise right now. Simultaneously indispensable and ungoverned. Incredibly powerful and poorly understood. The answer to problems we have and the source of problems we didn’t anticipate.
This post is my honest attempt to explain where I stand on it — and why it’s more complicated than either side of the argument usually admits.
I’ve Been Pulled in Both Directions. Sometimes in the Same Meeting.
I’m an IT and Security professional. I’ve spent my career helping organizations protect their data, manage their risk, and make sensible decisions about the technology they adopt. I have also, in that same career, watched AI do things that genuinely impressed me — and watched it create problems that genuinely alarmed me.
Sometimes on the same afternoon.
I am not anti-AI. I want to be clear about that, because this blog covers a lot of AI risk and it would be easy to read that as opposition. It isn’t. What I am is someone who has sat on both sides of the table — the side trying to harness AI’s capabilities and the side trying to prevent those capabilities from becoming a liability — and I’ve found that both sides have a point.
The tension in my head isn’t between people who are right and people who are wrong. It’s between two things that are both true at the same time.
The Part That Keeps Security People Up at Night
Let me start with the risk side, because it’s what I know best and because it has some genuinely instructive examples.
A few years ago, Samsung made headlines for the wrong reasons. Employees, working with good intentions and trying to do their jobs more efficiently, started using AI tools to help with their work. Reasonable so far. The problem was that in doing so, they pasted proprietary source code and internal meeting notes directly into a public large language model. Company data — the kind that lives behind NDAs and access controls and years of careful security architecture — went straight into an AI’s training pipeline.
Nobody meant to cause harm. That’s the part worth sitting with. These weren’t bad actors. They were people who found a useful tool and used it the way you use any useful tool, without fully understanding where their input was going or what happened to it afterward.
That story plays out in quieter ways in organizations every day. An employee summarizes a sensitive document using a free AI tool on their personal browser. A developer pastes client data into a coding assistant to debug a problem faster. A manager runs a confidential HR discussion through an AI transcription service because it’s easier than taking notes.
Each of those is a well-meaning person making a reasonable-seeming decision. Each of those is also a potential data breach that never shows up in a security log.
And that’s before we get to the AI being introduced at the endpoint level — tools embedded in operating systems, browsers, and productivity suites that can see everything on your screen, read your files, and learn from your behavior. The attack surface that creates for a determined adversary is not small.
The Part That Makes Me Genuinely Excited
Here’s where I might surprise you.
AI analyzing security logs is, frankly, remarkable. A human SOC team going through log data is doing their best — but they’re human, they get tired, they have biases, and there is a hard limit to how much data a person can meaningfully process in a shift. An AI system trained on threat patterns can go through the same data faster, flag anomalies a human would miss, and do it at three in the morning on a Sunday without complaining. For organizations that can’t afford a 24/7 security operations center — which is most SMBs — that capability is not a luxury. It’s a genuine equalizer.
The same logic applies to code. AI coding assistants that help developers write faster, catch errors earlier, and auto-test their output aren’t replacing good engineers — they’re making good engineers faster. The quality floor goes up. The feedback loop tightens. Things that used to take a week take a day.
And the ability to take enormous, unstructured data sets and make them searchable and retrievable through natural language? That’s transformational for organizations drowning in documentation, historical records, or compliance data. The information was always there. AI makes it findable.
These are real capabilities with real business value. Dismissing them in the name of caution is its own kind of risk.
So Where Does That Leave Us?
Here’s my actual position, as plainly as I can state it.
AI is not the problem. Ungoverned AI is the problem.
The Samsung incident didn’t happen because AI is dangerous. It happened because employees had access to powerful tools without any framework for understanding what those tools did with their input. The financial data shared over video conferencing platforms isn’t at risk because Teams is malicious. It’s at risk because the people using it were never told what “encrypted” actually means — or doesn’t mean.
The pattern is the same every time. A powerful capability gets introduced — sometimes deliberately, sometimes through an update, sometimes because an employee found something useful and started using it — and the governance, the education, and the policy work never quite catches up.
I’ve been in the room trying to write those policies. It is genuinely hard. The technology moves faster than the frameworks. The use cases multiply faster than the controls. And the people making the business decisions are often several steps removed from the people who understand the risk.
Which is why I used AI to help write an AI policy. Not because I was lazy — though I’ll admit the blank document wasn’t helping — but because the problem is complex enough that I’ll take useful input from wherever I can get it. Even if the source is slightly ironic.
What I Think Companies Should Actually Do
Not a compliance framework. Just what I’d tell a friend.
Start with a policy — even a simple one. “Here are the AI tools we’ve approved, here’s how they can be used, here’s what can never go into them.” That document doesn’t need to be 40 pages. It needs to exist and people need to have read it.
Educate your people before something goes wrong. The Samsung employees weren’t reckless — they were uninformed. That’s a training problem, not a character problem. Most people will make reasonable decisions if they understand the implications of their choices.
Give your IT and Security teams clear directives. They need to know what they’re allowed to block, what they’re expected to monitor, and what the escalation path looks like when someone finds an AI tool running in the environment that nobody approved.
And revisit it regularly. Whatever policy you write today will be partially obsolete in six months. Build in a review cadence and treat it like a living document, not a checkbox.
The Bottom Line
I’m not here to tell you AI is dangerous and you should be afraid. I’m here to tell you it’s powerful, it’s already inside your organization in ways you may not fully know, and the gap between its capabilities and your governance of those capabilities is where the risk lives.
I’ve seen both sides of this clearly — the remarkable things AI can do and the quiet damage it can cause when nobody’s paying attention. That’s the lens I bring to everything I write on this site.
And yes, I used AI to help write the policy meant to govern it. The first draft was actually pretty good.
Make of that what you will.
