EU AI Act glossary
for engineering teams.
The AI Act defines 68 terms. This page focuses on the ones that most often change role posture, release governance, model accountability, and the controls teams need around deployment and monitoring.
This is a curated working glossary, not a 68-term dump.
The graph tells us the AI Act defines 68 terms. The useful publishing move is not to expose all 68 with the same weight. It is to surface the terms that most often change whether a team is a provider or deployer, whether a modification changes the compliance posture, and how AI systems are monitored and governed after release.
Selected terms
- 01
AI system
A machine-based or engineered system designed to operate with varying levels of autonomy that infers and generates outputs such as predictions, recommendations, decisions, or content.
Why Engineers Should CareThis is the scope trigger. Teams need to know when a product feature, workflow, or integrated model has crossed from general software into an AI system the Act cares about.
Implementation ConsequenceArchitecture reviews need a durable way to flag AI-bearing components, not just full standalone models, so the correct role and risk analysis starts early.
- 02
Provider
The person or organisation that develops an AI system or general-purpose AI model, or has one developed on its behalf, and places it on the market or puts it into service under its own name or trademark.
Why Engineers Should CareProvider posture carries the heaviest design, documentation, conformity, and post-market burden in the Act.
Implementation ConsequenceTeams need clear ownership over release, documentation, logging, and corrective-action workflows whenever they ship AI under their own name.
- 03
Deployer
A person or organisation that uses an AI system under its own authority in a professional or organisational context.
Why Engineers Should CareMany companies will not build the model, but will still carry real operational obligations as deployers.
Implementation ConsequenceProcurement, product, and operations teams need controls around instructions for use, oversight, output handling, and fundamental-rights-sensitive deployments.
- 04
General-purpose AI model
An AI model that shows significant generality, can perform a wide range of distinct tasks, and can be integrated into a variety of downstream systems or applications.
Why Engineers Should CareGPAI is where foundation-model and model-platform obligations start to diverge from ordinary application logic.
Implementation ConsequenceTeams need documentation, downstream handoff, and model-governance workflows that survive reuse across many products and customer contexts.
- 05
Downstream provider
A provider of an AI system that incorporates or integrates an AI model into its own product or service, regardless of who built the underlying model.
Why Engineers Should CareThis term is where “we are only integrating someone else’s model” can stop being true from a regulatory standpoint.
Implementation ConsequenceProduct teams need a decision point for when integration, wrapping, or modification turns them into the responsible provider for the resulting system.
- 06
Intended purpose
The specific use for which an AI system is designed and designated by its provider, including the context and conditions of use communicated through instructions, sales materials, and technical documentation.
Why Engineers Should CareIntended purpose is one of the main boundaries that determines what the assessed compliance posture actually covers.
Implementation ConsequenceRelease notes, customer-facing claims, and documentation need to stay aligned so teams do not accidentally widen the regulated use case.
- 07
Reasonably foreseeable misuse
Use of an AI system in a manner not consistent with its intended purpose, but that can still be anticipated as a plausible outcome of predictable human behaviour or interaction with other systems.
Why Engineers Should CareThe Act does not let teams ignore obvious misuse paths simply because they sit outside the “happy path” in product copy.
Implementation ConsequenceThreat modeling, UX design, controls, and monitoring need to account for misuse patterns that are likely in real deployment conditions.
- 08
Substantial modification
A change to an AI system after market placement or service start that was not foreseen in the initial conformity assessment and that affects compliance or changes the intended purpose.
Why Engineers Should CareThis is a release-governance trigger. A later change can move a system outside the posture it was originally assessed against.
Implementation ConsequenceModel updates, feature changes, retraining, and deployment reconfiguration need structured review so teams know when a new assessment path is required.
- 09
Post-market monitoring system
The set of activities providers use to systematically collect and review operational experience from AI systems in order to identify corrective or preventive actions.
Why Engineers Should CareThe compliance burden continues after launch; monitoring is part of the regulated product lifecycle.
Implementation ConsequenceTelemetry, issue triage, corrective actions, and customer feedback loops need to feed a compliance-aware operating process instead of a generic support queue.
- 10
Serious incident
An incident or malfunction of an AI system that leads, directly or indirectly, to severe harm such as death, serious health effects, major critical-infrastructure disruption, fundamental-rights infringement, or serious property or environmental harm.
Why Engineers Should CareAI incidents are not limited to pure outages or security failures; rights and societal harms are part of the reporting picture.
Implementation ConsequenceIncident programs need AI-specific classification, evidence capture, and escalation logic rather than relying only on conventional reliability or security severity models.
- 11
AI literacy
The skills, knowledge, and understanding that let providers, deployers, and affected persons make informed decisions about AI systems, their capabilities, limitations, risks, and harms.
Why Engineers Should CareThe Act treats competent use and oversight as an operational requirement, not as optional internal training.
Implementation ConsequenceTeams need role-based enablement around AI capabilities, limitations, risk boundaries, and escalation points, especially where human oversight is expected to be meaningful.
- 12
Deep fake
AI-generated or AI-manipulated image, audio, or video content that would cause a reasonable person to perceive the depicted material as authentic or truthful when it is not.
Why Engineers Should CareThis term anchors a visible part of the Act’s transparency posture for synthetic content.
Implementation ConsequenceContent generation and publishing workflows need disclosure, labeling, watermarking, or metadata handling where the Act requires synthetic-content transparency.
- 13
Systemic risk
Risk specific to the high-impact capabilities of general-purpose AI models that can create significant large-scale effects on health, safety, security, fundamental rights, or society.
Why Engineers Should CareOnce systemic-risk thresholds are crossed, the governance posture for GPAI providers becomes materially heavier.
Implementation ConsequenceAdvanced-model programs need a way to route capability thresholds, evaluation results, incident signals, and cybersecurity posture into a stricter review and reporting path.
- 14
Remote biometric identification system
An AI-based automated system that identifies people at a distance, without their active involvement, by capturing biometric data and comparing it against a reference database.
Why Engineers Should CareThis is one of the most sensitive AI Act categories and quickly changes both regulatory scrutiny and product risk.
Implementation ConsequenceTeams building or integrating these systems need explicit classification, oversight, logging, and use-case restrictions rather than treating them as ordinary feature modules.
Then route into the operational read.
Use the vocabulary to align product, ML, and compliance work.
The glossary is the shared language layer. From there, move into the AI Act hub and the reports that connect AI governance to real operating systems.