The demo was spectacular. The LLM summarised the document, answered the customer's questions and even caught an error nobody had seen. Three months later, in production, the same system invents data 4% of the time, costs more than the salary of the person who used to do the task, and nobody can explain why it answered that yesterday. The distance between demo and product is where most AI integrations die.
The right question isn't "can we add an LLM?" — technically you almost always can — but "should this product have an LLM?". This guide is the checklist we use to answer it without the hype: four gates that must be crossed in order, and if one closes, the project ends right there (which is also a good outcome, because you've saved six months).
What an LLM Does Well (and What It Doesn't)
An LLM is a language engine: it transforms, summarises, classifies, extracts, drafts and converses with a fluency no other technology matches. What it isn't: a database (it doesn't "know", it predicts), a deterministic system (the same input can produce different outputs) or a guarantor of truth (when it doesn't know, it also writes fluently).
The whole checklist follows from those three limitations. If your use case can live with them, there's a product. If it contradicts them, there's a problem.
The Four Gates of the Checklist
Gate 1: Is the error tolerable?
The LLM will fail. Not if, but when and how badly. If a human reviews the wrong answer before it takes effect (drafts, suggestions, internal summaries), the gate opens. If the answer acts directly on the world — a medical calculation, a bank transfer, a signed legal text — you need a validation layer so strong that the LLM often stops being the useful part of the system. Quick rule: LLMs propose, rules dispose.
Gate 2: Do you have data to ground it?
The general model knows everything and nothing in particular. Product value appears when you ground it in your data: your documents, your catalogue, your history. That's exactly what retrieval-augmented generation (RAG) solves. If you have no grounding data — or you have it but it's scattered, outdated or without clear permissions — the LLM will answer with the average of the internet, and for that your user already has ChatGPT.
Gate 3: Do cost and latency fit the operation?
Every call costs cents and seconds. In a demo that's irrelevant; in a flow that runs a hundred thousand times a day it's the difference between margin and ruin. Do the maths with real numbers: tokens per operation × expected volume × model price, and compare against the current cost of the task. Latency is the other half: if the user waits for the answer on screen, two seconds of streaming may be acceptable; if it's an intermediate step in a synchronous chain, maybe not. Small models and response caching move this frontier a lot — but they must be measured, not assumed.
Gate 4: Can you evaluate that it works?
This is the gate most projects ignore and the one that matters most. If you can't define what a good answer is and measure it repeatably — a test set of cases with expected answers, sampled human review, user acceptance metrics — you don't have a product: you have a permanent demo. Without evaluation, every prompt or model change is a leap into the void, and silent degradation (the provider updates the model and your quality drops 10%) reaches you through complaints.
The Signs That Say It Fits
- A high-volume language task. Summarising, classifying, extracting or drafting hundreds of times a day, where a person does it today or it simply doesn't get done.
- A human in the loop. Someone reviews the result before it has consequences, or the failure is recoverable and cheap.
- Proprietary data, available and permitted. There's a corpus that grounds the answers in your reality, not the internet's average.
- Measurable quality. You can build an evaluation set of 50-200 representative cases before writing a single line of integration.
- The alternative is worse. Today the task isn't done, is done badly, or costs more than the LLM including its corrected errors.
The Signs That Say It Doesn't
- "Because the competition has it". AI as a marketing checkbox produces features nobody uses that cost money every month. If there's no concrete task, there's no product.
- Mandatory precision. Accounting, dosages, legal compliance: if the answer must always be correct, the LLM can only be a drafting assistant, never the source.
- The problem was the data. If the information is wrong, scattered or outdated, the LLM will serve it wrong, scattered and outdated — with better prose. Fix the data first.
- A business rule in disguise. "Classify tickets into three fixed categories" has been solvable with a keyword and a switch since 1995. If the domain is closed and the rules are known, classic code wins on cost, latency and reliability.
- Nobody will measure the outcome. If there's no budget or will to evaluate quality continuously, what you deploy isn't a feature: it's a faith.
The Costs That Don't Show Up in the Demo
The API price is the visible part. Underneath: the data pipeline for grounding, continuous evaluation, drift monitoring (the model changes without notice), prompt management as versioned artefacts, regulatory compliance — with the European AI Act now in force, it's worth knowing which risk category your use case falls into — and training the team that will operate it. An honest budget multiplies the API line by three or four. If the business still closes with that figure, go ahead; if it only closed with the API price, better to know now.
Common Mistakes
- Starting from the technology. "We have to use GPT-X" before having the task. The model is chosen at the end, once you know the precision, latency and cost the case needs — and often the winner is a small, cheap one.
- Measuring with the happy demo. Five hand-picked examples are not an evaluation. Without a representative test set, the launch decision is a coin flip.
- Hiding uncertainty from the user. Presenting the LLM's output with the same visual authority as a computed value invites trust where it isn't due. The interface must distinguish what's asserted from what's suggested.
- Agents before foundations. Putting an autonomous agent on top of a case that doesn't pass the checklist just multiplies the error by the number of steps it executes. Agents amplify what's there: if there's quality, quality; if there's smoke, smoke at scale.
- Forgetting the emergency exit. What happens when the provider goes down, the model degrades or the cost explodes. A fallback — even if it's "this function is temporarily limited" — is part of the design, not an extra.
In Short
An LLM fits your product when it crosses four gates in order: the error is tolerable, you have proprietary data to ground it, cost and latency close in the real maths, and you can evaluate quality continuously. If one gate closes, the honest answer is "not yet" — and that answer is worth more than any prototype. The AI that works in production isn't the most impressive: it's the one somebody measured.
If you're considering integrating AI into your product and want an answer with numbers rather than enthusiasm, we can walk through this checklist with your specific case. Let's talk →
Keep reading: What is RAG: a practical guide to giving your data to an LLM.