What "AI" actually means when someone tries to sell it to you
The word covers at least five genuinely different technologies, with different costs, different risks and different ways of failing. Knowing which one is in the proposal is most of the work of evaluating it.
The word on its own tells you nothing
"We use AI" is now roughly as informative as "we use software". It is true of a chatbot on a contact page, a model predicting which customers will churn, a camera counting cartons, and a script that files invoices by driving a browser. Those four things share almost nothing: not the data they need, not what they cost to run, not how they fail, and not what happens to your business when they are wrong.
This matters commercially, because the proposals are priced as if they were the same thing and they are not. Below is the taxonomy we use in our own scoping conversations, written out plainly so you can use it on us too.
The five things people mean
1. Language modelsSystems that read and write text. Drafting, summarising, rewriting, answering. Impressive out of the box and genuinely useful, but they know nothing specific about your business unless you give it to them.
2. Retrieval (RAG)A language model wired to your own documents, so answers come from your price list and policies rather than from the model's training. This is what turns a generic assistant into one that can answer about you.
3. Agents and automationSystems that do things rather than say things: filling forms, moving files, driving the applications your team clicks through daily. The value is in hours removed, not in the conversation.
4. Prediction on your dataClassic machine learning over your own numbers: which orders will be late, which customers will lapse, how much stock to hold. Older than the current hype, and often the highest return.
5. PerceptionReading the physical world through cameras and sensors, and sometimes acting on it with machines. Counting, inspecting, locating, moving.
What is not AIA rules engine, a scheduled script, a well-built search box. All perfectly good, frequently the right answer, and often quietly relabelled as AI on a pitch deck.
Two questions that sort out which you need
You rarely have to understand the technology to work out which category your problem sits in. Two questions do most of it.
What does the system need to know? If the answer is "general knowledge and good English", that is a language model. If it is "our documents, our prices, our policies", you need retrieval on top. If it is "our history - what happened last year and the year before", that is prediction on your own data. If it is "what is physically happening right now", that is perception.
What does it need to do with that? If the answer is "tell a person", you are building an assistant, and the risk is bounded because a human reads it before anything happens. If the answer is "take the action itself", you are building an agent, and the entire engineering problem changes - now you need permissions, logging, reversibility and a checkpoint before anything you cannot undo.
That second question is the one most proposals skip, and it is the one that determines the cost.
Genuinely good at, and badly oversold for
Genuinely good at: anything with high volume and forgiving tolerances. Drafting a first version. Summarising a long thread. Classifying incoming messages. Extracting fields from semi-structured documents. Answering the same forty questions your staff answer every week. Spotting a pattern across more rows than a person would read.
Badly oversold for: anything requiring a guarantee. These systems are probabilistic - they produce a likely answer, not a certain one. If your process needs "always", the AI part belongs behind a deterministic check, or somewhere else entirely.
The useful reframing: AI is very good at producing a draft of almost anything and quite bad at producing a guarantee of anything. Design around that and it works. Design against it and you get a system your team stops trusting, which is worse than not having built it.
The cost nobody quotes properly
Buyers tend to ask what the model costs. That is usually the smallest line. The real cost sits in three places.
Getting at your data. The documents are in four systems, two formats and one person's inbox. Before anything intelligent can happen, something has to collect, clean and keep that current. This is the majority of most AI projects and it is not glamorous.
The failure path. What happens when it is unsure, when it is confidently wrong, when the source document was out of date. Designing that path properly costs more than the happy path, and skipping it is why so many pilots never reach production.
Keeping it honest. Your prices change, your policies change, your process changes. A system answering from last quarter's documents is worse than no system, because people believe it.
A proposal that prices only the model is not pricing the project.
How to tell a real proposal from a wrapper
- Ask what it does when it is unsure. A good answer describes an escalation path. A bad one says it is very accurate.
- Ask where the answers come from. If nobody can name the source documents, it is a general model with your logo on it, and it will invent things.
- Ask what happens when your prices change. If the answer involves rebuilding, you are buying a snapshot.
- Ask to see it fail. Anyone can demo the good case. Ask for the awkward one - the edge case your staff hit every week.
- Ask who is accountable when it is wrong. If the system acts on its own and the answer is vague, that is your liability, not theirs.
Where a person belongs
Our rule is the same across every category: the further a system moves from telling someone toward doing something, the more explicit the human checkpoints have to be.
An assistant drafting a reply needs no gate, because a person reads it before it is sent. An agent issuing a refund needs one. A machine that moves needs one that works even when the software does not. The test is not how clever the system is - it is how expensive it is to be wrong, and whether the mistake can be undone.
Where that has real weight is in physical AI, where a decision becomes a motor turning and there is no undo at all.
Going deeper
On retrieval specifically - how a system matches a question to your content by meaning rather than keywords - we have written that up plainly.
On perception, what a camera can actually deliver and why one accuracy number hides the answer you need, start here.
And for a build where retrieval, perception and a machine all met on one site, see the Hock Lim Engineering rover case study.
Not sure which of the five you actually need?
Describe the problem in your own words - what you know, what you want to happen, and what it costs when it goes wrong. You will get a straight answer about which category it falls into, including when the honest answer is that it needs no AI at all.