Every generative AI conversation at work runs on the same half dozen words, and most of the confusion in those conversations comes from people using the words differently. A vendor says the model is “grounded”, the security lead hears “trained on our data”, and the meeting goes sideways. This is the shortest explanation of the six terms I can write that still leaves you able to hold your own with an architect or a vendor. No maths, no code, one running example.
The example: a support agent clicks a button that summarises a long ticket. Here is the whole journey with all six terms marked on it. The rest of the article walks through it left to right.
Prompt
The prompt is the instruction sent to the model. It is not usually what a person types. In an enterprise product the prompt is a template the vendor wrote, and the product fills it with data before sending it. For our ticket, the template says something like “summarise this ticket for a support agent, in three sentences, in plain language”, and the product pastes in the ticket description, the work notes and the resolution so far.
That filling is called grounding. A grounded prompt carries the specific facts the answer should be built from, which is why the summary talks about this ticket and not a generic one. When someone says a model is grounded, they mean the facts went into the prompt. They do not mean the model was trained on your data. Those are different things and the difference matters later.
Response
The response is what comes back. Text, usually, though it can be a structured object, code or an image. Three things about responses that are easy to miss.
A response is generated fresh each time, so the same prompt can produce slightly different wording on two runs. A response is not looked up, it is composed, which is why it can be fluent and wrong at the same time. And in any well designed enterprise product the response is shown to a person who checks it before it is used, and it is labelled as AI-generated so the person knows to check. If a product hides that label, ask why.
LLM
A large language model is a model trained on a very large amount of text so that it can predict what text should come next. That is the whole trick. Given a prompt, it produces the most plausible continuation, and it turns out that predicting plausible text well enough lets you summarise, translate, answer questions and write code.
GPT, Claude and Gemini are LLMs. Many platform vendors also train their own. The word “large” refers to the number of parameters, the internal values the model learned during training, which for the well known models runs to hundreds of billions. More parameters generally means more general capability and more cost per response.
SLM
A small language model is the same idea with far fewer parameters, typically a few billion rather than hundreds of billions, and tuned for a narrow set of tasks. An SLM will not write your strategy paper. It will classify a ticket, convert a plain English request into a workflow or a query, or check a piece of text for harmful content, and it will do it faster and cheaper than a large model, often running closer to your data.
The pattern in enterprise platforms is to use both. A large model where the task is open ended, a small one where the task is narrow and repeated ten thousand times a day. When a vendor tells you which model sits behind a feature, this is the distinction they are making.
RAG
Retrieval-augmented generation is the technique that makes an LLM useful on your information without training it on your information. Before the prompt is sent, the product searches your own records, knowledge articles, past tickets, documents, and puts the relevant passages into the prompt alongside the question. The model then answers from what it was given.
Two consequences, and they are the two your security team will ask about. First, RAG can respect access controls. If the retrieval step only searches records the user is allowed to open, the user only gets answers from those records. The model never sees the rest. Second, RAG is why answers stay current. Change the knowledge article and the next answer reflects the change, with no retraining. A model’s training data has a cutoff date. Your retrieved records do not.
Back to our ticket. If the summary button also pulls in the two knowledge articles linked to the ticket and mentions them in the summary, that is RAG at work.
Training and inference
These two words carry most of the data protection questions, so they are worth getting exactly right.
Training is teaching the model. It happens once, or occasionally, on very large datasets, in dedicated environments, and it produces the model’s parameters. It is slow and expensive and it is where the model’s knowledge comes from.
Inference is using the trained model to answer a prompt. It happens every time a person clicks the button. It is fast, it happens on serving infrastructure rather than training infrastructure, and it does not change the model.
The sentence to remember: inference does not train the model. When the support agent clicks summarise, the ticket goes into a prompt, the model produces a response, and in a properly run service the prompt and response are then deleted. Nothing about that ticket becomes part of the model. Whether a given vendor’s service actually works that way is a question to ask, in exactly those words, and to get in writing.
The six in one table
| Term | In one line | The question it answers |
|---|---|---|
| Prompt | The instruction and data sent to the model | What did we ask, and with what facts |
| Response | What the model produces, composed not looked up | What came back, and who checks it |
| LLM | A large model that predicts text, hundreds of billions of parameters | What is doing the work |
| SLM | A small model tuned for narrow tasks | Why this feature is fast and cheap |
| RAG | Retrieve your records first, put them in the prompt | How it knows about our data without being trained on it |
| Training and inference | Teaching the model once, using it every time | Does using it change it, and where does our data go |
If you can explain the difference between grounding and training, and between inference and training, you already understand more than most of the people in the room. The rest is product detail, and every platform’s version of that detail is a separate article. Mine for ServiceNow is ServiceNow AI, an Introduction for Implementation Teams.
