The Control Inversion
Why the biggest risk in AI adoption is the system built to prevent risk
Your organisation says it wants AI. The CEO said it at the end-of-year results. Leapfrog the competition. Leverage the technology. Move faster than anyone expects.
The next morning, a customer-facing AI pilot gets blocked by a second line team citing security concerns.
The concerns are not wrong, exactly. They are not specific either. They are a category of discomfort dressed in the language of governance.
The strategy says move. The structure says wait. And the structure always wins.
The System That Cannot Receive What the Strategy Demands
Most organisations treat AI adoption as a technology problem. Choose the right tools. Train the right people. Build the right infrastructure. When it stalls, they diagnose the failure as technical: the model was not accurate enough, the data was not clean enough, the integration was too complex.
That diagnosis is comfortable. It is also wrong.
The technology works. It has worked for over two years now. The tools are accessible, the cost is dropping, and the capabilities are accelerating faster than most leadership teams can track. The reason AI adoption stalls inside large organisations is not that the technology is immature. It is that the structures built to govern risk were designed for a world where the primary danger was moving too fast.
The primary danger has inverted. And the governance has not.
Control functions inside organisations, particularly in regulated industries, were built around a single premise: slow things down so they can be checked. Every process, every approval gate, every review cycle exists to prevent the organisation from doing something wrong. That made sense when doing something wrong was the most expensive outcome.
It no longer is.
The most expensive outcome now is doing nothing whilst the environment moves. And the control architecture has no mechanism for measuring that cost. It can quantify the risk of a failed pilot. It cannot quantify the risk of a pilot that never ran.
This is not a technology problem. It is a structural problem. The organisation has built a governance system that can assess execution risk with precision and has no equivalent framework for assessing inaction risk at all.
What “Because It Is New” Actually Means
A senior leader I work with recently proposed an AI-powered feature for a customer-facing banking app. The feature had cleared the test environment. The technical design was clean: rate-limited API, cost ceiling, existing DDoS controls fully in place. The go-live date was set.
Second line blocked it. The reason given: DDoS risk.
The problem was that the organisation already had mature DDoS protection. The existing controls were pattern-based, not endpoint-specific. They detected abnormal traffic and evicted bad actors. They had been doing this successfully across every other service the bank operated.
When asked what specific risk the existing controls would fail to address, the answer was: “It is new technology.”
That answer sounds reasonable. It is not a risk assessment. It is the absence of one.
When a new cyber threat emerges, the control function does not say “we cannot allow network traffic because this is unfamiliar.” It identifies the specific vector, assesses the likelihood and impact, applies proportionate controls, and lets the business continue. That is mature risk management.
With AI, the same function was doing something fundamentally different. It was treating novelty itself as the risk. Not a specific data exposure. Not a specific model failure pathway. Not a specific regulatory gap. Just: this is new, therefore no.
That is not governance. It is a refusal to govern.
And it is hiding behind the language of caution to avoid doing the actual work of assessment.
The Real Cost of the Control Loop
Every time a control function blocks a capability on the basis of novelty rather than specific, identified risk, a sequence begins inside the organisation. It is predictable. It is measurable. And it compounds.
The first cost is precedent.
If “it is new” is sufficient grounds to block, then every future capability, every model update, every feature release triggers the same loop. The organisation does not build a risk framework for AI. It builds a queue. And the queue becomes permanent.
This is how organisations create what looks like a governance process but is actually a holding pattern. Each new AI use case arrives at the same gate. The same questions are asked. The same concerns are raised. The same requests for further review are issued. Nothing is ever resolved at the level of principle, because resolving it would mean establishing a framework that permits AI capabilities to proceed without case-by-case approval. And case-by-case approval is the mechanism through which the control function maintains discretionary authority over whether the organisation moves.
The precedent does not just slow AI. It teaches the organisation that proposing AI capabilities is expensive. Not in money. In time, in political capital, in the energy required to navigate a process that has no clear endpoint. The most capable people, the ones with the strongest ideas and the clearest view of what is possible, learn the lesson fastest: do not propose. The cost of trying exceeds the reward of succeeding.
The queue does not just delay innovation. It selects against it.
The second cost is invisible and already happening.
The people who need AI to do their jobs do not stop when the formal channels close. They use personal accounts. They paste sensitive data into consumer tools. They build workarounds on unapproved platforms. They route around the controls because the controls gave them no legitimate path forward.
This is not rebellion. It is the rational response to an irrational constraint. When an organisation blocks AI usage without providing an approved alternative, it does not eliminate the demand. It pushes the demand underground, into spaces the organisation cannot see, cannot monitor, and cannot govern.
Research from 2025 confirms what anyone paying attention already knows: shadow AI is now one of the most significant compliance risks in enterprise organisations. Employees are using external, unvetted tools to aid decision-making without IT oversight, creating data leakage, compliance exposure, and uneven productivity across teams. The irony is precise. The control function blocked the pilot to protect against risk. The consequence of blocking the pilot is more risk, distributed across more surfaces, with no visibility and no controls at all.
A governed pilot with rate limits, monitoring, and approved data handling is incomparably safer than fifty employees using personal ChatGPT accounts with no guardrails. But the governance framework cannot see that, because it only measures the risk of what it approves. It has no mechanism for measuring the risk it creates by refusing to approve.
The control function is not reducing risk. It is redistributing it to places it cannot see.
The third cost is strategic, and it is the one that should keep the executive committee awake.
The CEO tells the market: we will leapfrog competitors through AI. The board approves the investment. The strategy is announced. And then the operating reality delivers something entirely different. The pilot is blocked. The capability is deferred. The timeline slips. The people who were hired to execute the strategy spend their time in governance meetings instead of building.
This gap between strategic commitment and operational delivery is not new. Organisations have always struggled to execute against ambitious targets. But AI compresses the timeline in ways that make the gap existential rather than merely inconvenient.
The competitive window for AI adoption is not measured in years. It is measured in quarters. Organisations that deploy AI capabilities into customer-facing products now are building feedback loops, gathering data, refining models, and compounding their advantage with every iteration. Organisations that are still debating whether the pilot is safe enough to run are not standing still. They are falling behind at an accelerating rate, because the organisations ahead of them are learning whilst they are deliberating.
Forty-two percent of companies abandoned most AI initiatives in 2025, up from seventeen percent the year before. Ninety-five percent of AI projects fail to demonstrate profit-and-loss impact. And the primary barriers are not technical. They are organisational: people, processes, and politics. Only six percent of organisations qualify as AI high performers seeing meaningful bottom-line impact. The rest are spending without moving.
The pattern is consistent across industries. Established firms, the ones with the deepest control architectures and the most layered governance, experience the steepest productivity declines after initiating AI adoption. Research from MIT found that older organisations saw declines in structured management practices after adopting AI, and that this organisational friction alone accounted for nearly a third of their productivity losses. Not the technology. Not the models. The friction between the new capability and the old structure.
The control architecture is eating the thing it was built to protect.
The fourth cost is the one nobody measures, because the people it affects leave quietly.
The best people inside an organisation, the ones who can see what AI makes possible, who have the skills to build it, and who understand how it connects to the business strategy, are also the people with the most options. When the control loop blocks their work for the third or fourth time, they do not fight harder. They update their LinkedIn profile.
Talent retention does not appear in any risk register. No control function includes “probability of losing your best people because the governance process made their work impossible” in their assessment framework. But it is the cost that compounds fastest and reverses slowest. You can change a governance process in a quarter. Replacing the person who left because of it takes a year, if you can replace them at all.
The organisation does not see this as a consequence of its control architecture. It sees it as a hiring problem, a market problem, a compensation problem. It is none of those things. It is the direct, traceable result of a system that made the cost of trying higher than the cost of leaving.
Why the Blocker Blocks
It is tempting to read this as a story about cautious people resisting change. It is not. The people inside control functions are not irrational. They are responding to the incentives the system gives them.
Consider the position of someone in a second line function. Their mandate is to identify risk and ensure controls exist. They are evaluated on what they catch, not on what they enable. When something goes wrong that they approved, their career suffers. When something does not happen because they blocked it, nobody notices.
The asymmetry is structural. The cost of approving something that fails is visible and attributable. The cost of blocking something that would have succeeded is invisible and diffuse. No one writes a report about the pilot that never ran. No one measures the revenue that was never generated, the capability that was never built, the talent that left because the organisation could not move.
Inside this incentive structure, blocking is always the safer career move. Not for the organisation. For the individual.
And when you add the possibility that existing positions on infrastructure resilience may not hold up under the scrutiny that new capabilities invite, the incentive to block becomes even stronger. The concern is no longer about the pilot. It is about what the pilot might reveal about decisions already made.
The pilot is not the risk. The pilot is the mirror.
The Feature Already Exists
In the case of the banking pilot, the technical argument was remarkably simple once you stripped away the governance theatre.
The feature already existed in the app architecture. The endpoint was already live. The attack surface was the feature itself, not the AI component. Anyone who wanted to exploit it could already try. Routing a subset of users to an LLM-powered version of that feature did not expand the attack surface. It changed what happened on the backend when the call was processed.
The DDoS risk profile of the app had not changed. What had changed was the cost profile of a successful attack on that specific endpoint, because GPU compute is more expensive than a standard server response.
The solution was one sentence: rate limit the API.
Set the threshold correctly based on the cost profile. Let the existing monitoring detect anomalous patterns. Let the eviction controls do their job. The same pattern the organisation already used for every other service.
The entire governance debate collapsed into a configuration decision. Not a policy debate. Not a committee review. A threshold, set correctly, that resolves the only new variable the AI feature introduced.
Everything else was theatre.
What the Middle Sees
The person who navigated this situation was not at the top of the organisation or the bottom. He was in the middle. He reported both ways. His job was to surface friction to leadership and translate strategy back down into execution.
This is the position that carries the most structural weight and the least formal authority. The person in the middle can see the CEO’s commitment. They can see the control function’s resistance. They can see the gap between what the organisation says it wants and what the organisation will actually allow. And their job is to make that gap legible without becoming the casualty of the truth they are carrying.
The instinct is to argue the case: “Let me do this pilot. Here is why it is safe. Here is the technical rationale.” That framing positions you as someone seeking permission. And permission-seeking invites gatekeeping.
The stronger move is to use the control function’s own stated position as the foundation of the argument. If the resilience ratings say the app is mature, if the control reports say DDoS protections are robust, then there is no technical basis for blocking a feature that the existing controls already cover. The pilot is not an exception to the governance framework. It is a direct consequence of the governance framework’s own conclusions.
That reframe changes the dynamic entirely. You are not asking for an exemption. You are holding the system to its own standard.
The Move That Changes the Room
The leader I worked with did not win this by arguing louder. He did not escalate. He did not accuse anyone of protecting a prior position. He did something more precise.
He engineered the timing.
The pilot cleared the test environment. The go-live date was confirmed. The feature was tied to a strategic priority that the CEO had committed to publicly. And then he put the clean technical argument on the table: the attack surface is unchanged, the existing controls apply, the only new variable is cost, and the rate limit resolves it.
At that point, blocking was no longer free. Blocking a strategic priority, after the test phase was complete, when the technical controls were documented and the residual risk question had been asked directly, required an explanation that would travel upward.
He did not change the argument. He changed the cost of ignoring it.
This is the difference between being right and being placed. Anyone can be right. Placement requires understanding that the same words, delivered at the wrong moment, dissolve into the room’s existing logic. Delivered at the right moment, inside the right structure of consequence, they become unavoidable.
What AI Adoption Actually Reveals
The conversation about AI in organisations is dominated by two framings. The technical framing asks which tools, which models, which infrastructure. The change management framing asks about training, culture, and mindset.
Both miss the deeper pattern.
AI does not break your organisation. It reveals it.
It functions like a stress test you did not request. Every organisation has informal agreements, unstated compromises, and positions that are accepted rather than verified. These exist at every level: in how budgets are justified, in how infrastructure is assessed, in how risk is reported, in how authority is distributed between functions that enable and functions that control. In stable environments, these agreements hold because nothing tests them. The systems run. The reports are filed. The ratings are maintained. Everyone proceeds on the basis of what has been stated, not what has been examined.
AI changes the speed, and speed changes what is visible.
When a new capability requires the infrastructure to perform under conditions it has not been tested against, the distance between stated resilience and actual resilience becomes measurable. When a pilot requires approval from a control function whose mandate has not been updated for the current environment, the distance between governance and gatekeeping becomes observable. When a strategic commitment requires execution that the operating architecture cannot deliver, the distance between what the organisation says it is and what the organisation actually is becomes undeniable.
AI is not the disruption. It is the diagnostic.
Consider what the banking pilot revealed, without anyone intending it to. It revealed that the control function’s DDoS objection could not withstand basic technical scrutiny. It revealed that the resilience ratings had not been updated for the load profile that AI features would create. It revealed that a control function was using procedural authority to avoid rather than assess. It revealed that the incentive structure rewarded blocking over enabling. It revealed that the middle layer of the organisation, the people responsible for translating strategy into execution, had no formal mechanism for surfacing the cost of inaction.
None of these are AI problems. Every one of them existed before the pilot was proposed. The pilot simply made them impossible to ignore.
This is the pattern across industries. Organisations that struggle with AI adoption are not struggling with a new problem. They are struggling with old problems that the pace of AI adoption has made visible for the first time. The rigid workflows. The entrenched power structures. The misaligned incentives. The gap between what is reported and what is real. The absence of any governance mechanism that weighs the cost of standing still.
Research from Harvard Business School confirms this directly: firms struggle to capture value from AI not because the technology fails, but because people, processes, and politics do. Fear of replacement, rigid workflows, and entrenched power structures quietly derail initiatives even in companies with advanced tools. The organisations that succeed are the ones that redesign incentives, workflows, and governance to align human behaviour with technological capability.
But most organisations are not doing that. Most organisations are overlaying AI onto existing structures and expecting the structures to hold. They are asking a governance architecture built for a slower, more predictable world to process capabilities that move at a speed the architecture was never designed for. And when it fails, they blame the technology, the training, or the culture. They do not examine the architecture itself.
The architecture is the problem. And AI is the instrument that made it visible.
Every executive who says “we are struggling with AI adoption” is actually saying something more revealing, whether they know it or not. They are saying: the way we make decisions, allocate authority, assess risk, and distribute consequence is not built for the environment we now operate in. AI did not create that gap. AI measured it. And the measurement is unflattering.
The question is not whether your organisation can adopt AI. The question is whether your organisation can see itself clearly enough to understand why it cannot.
The Question That Changes the Outcome
If you are in the middle of this, if you are the person who can see the strategic commitment and the structural resistance and the widening gap between them, the question is not how to get your pilot approved.
The question is: does your organisation have a governance framework that weighs the cost of not acting with the same rigour it applies to the cost of acting?
If it does, the pilot is a configuration decision. Set the rate limit. Set the threshold. Let the existing controls do their job.
If it does not, the pilot is the least of your problems. Because every capability that follows, every model update, every feature, every competitive move that requires speed and judgment under uncertainty, will hit the same wall. And the wall is not protecting you. The wall is the risk.
The control architecture was built to prevent the organisation from doing something dangerous.
It is now the most dangerous thing the organisation is doing.