Glossary
The terms, and what people get wrong about them.
33 terms from AI product work and the EU AI Act, each with the mistake that costs most.
Definitions are easy to find and mostly identical. What follows each one here is the misreading — the version of the term that gets repeated in meetings and costs money later. Most of these come from assessment work rather than from reading the regulation.
The EU AI Act entries are checked against Regulation (EU) 2024/1689 and the European Commission’s implementation timeline as amended by the Digital Omnibus on AI. If you want the dates rather than the vocabulary, what applies from 2 August 2026 covers those.
EU AI Act
Provider
Under the EU AI Act, the party that develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. Providers carry the heaviest obligations, particularly for high-risk systems.
What people get wrongThat buying rather than building keeps you out of it. Under Article 25 you become a provider if you put your name or trademark on a high-risk system, modify it substantially, or change its intended purpose — and the original provider's obligations transfer to you.
Deployer
The party using an AI system under its own authority, in a professional context. Deployer obligations are lighter than provider obligations but not absent: human oversight, input data relevance, monitoring, and log retention where applicable.
What people get wrongThat deployer status is permanent. It is a role, not a category, and the same organisation can be a deployer of one system and a provider of another. Rebranding a purchased system moves you.
Substantial modification
A change to an AI system after it has been placed on the market that affects compliance with the Act's requirements, or changes the intended purpose. It can make the modifying party a provider.
What people get wrongThat fine-tuning a purchased model is routine configuration. Depending on what changes, it can be the thing that transfers provider obligations onto you — and that is a decision usually made by an engineer, not by legal.
Annex III
The list of high-risk use areas in the AI Act: biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration, and administration of justice. Obligations for Annex III systems apply from 2 December 2027 following the Digital Omnibus amendments.
What people get wrongThat the delay applies to everything. It applies to the high-risk tier only. If you are not doing one of the Annex III activities, December 2027 was never your date.
Article 50
The transparency provision. It requires disclosure when a person is interacting with an AI system, machine-readable marking of synthetic content, disclosure of deepfakes, and disclosure of AI-generated text published on matters of public interest. Enforceable since 2 August 2026.
What people get wrongThat it was delayed with everything else. It was not amended by the Digital Omnibus. It is also the part of the Act that reaches the most organisations, because it applies to AI systems generally rather than to a risk classification.
General-purpose AI model
A model displaying significant generality, capable of competently performing a wide range of tasks, that can be integrated into downstream systems. The large language and image models most companies build on.
What people get wrongThat GPAI obligations started in August 2026. They took legal effect on 2 August 2025. What changed in 2026 is that enforcement of them began.
AI literacy
The Article 4 requirement that providers and deployers take measures to ensure a sufficient level of AI competence among staff dealing with AI systems, proportionate to context and risk. Applicable since 2 February 2025.
What people get wrongThat it means buying a training course. It means being able to show the people operating a system understand what it does and where it fails. A generic e-learning module with no relation to the systems you actually run satisfies procurement, not the requirement.
Conformity assessment
The process of demonstrating that a high-risk AI system meets the Act's requirements before it goes to market. Depending on the system, this is a self-assessment or involves a notified body.
What people get wrongThat it happens at the end. Most of what a conformity assessment asks for — risk management, data governance, technical documentation, logging — has to exist while the system is being built. Retrofitting it is the expensive version.
Post-market monitoring
The obligation on providers of high-risk systems to actively collect and review performance data after deployment, and to act on what it shows.
What people get wrongThat it is a reporting duty. It is an operational one. If nobody owns the system after launch, there is nothing to monitor with and no one to act on what monitoring finds.
Prohibited practices
The uses banned outright: social scoring, exploitative manipulation, untargeted facial image scraping, emotion inference in workplaces and education, and certain biometric categorisation. In force since 2 February 2025.
What people get wrongThat the list is exotic and irrelevant to ordinary business. Emotion inference in a workplace context catches more HR and productivity tooling than most buyers expect.
Deciding what to build
Use case
A specific job an AI system is proposed to do, described concretely enough that its value and feasibility can be assessed independently of other proposals.
What people get wrongThat a theme is a use case. "Improve customer experience with AI" cannot be scored, funded or falsified. If two people would build different things from the same description, it is not yet a use case.
AI theatre
Work that carries an AI label without needing to. Usually automation, a rule, a lookup table or a database query wearing a more fundable name.
What people get wrongThat it is dishonest. It is almost always sincere. The incentives point that way: calling a project AI gets a faster answer than calling it automation, and nobody in the room is rewarded for saying this one is not AI.
Kill criteria
The condition, agreed before a project starts, under which it will be stopped. Typically a named metric failing to move by a named date.
What people get wrongThat agreeing them signals a lack of confidence. The opposite: a pilot with no defined way to fail does not end, it becomes permanent — consuming budget and producing nothing while nobody is willing to be the person who cancels it.
Baseline
The current value of the metric a project is meant to move, measured before work starts.
What people get wrongThat it can be established afterwards. Without a baseline there is no way to demonstrate the change, which is how a project can ship successfully and still be unable to prove it was worth doing.
Proof of concept
A small build intended to establish whether something is technically possible.
What people get wrongThat it is a step toward production. It answers a feasibility question and is usually built on hand-prepared data with no operational constraints. IDC found that for every 33 proofs of concept an enterprise starts, roughly four reach production.
Pilot
A limited deployment in real conditions, intended to establish whether something delivers value.
What people get wrongThat it is a longer proof of concept. A pilot without a baseline, a target and a date is not measuring anything — it is a proof of concept with a larger audience.
Shadow AI
AI tools adopted by individuals or teams outside sanctioned procurement, security review or governance.
What people get wrongThat an inventory of approved tools describes your AI footprint. It describes the part you know about. Under the AI Act your obligations attach to what is actually in use, not to what was approved.
Building and running
Retrieval-augmented generation
An architecture where a model is given relevant documents retrieved at query time, rather than relying only on what it learned during training. Commonly abbreviated RAG.
What people get wrongThat it eliminates hallucination. It reduces one cause of it. A model handed the wrong documents produces a confident answer grounded in the wrong source, which is harder to catch than an obvious invention.
Fine-tuning
Further training of an existing model on a specific dataset to adapt its behaviour.
What people get wrongThat it is the default answer to poor output. It is expensive, it has to be repeated when the base model updates, and prompt design or retrieval solves the problem more often than the industry's enthusiasm for fine-tuning suggests. It can also constitute substantial modification under the AI Act.
Evaluation
The systematic measurement of a model's output quality against a known set of cases. Often shortened to evals.
What people get wrongThat it is a testing phase. It is a permanent cost. Models change under you, inputs drift, and without ongoing evaluation the first sign of degradation is a user complaint.
Golden dataset
A curated set of inputs with known-correct outputs, used as the reference for evaluation.
What people get wrongThat it can be assembled by the engineering team alone. The value depends on the correct answers being correct, which usually requires the people who do the job — and their time is the part nobody budgets for.
Hallucination
Output that is fluent, confident and wrong. A model generating plausible content unsupported by its inputs or by fact.
What people get wrongThat the fluency is a bug. It is the system working as designed — these models optimise for plausible continuation, not for truth. Which is why detection has to be external to the model.
Guardrails
Controls constraining what a system will accept as input or produce as output.
What people get wrongThat they are a safety layer added at the end. Guardrails written after launch are written in response to incidents, which means each one is documenting something that already went wrong.
Drift
Degradation in performance over time as real-world inputs diverge from what the system was built and tested against.
What people get wrongThat it announces itself. Drift is gradual and the system keeps producing confident output throughout. Without monitoring, the detection mechanism is a customer noticing.
Observability
The ability to see what a system is actually doing in production: what it was asked, what it returned, how long it took, what it cost, and where it failed.
What people get wrongThat logging is observability. Logs tell you what happened. Observability means being able to answer a question you had not thought to ask in advance, which is what an incident requires.
Human in the loop
A design in which a person reviews or approves AI output before it takes effect.
What people get wrongThat naming a reviewer creates oversight. If the reviewer has no time, no context and no incentive to disagree, the loop is decorative — and under the AI Act, human oversight has to be effective rather than nominal.
Prompt injection
An attack where instructions hidden in content the model processes cause it to ignore its original instructions.
What people get wrongThat it is a prompt engineering problem. If your system reads untrusted content — emails, documents, web pages — it is an architecture problem, and no amount of instruction hardening closes it fully.
Agent
A system that takes actions rather than only producing text: calling tools, writing to systems, or executing multi-step tasks with limited supervision.
What people get wrongThat agentic is a capability tier. It is a risk tier. The moment a system acts rather than suggests, the cost of being wrong stops being a bad answer and starts being a bad outcome.
Context window
The amount of text a model can consider at once, measured in tokens.
What people get wrongThat a larger window removes the need for retrieval. Filling a window with everything available degrades output and multiplies cost. What goes in still has to be selected.
Token
The unit of text a model processes, typically a word fragment. Pricing and context limits are counted in tokens.
What people get wrongThat token cost is the cost. It is the visible part. Evaluation, observability, governance, security review and human quality assurance are usually larger, and they are the line items missing from the business case that got approved.
The economics
Run cost
The ongoing cost of operating an AI system in production: inference, evaluation, observability, governance, model updates, drift management, security review and human quality assurance.
What people get wrongThat it is the API bill. When the real run cost surfaces, the return in the original business case does not evaporate — it was never there. The case contained an arithmetic error from the start.
Time to value
How long from starting work to the point where a measurable outcome changes.
What people get wrongThat shortening it means moving faster. It usually means scoping smaller. A narrow thing in production beats a broad thing in development, and the difference is a scoping decision rather than a delivery one.
Build versus buy
The decision between developing an AI capability internally and licensing an existing one.
What people get wrongThat building gives you control and buying gives you speed. Both can be true and neither is automatic — and the decision has legal consequences under the AI Act, because building can make you a provider while buying does not reliably keep you a deployer.
Scoring 40 AI use cases in a regulated enterprise — where most of these misreadings turned up, and what they cost.