I have worked on hundreds of business cases. Every one was written inside a department or a division, and written for the benefit of that department or division. That is not a criticism. It is what a business case is for.
The only one I ever saw that mentioned disaster recovery was a business case about disaster recovery.
That was fine for thirty years. It is not fine now, and the reason has nothing to do with the quality of the cases or the people writing them.
The AI business case and the continuity plan never meet
Two owners, one assumption, no shared document
An AI business case is built by a business unit that wants to be better at the thing it does. Faster lease abstraction, cleaner forecasts, fewer touches per invoice. The case compares the world with the project against the world without it, over three or five years, and both of those worlds are assumed to keep operating.
Continuity belongs to somebody else. IT owns it, writes the plan, tests it on its own cycle, and reports on it to a different committee.
The continuity plans I have read all have a section saying the work will be done manually and reconciled when service returns. Underneath that section sits an assumption: somewhere in the business are people who know how to do the work without the system.
Not named. Not budgeted. Not tested. Present.
That assumption survived mainframes, client-server, ERP, the web, mobile and the cloud. Every one of those waves changed how the work was done and left behind the people who knew how to do it. The process moved. The knowledge stayed in the building.
The gap is not a missing number. It is a seam between two owners.
And a second seam opens after the deployment goes live. The business has reduced its human fallback and increased its dependence on a provider it does not control. Two dependencies moving in opposite directions, neither of them recorded in the document that authorized the move.
Nobody skipped a step. No step exists.
Stated as a CFO would state it: the case captures the labor avoided. It does not capture the replacement cost of the capability being consumed, because that capability has never appeared on any ledger.
The first wave that can consume the fallback
Earlier automation moved the process and left the practitioners
Earlier waves removed people too. Mainframes removed clerks, ERP removed accounting staff, self-service removed transaction processors. The distinction is not headcount.
What those waves left behind was enough capability to reconstruct the process. The people who understood the work were still in the building, and parts of the job were still done by hand, so the understanding stayed current without anybody maintaining it.
An AI deployment is funded on the basis that it absorbs volume. That is the case, it is usually a good case, and the savings land. What lands with them is the headcount change that made the numbers work. Some of those people leave. Others are redeployed, which sounds gentler and often is, though it depends on how completely and for how long they leave the work.
The relevant question is not whether they are still on the payroll. It is whether anyone is still doing the thing by hand, and how recently.
Keeping a human in the loop does not solve it
What thirty years of research says about reliable systems
The obvious answer is that the people are still there, supervising rather than doing. A human stays in the loop, the process gets reviewed, the capability is preserved.
Two things are wrong with that, and both are established rather than argued.
Reliability degrades the reviewer. Parasuraman, Molloy and Singh ran a multitask flight simulation in 1993. Participants monitored an automated system while handling other jobs. For one group the automation was consistently reliable. For the other it varied. After about twenty minutes, the group watching the reliable automation was substantially worse at catching its failures. The reliability itself degraded the monitor, and the effect disappears when monitoring is the only job, which matters because enterprise reviewers rarely have one job.
Rarity degrades detection. Wolfe, Horowitz and Kenner published in Nature in 2005. Observers searched simulated baggage x-rays, and the only thing that changed between conditions was how often a target was actually there. At fifty percent prevalence they missed seven percent. At one percent they missed thirty.
Think of it as Where’s Waldo, except Waldo is only on one page in a hundred. You would find him on page one. By page forty you would be flipping. By page ninety-nine you have stopped looking in any way that counts, and when he finally shows up you turn straight past him.
Nobody decides to stop looking. The absence of a decision is the whole problem.
The two research traditions rarely cite each other, and they describe the same condition from opposite ends. Ninety-nine percent accuracy, from the reviewer’s side of the desk, is an environment where an error shows up once in a hundred.
So two things govern whether a reviewer is a control or a formality: how often errors appear, and whether the reviewer is doing anything else.
| Errors frequent | Errors rare | |
| Reviewer does nothing else | Works. Frequency keeps them calibrated, attention is undivided | Prevalence pulls detection down, though single-task monitors held up regardless of reliability |
| Reviewer has a queue and a day job | Degraded and still functioning. Finding things regularly keeps them in the task | Both effects compound. The quitting threshold falls and attention goes to the work that visibly needs it |
This is a way of locating the problem rather than a model of it. Bottom right is where many enterprise review roles end up, and it is where a successful deployment can put you.
The deployment moves you right, because the errors the reviewer sees become rarer as the model improves. It moves you down, because the headcount that justified the project is gone and the people left absorb other work. Both movements are consequences of the project delivering what it promised.
You do not choose that cell. You arrive in it, and the arrival looks like a win in every report written about it.
Reviewing is not doing
Recognition and construction are different skills
The loop is assumed to do a second thing, and it matters more to the seam than the first does.
Keeping a person in the loop is supposed to keep the capability alive. If the model goes away, the reviewer can do the work.
Checking a proposed answer is recognition. Building the answer from source material is construction. From outside they look adjacent, and they train different things.
A senior property accountant, twenty years in, can look at a rent roll and tell you within about four seconds that something is wrong before she can tell you what. The number does not sit right against a building she knows, in a market she knows, at a time of year she knows, and the reasons surface afterwards.
That did not come from approving rent rolls. It came from building them, being wrong, and being corrected, over and over.
Hire her replacement into a review role and they never acquire it. Keep her in one for three years and it fades, because the thing that maintained it was the doing.
The continuity assumption is not only weakened by the people who left. It is weakened by the people who stayed.
Two clocks start the day you approve
The fallback capacity ratio, in three numbers you already own
One is the payback period. Everybody watches it. It appears in the case, in the post-implementation review, and in the slide that says the project delivered.
The other measures how long until the fallback is gone. Nobody computes it, and it can run faster than people assume, because skill can decay faster than headcount disappears.
You can read it in an afternoon, with three numbers you already own.
Daily volume. Units per day through the process.
Per-person manual throughput. Units one trained person completed per day before the deployment. Somebody has this, because it was in the case that funded the project.
Capable headcount. People who have actually done the work by hand. Not the org chart for that function. Names, and when each of them last did it.
Multiply the second by the third to get manual daily capacity. Divide that by daily volume. Call the result the fallback capacity ratio.
At 1.0 the fallback keeps pace. Above it, the work gets absorbed. Below it, the fallback cannot keep pace with incoming volume, so backlog grows for every day the model is unavailable. Materially below 1.0, the continuity plan describes a state the organization cannot reach.
Then run it again with an honest view of how good those people are now, three years into reviewing rather than doing.
The ratio is not a forecast and does not need to be precise. It needs to be spoken out loud in the room where the case is approved, because right now no number occupies that seat at all.
Then the next case arrives
Why the exposure does not stay the same size
The next deployment gets proposed against the fallback as it stands now, not as it stood before the last one. The manual alternative has quietly become worse, which makes automating further look less risky than it did.
Each case is approved on the evidence available in the room. Each one lowers the bar for the next. The direction is not symmetric either, because capability is rebuilt by doing the work and being corrected, which takes years and requires somebody who still knows how to correct you.
The exposure does not stay the same size.
The second dependency, the one you acquired
When the provider disappears for reasons that are not technical
Everything above is about the fallback you spent. The other half of the seam is the dependency you took on in exchange for it.
The scenario worth planning against is not a model producing a wrong answer. That is what the reviewer is for, degraded or not. It is the model being unavailable while the work still has to happen.
In June 2026 Anthropic released its two most capable models. Three days later the US Department of Commerce issued an export control directive requiring the company to restrict access by any foreign national, anywhere. Anthropic said it had no reliable way to verify nationality in real time, so it suspended access to both models for all users. Access was restored on 1 July, after the controls were lifted.
Eighteen days. No notice, and it began three days after customers were invited to build on it.
Nothing broke. No outage, no bug, nothing to detect. A regulator acted, a provider complied, and the capability was gone.
The standard advice is to abstract behind a gateway and keep a second model warm. That is sound and it does not help here. No abstraction routes around a jurisdiction, and a second vendor inside the same one fails on the same morning.
Continuity planning assumes failures are largely independent. Your systems and your competitor’s do not go down on the same morning for the same reason. Shared providers and shared jurisdictions break that assumption, and the people who price risk noticed first. In January 2026 ISO form CG 40 47 became available to carriers, removing bodily injury, property damage and personal and advertising injury arising out of or attributable to generative AI from commercial general liability.
Coverage counsel put the logic more plainly than an essay can. A bad employee email reaches one customer. A bad chatbot answer may reach thousands.
Transferring this risk is getting harder at exactly the point more organizations are taking it on.
Who owns this
Four questions for the room where the case is approved
I do not think there is a general answer, and I have seen enough organizations to be wary of anyone offering one. Where this sits depends on who holds the operating model, and whether continuity reports somewhere with the standing to ask a division a hard question.
The shape of the problem is clearer. The case is written by the division that benefits. The exposure lands on a function that was not in the room. The assumption connecting them was never written down, because until now it was never wrong.
So these are ownership questions before they are technical ones.
Who was in the room when the AI business case was approved, and who owns the continuity plan for that process? If those are different people who did not speak, that is the seam.
Which processes still have someone who can do them by hand, and when did they last do it? Names and dates. This is the only question here with a factual answer, and most organizations cannot produce it.
What is our fallback capacity ratio? If it is below 1.0, say so out loud before the next case is written.
Which processes are we willing to run with no fallback at all? That is a legitimate answer. Plenty of businesses depend on capabilities that would simply stop, and pretending otherwise is its own kind of dishonesty. What is not legitimate is arriving there without having chosen it.
The business case was never designed to hold any of that. It was built to compare two versions of a division’s operating performance, and it does that job well.
The AI business case just cannot see the thing it is spending.
Brian Zrimsek has occupied all four seats in enterprise software: advisor at Big Six consultancies, analyst at Gartner, client at Irvine Company, and provider at MRI Software. He is the Enterprise Software and Commercial Real Estate Specialist for Lumerai Advisors. Advisor, analyst, client, provider. He writes at The Four Seats.
