AI is here to stay, the naysayers have been all but been silenced, the final pieces are falling into place. For any of us working in the industry, it’s clear that two things are true across almost all of our organizations:
Enterprise leaders love buzzwords like ‘AI’ and ‘Codegen’ and ‘rapid innovation’. Every organization is in love with AI.
and;
It’s almost impossible to do anything remotely useful with it, because large organizations are afraid of risk. Almost every policy and procedure you can find is ultimately built and enacted to reduce risk.
Running on a treadmill
Large enterprise organizations love to talk about all of the cool new ways they’re implementing AI. Big pump up sessions at quarterly meetings, cool new entries on the website. You go back to office, excited to install some tools and start building. Except you can’t, because any software install requires sixteen approvals from eleven different workstreams and none of them have a process to talk to each other. Three months later you’re no further along than when you started and you start to realize you’ve been running on a treadmill, but you can’t really pinpoint why.
Everyone is talking about the big new game. Except I don’t think the leaders selling the tickets have ever actually played it.
Why Cyber risk intolerance is a blocker to innovation
Most enterprises say they want AI innovation, then require every experiment to satisfy the same controls as a production system handling secured or regulated data. Security teams aren’t misguided or wrong to care about exposure…the problem is that the framework they are being asked to enforce was built for the old, pre-ai world where innovation was paced and architectures were stable.
AI strategy, cybersecurity, legal, procurement, and engineering operate as separate executive workstreams, each optimized to avoid its own mode of failure. Engineering is told to move quickly. Cyber is told to eliminate uncertainty. Legal is told to prevent liability. Nobody is accountable for the combined cost - the waiting that ground level teams must endure before anything can be approved and used. The combined cost is what directly stifles innovation.
This structure turns exceptions into policy failures. An unfamiliar request enters the review process, doesn’t match an existing control pattern, and stops there. By the time everyone is comfortable with it, the technology has changed, a competitor has already achieved your goal, or even worse, the team has been so traumatized by the process they stop proposing anything ambitious.
The question “is it vulnerable?” is no longer the right question. The answer is overwhelmingly yes. Every useful system is vulnerable to something. Whether it’s the 20 year old zip software or a brand new frontier model. The right question to ask now is, how quickly can we detect a problem, and are we equipped to contain or reverse it.
Security is important, but it’s not the objective in isolation. When risk intolerance prevents learning, stifles innovations, or blocks shippping meaninful software, it has not eliminated risk. It has exchanged cybersecurity risk for business failure. Perfectly securing an organization that is becoming irrelevant is not a successful security outcome. And while small failures may be tolerable today, rest assured these failures will add up as talent hungry to evolve leaves for spaces more open to innovation.
How do we overcome it
We need to shift the enterprise conversation from “is it vulnerable?” to “are we proactively mitigating the risks this workspace actually creates?” This question drives security teams to focus less on policy checkboxes and more on understanding the tools and technologies in use in their organizations. This understanding is infinitely more valuable than policy.
A sandbox using mock data does not need the same posture as a customer-facing agent with access to production systems. An internal tool retrieving approved documentation should not be evaluated like an autonomous workflow capable of taking financial or operational action. Data, integrations, blast radius, reversibility, and level of human oversight are different for every project, so it follows that the allowable risk is different too.
That means a one-size-fits-all cyber posture no longer works. We need risk tiers aligned to individual project workspaces. Teams should have preapproved environments, clear data classifications, observable model access, bounded credentials, named risk owners, and time-limited exceptions. Exceptions should have a defined scope, compensating controls, and an expiration date. This is not avoidance, this is how true governance should work.
On top of this, we need to start integrating security into our teams. Security in a silo only turns them into policy clip board holders. Integrating security into the development and innovation process from the start is essential to ensuring we properly understand risk.
The AI landscape is moving too quickly for policies that depend on a permanent list of approved tools. We need real policies that define how to evaluate changing tools quickly and consistently. The goal should be to build the organizational capacity to make informed risk decisions at the speed innovation now requires.