Who owns AI's bad day?

An IT leader told me last week that he has deliberately refused to own AI in his business. "AI is not really an IT thing," he said. He didn't want IT's handbrake on something that could be useful to the business.

I think he's right. I also think his business now has a problem nobody has noticed: when the AI goes wrong, there is nobody to call.

He knew exactly what an hour of downtime costs for each of his core systems. Ask the same question about the AI already running through his business and the answer isn't there. AI sits in the client service system, the file platform and the CRM, alongside Copilot, a ChatGPT pilot and a team trying Gemini for visualisations. When staff lost their corporate ChatGPT accounts in the move to Copilot, some went back to personal accounts with company documents.

Here is the short version. The industry is busy debating who owns AI strategy. In the mid-market, the gap that will hurt first is who owns AI's bad day.

Why this matters now

The same week, a health and aged-care organisation told me about its weekend disaster recovery test. It failed over to its secondary site, and a single legacy platform took an hour and a half to two hours to come back. Its emergency department system depended on it. Nobody had mapped that dependency until the test exposed it. Their response was the right one: zero appetite to leave it as it was for another day.

That is what a rehearsal is for. Almost nobody I speak to rehearses AI. Continuity plans have pages for the server room and the internet link, and none for the agent that drafts customer replies or the assistant every manager now relies on to read their inbox.

Stepping back from AI doesn't step IT out of the blame. In one global survey, nine in ten CIOs said central IT would still be held accountable for security or compliance failures caused by AI tools the business bought on its own.

What organisations are getting wrong

They treat ownership as one question when it is two. Who decides what AI is for belongs with the business. Who can switch it off at three in the morning, and decide what runs in its place, has to be named in advance. Leaving the second one blank is how a good programme turns into a frightened one.

We have seen that too. One client said yes to an AI programme, then grew so worried about everything that might go wrong that it stopped altogether. Fear filled the space a plan should have occupied.

And they assume the old playbook covers it. AI rarely fails with an error message. It fails by quietly doing the wrong thing at normal speed, which is exactly what a monitoring dashboard won't catch.

What this means for providers like me

A managed service provider's runbook is forty pages about servers going down. A managed intelligence provider has to write the page that's missing: what each AI capability touches, who can stop it, what the manual fallback is, and when it was last tested. We have just been certified to ISO/IEC 42001 for AI management, and the discipline that matters most isn't the certificate. It is being able to answer that page for every agent we build or run.

Three things to do before Christmas

• Name one person who can switch off each AI capability in your business, and make sure they know it.
• Add your top three AI-dependent processes to your next disaster recovery test, and write down what the manual fallback is.
• Ask your provider to show you the AI page in their incident runbook. If there isn't one, you have found your first project.