Glossary · AI Act

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.

Selected definitions·Editorially framed·AI value chain-focused
How to use this page

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 Care

    This 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 Consequence

    Architecture 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 Care

    Provider posture carries the heaviest design, documentation, conformity, and post-market burden in the Act.

    Implementation Consequence

    Teams 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 Care

    Many companies will not build the model, but will still carry real operational obligations as deployers.

    Implementation Consequence

    Procurement, 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 Care

    GPAI is where foundation-model and model-platform obligations start to diverge from ordinary application logic.

    Implementation Consequence

    Teams 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 Care

    This term is where “we are only integrating someone else’s model” can stop being true from a regulatory standpoint.

    Implementation Consequence

    Product 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 Care

    Intended purpose is one of the main boundaries that determines what the assessed compliance posture actually covers.

    Implementation Consequence

    Release 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 Care

    The Act does not let teams ignore obvious misuse paths simply because they sit outside the “happy path” in product copy.

    Implementation Consequence

    Threat 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 Care

    This is a release-governance trigger. A later change can move a system outside the posture it was originally assessed against.

    Implementation Consequence

    Model 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 Care

    The compliance burden continues after launch; monitoring is part of the regulated product lifecycle.

    Implementation Consequence

    Telemetry, 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 Care

    AI incidents are not limited to pure outages or security failures; rights and societal harms are part of the reporting picture.

    Implementation Consequence

    Incident 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 Care

    The Act treats competent use and oversight as an operational requirement, not as optional internal training.

    Implementation Consequence

    Teams 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 Care

    This term anchors a visible part of the Act’s transparency posture for synthetic content.

    Implementation Consequence

    Content 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 Care

    Once systemic-risk thresholds are crossed, the governance posture for GPAI providers becomes materially heavier.

    Implementation Consequence

    Advanced-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 Care

    This is one of the most sensitive AI Act categories and quickly changes both regulatory scrutiny and product risk.

    Implementation Consequence

    Teams building or integrating these systems need explicit classification, oversight, logging, and use-case restrictions rather than treating them as ordinary feature modules.

Next

Then route into the operational read.

Keep Reading

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.