LLMs for Business: What Your Options Are and How Each Fits

An LLM —a large language model— is the engine that reads and generates text inside an AI system: it interprets an email, drafts a reply, pulls data out of a document, or reasons over a set of rules. For a business, the relevant decision is not which LLM is “the best” but which type of model fits each use, based on four things: what data it handles, how much it can cost, how fast it must respond, and what compliance demands. This article is the map of the options. The criterion for deciding task by task I develop separately.

The most common mistake I see in a boardroom is asking for “the best model on the market” as if it were a one-time purchase. It isn’t. There are categories of models with different profiles, and choosing well means understanding those categories, not memorizing names from a ranking that expires every quarter.

What an LLM is in a business context

An LLM is a component, not a finished product. On its own it converses. To make it execute business work you have to wrap it in rules, permissions, access to your systems, evaluation and traces. That wrapper is what turns a model into an agent that operates, and it’s also where most of the work lives. The model matters, but it’s the easiest piece of the whole to change. The full system I describe in AI agent architecture.

Getting this straight early changes the conversation: you aren’t buying a brain, you’re picking an engine for a system you control.

The three model categories

Almost every option falls into one of three families. None is better in general. Each solves a different profile of need.

Category	What it is	Fits when
Frontier models via API	The most capable models, hosted by their provider and contracted through an API (the models from Anthropic, OpenAI or Google as a category)	You need top reasoning quality and accept that data is processed under contract with a third party
Self-hosted open models	Models whose weights you can download and run on your own infrastructure	Control of the data and environment matters more than having the latest capability, and you have someone to run them
Small specialized models	Compact models, often tuned for one specific task	The task is bounded and repetitive, and cost and latency per case matter more than versatility

Most serious operations end up using more than one category at once: a frontier model for tasks that need judgment, a small model for repetitive volume, and sometimes a self-hosted model for what can’t leave the building. The question isn’t which one you pick, but how you split the load.

The four fit criteria

To know which category fits a use, I look at four things.

Data. What information goes into the model and how sensitive is it? If there’s personal data or trade secrets, where and how it’s processed stops being a technical detail and becomes a compliance decision. I develop this in AI agents and data privacy.

Cost. Price per case multiplied by real volume. A frontier model can be a rounding error at a thousand cases a month and ruinous at a million. The math that matters is your volume, not the list rate.

Latency. How long the response can take without breaking the process. An overnight accounting close tolerates seconds; a reply inside a live conversation does not. Speed is a process requirement, not a preference.

Compliance. What your regulatory and contractual frame demands about where data may reside and be processed, and which traces you must keep. This criterion sometimes decides the category on its own, before you even look at quality or price.

These four criteria rarely point at the same model, and that’s the work: weighting them by task. Where each option runs —in your infrastructure or via API— is a decision in its own right that I cover in on-premise vs cloud AI agents.

The mistake of hunting for “the best model”

Hunting for the best model in the abstract is like asking which is the best vehicle without saying whether you’re moving house, commuting, or crossing a desert. The question has no answer because it’s missing the context that would make it answerable.

There are three concrete reasons “the best model” is a bad goal:

• The ranking expires. The frontier moves every few months. A system tied to today’s winner is born with an expiry date.
• The best is usually overkill. The most powerful model is also, almost always, the most expensive and the slowest. For most of your tasks that’s overpaying for capability you don’t use.
• It locks the architecture. Designing around one specific model turns a swap into a project. Substitutability is what protects that investment.

That’s why I treat models as a utility: selected per task and replaced when it makes sense, without touching the process. The provider’s name should be the easiest detail to change in the whole system.

What happens when the model you run goes away

Picking the category is one decision. Holding it over time is a different one, and it almost never gets budgeted. Models contracted through an API have a lifecycle: the provider ships new versions, marks the old ones for retirement and eventually switches them off. That is not an accident or bad practice on the provider’s part, it is what treating the model as utility actually means. The bill for that choice arrives when the version your process has been running for months gets switched off.

The shutdown is not the problem, and it usually comes announced. The problem is that your process is calibrated against the behaviour of one specific version. The instructions you give it, the thresholds at which a case escalates to a person and the examples you use to steer it were all tuned against that behaviour. Change the version and all of it shifts a little, almost always upward in raw capability and almost always unpredictably at the edges, which are exactly the cases that decide whether the operation holds.

With self-hosted models the clock runs the other way and the bill still lands. Nobody switches anything off, so the version sits where it is until someone notices it has gone untouched for too long, that new capabilities never arrived and that whoever knew how to operate it has left. That is debt too, just without a notice date.

What makes the change manageable is having planned for it before you needed it. Four things, none of them expensive if you build them in at the start:

• Pin the version, not the family. Have the system point at one specific version, and make changing it an explicit decision rather than something that happens on its own when the provider moves an alias.
• Keep an evaluation set that works as an acceptance test. Without a body of cases with known answers you cannot say whether the new model holds quality, and you end up deciding on impression. How to build one is in AI agent evaluation.
• Require notice in the contract. How far ahead they tell you about a retirement, and what overlap window you get to test and migrate. Almost nobody asks this at the buying table, and it decides whether the migration is a Tuesday or a quarter.
• Keep the model separate from the process. If rules, permissions and traces live outside the model, replacing it is swapping a part. If they live inside one provider’s primitives, it is rewriting the process.

The board question that follows is who does that work. If you contract the model and maintain the system, the cycle is yours and has to be staffed. If you buy the operation rather than the tool, whoever runs it absorbs that cycle, and it is one of the real differences between the two ways of buying that I separate in AI managed services.

From model to system

Choosing the category is the beginning, not the end. An LLM knows nothing about your company until you give it: your documents, your rules, your data. The technique for making the model work over your own knowledge without retraining it is RAG, which I explain in enterprise RAG. And the process of deciding which specific model goes to each task, evaluating quality, cost, latency and risk, is in choosing the best LLM for each task. This article gives you the map of options; that one, the method for deciding. All of it fits inside the wider picture of AI agents for business.

Frequently Asked Questions

What is an LLM for business?

An LLM is a large language model: the engine that reads and generates text inside an AI system. In a company it’s used as a component of an agent that executes work —interpreting emails, drafting replies, extracting data— wrapped in rules, permissions and traces. It’s not a finished product but a replaceable piece of the system.

What types of LLM can a business use?

Three main categories: frontier models contracted via API, open models you can self-host on your infrastructure, and small specialized models for bounded tasks. Each fits a different profile of data, cost, latency and compliance, and many operations use several at once.

What is the best LLM for a business?

There’s no single best one for everything. The best depends on the task and on the data, cost, latency and compliance criteria that apply. Hunting for the best model in the abstract leads to overpaying and to tying the architecture to a winner that expires. The sensible move is to choose per task and keep the ability to switch.

What happens if the provider retires the model my process runs on?

API models have a lifecycle and versions eventually get switched off, normally with notice. If your process points at one specific version, you keep an evaluation set that works as an acceptance test, and your rules live outside the model, the swap is a few days’ work. If not, it is a project that starts the day it stops working.

How often do I need to change models?

There is no calendar, there are two triggers. One is the provider, when it announces the retirement of the version you use. The other is yours, when a new option improves quality, cost or latency enough to justify the test. The healthy position is to have the mechanism in place and use it when it applies, rather than deciding each time whether building it is worth it.

Do I need a different model for each task?

Not always different, but rarely the same for everything. Tasks differ in quality demand, tolerable cost and data sensitivity, so a well-designed system routes each task to the model that balances it best rather than imposing one across the whole operation.