LLMs in business: what they are for what the model really does, and what follows from it
No version names, no benchmarks, no token prices, because all of that goes stale in a month. Instead: one sentence about how a language model works, and everything that sentence means for your company. Where hallucinations come from, why the model does not know your data, the three levels companies use it at, and the tasks you take off it before it goes anywhere near a live process.
- 3 levelsthat is how many ways a company uses a model: a person chatting with it, a model inside a process, an agent taking an action. Value and risk rise together
- 4 task typesreading, classifying, summarising, rewriting between formats. That is where the model works repeatably. Arithmetic and decisions that need certainty stay outside it
- 5 to 10 secondshow long BOND, our company AI agent, takes to answer a question about data sitting in your systems
- EUR 0.005 to 0.07what a single query to the model costs in our deployments, paid to the model provider directly
Short answer
What does a language model actually do in a business?
A language model predicts the next pieces of text from whatever it was given as input. It does not check, it does not calculate, it does not hold your data. It builds the most probable answer, and probable is not the same as true. Everything else, hallucinations included, follows from that one sentence.
The mechanism sets the division of labour. The model reads text well, puts a category on it, shortens it and rewrites it from one format into another. It calculates badly, it is bad at knowing what it does not know, and it is no good as a source of truth about your company. It has none of your data on its own; someone has to hand it over with every question.
In practice: take one repeatable task on text where a mistake can be caught before anything is sent, and let the model in there. Leave the tasks that need certainty to a rule or to a person. Which model you use is the smallest decision in the whole project and it can wait until the end.
What does a language model do when it answers a question?
Picture a function that takes a piece of text and appends the most probable continuation. Then it takes what came out and appends the next piece. And so on to the end of the answer. That is the entire mechanism, with no metaphor and nothing left out.
The probability comes from an enormous volume of text the model was trained on. That is why it sounds like someone well read. And that is why there is no database inside it to look things up in, and no calculator to run the sum.
For a company the conclusion is single: the model produces text that is probable, not text that is verified. Verification is a separate act. A system does it, a person does it, or nobody does it, in which case a wrong answer travels on in exactly the same packaging as a right one.
- The model does not know whether something is true; it knows what an answer to that kind of question usually looks like
- It has no access to your systems until somebody gives it one
- It does not calculate, it reproduces the shape of a calculation, so the result comes out nearly right
- The same question asked twice can give two different answers, both of them sounding sensible
- It does not remember the previous conversation unless someone attached it to the question
Why does the model make things up, and what brings it down?
A hallucination is not a fault. It is the same mechanism at an inconvenient moment. A model with no answer in the material still appends the most probable continuation. Out comes a sentence that is linguistically correct and factually wrong, delivered with the same confidence as the rest.
So the question „does the model lie” is the wrong question. It does not separate knowing from guessing, because inside it those are the same operation. Your process has to do the separating: by handing over the documents it is allowed to answer from, by validating the output, and by keeping a person where a mistake costs money.
Three things bring hallucinations down hardest. Give the model source material instead of relying on its memory. Force it to point at the place the answer came from. Write the instruction so it is allowed to say „that is not in the material”. We go through this at length in the guide on AI hallucinations and how to avoid them.
How is the model's knowledge different from your company data?
This is the distinction that goes missing most often in conversations about AI, and whether a deployment makes any sense depends on it. The model knows language, general facts and the way people write about the world. It does not know your price list, your stock level, or what you agreed with a customer on Thursday afternoon.
Company knowledge cannot be loaded into a model once and for all. It is supplied with every question: a system retrieves the right passage of a document, or queries your CRM, spreadsheet or warehouse, and adds the result to the instruction. The model gets the material and assembles an answer out of it. That is how BOND works, our company AI agent: you ask in plain language, it reaches into the systems and answers in 5 to 10 seconds. The mechanics are on the BOND page.
| Kind of knowledge | Where it comes from | What that means for you |
|---|---|---|
| Language and general facts | training, frozen at the moment a version shipped | works with no setup, can be out of date, and you cannot correct it from your side |
| Data from your systems | CRM, ERP, spreadsheets, a data warehouse, attached to the question | accurate to the minute, needs integration and control over who sees what |
| Company documents | policies, contracts, procedures, retrieved for the specific question | the answer can be checked, because it names the file and the passage |
| The current conversation | whatever somebody pasted into this window | it disappears with the conversation and never becomes company knowledge |
| Results from the web | a search engine wired into the model | current, but somebody else's pages stand behind it, so a decision needs a check |
The middle column matters more than it looks. If you cannot say where an answer came from, you have no way of defending it, to a customer or to an auditor.
At which three levels do companies use a model?
Mixing these levels up is behind most of the confusion in conversations about AI. At the first, a person talks to the model and decides what to do with the answer. At the second, the model sits inside a process and works through data without a person looking at every result. At the third, an AI agent takes an action: it writes, it sends, it changes a status in a system.
Value grows with every step, because a person's time drops out. Risk grows with it, because their eyes drop out too. That is not an argument for staying at the first level. It is an argument for adding, at each level, the control the previous one did not need.
The third level has been running in production for us since March 2026, in our founders' two companies. The measurements, together with what those numbers do not prove, are on the AI automation agency page.
| Level | What you get | What you have to add |
|---|---|---|
| A person chatting with it | faster writing, summaries, a first draft; a person reads every answer | company accounts instead of private ones and a clear list of data nobody may paste in |
| A model inside a process | hundreds of documents or tickets handled without a person touching them | output validation, a confidence threshold and an exception route to a human |
| An agent taking action | a closed loop: the agent reads, chooses within narrow limits and writes the result into a system | restricted permissions, a log of every operation, a way to undo it |
Jumping from the first level to the third in one move usually ends with the project being pulled. In the workshop we set the pilot at the second level and go higher only once the errors are counted rather than described as an impression.
Which tasks fit a model and which do not?
The line is sharper than the advertising suggests. The model is good where the input and the output are both text and correctness can be judged by looking. It is weak everywhere the result has to be certain, repeatable to the character, and derivable from a rule.
Arithmetic is the most common mistake. A model can write a correct-looking invoice summary in which the total does not add up, because it reproduces the shape of the calculation instead of performing it. A spreadsheet, a database or code does the maths. The model can at most pull the numbers out of a document and pass them on to be added up.
| Task | Will the model carry it | What stays on your side |
|---|---|---|
| Reading a document and pulling fields out of it | yes, this is its strongest suit | a rule for what happens when a field is missing from the document |
| Classifying tickets and emails | yes, where the categories are clearly described | the category list and a route for the uncertain cases |
| Summarising a long text | yes, if you say what the summary has to contain | who the summary is for and what it will be used for |
| Rewriting content from one format into another | yes, this is mechanical work | the target template and a check against it |
| Adding up a total, a margin or a due date | no, the result comes out nearly right | the calculation in a spreadsheet, a database or code |
| A decision with legal or financial consequences | no, the model does not know its own confidence threshold | a human decision or a rule written down explicitly |
| Being the source of truth about the company | no, the model does not hold your data | a system that supplies the data and names its source |
The „yes” rows share one property: the result can be checked before it goes any further. That is a better test for a first deployment than a list of use cases from a vendor deck.
When is a plain rule enough and the model unnecessary?
A model is tempting because it makes an impression. But if a task can be written as „when X, do Y”, a rule will do it cheaper, faster and identically every time. In that spot a model adds a query cost, a delay, and an element of chance the process did not have before.
The order we use in our workshops is the reverse of the one in most proposals: first we check whether a rule in Make or n8n will do. The model comes in only where the input is unstructured and the exceptions outnumber anything you could list. Most deployments break not on the model but on it being dropped into a place where a condition would have been enough.
- Moving data between systems where the fields match: a rule, no model
- An alert once a threshold or a due date is passed: a condition, no model
- An invoice that always arrives in the same template from the same supplier: a parser, no model
- An email from a customer describing two separate matters at once: this is where a rule ends and the model starts
- A document every supplier sends in a different layout: a model, because the exceptions cannot be listed
How do you put a model into a process so you can undo it?
The order below is the one we run with clients: workshop, pilot on real data, production, measurement at 30 and 90 days. Not because it is cautious, but because after each step you know what to do next.
Most of it is decided at step three, when the instruction gets written. The same task stated precisely and stated vaguely produces a bigger difference than switching model provider. How to write instructions that give repeatable output is in the guide on prompt engineering for business.
Pick one task
Repeatable, on text, with a result somebody eyeballs today. Do not start with a process where the mistake only shows up at the customer.
Collect 20 real cases
From the last month, hard ones included. Write down what a good answer looks like for each. The person doing the work today does this, because only they know what goes out and what goes back for correction.
Write the instruction and test it on those cases
Score it as a yes or a no: sendable without correction, or not. No scale of one to five, because on a scale everything comes out at four. You count one number: how many of the 20 passed.
Go live with a person in the loop
For the first few weeks the model proposes and a person approves. In that time you collect the list of cases it got wrong, and that list decides the next step, not the project calendar.
Measure at 30 and 90 days
Against metrics written down before the start: how many cases went through without correction, how many hours came off the team, what the queries cost. Without those numbers you cannot say whether you are allowed to move up a level.
Common mistakes
Five mistakes when letting a model into a company
Treating the model as a search engine over company data
It answers from what it knows about the world, not from your system. The answer sounds credible and is about somebody else's company. Without an integration to your data it is simply a different tool.
Giving the model the arithmetic
The total, the margin or the due date comes out nearly right, which is the worst possible outcome. The error is too small to catch the eye and too large to survive the accounts.
An agent taking actions with no log and no way to undo them
The first mistake is irreversible and nobody can reconstruct what happened. It usually ends with the whole project being pulled, including the part that worked correctly.
A model where a rule would have done
You pay per query, you wait longer, and you add randomness to a process that used to be predictable. Maintenance gets more expensive and the gain stays at zero.
Judging it on a demo instead of on your own data
On a prepared example everything works. The difference shows up on your credit note and in the email where a customer describes two matters at once.
Checklist
Checklist before a model goes into a process
If any line is a no, the task is not ready for a model yet.
- The task has text in and text out, and correctness can be judged by looking
- Checked whether a plain rule settles it cheaper and more reliably
- Company data supplied to the model from a system, not assumed to be inside it
- Every answer names a source or says outright that it has none
- 20 real cases from the last month, with the expected answer written by a practitioner
- Arithmetic on the side of a spreadsheet, a database or code, never the model
- An operation log and a way to undo, before the agent gets write access to a system
- The 30-day and 90-day measurement dates already in the calendar
Sources
Sources
- Anthropic: Claude model documentation and terms for business customers
- OpenAI: model documentation and terms of use
- Regulation 2016/679 (GDPR), Article 28 on processors and Chapter V on transfers outside the EEA
- Regulation 2024/1689 (AI Act), obligations for deployers of AI systems
- JustAutomate, AI automation agency: our own deployments with the measurement method and the caveats
Let us start with one task
The model is the last choice you make, not the first
On a free 30-minute consultation we take one of your tasks and say plainly whether it belongs to a model or whether a rule will do. The process workshop costs EUR 3,500 net per week and ends with a process map, a list of the tasks a model can take, and a 30-day pilot plan. The build is quoted after the workshop, and the query cost of EUR 0.005 to 0.07 stays on your side, paid to the model provider directly.
Book a free consultationFrequently asked questions
What is an LLM and how is it different from an ordinary program?
An LLM is a language model that predicts the next pieces of text from whatever it was given as input. An ordinary program executes instructions written out explicitly and returns the same result every time for the same data. A model returns a probable result, so two runs can differ, and correctness has to be checked separately.
Why does an AI model make things up?
Because it always appends the most probable continuation, including when the answer is not in the material. It does not separate knowing from guessing, since inside the model those are the same operation. What helps: handing it the documents it may answer from, forcing it to name the source, and allowing the answer „that is not in the material”.
Does the model know my company data?
Not until you give it. The model knows how language works and how people write about the world; it does not know your price list or your stock level. Company data is attached to the question: a system retrieves a document passage or queries the CRM and passes the result to the model. That is how the BOND agent works, answering in 5 to 10 seconds.
What is an LLM best at inside a company?
Tasks where the input and the output are both text: reading documents and pulling fields out of them, classifying tickets, summarising, rewriting content from one format into another. These share one property: the result can be checked by looking before it goes further, so the model's mistake does not surface at the customer.
Can a model be trusted with arithmetic?
No. It reproduces the shape of a calculation instead of performing it, so the result comes out nearly correct, and that is the worst kind of error. A spreadsheet, a database or code does the maths. The model can pull numbers out of a document and pass them on, but the sum is done by a tool standing next to it.
How is chatting with a model different from an AI agent?
In a chat, a person asks a question and decides what to do with the answer. An AI agent has access to company systems and takes an action: it reads data, writes a result, changes a status. The value is higher because a person's time drops out, so you add restricted permissions, a log of every operation and a way to undo.
How much does using a language model cost a company?
The query itself costs EUR 0.005 to 0.07 and you pay the model provider directly; where you land in that range depends on how much text reaches the model. On top of that comes the build, which we quote after the workshop, and your team's time on corrections. That last one usually outweighs the cost of the queries.
Do you need an IT department to deploy an LLM?
Not for the first test. One person who knows the process and knows what a good answer looks like is enough. IT or an implementation partner is needed to wire the model into systems, validate the output, and make sure no data reaches the model that the task does not require.