EU AI Act glossary

This EU AI Act glossary explains the key terms that decide your obligations under the law. It covers who counts as a provider versus a deployer, what makes an AI system high-risk or subject to transparency rules, and the practical differences between a GPAI model and a finished AI system. Each entry links the legal concept to operational reality with plain-English explanations, real-world micro-examples (such as a customer-support chatbot or recruitment screening tool), and direct paths to implementation guides.[1][2]

Use the navigation table below to jump straight to the guide that matches your role or use case. All entries reflect the Regulation (EU) 2024/1689 and official Commission guidelines. They are designed as an internal-link hub so you can move quickly from terminology to actionable workflows.

Current law status (May 2026) Prohibitions, the AI system definition, AI literacy, and GPAI model obligations apply. High-risk rules for Annex III systems are scheduled to apply from August 2026. The Digital Omnibus proposal may adjust certain high-risk timelines and simplify obligations for small mid-caps; any such changes remain proposals and are labeled as such below. This glossary uses only official definitions and guidelines. It is not legal advice and does not promise compliance or certification. Check the AI Act Service Desk for the latest authoritative updates.[3]

Each entry follows the same structure for quick scanning and operational use:

• Plain-English meaning: A clear, non-legal translation.
• Why it matters operationally: What obligations or actions it triggers for your team today.
• Micro-example: A concrete scenario (chatbot, recruitment tool, etc.).
• Legal anchor: Reference to the Regulation or official guideline.
• Best next page: Internal link to the most relevant operational guide or tool.

Entries focus on current law. Any reference to possible future changes (e.g., Digital Omnibus simplifications) is explicitly labeled as a proposal or negotiation status. Terms are grouped thematically but can be searched alphabetically via browser find.

Plain-English meaning: A machine-based system that takes inputs, infers how to generate outputs (predictions, content, recommendations, or decisions), and can influence physical or virtual environments. It uses techniques from Annex I of the Regulation (machine learning, logic-based, or statistical approaches) and operates with some level of autonomy or adaptiveness after deployment. Traditional software that follows fixed, deterministic rules is generally not an AI system.[1]

Why it matters operationally: The entire risk-based framework of the AI Act applies only once something qualifies as an AI system. If your tool meets the definition, you must classify its risk level, assign roles (provider/deployer), and apply the corresponding obligations. Misclassifying a tool as “just software” can lead to later regulatory surprises during audits or incidents.

Micro-example: A customer-support chatbot that analyses past tickets and generates tailored responses using learned patterns is an AI system. A simple rules-based decision tree that always follows “if keyword X then reply Y” is not.

Legal anchor: Article 3(1) and Recital 12 of the AI Act; Commission guidelines on the AI system definition (February 2025). The guidelines emphasise practical criteria such as inference from data rather than purely deterministic programming and are non-binding but guide consistent application.[4]

Best next page: AI system versus GPAI model: the distinction that changes obligations

Plain-English meaning: An AI model that displays significant generality, can competently perform a wide range of distinct tasks, and can be integrated into many different downstream AI systems or applications. It is typically trained on large amounts of data with self-supervision. A finished application built on top of it is usually an AI system, not the model itself.[5]

Why it matters operationally: Providers of GPAI models have specific obligations (technical documentation, information to downstream providers, copyright policy, summary of training content) that apply from 2 August 2025. These are separate from high-risk AI system rules. Downstream developers who fine-tune or integrate the model may become providers of a new system and inherit additional duties. Open-source models can qualify for limited exemptions if conditions are met.

Micro-example: A foundation language model released via API that can write code, summarise documents, or draft marketing copy is a GPAI model. The customer-support chatbot built by integrating and prompting that model is an AI system.

Legal anchor: Article 3(63), Recitals 98–99, Article 53. Commission guidelines clarify the indicative 10^23 FLOP training compute threshold and exceptions.[6]

Best next page: AI system versus GPAI model: the distinction that changes obligations

