This past Thursday, the email and meeting tools much of the working world relies on went down in at least 74 countries. Then, on Friday, every departure in the U.S. stopped, marking only the second nationwide ground stoppage since 9/11.
Neither of these incidents was an attack, and AI wasn’t to blame. In fact, Microsoft said so directly: the outage had nothing to do with cyber activity or AI agents. It traced the failure to an earlier network upgrade that surfaced after a recent network change. Federal officials, too, found no evidence of a cyberattack on air traffic control, and pointed instead to a contractor’s routine upgrade from copper to fiber, and a router that flooded the network.
Nothing exotic happened, and that should give us all pause. These were ordinary changes inside enormously complex systems upon which billions of people depend. If something that ordinary can stop the world, then getting it back can’t wait until something breaks. This underlines the case for adopting a posture of proactive, continuous recovery.
The truth is no one fully understands the decades of infrastructure, patches, updates, and new connections the modern world runs on. And while that complexity enables our modern world to move so efficiently and rapidly, it’s also what can cause it to stop just as fast. One change in one place, and the systems everyone relies on grind to a halt.
Now add AI, and near-autonomous agentic systems that change settings, grant access, and move data faster than anyone can watch. Now add bad actors using AI at a scale no human team can match. I call it AI vulnerability: more change, more connections, and more ways to fail, all at machine speed. This week wasn’t AI but the next one likely will be.
When something breaks, the hardest hours come after the alarm, when you’re working out what changed and what you can still trust. Applications, identities, configurations, and their dependencies have to come back together, in the right order: clean, trusted, and ready to run.
So recovery can’t be a plan you test once a year. It has to be a continuous proactive state, not a defensive one.
This week at SHIFT in Nashville we showed what this looks like in practice. ResOps treats resilience as something you operate continuously rather than a plan you test once a year, discovering what you have, detecting what changed, and recovering exactly that. If you want more on ResOps, check it out here.
Resilience is what every board wants. Continuous recovery is the only way to get there, from the attack you’re bracing for and from an ordinary Thursday that nobody saw coming.
