Machine learning or generative AI: which does your problem need?

The question usually arrives as a choice between two technologies, and that framing is slightly off. The UK government's AI Playbook defines machine learning as the branch of AI that learns from data, and says plainly that modern large language models are also examples of machine learning systems. Generative AI, in the Playbook's words, is a subset of AI capable of generating text, images, video or other forms of output by using probabilistic models.

The line that matters to a buyer sits between two kinds of system you could build. The first is a predictive model trained on your own records to answer one narrow question, such as which invoices are likely to be paid late. The second is a large model that someone else trained in advance, which you call through an API and point at your documents and workflows. For the rest of this page I call the first predictive machine learning and the second generative AI, because that is how suppliers sell them.

They differ on almost everything a sponsor cares about: the data you need before you start, where the money goes, how the system fails and how you prove it works. They also need different people. That is why it matters whether a supplier's recent work trained models or called them.

The quickest test is the shape of the answer. If the output is a number, a probability or a label from a fixed list, and you hold past cases where you know how things turned out, you are looking at predictive machine learning. If the input or the output is free text, a document or an image, and there is no single correct answer to train on, you are looking at generative AI.

Decisions about people also raise data protection questions, about fairness and about how accurate the system is, which the ICO's guidance on AI and data protection covers. The ICO says that guidance is under review following the Data (Use and Access) Act, so check the current version with your data protection officer before the design is fixed. This page is not legal advice.

Many of the systems worth building combine the two, and the combination is often safer than either on its own. The usual split gives the language model the unstructured part of the job and hands the decision to something that can be tested case by case.

Take supplier invoices that arrive as PDFs. A language model reads each one and pulls out the supplier, the amounts and the purchase order number, and rules then match those fields against the purchase order. A predictive model trained on past invoices flags the ones that look unusual, and a person approves those. Each step has its own test, and at no point does the language model have to be right about money on its own.

That shape, where the model proposes and a deterministic check decides, is the one I reach for whenever a wrong answer costs money or affects a person. It also works the other way round: a language model can turn free text into inputs, such as the topic of a complaint, that a predictive model then uses alongside your structured data.

Predictive machine learning needs history before it can do anything. You need past cases with the outcome recorded, enough of them to cover the situations the model will meet, and a definition of the outcome that did not change halfway through the data. The Playbook's warning applies directly: AI systems rely heavily on the quality and quantity of data, and insufficient data can leave a model failing to generalise. If the outcome was never recorded, the first project is collecting it.

Generative AI needs no training data to start, which is why a prototype can appear within days and why demos flatter it. It still needs three things from you: the documents or records it will read, access controls so it sees only what the person using it may see, and a set of real cases with known good answers to test it against. I would rarely start with fine-tuning a model on your own data. Putting the right documents in front of it usually matters more.

Either way, check access, quality, ownership and personal data for the one use case before anything is built. A feasibility answer that arrives after the build is just an expensive one.

Neither approach is cheaper in general. They spend money in different places and fail in different ways, so a business case written for one will miss the costs of the other. The table compares the drivers rather than prices, because prices depend on your volume, your data and the scope.

Both columns share the costs that business cases tend to leave out: an owner, monitoring, and a re-test every time the model, the data or the prompt changes. Put those in before comparing the two, or the cheaper-looking option will simply be the one with fewer lines counted.

Predictive models have the easier evaluation problem, because there is a right answer. Hold back data the model never saw in training, ideally the most recent months, and measure it there. Compare it with the simple method it would replace, such as last year's figure or the current rule, because a model that cannot beat that is not worth running.

Pick the measure that matches the cost of being wrong. The ICO's guidance on AI separates precision, the share of cases flagged as positive that really are positive, from recall, the share of real positives that get flagged, and notes the trade-off: chasing recall can cost you false positives. A fraud model that misses little but flags a great deal will bury the team that checks its output.

Generative AI is harder to test, because there is often no single right answer. Build a set of real cases from your own work, a few hundred where you can, write down what a good answer must contain, and grade the output against it, with people checking a sample. Include cases designed to go wrong, such as documents carrying hidden instructions and questions your sources cannot answer.

Do not buy on public benchmark scores. NIST's profile for generative AI warns that measurement gaps arise from mismatches between laboratory and real-world settings, and that tests restricted to benchmark datasets may not carry over to real conditions. A model's score on a public test tells you very little about your invoices.

Both need checking after launch as well as before. The Playbook asks for full testing before deployment, regular checks of the live tool, and a way for users to report problems that prompts a human review.

The two approaches call for different people, and the Playbook says so directly: developing bespoke AI solutions and training your own models require different specialist skills from using pre-trained models through APIs. Hiring the wrong profile is an expensive way to find that out.

The government's Digital and Data Profession Capability Framework draws the same line. It describes a machine learning engineer as someone who develops, assures and maintains machine learning models so they can be used in products and services, and at senior level deploys them into production and checks that live models stay safe, secure and continue to work. Its data scientist explores data using statistical tools and techniques, such as machine learning and predictive analytics, to inform decisions.

The same goes for suppliers. A firm selling machine learning consultancy and a firm selling generative AI can each be strong on their half and thin on the other. Ask each for the last system it put into production of the kind you need, and how it proved that system worked. If the problem needs both, you want one party accountable for how the pieces fit, which is the job described in our guide to what an AI solution architect does.

For a business weighing several possible uses, 1AYM's AI Opportunity & Feasibility Sprint is where I would settle this. It is fixed scope and typically takes two to four weeks: we look at how the work runs today and what your data and systems can support, score the candidate use cases on value, feasibility and risk, settle build versus buy, and set out the technical architecture for the recommended direction. You come away with a plan an engineer can build from and a sponsor can fund.

Where the answer is a system built on pre-trained models, with the controls that let it touch real data and real decisions, we build that too, as fixed-scope production AI systems work. 1AYM takes small fixed-scope statements of work as well as larger builds, and if you already have a scoped job, we can resource it on contract from the collective of associates who work with us, held to the same standard. If you want a second opinion on which kind of problem you have, book a call below.