---
title: 
date: 0001-01-01
canonical: https://mariothomas.com/blog/_draft/
---

# Maybe We Do Not Need AI After All

Last week at the IoD Chartered Director Conference, on a panel about governing AI, an audience member asked me how I actually decide whether to use it. My answer began with two questions I have come to rely on. What are you trying to do, and do you really need a model for that. They do a great deal of work, and most of the time they are enough. But sitting with the answer afterwards, I realised there is a question that belongs before both of them, and that it is the one almost everyone skips. The task in front of every Board now is remaking the business around AI. That mandate is settled, and I have made the case for it at length. The first act of judgement inside it, though, is not choosing a tool. It is deciding what is even worth remaking, because the honest answer cannot be everything. Remaking everything with AI is not transformation. It is fashion with a budget. Better business judgement produces better AI decisions. This article is about the judgement that has to come before any decision about a model.

## Three honest things you can do with any piece of work

Most conversations about AI begin in the wrong place. They begin with the model. Which one, how large, how expensive, hosted where. That is a real decision, but it is the last one, and starting there quietly assumes the two decisions before it have already been made correctly. Usually they have not been made at all.

[The Great Remaking](/blog/the-great-remaking/) is best understood as a magnifying glass held over the whole business. Hold it over any single piece of work, look at that work honestly, and there are only three things you can do with it. You can leave it as it is. You can stop doing it. Or you can remake it. Only the last of those reaches a tool decision, and even then the choice is between AI and something simpler. Most of the time the conversation never gets near the harder question buried underneath the tool. It starts with the model and works backwards. Look through the magnifying glass instead, and one question keeps turning out to matter more than the rest.

That question is whether the work still needs doing at all. Businesses accumulate work the way houses accumulate objects, quietly and without decision. A report is produced this quarter because it was produced last quarter. An approval sits in a chain no one has revisited since the person who designed it left. A monthly reconciliation still runs to catch a discrepancy that was engineered out of the system three years ago, and nobody has thought to ask whether it is catching anything now. A committee pack grows a section every time something goes wrong and loses one only when someone retires. None of it is doing harm, exactly, which is precisely why no one stops it. We have watched this happen in a neighbouring field. AWS's enterprise-strategy guidance on cloud migration observed that when organisations finally examined their application estates and asked who still used each thing, [as much as 10 percent, sometimes 20](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/), turned out to be no longer useful and could simply be switched off. That figure is about software, not about AI, and I offer it only as evidence for a broader habit. Hold a magnifying glass over a body of work and a meaningful share of it turns out not to earn its place. This is why the first question is the valuable one. Choosing a clever tool for work that should have stopped is often the most expensive mistake of the three, because you pay to build it, pay to run it, and pay a third time in the attention it draws away from work that matters. The best saving usually arrives before any technology does.

Only once that question is answered honestly does the second one become worth asking: what are you actually trying to do. This pulls the conversation back from technology to outcome, where it belongs, and it is remarkable how often the elaborate thing someone set out to build was never the thing they needed.

Only then, third, do you ask whether you really need a model. This is where fact-work and judgement-work part company. Some work has one right answer. A balance reconciles or it does not. A count is right or it is wrong. Other work is judgement, where the honest output is a reasoned view of an uncertain situation and there is no single right answer waiting to be looked up. The [four indicator types](/blog/maximum-fidelity-four-indicators/) I have set out elsewhere separate the confirmed fact from the signal, the forecast, and the reasoned conclusion, and it is the fact-work that gives this third question its force. A model is the right instrument for judgement. It is the wrong instrument for a question that already has one right answer, and handing that kind of question to a model is where the trouble tends to start.

## The task that taught me this

I learned this from my own work. I wanted a list of tasks pulled from a system of record and shown in a file that refreshed itself. It looked like an AI job, so I built it as one. It returned a different answer almost every time it ran. The task had exactly one right answer, and I had handed a fixed question to a probabilistic tool that was entitled to work it out afresh on every pass, and did, arriving somewhere slightly different each time.

The tool was not broken. It worked exactly as designed. It reached the source and it received correct data. It still produced a wrong and varying answer, because completeness and counting had quietly become the model's decisions to make rather than settled parts of the task. That is the real danger, and it is easy to miss. The wrong answer did not look wrong. It looked exactly like a right answer: plausible, confident, and slightly different from the last one. Had I not known the correct number independently, I would have had no way to tell which run to trust.

Rebuilt as a few lines of ordinary code reading the data directly, it returned the right answer every time, for a fraction of the cost, and it has not varied since. I want to keep the lesson from this narrow, because it is easy to inflate. I am not saying that ordinary code is trustworthy and models are not. Deterministic systems can return the wrong answer perfectly consistently. The lesson is only this: a task with one right answer should not be handed to a tool that decides it afresh on every run. There is a quieter lesson underneath it, too. The elaborate self-refreshing file I first imagined was never really the thing I needed. The simpler tool did the actual job, which means the honest answer to the first question had already reshaped the whole exercise before the tool question ever arrived.

## The discipline of remaking

The remaking is real and the mandate stands. Nothing here is a retreat from that case. But remaking well is not remaking everything, and it is certainly not putting a model into everything. The three questions are simply how a Board exercises judgement inside the mandate. They stop the work that should stop. They leave alone the work that already does its job. And they spend AI where the work genuinely calls for reasoning, synthesis, or judgement, rather than where a simpler tool is better, cheaper, and more reliable.

The organisations getting the remaking right are not the ones putting AI into everything and calling it transformation. They are the ones doing the harder work of deciding, task by task, what to stop, what to leave, and what to remake with a model. Better business judgement produces better AI decisions, and there is no shortcut that skips the judgement and arrives at the good decisions anyway. **The willingness to say a task does not need AI, or does not need doing at all, is what makes AI investment credible, not a retreat from it.**