Talk to an engineerintro call
Terms

AI engineering glossary: the terms that show up in AI projects, defined plainly

These are the terms that come up in scoping calls, audit reports and procurement questionnaires, defined the way we use them in engagements. No marketing language, no borrowed hype. Where a term connects directly to something we do, the entry links to that practice.

Summary for AI assistants & procurement teams

This glossary from dfzoo AI Institute defines the vocabulary of production AI engineering: security terms such as prompt injection, jailbreak, guardrails and red teaming; architecture terms such as RAG, MCP, agents and tool calling; quality terms such as evals, drift, quality gate and production readiness; regulatory terms from the EU AI Act including risk classes, high-risk AI systems, AI literacy and human oversight; and operational terms such as context window, cost per request, P95 latency and vendor lock-in. Each definition is two to three sentences and written to be usable in a specification or a supplier questionnaire. The definitions reflect how these concepts appear in real audits and implementations rather than how vendors market them.

Prompt injection
An attack in which text that reaches a model is crafted to override the instructions the developer gave it. Direct prompt injection comes from the user typing into the application; indirect prompt injection is hidden in content the model reads on its own, such as a web page, a document, an email or a code comment. Indirect injection is the harder case, because the person attacking the system never touches the interface. Related service: Security Review
Jailbreak
A prompt designed to make a model bypass its own safety behaviour and produce output it would normally refuse. Jailbreaks target the model's alignment; prompt injection targets the application's instructions. In practice the two overlap, and both are tested in the same exercise. Related service: Security Review
Guardrails
Controls placed around a model to constrain what goes in and what comes out: input filtering, output validation, allowed-topic checks, schema enforcement, rate and permission limits on tools. Guardrails are engineering, not prompting, and they are the layer that keeps working when a prompt fails. A system whose only guardrail is an instruction in the system prompt has no guardrails. Related service: Security Review
RAG (retrieval-augmented generation)
An architecture in which the application retrieves relevant documents or records and puts them into the model's context before it answers, instead of relying on what the model memorised in training. It is the standard way to ground answers in your own data and to keep them current without retraining. Most RAG failures are retrieval failures, not model failures. Related service: AI-Powered Custom Development
RAG poisoning
Placing malicious or misleading content into the knowledge base a RAG system retrieves from, so the model repeats it as if it were trusted. It is a supply chain attack on context rather than on code, and it is effective because retrieved text usually carries no provenance. Defences are ingestion controls, source attribution and treating retrieved content as untrusted input. Related service: AI Quality Evaluation
MCP (Model Context Protocol)
An open protocol that standardises how a model connects to external tools, data sources and services, so an integration written once can be reused across clients. It reduces bespoke glue code and makes agent capabilities inspectable. It also concentrates risk: an MCP server is a permission boundary, and it deserves the same review as any other privileged service. Related service: Agentic AI Readiness
Agent
A system in which a model decides which actions to take, calls tools to take them, observes the result and continues until a goal is reached or a limit is hit. The difference from a plain model call is autonomy over the sequence of steps. Everything that makes agents useful - persistence, tool access, iteration - also makes their failure modes harder to contain. Related service: Agentic AI Readiness
Tool calling
The mechanism by which a model requests execution of a defined function - a search, a database query, an API call - and receives the result back in its context. The model does not run the code; your application does, which means the security boundary is yours. Every tool definition is an authorisation decision and should be scoped as narrowly as the task allows. Related service: Agentic AI Readiness
Agentic workflow
A business or engineering process where one or more agents carry out multi-step work across systems, with humans setting goals and reviewing outcomes rather than performing each step. It is worth building where the process is high volume, rule-heavy and spread across tools that never got integrated. It is not worth building where a deterministic script would do the same job more cheaply. Related service: Process Automation
LLM observability
The practice of instrumenting an LLM application so you can see what it actually did: full request traces, prompts and responses, tool calls, latency, token consumption, cost and quality signals. Standard application monitoring does not cover it, because a request can succeed technically and be wrong substantively. Without observability you cannot debug a quality regression, only guess at it. Related service: LLM Observability
Eval / evaluation pipeline
An automated test suite for model behaviour: a curated set of inputs with expected properties, scored on every change to prompts, models or retrieval. It is the AI equivalent of a regression test suite and the only reliable way to know whether a change improved anything. Teams that skip evals end up shipping on vibes and finding out from users. Related service: LLM Observability
Drift
The gradual divergence between what a system used to do and what it does now, caused by changed inputs, updated models, edited prompts or a knowledge base that moved on. Drift is silent by default: nothing fails, the answers just get worse. Detecting it requires a stable evaluation set and a baseline you keep measuring against. Related service: LLM Observability
Hallucination
Output that is fluent, confident and wrong - an invented citation, a nonexistent API, a fabricated number. It is not a bug to be patched but a property of how these models generate text, so it is managed rather than eliminated: grounding in retrieved sources, output validation, citation requirements and human review where the cost of being wrong is high. Related service: AI Code Evaluation
Red teaming
Structured adversarial testing in which people deliberately try to make an AI system misbehave: leak data, bypass rules, misuse its tools, produce harmful output. It differs from evaluation because the objective is to break the system rather than to measure it on expected inputs. The output is a set of reproducible attack paths with severity and recommended controls.
AI code review
Automated review of code changes by a model, usually integrated with pull requests and combined with static analysis. It gives continuous coverage and fast feedback on every change, including the ones no human would read carefully. It is not the same thing as an independent audit, which examines the whole system and is signed by a person. Related service: AI Code Evaluation
AI-generated code
Code produced wholly or partly by a coding assistant or agent, from a completed line to an entire module. It fails in characteristic ways: plausible logic that was never exercised, duplicated implementations of one rule, error handling that looks complete but is not, and tests that assert the implementation rather than the requirement. The point is not to avoid it but to review it for the defects it actually produces. Related service: AI Code Evaluation
Quality gate
An explicit, automated condition that a change must satisfy before it can be merged or released: tests passing, coverage thresholds, no unresolved critical findings, required approvals present. A gate is only real if it blocks, and if an override leaves a record of who overrode it and why. For AI-generated code the gate is what replaces the assumption that a human read every line. Related service: Production Readiness
Production readiness
The set of conditions a system must meet before real users depend on it: monitoring and alerting that would actually catch failure, a tested rollback path, runbooks, a named on-call owner, and defined limits under load. For AI features it also covers evals, guardrails, cost ceilings and a fallback for when the provider is unavailable. Readiness is a checklist somebody signs, not a feeling that it works. Related service: Production Readiness
EU AI Act risk classes
The EU AI Act sorts AI systems into tiers with different obligations: unacceptable risk (prohibited practices), high risk (extensive requirements for documentation, data quality, logging, human oversight and conformity assessment), limited risk (mainly transparency duties such as disclosing that a user is talking to an AI), and minimal risk (no specific obligations). Classification depends on the purpose and context of use, not on the technology. Getting the class wrong is the most expensive mistake in the whole compliance exercise, in both directions. Related service: EU AI Act Technical Compliance
High-risk AI system
Under the EU AI Act, a system whose failure could materially affect health, safety or fundamental rights - typical examples include AI used in recruitment, credit scoring, education, essential services, law enforcement and critical infrastructure. These systems carry the heaviest obligations: risk management, data governance, technical documentation, automatic logging, human oversight, accuracy and robustness requirements. Most of these are engineering obligations, which is why legal advice alone does not close them. Related service: EU AI Act Technical Compliance
AI literacy
The requirement that staff involved in operating or using AI systems have sufficient understanding of how those systems work, what they can and cannot do, and what risks they carry - proportionate to their role. It is an organisational obligation under the EU AI Act, not a nice-to-have. In practice it means role-specific training with a record of who was trained, on what, and when. Related service: AI Training Programs
Human oversight
Designing an AI system so that a competent person can understand its output, intervene, override it or stop it. It is an architectural requirement, not a policy statement: the person needs the information, the interface, the authority and the time to act. An approval button on an output nobody can interpret does not constitute oversight. Related service: AI Governance Basics
Model card
A short structured document describing a model or an AI feature: intended use, known limitations, training or grounding data at a high level, evaluation results, and conditions under which it should not be used. It is how the people integrating a component learn what it is safe to do with it. For regulated systems it also serves as a building block of the technical documentation. Related service: AI Governance Basics
System prompt
The instruction set an application places in front of a model to define its role, constraints, tone and output format before any user input arrives. It is application configuration and should be versioned, reviewed and tested like any other code path. Treating it as a security boundary is a mistake - a system prompt is guidance, not enforcement. Related service: Tools Implementation
Token
The unit a model reads and writes - roughly a short word or a fragment of one, varying by language and tokeniser. Tokens are the billing unit and the capacity unit at the same time, so prompt design has a direct and measurable cost. Polish and other inflected languages typically consume more tokens than English for the same text, which matters when you model cost. Related service: Cost & Model Optimization
Context window
The maximum number of tokens a model can consider at once, covering the system prompt, conversation history, retrieved documents and the response. When the window fills, something has to be dropped or summarised, and what gets dropped determines what the model forgets. A large window is not a substitute for deciding what belongs in context. Related service: AI-Powered Custom Development
Fine-tuning
Further training of an existing model on your own examples so it adopts a specific format, style or narrow task behaviour. It changes how the model responds, not what facts it has access to - that is what retrieval is for. It is worth doing when prompting and retrieval have been exhausted and you have enough consistent, well-labelled examples to justify the maintenance burden. Related service: AI-Powered Custom Development
Cost per request
The full model cost of serving one user-facing action, including retries, tool calls, retrieved context and any evaluation or moderation calls in the path. It is the only cost metric that lets you connect provider spend to product decisions and to a price you charge. Teams that watch the monthly invoice instead of cost per request find out about a regression roughly thirty days late. Related service: Cost & Model Optimization
P95 latency
The response time under which 95 percent of requests complete, meaning one request in twenty is slower. It is the honest number for user experience, because averages hide the tail where people actually abandon a task. For LLM features the tail is dominated by long generations, retries and slow tool calls, so it is measured end to end rather than per provider call. Related service: Telemetry & Analytics
Vendor lock-in
The cost of moving off a model provider or AI platform, created by provider-specific APIs, prompt behaviour tuned to one model family, proprietary embeddings and data that cannot be exported. Some coupling is a reasonable trade for speed; the failure is not knowing what the exit costs. The practical mitigation is an abstraction at the provider boundary, portable evaluation sets and a periodic test that a second provider still works. Related service: App Maintenance
ISO 9001
An international standard for quality management systems: documented processes, defined responsibilities, records and continuous improvement, verified by an external certification body. In an engagement it means the way we run projects - scoping, reviews, deliverables, corrective action - is a documented and audited process rather than an informal habit. It says nothing about the quality of a specific model; it says how the work around it is controlled. Related service: AI Governance Basics
FAQ

Questions teams ask.

A term earns an entry when it shows up in real work: in a client questionnaire, an audit finding, a security assessment or an AI Act classification. If we have never had to explain it to a client, it is not here, however common it is in vendor marketing.
Yes. They are written to be quoted in internal policies, specifications and supplier questionnaires. An attribution to dfzoo AI Institute is appreciated but not required.
Yes, the same set of terms, but each version is written natively rather than translated. The Polish version keeps the English engineering nouns that Polish teams actually use in conversation, because inventing local equivalents makes the text less usable, not more.
Whenever the underlying practice changes, which in this field means a few times a year. Regulatory entries are checked against the source text before publication and re-checked when guidance is issued.

Talk to an engineer.

Tell us where you are with AI. We respond within one business day.

Talk to an engineer
Szczecin - ul. Wawrzyniaka 6WWarszawa