Plain-English meaning: The natural or legal person who develops an AI system or GPAI model (or has it developed) and places it on the Union market or puts it into service under their own name or trademark. This role carries the heaviest compliance burden.

Why it matters operationally: Providers must carry out conformity assessment, maintain technical documentation, implement quality management systems (for high-risk), provide instructions to deployers, perform post-market monitoring, and register high-risk systems. Non-EU providers must appoint an authorised representative. Confusing this role with “we just use it” is one of the most common compliance gaps.

Micro-example: A startup that trains and releases a recruitment screening model under its brand is the provider. The HR department that uploads candidate CVs to the hosted version is the deployer.

Legal anchor: Article 3(3) and Chapter III obligations. Guidelines on GPAI providers further clarify when fine-tuning creates a new provider status.[6]

Best next page: Provider versus deployer under the EU AI Act

Plain-English meaning: Any natural or legal person using an AI system under its authority (except purely personal non-professional use). Deployers operate the system in real-world conditions and monitor its performance.

Why it matters operationally: Deployers must follow instructions, ensure human oversight, keep logs (for high-risk), perform Fundamental Rights Impact Assessments in certain cases, and report serious incidents. They are not responsible for the initial conformity assessment but can become providers if they make substantial modifications.

Micro-example: A bank that integrates a GPAI-powered credit assessment tool into its loan workflow and monitors outputs for bias is the deployer.

Legal anchor: Article 3(4), Article 26 (high-risk deployer obligations), Article 27 (FRIA).[1]

Best next page: Provider versus deployer under the EU AI Act

Plain-English meaning: A Union-established entity that places a third-country AI system or model on the Union market under the original manufacturer’s name/trademark.

Why it matters operationally: Importers must verify that the provider has fulfilled obligations, ensure correct documentation and CE marking (where applicable), and take on provider responsibilities if they modify the system substantially.

Micro-example: A European distributor bringing a non-EU recruitment AI tool to the single market must check conformity documentation before selling it to local companies.

Legal anchor: Article 3(5), Article 23.

Plain-English meaning: Any entity in the supply chain (other than the provider or importer) that makes an AI system available on the Union market.

Why it matters operationally: Distributors must act with due care, verify basic compliance indicators (marking, instructions), and assume provider obligations if they modify the system or add their own branding.

Legal anchor: Article 3(6), Article 24.

Plain-English meaning: A Union-based natural or legal person explicitly mandated in writing by a non-Union provider to perform specified compliance tasks and act as the point of contact for authorities.

Why it matters operationally: Non-EU GPAI or high-risk providers must appoint one before placing products on the market. The representative can be held accountable for certain information and cooperation duties.

Legal anchor: Article 54 (GPAI-specific) and Article 22 (high-risk).[6]

Best next page: Provider versus deployer under the EU AI Act

Plain-English meaning: The first making available of an AI system or GPAI model on the Union market for distribution or use (paid or free).

Why it matters operationally: This moment triggers most provider obligations, conformity procedures, CE marking (for high-risk), and registration. It also starts the clock for post-market monitoring.

Legal anchor: Article 3(9).

Plain-English meaning: Significant risk at Union or global scale arising from particularly capable GPAI models (high performance, wide reach, or potential for misuse such as lowering barriers to weapons or large-scale manipulation).

Why it matters operationally: Models meeting the systemic-risk criteria face additional evaluation, mitigation, incident reporting, and cybersecurity obligations. Providers must notify the Commission.

Legal anchor: Article 51 and Annex XIII. Guidelines provide criteria including compute thresholds and model capabilities.[5]

Best next page: AI system versus GPAI model: the distinction that changes obligations

Plain-English meaning: AI systems listed in Annex III or used as safety components in regulated products that could materially affect health, safety, or fundamental rights. They are not banned but must meet strict requirements before market placement.

