Buying · 8 min read · Sep 15, 2026
Four things get sold as “an AI solution.”
“AI solution” is the least informative phrase in enterprise software. It is applied to a login to somebody else's model, to a chat box over a help centre, and to a system that runs unattended against your books — three products with different failure modes, different obligations and different prices, described in the same sentence. Here is how to tell which one is in front of you.
The word describes the buyer, not the product
Every category of software eventually acquires a word that means "the thing you want" rather than "the thing this is", and for the moment that word is solution. It survives because it is unfalsifiable. A vendor who says they sell an AI solution has told you nothing you can check, which is precisely why the phrase is on the homepage.
That matters at signature. Two proposals using identical language can differ by an order of magnitude in what they oblige the vendor to do, and the difference is usually invisible until the thing is wrong in production and somebody has to decide who owns it.
Four products, one name
Almost everything marketed as an AI solution falls into one of four tiers. They are not ranked — tier one is the right purchase for plenty of teams — but paying tier-four prices for a tier-two product is a common and expensive mistake.
| Tier | What you are actually buying | Who carries it when it is wrong |
|---|---|---|
| Model access | A key to somebody else's model, billed per token | You do, entirely |
| Wrapper | A prompt and a UI over that same model | You do, with a support email |
| Workflow product | A model embedded in a defined business process | Shared, if the contract says so |
| Operated system | A process, plus evaluation, review and fallback | The operator, by design |
The tell is not the demo. All four demo identically, because a demo is a curated case and all four handle curated cases well. The tell is what exists around the model — and that is a question about operations, not about intelligence.
The only question that separates them
Ask what happens on the case it gets wrong. Not whether it gets things wrong; it will. Ask what the system does next.
A tier-one or tier-two product does the same thing it always does: it returns the wrong answer, confidently, in the same format as a right one, and passes it downstream to whoever trusted it. Nothing detects this. The first person to notice is a customer or an auditor. A tier-four system catches its own uncertainty, routes that case to a person, and records that it did — so the failure becomes a queue item rather than an incident. We have written separately about what that containment looks like in practice.
If a vendor cannot describe, concretely, what their system does on a case it gets wrong, they are selling a wrapper at operated-system prices.
What a real one carries
The parts that distinguish an operated system from a demo are unglamorous, which is why they are missing from most proposals. Five of them:
- An evaluation set drawn from your history. Including the exceptions that previously needed a human decision — that is where systems actually fail, and where invented test cases never look.
- A human gate on anything irreversible. Payments, submissions, deletions, anything a customer sees unreviewed. Automation stops at the point where being wrong cannot be undone.
- A written data boundary. What leaves your systems, where it is processed, how long it is retained, and whether it trains anything — answered before the pilot, in writing.
- A known cost per run. Not a licence fee. What one document, one call, one report costs to process, and what that becomes at full volume.
- A fallback path. What the business does on the day the model provider is down or the upgrade changes behaviour. If the answer is "stop working", it is not in production.
None of those require trusting the vendor's claims about model quality, which is the point. They are all checkable before money moves.
“Solution” is the wrong unit to buy
The deeper problem with the word is the shape it implies: a thing that arrives, is installed, and solves something. Very little of this behaves that way. Model providers change models underneath you. Your own process changes. The exceptions that were rare become common because volume grew.
So what is actually being bought is a system plus the operation of it over time, and the contracts that work say so — who re-runs the evaluation after a model change, who watches the review queue, who is accountable for the number the board sees. A proposal that is silent on all three is describing a handover, whatever it is priced as.
The practical version of this is narrow and boring: pick one process, agree the pass mark before building, run it on one entity against reports you already trust, and only then widen. Most of what goes wrong with AI purchasing is a scope decision made before any of that evidence existed — which is the same reason so many pilots never reach production.
Dealing with this in your own group?
We answer scoping questions before there's a contract in sight — including the ones about cost and data handling.