What is an LLM?
A practical explanation of language models, what they do well, where they fail and why they are only one layer of an enterprise AI platform.
A large language model is a probabilistic system trained to continue and transform language. It can summarise, classify, extract, draft and reason over context, but it does not become a trustworthy enterprise system by itself.
Many organisations focus on selecting the “best” model. In practice, models are increasingly interchangeable. The harder work is building context, security, observability and a process around them.
Evaluate the model inside the real workflow. A benchmark score is less valuable than reliable behaviour with your data, users and constraints.
There is rarely one universally correct architecture. The best decision is the one that fits the process, risk, people and operating capability of the organisation.
Why it matters
Many organisations focus on selecting the “best” model. In practice, models are increasingly interchangeable. The harder work is building context, security, observability and a process around them.
In practice, value appears when the technology becomes part of a governed process: responsibilities are clear, evidence can be checked and the organisation can observe whether outcomes improve.
What it really means
A large language model is a probabilistic system trained to continue and transform language. It can summarise, classify, extract, draft and reason over context, but it does not become a trustworthy enterprise system by itself.
The useful distinction is between a technical capability and a production service. Enterprise use requires identity, permissions, data handling, evaluation, monitoring and a clear owner for the result.
How it works in practice
The flow can be described in five steps. Each one needs an explicit purpose, an owner and a way to verify that it behaves as expected.
The exact architecture will vary. What matters is keeping the boundaries visible and making failures diagnosable rather than hiding them behind a fluent answer.
What this looks like in real work
A legal team uses an LLM to extract clauses from supplier contracts. The model reduces reading time, while every clause remains linked to the original document and final decisions stay with the legal team.
The lesson is not that AI produced an answer. It is that the answer appears inside a controlled process, can be verified and is tied to a measurable outcome.
Common mistakes we see
Assuming it understands like a person
It detects patterns and relationships; it does not possess human judgement or accountability.
Using it as a database
Current enterprise knowledge must be supplied through context, retrieval or tools.
Testing only with demos
A striking answer says little about consistency across thousands of real requests.
Choosing by size alone
A smaller model can be faster, cheaper and entirely sufficient for a narrow task.
When it makes sense
- The process has a clear owner and outcome
- The required information and permissions are understood
- Results can be checked or measured
- The organisation can operate the capability responsibly
When it probably does not
- The problem is still undefined
- A deterministic rule would be simpler and safer
- No one owns data quality or exceptions
- The consequence of failure cannot be controlled
Not using AI can be the right decision. Honest scope is usually more valuable than a technically impressive pilot without a real problem.
How we usually approach it
We work from engineering and operational experience. We do not believe in a universal recipe, but we consistently ask the same questions before building:
Once these answers are reasonably clear, choosing models, infrastructure and integration becomes much easier.
Useful enterprise AI is not defined by how impressive the demo looks, but by how reliably it improves a real process.
Technology evolves quickly and we do not claim to have final answers. These guides capture what we have learned while building and operating platforms, shared with the humility that tomorrow may require a better approach.