Your AI Rollout Needs a CISO in the Room. Already.
Every company I talk to right now is racing to ship something with AI in it. Good — they should be. But there’s a pattern I keep seeing: security gets invited to the AI conversation about six months after the AI has already shipped, usually right after someone realizes the shiny new assistant will cheerfully repeat whatever a customer pastes into it, or act on an instruction that was hidden inside a document it was asked to summarize.
That’s backwards, and it’s expensive to fix in that order. Retrofitting guardrails onto a live AI system that’s already wired into your data and your customers is a very different job than designing them in from the start — slower, riskier, and far more likely to involve an awkward conversation about something that already went wrong.
The attack surface is the model, not just the app
I spent two decades learning to secure code — deterministic systems that do exactly what they’re told, where the security job is making sure they’re told the right things. AI adds a genuinely new category of problem: the system now behaves based on inputs it was never explicitly programmed to handle. Prompt injection, where hidden instructions hijack the model’s behavior. Data poisoning, where the training data itself is the attack. Outputs that quietly leak the sensitive data the model was trained on or given access to. An agent handed a little too much authority, calling an API it shouldn’t, because it was persuaded to. None of that is hypothetical anymore.
I’ve helped teams govern AI/ML systems specifically for integrity against this, and the uncomfortable truth is that a lot of it looks like security problems I already know, wearing a new coat. Prompt injection is really an input-validation and trust-boundary problem. Data leakage is really an access-control problem. An over-empowered agent is really the principle of least privilege, applied to something that can now reason its way around a lazy boundary. The fundamentals transfer. What changes is that the system is non-deterministic, so you can’t just test every input and call it covered.
An agent that can act is a different risk than one that can answer
The line I care about most is the one between a model that answers and a model that acts. A chatbot that says something wrong is an embarrassment. An agent that can move money, change a record, send an email, or call an internal API and does something wrong is an incident. The moment you give a model the ability to take actions in the real world, you’ve handed it authority — and authority in the hands of something that can be talked into things needs the same scrutiny you’d give a new employee with those permissions, except this one can be socially engineered by a paragraph of text hidden in a PDF.
Governance is a feature, not a brake
The framing I push back on hardest is “security will slow the AI down.” Done right, it’s the opposite. When I’ve helped clients put responsible-AI guardrails in place — clear boundaries on what a model can touch, what data it can see, how its outputs get checked before they reach a customer — that’s precisely what let them move faster, because they could deploy into regulated environments like payments and healthcare without holding their breath. The guardrail isn’t what stops the car. It’s what lets you take the corner at speed.
The companies that win with AI won’t be the ones who moved fastest and hoped. They’ll be the ones who could say “yes” to the risky, high-value use case — the one their competitors were too scared to ship — because they’d already built the guardrails to do it safely. Governance is what converts “we’re not sure we can do that” into “we can do that, and they can’t.”
Where to start
You don’t need a 40-page policy on day one. You need three honest answers. What data can this model see? Because that’s the ceiling on what it can leak. What can it actually do — just read and respond, or also take actions that touch the real world? Because that’s the difference between embarrassment and incident. And who is accountable when it does something wrong? Because “the AI did it” is not an answer any regulator, customer, or board will accept. Get those three straight and you’re already ahead of most of the market, which shipped first and is now trying to reconstruct the answers after the fact.
AI is the most exciting shift I’ve seen in this field in twenty years, and I want companies to move on it. I just want them to move like they intend to still be standing in three years — with security in the room while the thing is being designed, not called in after it’s already talking to customers.
AI doesn’t remove the need for security judgment. It raises the stakes on it.