Glossary of AI in production

Under the hood of search

**Embeddings.** The way a piece of text is turned into a list of numbers that captures its meaning. Two sentences about the same thing land close together in that space, even with no words in common. It is what lets you find information by the meaning of a question, not by an exact word match.

**Reranking.** A second pass that reorders the passages a search brings back. The first search quickly returns a batch of plausible candidates; the reranker reads them one by one and pushes the most relevant to the top. A small addition with a large effect on answer quality, especially on a big corpus.

Making AI act

**AI agent (vs a chatbot).** A chatbot answers, an agent acts. Where a chatbot just talks, an agent breaks a goal into steps, uses tools (search, a database, sending an email) and chains actions together until the job is done. The trade-off: because it acts inside your systems, it needs guardrails and a human on sensitive actions.

**Multi-agent orchestration.** Having several specialised agents work together instead of one agent meant to do everything. One agent researches, another writes, a third checks, with a coordinator that splits the work and cross-checks it. Useful when a task is too broad for a single agent, as long as you resist complexity for its own sake: often one well-tuned agent is enough.

Making AI reliable

**Eval.** A test set that measures whether the system answers correctly, on cases that reflect your real work. Instead of judging by eye, you put a number on the share of correct answers before every release and after every change. Without evals you are not deploying AI, you are hoping it works.

**Guardrails.** The rules that bound what the AI is allowed to say and do. Filtering off-topic requests, refusing a question outside its scope, requiring human sign-off before an irreversible action, blocking sensitive data from leaking. It is what separates a demo from a system you let run in production.

**Hallucination.** When a model produces a wrong answer with the confidence of a right one. This is not a rare bug, it is a property of language models: they predict plausible text, not truth. You do not remove it entirely, you cut it sharply with sourced RAG, guardrails, and evals that measure it.

**LLM observability.** Seeing what your AI does once it is live: every question, every source it used, every answer, its cost and its latency. Without it, a problem stays invisible until a user complains. With it, you catch drift, a cost hotspot or a badly handled question before it does damage.

Evals, guardrails and observability are the core of my Reliability & security work, applied before every release.

Stress-testing AI

**LLM red teaming.** Deliberately attacking your own AI system to find its weak points before someone else does. You try to make it say what it should not, bypass its rules, or reveal data. The point is not to prove it is perfect, but to learn where it breaks and fix it before it goes live.

**OWASP LLM (Top 10).** A reference list, maintained by the OWASP foundation, of the ten most common security risks in LLM-based applications: prompt injection, data leakage, excessive permissions, among others. I use it as a security checklist, so a classic hole does not get discovered once you are in production.

Keeping control of your data

**Sovereign AI.** AI whose data and processing stay under your control and your jurisdiction, usually the EU. In practice: the model runs on a European cloud or on your own infrastructure, your data does not go off to feed a third-party service, and you know where it sits. It is an architecture choice, not a label you stick on afterwards.

**On-prem (on-premises).** Running the model and your data on your own servers, or in a private cloud you control, rather than at an external provider. More demands on hardware and operations, but full control and nothing leaving your walls. The right call when confidentiality or regulation requires it.

The EU cloud or on-prem choice, I handle in my Cloud & on-prem work; model cost, in Audit & optimisation.

Adapting the model to your work

**Prompting.** Steering an existing model with well-built instructions and examples, without retraining it. It is fast, cheap, fixable in minutes, and it is enough in the large majority of cases. It is almost always where I start.

**Fine-tuning.** Retraining a model on your own examples to lock in a very specific style, format or vocabulary. Powerful, but heavier and more expensive: you need quality data, and you have to redo it every time things change. I only propose it once prompting and RAG have hit their limits, not by reflex.