Is AI good enough yet?

"Is AI good enough yet?" is a question I get asked a lot, in one form or another, usually by people running established businesses who are wondering whether now is the time to start using AI.

In a recent conversation, a senior person from an established retail chain asked me exactly that (whether, in my opinion, AI was good enough yet to use across different areas of their business), and partway through the question he stopped to say that he fully expected me to give a resounding "yes", assuming that telling him AI was ready for anything was how an AI consultant like me would win the work.

But what struck me at the time was that I definitely wouldn't have said yes, at least not as a flat answer for the whole business. My own way of thinking about it seemed fairly obvious to me: it depends on what you want AI to do. And it was the fact that we were coming at it from such different directions that made me think it was worth setting out how I actually think about it, and why I think trying to pin down a point where AI becomes "good enough" is the wrong way to look at it.

That's not to say his point of view was wrong. His whole reason for asking was that he wanted his company to be an early adopter, but not the one who takes the pain of having a failed project. That makes complete sense: nobody wants to put time and money into something that isn't going to deliver, and in his position I'd probably be asking the same thing. It's a sensible way to try to manage the risk, but I think there are better ways of doing that than waiting for AI as a whole to be ready.

Where I start

I didn't always think about applying technology this way. Earlier in my career I was probably more technology focussed, so when a new type of machine learning model, or something like deep learning, came along, I would investigate what it could do, and start looking for somewhere to use it. I still understand the appeal (exploring something new is part of how you learn what's possible), but I've seen again and again how easily the technology becomes the focus of the work. You spend your time getting it to do something impressive, and gradually lose sight of whether that thing is useful to the business. You can end up with a very good demo and very little reason for anyone to keep using it. At the end of the day, if something solves the business need, it doesn't really matter which technology was used to achieve it.

So now I always try to start with the business: what it's trying to achieve, and how the work is currently done (who does it, what information they have, and where things go wrong). Separately I'd also want to know what's at stake if an answer is wrong, as that can add complexity in the form of extra checks and guardrails that need to be built in.

Sometimes the answer isn't AI at all: if a decision follows clear rules, standard software can apply those rules. And sometimes the existing process is fine as it is: there has to be a worthwhile improvement to justify changing it.

Good enough for what?

Once I understand the job, the next question is which approaches might suit it, and "AI" covers quite a few different things. Now, when most people ask about it, they usually mean generative AI: tools like ChatGPT, which produce text, images and so on. But AI covers a range of approaches, many of which were in use long before ChatGPT:

• Predictive models can use historical data to forecast demand or estimate a price.
• Optimisation can help work out schedules or routes within practical constraints.
• Language models can help with drafting, summarising and answering questions over text.
• Computer vision can help inspect products or extract information from images.

A single business might have a use for several of these, and how hard each job turns out to be depends far more on its details than on which kind of technology it uses. A well-established technique can still be a difficult job to get right in a particular business, and some uses of generative AI are already fairly well understood (and reasonably risk-free).

So "is AI good enough?" is really several questions bundled together, and they don't all have the same answer. The way I think about it, "good enough" isn't a property of AI at all: it's a match between what a particular job needs and what a particular approach can reliably do, and both of these factors change from one use case to the next.

How proven is it for this job?

When I say a job is well understood, what I mean is: has this kind of approach already been made to work on this kind of job, in conditions similar to yours?

This way of thinking certainly isn't something I invented, and it isn't new to AI: engineers have thought about technology this way for a long time. NASA came up with technology readiness levels in the 1970s, and the EU now uses the same nine-level scale to judge the research it funds through its Horizon programmes. Roughly speaking, the levels fall into three stages:

• Early research (levels 1 to 3): the basic idea has been worked out and shown to work in principle.
• Testing (levels 4 to 6): it has been made to work in a lab, and then in conditions close to the real thing.
• Proven in use (levels 7 to 9): a working system has been demonstrated, and then proven, in the conditions it will actually be used in.

What I find useful about it is that it's an established way of thinking about exactly this question, and it maps quite naturally onto AI. Different use cases sit at different levels: some are well proven, with plenty of examples of them working in conditions like yours, while others are much closer to the research end, with more unknowns and more risk. And even near the top of the scale, how well something works can still vary from one company to the next, depending on its data and the specifics of the job. So within a single company, the use cases on the table can be spread right across these levels.

To work out roughly where a particular use case sits, and how much is still unknown, I'd try to answer four questions:

• How complex is this particular case? The scale, how much things vary, if there are difficult exceptions, and how much of the existing systems and ways of working would have to change around it.
• Has something similar been made to work before? Ideally somewhere like yours, and not just in a demo.
• Can you tell when it's right? Some jobs have a clear answer to check against and give the same answer every time; others come down to a judgement about quality, and the output varies from one run to the next. In some cases, if two people looked at the same task, they might not even agree on the answer.
• Is there data to support it? And is it in a state anyone can actually use?

The more of those that come out well, the more confident you can be that it will work.

