Share with your CISO
The EU AI Act, NIS2, DORA, and the NIST AI Risk Management Framework are converging on the same operational demand: treat AI systems with the same criticality, dependency mapping, and incident-response discipline you’d apply to any infrastructure your business can’t afford to lose. The BCI’s argument for extending existing resilience controls to AI rests on a striking data point: 72.5% of organizations already run a formal resilience programme, typically led by business continuity managers, not a dedicated AI governance function.
What this means for your business
The compliance instinct here is to stand up a new AI governance structure, hire for it, and buy tools to support it. That instinct is expensive and probably wrong. If your organization already has mature business continuity discipline, the gap isn’t capability, it’s coverage. The question worth asking before your next budget cycle is whether your existing change management, business impact analysis, and incident escalation processes actually extend to the AI models now embedded in fraud detection, customer workflows, or supply-chain decisions, or whether they stop at the layer above.
The harder analytical point is about failure modes. An AI system failing doesn’t look like a server going down. The model stays available while producing degraded or quietly wrong output, and that ambiguity is exactly what existing incident frameworks aren’t calibrated for. Recovery time objectives written for internally hosted systems get invalidated the moment a critical process depends on a third-party model provider’s own recovery capacity. Organizations that haven’t explicitly tested that dependency haven’t actually tested their recovery plan; they’ve tested a comfortable fiction about it.
The frame worth noting is that the BCI, whose membership and advisory work center on resilience professionals, has a natural interest in positioning that profession as the right home for AI governance rather than IT security or a standalone AI function. That tilt is real, but it doesn’t make the argument wrong. The more honest read is that whichever function owns AI governance at your organization, the disciplines described here, criticality mapping, change control, threshold-based incident escalation, need to be owned clearly by someone with enforcement authority, not distributed across teams that each assume another is covering it.
Concept deep-dive: Recovery Time Objective
A Recovery Time Objective, or RTO, is the maximum tolerable downtime a business process can absorb before the disruption causes material harm, essentially the clock that starts when something breaks and stops when it’s restored. RTOs are typically set during business impact analysis and then baked into vendor contracts and recovery plans. The problem with AI-dependent processes is that the RTO may be set against an assumption, internal hosting, owned infrastructure, that the actual architecture no longer reflects.
Based on reporting from From AI Regulation to Resilience Practice: What Continuity Teams Need to Do Next, originally published 2026-11-02 20:05:00.