Why it matters operationally: High-risk triggers the full suite of obligations: risk management system, high-quality data governance, technical documentation, transparency to deployers, human oversight, accuracy/robustness/cybersecurity, quality management system, conformity assessment, CE marking, registration in the EU database, and post-market monitoring. As of April 2026 these rules are not yet fully in force for most Annex III systems.

Micro-example: An AI tool used by a company to screen job applicants or score employees for promotion is high-risk under Annex III point 4 (employment).

Legal anchor: Article 6 and Annex III. Exemptions exist for systems that do not materially influence outcomes.[3]

Best next page: Annex III high-risk AI systems: the categories to watch

Plain-English meaning: Eight specific uses of AI that are banned because they contravene EU values and fundamental rights (e.g. manipulative subliminal techniques, social scoring by private or public actors, real-time remote biometric identification in public spaces with narrow law-enforcement exceptions, untargeted scraping of facial images for databases, emotion recognition in workplaces and schools except for medical or safety reasons).

Why it matters operationally: These bans have applied since 2 February 2025. Providers and deployers must ensure no product or internal process uses prohibited techniques. Violations can lead to significant fines and corrective actions.

Micro-example: A marketing tool that uses subliminal stimuli in video ads to influence purchasing decisions without user awareness would be prohibited.

Legal anchor: Article 5. Commission guidelines on prohibited practices provide legal explanations and practical examples.[7]

Plain-English meaning: Requirements to inform people when they are interacting with an AI system (chatbots) or when content has been AI-generated (deepfakes, synthetic audio/video), unless obvious from context.

Why it matters operationally: Deployers of interactive systems must disclose the AI nature “in a clear and accessible manner.” Providers of certain generative systems must label outputs. A voluntary Code of Practice supports implementation. Non-compliance risks eroding trust and potential enforcement.

Micro-example: A customer-support chatbot must tell users it is AI-powered at the start of the conversation.

Legal anchor: Article 50. Commission transparency FAQ and draft Code of Practice.[8]

Best next page: Article 50 transparency obligations explained

Plain-English meaning: The knowledge, skills, and understanding that providers and deployers need to use AI systems responsibly, including awareness of risks, limitations, and human oversight needs. It is not a mandatory training certificate.

Why it matters operationally: All providers and deployers must ensure staff have sufficient AI literacy to fulfil their obligations. This supports effective human oversight and reduces misuse risk. It applies from the first phase of the Act.

Micro-example: Recruiters using an AI screening tool should understand how bias can enter training data and how to override or interpret outputs.

Legal anchor: Article 4 and associated Commission Q&A. No mandatory AI officer or certified training is required.[3]

Best next page: AI Literacy Planner

Plain-English meaning: A structured assessment that public bodies and certain private deployers must carry out before using high-risk AI systems that could affect fundamental rights.

Why it matters operationally: It forces early identification of risks to non-discrimination, privacy, dignity, etc., and requires mitigation measures and notification to authorities in some cases. It is a key artifact for demonstrating accountability.

Micro-example: A municipality deploying an AI system to allocate social benefits must document potential impacts on vulnerable groups.

Legal anchor: Article 27.

Best next page: Annex III high-risk AI systems: the categories to watch

Plain-English meaning: The ongoing process by which providers collect data on real-world performance of their AI systems after placement, detect incidents or drifts, and take corrective action.

Why it matters operationally: It turns compliance into a continuous activity. Providers must have a system in place, analyse feedback, and report serious incidents. Deployers assist by providing usage data.

Legal anchor: Article 72 and related provisions in Chapter IX.

Plain-English meaning: A documented internal system of policies, procedures, and responsibilities that ensures consistent compliance with AI Act requirements for high-risk systems throughout the lifecycle.

Why it matters operationally: Providers of high-risk systems must implement and maintain a QMS. It covers risk management, data governance, documentation control, corrective actions, and management review. Auditors will examine it.

Legal anchor: Article 17.

