What trained on your business actually requires

Buyers ask for a model trained on their business. Vendors say yes, because the phrase sells. Both parties usually mean different things, and the gap between them surfaces about six weeks in, when it becomes clear that the expensive option was also the wrong one.

There are three distinct things the phrase can mean, and they differ by an order of magnitude in effort and in what they actually change about the output.

The three interpretations

• The system knows your facts. Your policies, products, customers, and history are retrievable at the moment they are needed. This is retrieval and context engineering, and it is what nearly every business actually wants.
• The system follows your procedure. It applies your escalation rules, your tone, your approval thresholds, your definition of a complete record. This is prompt and workflow design with good examples, plus evaluation against your own historical decisions.
• The system has internalised a pattern that cannot be described. Usually a specialised classification, an unusual format, or a domain vocabulary that no amount of context solves. This is the only case where fine-tuning is the right instrument.

Fine-tuning changes how a model behaves. It does not tell the model what happened in your business yesterday. Most requests for the first are really requests for the second.

What the first two actually require

They require that your knowledge exists somewhere an agent can read, that it is current, and that someone owns keeping it that way. That is the entire prerequisite, and it is where these projects stall, because it is unglamorous work that belongs to nobody.

The second interpretation has a further requirement that surprises people: you have to be able to articulate the procedure. Where the rule is genuinely tacit, held by one experienced person who makes good calls they cannot explain, the work is to extract and document that judgement before any system can apply it. This is valuable in itself and it is usually the harder half of the engagement.

When fine-tuning is genuinely right

Fine-tuning earns its cost when you have a large volume of consistent input-output pairs, a task narrow enough that the pattern is stable, and a reason that context alone cannot carry it, typically format rigidity, latency, or unit economics at scale. If you cannot state which of those three you are solving for, you are buying a fine-tune to satisfy a phrase in a slide.

And understand what it commits you to. A fine-tuned model is an artefact that needs versioning, re-training as the underlying base changes, and its own evaluation. It is infrastructure, not a one-off procurement, which is exactly the reason it should sit in an account you control rather than inside somebody else's product.