A separate question, alongside how well it might work, is how consequential the decisions are. The EU AI Act sorts AI systems into risk levels based on what they're used for: a standard spam filter faces no additional obligations, while software that sorts CVs for recruitment, or assesses whether someone is creditworthy, is classed as high risk (meaning that additional safeguards need to be put in place). This doesn't typically change whether a use case is possible. It just means that some of them need additional work to do them in a compliant way.

One business, two different answers

To make that more concrete, take a business that sells its products online, and two things it might want to use AI for.

The first is writing product descriptions for its website. Language models already do this well, and it's a fairly common use. The information needed is mostly there already (in the existing product details and supplier information), and it's easy to tell whether a description is right: someone who knows the products reads each one before it goes live and fixes anything that's wrong. Nearly everything comes out well against those four questions, so for this job there's not much reason to wait, and you wouldn't be particularly early at all.

The second is answering customer queries automatically. It uses the same kind of technology, but it's quite a different job. The questions vary a lot, many of the answers depend on looking up live information (where an order is, or what the returns policy says for a particular product), and the answers go straight to customers without anyone checking them first, so it's harder to tell when it's right and it matters more when it isn't. To be confident it works, it would need testing properly before it goes live, and for that you'd want a good set of past customer queries (and how they were answered) to test it against. Something similar has been made to work elsewhere, but whether it would work well enough with this business's customers and systems is a genuinely open question.

And if the business wanted to take that further and make it agentic, so that it could act on what customers ask (arranging a return or changing a delivery date, for example) rather than just answering, that's more advanced again. It may well be possible, but it would need more investigation: working out which actions would actually be useful to customers, and how well the business's existing systems would let an AI system carry them out.

So the same technology, in the same business, gives two different answers to "is it good enough?", which is why I don't think the question can be answered for a whole business at once.

What if it isn't obvious?

Having worked on these sorts of problems for a long time, I can usually get a fairly good sense from the outset of how complex a job is likely to be, and which approaches are likely to work. That doesn't mean I always know in advance, but I can usually say which elements contain the most risk. Then, wherever there's enough potential value to justify it, I'd strip away everything around that part and run a short feasibility study on it, so we can find out very quickly whether it's likely to work (without wasting a lot of money). This is really about avoiding that "pain" of going the whole way through developing a full system, only to find at the end that it isn't going to work as well as it needs to: that's the one scenario we really don't want to end up in.

With the customer queries, for example, the open question might be whether the answers would be good enough to send to customers, given how varied the questions are. That can be tested on a sample of real past queries well before anyone builds the chat window or connects it to live systems. Either you establish there's value worth building on (with a clearer view of any limits), or you learn that it isn't up to the job and try something else or stop. A good result doesn't make the rest of the build easy (and not every project needs a study at all), but it does mean the biggest unknown has been dealt with first.

Where to start

Sometimes a business comes to me with one particular use case in mind, and then it's really a case of looking at that one on its own merits, using the same questions as above.

Other times the starting point is broader: something along the lines of "we think AI could be useful in our business, but we're not exactly sure where", often with a set budget to work within. In that case I'd usually start with a discovery piece of work, to get a good sense of what the business actually does. How long that takes depends on the size of the company and how varied its work is, but it generally means talking to the people involved, and looking at the data and systems that any use of AI would rely on.

From there I can map out the possible use cases and prioritise them: how much each one is likely to be worth, how confident we can be that it will work (and whether any part of it needs a feasibility study first), whether the underlying data, systems and people are ready. The budget then helps decide how far down that list it makes sense to go.

I also look at what they have in common (the same data, the same systems, similar security and monitoring), so that ideally the first project leaves something the next one can build on, whether that's data that has already been cleaned up, connections to existing systems, or something learned in a feasibility study that applies to more than one proposal. Done well, that means each project after the first should be quicker and more efficient to deliver, because more of the groundwork is already in place and some of the unknowns have already been dealt with.

That said, each one still needs judging on its own merits: getting one use case to work doesn't automatically prove the next one will.

So, is it good enough yet?

For plenty of jobs, yes, but you only find that out by breaking the question down:

• Start with the business, not the technology.
• Judge each use case on its own: how proven is the approach for that particular job?
• Test the uncertain part first, before committing to the full build.
• Plan across use cases, so that each project builds on the last.

That's also my answer to the person who wanted to be an early adopter without being the one who takes the pain. For some jobs he wouldn't be particularly early at all, for others a short feasibility study takes a lot of the risk out, and some are probably best left for now. That's not quite the resounding "yes" he was expecting, but hopefully it's a more useful one.

---

If you'd like help working out which AI use cases are worth pursuing in your business, and which to start with, get in touch.

References

• European Commission, Horizon 2020 Work Programme 2014 to 2015, General Annexes, "G. Technology readiness levels (TRL)": ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf
• NASA, "Technology Readiness Levels": nasa.gov/directorates/somd/space-communications-navigation-program/technology-readiness-levels
• European Commission, "AI Act" (regulatory framework for AI): digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation, "Revised Guidance on Model Risk Management" (SR 26-2), 17 April 2026: federalreserve.gov/supervisionreg/srletters/SR2602.pdf