As AI becomes embedded in core business processes, a new leadership challenge is emerging. Most organisations can tell you where AI is delivering value. Few can identify where they have become dependent on it.
As artificial intelligence moves from experimentation into the operating fabric of the business, a new category of risk is being created. Organisations are increasingly using the technology to write code, support customers, analyse risk, inform decisions and coordinate and trigger workflows across systems. In doing so, it has become intertwined with technology, people, suppliers, data and critical business processes.
The result is a growing reliance on capabilities whose availability, behaviour and ownership may sit partly outside an organisation’s control. When those dependencies are not fully understood, the consequences of disruption can extend far beyond the original use case.
When an AI tool is peripheral, failure is inconvenient. When it is embedded in a critical workflow, disruption will have far wider implications for operations.
As business leaders consider how to deploy AI safely and at scale, a more fundamental question is emerging: where is the organisation becoming dependent on it?
Autonomy turns dependency into delegation
Dependency becomes more consequential when AI moves from supporting work to acting within it. A system that summarises documents creates one type of exposure. A system that updates records, routes alerts, prioritises customers, drafts regulatory responses or triggers workflows creates another. At that point, the organisation is not only relying on a capability; it is delegating authority. Leaders need to understand what the system can access, what it can change, how quickly its actions can spread across connected systems and processes, and whether those actions can be contained orreversed.
This does not mean the greatest risk is unpredictable behaviour. A system may behave exactly as instructed while optimising for the wrong outcome. A sales agent may increase conversion while creating conduct risk. A coding assistant may accelerate development while introducing vulnerabilities. A compliance tool may generate confident but incomplete analysis. As AI takes on greater autonomy, thecentral question extends beyond model performance to the governance of delegated authority and the boundaries placed around it.
We saw this when advising the CTO of a SaaS company piloting AI in a customer-facing workflow, which delivered faster resolution, greater automation and less human intervention. The model was designed to be rewarded for speed, but it could also avoid appropriate escalation, become overly persuasive or create security, conduct and reputational risks elsewhere.
The AI was operating exactly as intended. The blind spot was that technical and product performance were being measured separately from the wider consequences of delegated authority.
The CTO ultimately paused the pilot before increasing autonomy. The lesson was simple: optimisation can create risk. Success against one metric doesn’t guarantee the right outcome.
Accountability cannot be outsourced
A regulator, customer, investor or court is unlikely to accept that a poor outcome was caused by “the AI”. Responsibility remains with the organisation and with the leaders who approved, tolerated or failed to understand the operating model around it. They do not need visibility into every technical detail. They do need a defensible understanding of where AI is used, what it can affect, who owns the risk and how the organisation would intervene.
A useful test is: Can we see it? Can we stop it? Can we reverse it? Can we substitute it?
When the answer is no, AI may already be more embedded than the control environment can support.
The real risk is silent dependency
AI dependency often develops incrementally through everyday adoption rather than formal transformation programmes. Developers begin using AI to write code. Customer teams use it to draft responses. Risk teams use it to summarise evidence. Gradually, the organisation becomes faster but less aware of where judgement has shifted, where data is flowing and which activities would slow or fail if the capability disappeared.
The challenge is that dependency can become strategic before it becomes visible. That is why AI resilience should begin with policy supported by a dependency map. The map should identify the technology, people, suppliers, data and critical services around each use case – and how disruption could cascade across those connections:
- Where is AI being used?
- Which uses are becoming business-critical?
- Which providers, models, infrastructure and data flows do they rely on?
- What would happen if access changed?
- Where is AI influencing decisions or taking action?
- Which failures would be reversible?
- Who owns the risk?
These questions are not meant to slow adoption. They are intended to make it durable and help organisations build lasting advantage.
The board conversation needs to change
AI discussions still focus heavily on use cases, productivity and governance principles. Those conversations are necessary, but they do not tell a board where operational dependency is forming, whether the organisation can withstand disruption, how much authority has shifted into AI-enabled systems or how an AI incident could cascade across technology, operations, suppliers, people and reputation.
The board-level conversation must move from adoption to dependency. Leaders need to understand which AI-enabled capabilities are becoming critical, who controls them, what authority they hold and how the organisation would respond if they failed or became unavailable.
Long-term success with AI will depend as much on resilience and control as on adoption. The organisations that succeed with AI will be those that understand where AI creates genuine advantage, where it creates fragility and where concentration is acceptable. They will preserve the ability to switch provider, adopt a different model or isolate a critical dependency without disrupting the business.
AI is no longer just a capability question. It is a resilience question.
The risk is not AI adoption itself. It is allowing dependency to outpace visibility, control and the ability to recover.