I’ve been in the room. Multiple times. Multiple companies.
The security organization says no. Completely, categorically, by default. The posture isn’t “let’s figure out how to make this work safely.” It’s “this is forbidden until we’ve completed our review” where the review cycle is measured in quarters and the technology is shipping weekly. My mandate as a VP Engineering is to innovate, to move faster than competitors, to deliver on what the board is demanding. Both of us are right. Both of us escalate to the same C-suite executive, who makes a tie-breaking call based on incomplete information, and one side walks away having lost.
Neither loss is survivable in the long run.
Both outcomes kill companies. The only question is which one arrives first.
If security loses, if the hardline posture is overridden and adoption accelerates without guardrails, the outcome is a breach. Regulatory action. Data exfiltration that makes the front page. The bills for that incident arrive in multiples of millions of dollars and years of legal exposure. If velocity loses, if the security posture holds and the innovation mandate is deferred indefinitely, the outcome is slower but no less final. Your competitors ship AI features while you’re still in review. Your best people leave because they can’t do the work the way the industry now demands. Your product becomes incrementally less relevant until one day it’s irrelevant.
These are not speculative. Both outcomes happen, regularly, to real companies.
The structure is the problem. Not the people in it.
The Two Costs Nobody Calculates Together#
Every decision to adopt an AI tool has two cost surfaces. One is the cost of doing it unsafely: the data breach, the regulatory fine, the reputational damage. The other is the cost of not doing it at all: the lost market share, the talent exodus, the competitor who ships your feature before you. These costs are calculated in different departments, on different timelines, with different reporting lines, and they never meet in the same spreadsheet.
The security organization calculates the risk of adoption. They’re good at this. They have frameworks, tools, and decades of experience evaluating attack surfaces. They can quantify what happens when a model trained on customer data gets compromised. They can quote you the IBM Data Breach Report numbers: shadow AI breaches cost an average of $4.63 million, $670,000 more than the baseline.
The engineering organization calculates the risk of inaction. They have fewer frameworks for this, less data, less institutional support. The cost of a product that didn’t ship is invisible. No one writes a post-mortem for the feature that was never built. No one publishes a cost analysis of the quarter you lost because your security review process couldn’t keep pace with your product roadmap. But the people who’ve lived it know that invisible cost is real, and it compounds.
Neither department is wrong. Both are making the only rational calculation given the half of the cost surface they can see.
One cost surface gets measured, tracked, and reported. The other goes uncalculated until it’s too late.
The Tension That Has Always Existed#
This isn’t an AI problem. The tension between security and velocity has been a feature of enterprise technology adoption for as long as I’ve been in this industry. Every major platform shift (cloud, SaaS, mobile, DevOps) produced the same dynamic. Security wants to evaluate before adoption. Engineering needs to ship before evaluation. The tension is resolved through a combination of escalation, exception, and Shadow IT that everyone pretends doesn’t exist.
But each of those previous shifts happened on a timeline the structure could absorb. Cloud adoption took years. SaaS rollouts happened quarterly. You could fight the security battle on a single front at a time.
AI is different. AI tools ship weekly. They’re adopted by employees in hours, not months. They’re not a perimeter technology you can gate at the network edge; they’re embedded in every IDE, every chat window, every SaaS product your company already uses. The Cyberhaven Q2 2024 data found 73.8% of ChatGPT usage in enterprise environments was unauthorized. The security organization didn’t approve it. It happened, because the tools are free, they work in a browser tab, and the employee who needs them knows the answer to “may I?” is almost certainly “no.” You don’t wait 90 days for permission that may never come. You ask forgiveness instead.
The tension that was a manageable chronic condition has become an acute crisis because the resolution mechanism (escalation to the C-suite) doesn’t scale. When every team is making independent AI adoption decisions every week, you can’t escalate every one of them to an executive who’s already spread across five other priorities. The system breaks not because anyone failed but because it was designed for a volume of decisions it no longer has to process.
The Symmetry Problem#
The most common response to this tension is to pick a side. Give security more authority. Or give engineering more autonomy. Neither approach works because both sides are structurally correct in their assessment of the situation.
The security organization’s natural “no by default” posture isn’t obstructionism. It’s that they lack the authority to say “yes, but here’s how.” They have responsibility for AI governance (96% of CISOs are assigned this accountability, according to CSA research), but they rank fourth in actual decision-making authority, behind the CIO, CTO, and business unit leaders. When your only formal power is to block, blocking is what you do.
The engineers who go around security aren’t being reckless. The official process can’t deliver a decision at the speed their deadlines demand. A 60-day security review cycle exists in the same organization where AI tools are adopted in under 24 hours. The engineer who waits for permission isn’t being responsible. They’re missing their quarterly target. The engineer who deploys anyway isn’t being reckless. They’re responding rationally to the incentive structure they were given.
On both sides, people are responding rationally to the subset of the problem they can see. The structure that puts them in opposition was designed for a slower, simpler era, and it hasn’t been updated.
What Symmetry Looks Like#
The organizations that navigate this tension successfully don’t pick a side. They don’t give security more veto power or give engineering more autonomy to bypass security. They redesign the interface between the two functions.
The pattern that works has three components, and they reinforce each other.
Security enters at strategy time, not deployment time. The CISO doesn’t learn about an AI initiative when the engineering team submits a tool request. They learn about it when the initiative is being planned, and their job is to shape how it’s done, not to approve or reject after the fact. The data on this is measurable: organizations where the CISO reports to the CEO or board, rather than through the CIO, show 2.7x fewer security exceptions and 72% faster detection and response times.
The default becomes “yes, with guardrails” rather than “no until reviewed.” Pre-approved toolchains with defined risk boundaries let engineering teams move at speed within a known envelope. The security organization’s expertise gets applied to defining the envelope: what data can go where, what models are acceptable, and what audit trails are required, rather than applied to every individual request. The behavioral economics here are straightforward: a paved road is safer than an unmarked path, and people will follow the paved road if it gets them where they need to go.
The cost surface is made visible to both sides. The risk cost of AI adoption and the delay cost of inaction are calculated on the same spreadsheet, not in different departments. This is the hardest change because it requires the security organization to have business context and the engineering organization to have risk context. But the organizations that invest in this shared visibility (through embedded security engineers, joint risk reviews, and shared metrics) consistently outperform those that maintain the wall.
The Bottom Line#
We’ve built organizations where the people responsible for risk and the people responsible for velocity operate on different timelines with different information. Their only resolution mechanism is escalation to someone who doesn’t have the full picture either.
This worked, barely, when technology adoption happened on quarterly cycles. It doesn’t work when AI tools ship weekly and are adopted in hours. The structure hasn’t changed to match the pace of the technology it’s trying to govern.
The companies that figure this out won’t be the ones with the most aggressive AI adoption or the strictest security controls. They’ll be the ones that redesign the interface between security and velocity, giving both sides the visibility, authority, and incentives they need to make decisions together rather than against each other.
I’ve been in the room where the only way forward is an escalation that leaves one side losing. The company loses either way. The point isn’t to stop the escalation. It’s to design an organization that rarely needs it.