What is a large language model and how do businesses use them?

Most business leaders have spent the last two years being told that large language models will transform their industry. Many have run a pilot. A few have deployed something into production. Almost none have a clear picture of what these systems actually are, what they can and cannot do, and where the real commercial value sits.

That gap is expensive. Not because ignorance is shameful - but because decisions made without a working mental model tend to be the wrong ones. Organisations either over-invest in the wrong use cases or under-invest because they cannot articulate the return. Both paths waste time and money.

This article will give you a working understanding of what a large language model is, how it processes information, where it genuinely adds commercial value, and where it tends to fail. It will also give you a practical way to evaluate whether a proposed use case is worth pursuing.

What a large language model actually is

A large language model is a statistical system trained to predict the most plausible next sequence of words given a preceding sequence of words. That is not a simplification - it is the mechanism. The sophistication comes from the scale of training data, the architecture of the model and the alignment work done after initial training to make the outputs useful and safe.

The models you encounter in a business context - GPT-4, Claude, Gemini, Llama and their variants - have been trained on hundreds of billions of tokens of text. They have developed internal representations of language, reasoning patterns, factual knowledge and stylistic convention that allow them to generate coherent, contextually appropriate text across an enormous range of tasks.

What they are not: a database, a search engine or a reasoning system in the formal sense. They do not retrieve stored facts the way a database does. They generate plausible text based on patterns learned during training. This distinction matters enormously in practice. A model will give you a confident-sounding answer whether or not that answer is accurate. It has no internal flag that says "I do not know this." It has learned that confident responses are usually what a human wants.

This is the single most important thing a business decision-maker needs to understand before deploying one of these systems. The model's fluency is not a proxy for its accuracy.

How businesses are actually using them

The commercially mature use cases cluster into four categories.

Content and communication at scale. A mid-market retailer with a catalogue of 40,000 SKUs cannot afford to write individual product descriptions, SEO copy and email variants for every item. A well-configured LLM pipeline can generate, format and quality-check that content in a fraction of the time. The value is not that the model writes better than a human - it is that it writes adequately at a volume no human team could match economically.

Internal knowledge retrieval and question answering. A professional services firm with fifteen years of project documentation, policies and process guides has a significant knowledge management problem. New staff spend weeks locating institutional knowledge that exists somewhere in the firm but is practically inaccessible. An LLM deployed against that document corpus - using a technique called retrieval-augmented generation, where the model draws on retrieved documents rather than relying solely on its training - can surface answers in seconds. The productivity gain in onboarding alone can justify the build cost.

Structured data extraction and classification. Insurance companies, legal firms and logistics operators process enormous volumes of unstructured text: contracts, claims, manifests, correspondence. LLMs can extract structured fields from these documents, classify them and route them to the appropriate workflow - tasks that previously required significant manual processing. A logistics business handling 10,000 supplier communications a week can eliminate a substantial portion of that manual triage.

Customer-facing interaction and triage. This is the area where execution quality matters most and failure is most visible. A poorly configured LLM deployed as a customer service agent will hallucinate, give incorrect policy information and frustrate customers. A well-configured one - scoped narrowly, given access only to verified information sources, with clear escalation logic - can handle a significant proportion of routine enquiries without human intervention. The word "scoped" is doing a lot of work in that sentence.

Where they fail, and why it matters

LLMs fail in predictable ways. Knowing the failure modes in advance determines whether a proposed deployment is viable.

Hallucination. The model generates plausible but incorrect information. This is structural, not a bug to be patched. It can be mitigated through retrieval-augmented generation, output validation and human review steps - but it cannot be eliminated entirely. Any deployment where a hallucination has serious consequences (medical, legal, financial) requires significant additional safeguards.

Reasoning under constraint. LLMs perform well on pattern-matching tasks and poorly on tasks that require consistent logical reasoning over many steps. Ask a model to summarise a contract and it will do so well. Ask it to determine whether a specific clause creates a liability under a specific regulatory framework and you need a lawyer reviewing the output.

Knowledge cutoffs and domain gaps. A model trained on publicly available text will know nothing about your internal pricing logic, your customer segments or your operational constraints unless you provide that context explicitly. Most failed LLM deployments fail here - someone expected the model to understand the business without ever telling it anything about the business.

Consistency at scale. A model that produces excellent output 95% of the time produces 500 errors for every 10,000 outputs. Whether that is acceptable depends entirely on the use case. For draft email generation, probably yes. For financial report commentary, probably not.

A practical framework for evaluating LLM use cases

Before approving an LLM project, a senior operator should be able to answer five questions.

1. What is the task, exactly? Not "improve customer service" - but "classify inbound complaints into seven categories and suggest a response template." Vague scoping produces vague outcomes.
2. What happens when it is wrong? Map the failure mode before you build. If an incorrect output causes financial loss, reputational damage or a regulatory breach, the required safeguards change the build cost significantly.
3. What data does the model need, and do we have it? The model is only as good as the context you provide. If the relevant information lives in an ERP system, a SharePoint instance and three people's heads, that is a data problem before it is an LLM problem.
4. How will we measure it? "It seems to be working" is not a success metric. Define the baseline, define the target, define the measurement method before you start.
5. Who owns the output? LLM-generated content, decisions and communications require human accountability. Define who reviews, approves and is responsible before the system goes live.

Organisations that can answer all five questions clearly are ready to build. Organisations that struggle with question one are not - and building anyway is where most of the wasted spend in this space originates.

The commercial reality

Large language models are genuine infrastructure, in the same way that cloud computing was genuine infrastructure fifteen years ago. Not every application built on cloud computing succeeded - most failed - but the underlying capability proved transformative for the organisations that deployed it with discipline.

The businesses that will extract durable value from LLMs are not the ones that move fastest. They are the ones that understand the technology clearly enough to match it to problems it can actually solve, build the data and governance foundations it requires, and treat the first deployment as a learning system rather than a finished product.

That takes a clearer picture of the technology than most leadership teams currently have. If your organisation is making LLM decisions without that picture, the cost is not just the budget on the current pilot - it is the compounding disadvantage of building on the wrong foundation.

If you want a clear-eyed view of where LLMs can genuinely move the needle in your business, start with Rodan's diagnostic engagement. Two weeks, a defined scope and a commercial case you can act on.