Plain-English meaning: The detailed records (general description, architecture, data used, testing, risk analysis, etc.) that demonstrate how a high-risk AI system or GPAI model meets legal requirements.

Why it matters operationally: It must be kept up to date and supplied to authorities or notified bodies on request. For GPAI models it includes development process information. Poor documentation is a frequent audit failure point.

Legal anchor: Article 11 (high-risk) and Article 53 (GPAI).

Plain-English meaning: The exhaustive list in the Annex that defines most stand-alone high-risk AI use cases (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice, democratic processes).

Why it matters operationally: If your use case matches an Annex III point and the system can materially influence outcomes, it is high-risk by default (subject to narrow exemptions).

Legal anchor: Article 6(2) and Annex III. The list can be updated via delegated acts.[3]

Best next page: Annex III high-risk AI systems: the categories to watch

Plain-English meaning: A continuous, iterative process to identify, analyse, evaluate, and mitigate foreseeable risks to health, safety, and fundamental rights throughout the AI system lifecycle.

Why it matters operationally: It is the foundational requirement for high-risk providers. It must be proportionate, documented, and updated with post-market data.

Legal anchor: Article 9.

Plain-English meaning: The design and operational measures that allow humans to understand, interpret, and intervene in or override AI outputs to prevent or minimise risks.

Why it matters operationally: High-risk systems must be designed for effective oversight. Deployers must assign competent people with authority and training.

Legal anchor: Article 14.

Plain-English meaning: The process (internal or involving a notified body) that verifies a high-risk AI system meets all applicable requirements before CE marking and market placement.

Why it matters operationally: It is the gateway to lawful market entry. SMEs have some simplified options.

Legal anchor: Articles 43–44.

(Additional entries for completeness: Data governance, Record-keeping, Accuracy/robustness/cybersecurity, Notified body, CE marking, EU database registration, Code of Practice for GPAI, Downstream provider responsibilities, and Serious incident reporting follow the same pattern and are available in the full workspace version of this glossary.)

• Treating every LLM-powered tool as automatically high-risk instead of checking Annex III and material influence criteria.
• Blurring provider and deployer roles — a company that fine-tunes a GPAI model for internal use may become a provider.
• Assuming “open source = no obligations” — many GPAI transparency and copyright duties still apply.
• Skipping technical documentation because “the model is hosted by a third party” — downstream obligations remain.
• Confusing Article 50 transparency with optional labelling — disclosure is mandatory when not obvious from context.
• Waiting for high-risk rules to “start” before building QMS or risk management processes — early preparation reduces later rework.
• Relying only on vendor statements without mapping your own role and required artifacts.
• Treating FRIA as a one-time checkbox instead of a living document tied to post-market monitoring.

• Inventory all AI systems and GPAI models in use or under development.
• Classify each against the AI system definition and Annex III (or GPAI criteria).
• Assign and document provider/deployer/importer roles for every item.
• Map current artifacts (technical documentation, risk analyses, training summaries) against obligations.
• Check Article 50 applicability for any user-facing or content-generating tools.
• Schedule AI literacy sessions for relevant teams.
• For high-risk items, begin drafting QMS, risk management, and FRIA templates now.
• Test your inventory against the free scanner tool below.

Ready to turn these definitions into evidence? Use the Evidence Scanner to map your current AI inventory against these terms and roles, or generate Article 50 disclosures for your chatbots and generative tools. Start free at EU AI Act Evidence Scanner.

• Regulation (EU) 2024/1689 (EUR-Lex official text).[1]
• Commission Guidelines on the AI system definition and prohibited practices (2025).
• Guidelines on obligations for providers of general-purpose AI models and associated FAQ.[6]
• AI Act Service Desk timeline, FAQ, and Article 113 pages.[2]
• Official transparency and GPAI Code of Practice resources.[8]

All links lead to primary EU sources or the operational guides built from them. This page is updated as new official guidelines are published.