This article was first published on the edhec.edu website - 29/09/2026
Artificial intelligence services have already experienced outages. Brief ones, so far. Why does such a visible risk struggle to make it onto executive committee agendas? The answer lies in specific, observable mechanisms. Anne Fessan, Executive Director of Custom Programmes at EDHEC, explains.
On 23 June 2026, thousands of companies saw their artificial intelligence tools grind to a halt for several hours. In April, an infrastructure outage had already brought down several major AI models simultaneously. European financial regulators now identify dependence on a handful of providers as a risk requiring close monitoring. This information is public, dated and documented. Yet in the executive committees I observe, something surprising happens: executives readily express concern between agenda items, then move on to the next topic. Leaders are preoccupied in the most literal sense: busy worrying rather than taking action. Too rarely are they prepared.
This gap between knowledge and action is nothing new. Decision science has documented it for half a century, from predictable surprises to near misses that reassure organisations instead of alerting them. What is new is something else: watching these well-known mechanisms play out all over again, almost identically, with the technology businesses are adopting faster than any other in their history. Four mechanisms, and one false friend, largely explain why.
The first is habituation. Each outage lasted a few hours, then everything returned to normal. Every incident therefore teaches the wrong lesson: normality always returns. Concern gradually fades as outages recur without lasting consequences, just as near misses can lull industrial organisations into a false sense of security. Yet the question was never about three hours. Imagine three days.
The second is the absence of clearly assigned responsibility. As long as business continuity falls within nobody's explicit remit, everyone has good reasons not to take ownership. The executive sponsoring AI may fear undermining the ongoing rollout. The technology department may appear to be holding back progress. The risk department may be confined to its traditional role of raising warnings. None of this reflects bad intentions, merely the constraints inherent in each function. When responsibility is explicitly assigned (and deciding to whom is already a decision), progress follows. Without an owner, the issue stays off the agenda.
The third is the most human: the collective nature of an outage. If every company is affected, each can attribute the disruption to an external event rather than an internal failure. The costs, however, remain specific to each organisation: the workload previously handled by AI does not simply disappear. It accumulates as pending requests, unprocessed cases and postponed checks. Each company emerges from the outage with a backlog proportional to its dependence. Yet a risk that creates no relative competitive disadvantage often reduces the urgency to act. A shared outage does not eliminate the consequences; it dilutes the perception of responsibility.
The fourth is a matter of timing. At what point did your executive committee formally decide to become dependent on AI? The technology has spread through thousands of individual uses, often undeclared and sometimes without licences. Without a decision, there is no plan: continuity arrangements are built around predefined objectives. Companies know how to secure their energy or component supplies because, at some point, a contract was signed. Their cognitive supply chain (the capabilities provided by AI), however, has no clear starting date, no contractual provisions and therefore no continuity plan.
Then comes the false friend: the belief that the issue has already been addressed. A business continuity plan exists, critical suppliers have been mapped, and sometimes a second provider is under contract. Yet these arrangements were designed before AI became embedded in business processes. The dependency they should cover is absent because it was never formally declared. April's outage served as a reminder, simultaneously taking down several competing models that relied on the same infrastructure. The challenge is less about creating yet another plan than reviewing existing ones in light of actual dependencies. Documentation prepares an organisation. Only operational capability keeps it running.
What would a real AI shutdown look like?
Three hours create operational friction: slower emails, code left unfinished, summaries postponed. Three days begin to affect commitments. Consider a customer service department where AI models classify enquiries, summarise cases and draft responses. On day one, teams absorb the extra workload. By day three, contractual deadlines are missed: the disruption becomes a customer issue, then a financial one, and potentially even a regulatory matter in a supervised sector. The dividing line between inconvenience and breakdown lies precisely here: in processes where AI has become an essential link in the chain, rather than merely an additional tool.
All this might sound inevitable. Quite the opposite. Mechanisms this well understood do not require a crisis to be brought into the open. Putting an issue on the agenda has a limited but precise effect: it gives the subject an owner, a date and a formal record, everything it previously lacked to be recognised as a priority. The plan comes next, and it will require work. It cannot be entirely delegated: business teams, technology specialists and risk managers will contribute to mapping dependencies, but decisions about acceptable downtime, reduced service levels and the investment required belong to senior management. That is why this question belongs in the executive committee, not just the IT department. Raising it before a crisis changes the nature of the response: decisions are made through deliberate consideration rather than improvisation.
One item to add to September's agenda: what have we delegated to AI this year, and what would we do if we had to operate without it for, say, a week? The following half-hour should produce an initial framework, with four provisional answers fitting on a single page: the processes unlikely to withstand a three-day outage, an acceptable downtime threshold to be confirmed, a reduced-service operating model to be tested, and a named person responsible for the issue. These answers will need to be verified. But that list of checks is already the missing work programme. None of this constitutes a business continuity plan in itself, but it finally makes one possible.
Anne Fessan, Executive Director of Custom Programmes (EDHEC Executive Education), writing for Décideurs/RH.
Comments0
Please log in to see or add a comment
Suggested Articles
