EU AI Act Article 3: Key Definitions and What They Mean for Your Obligations
Article 3 of the EU AI Act defines AI system, provider, deployer, and GPAI model. Understand your role and obligations under Regulation (EU) 2024/1689.
Article 3 of Regulation (EU) 2024/1689 contains 83 definitions. That number is not trivia — it reflects how much of the Act's compliance logic lives at the definitional level, before you even reach the substantive obligations. Whether a penalty of €35 million attaches to your organisation depends, in the first instance, on whether the system you operate qualifies as an "AI system" under Article 3(1) and on which role Article 3 assigns to you. Get the definitions wrong and every downstream classification step is built on faulty ground.
This guide works through the load-bearing definitions: what they say, how the Commission's February 2025 guidance on the AI system definition refines interpretation, and — critically — how misreading "provider" versus "deployer" exposes you to an entirely different set of statutory duties.
What the EU AI Act Means by "AI System"
Article 3(1) defines an AI system as:
"a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."
Four elements matter here.
Machine-based. The system must execute its logic automatically. A human analyst drawing on data to write a recommendation is not an AI system. An algorithm generating that recommendation from the same data is.
Varying levels of autonomy. The definition does not require full autonomy. A system that always requires human approval of its output still qualifies, provided its logic operates independently of that human at the inference step.
Inference from input. This is the definitional threshold that separates AI systems from other software. A static rule engine — "if field X equals Y, output Z" — applies predetermined logic with no inference. A system that learns patterns from training data and applies them to new inputs infers, and therefore qualifies. Boundary cases are real: a fraud detection tool using fixed threshold rules sits outside the definition; the same tool with a machine-learning layer that adjusts those thresholds based on transaction history sits inside it.
Influence on physical or virtual environments. Outputs must have reach beyond the system itself. A model that classifies data for internal archiving purposes and whose output is never acted on sits at the edge. A recommendation engine that shapes what users see, a predictive maintenance alert that triggers equipment shutdown, or an HR screening tool that determines who advances in a hiring process — all of these clearly meet the criterion.
The Commission's February 2025 Guidelines
In February 2025 the European Commission published guidance to help operators apply the Article 3(1) definition in practice, noting particular difficulty with the inference criterion. The guidelines clarify that the focus is on whether the system uses a machine-learning or statistical approach that generalises from training data — not whether it uses a specific technical architecture. A system trained on labelled datasets and used to classify new inputs is an AI system even if its architecture is relatively simple. A lookup table, by contrast, is not. The guidelines also confirm that adaptiveness after deployment — the ability to update its behaviour based on new data without explicit reprogramming — is a sufficient but not necessary condition; a system can be an AI system without exhibiting post-deployment adaptation, provided the other elements are satisfied.
For practical classification: if your system makes predictions, generates content, issues recommendations, or produces decisions by processing inputs through a model trained on data, treat it as an AI system unless you have a documented technical basis for saying otherwise.
The Roles That Determine Your Obligations
Provider — Article 3(3)
A provider is a natural or legal person who develops an AI system or general-purpose AI model and places it on the market or puts it into service under their own name or trademark, whether for remuneration or free of charge.
Three elements trigger provider status. First, you must have developed the system — or commissioned its development and retained meaningful control over the design, training data, and performance parameters. Second, you must place it on the market or put it into service (see those definitions below). Third, it bears your name or trademark, or you otherwise present it as your own product.
Provider obligations for high-risk AI systems are set out in Article 16. The list is the heaviest in the Act: a risk management system under Article 9; data and data governance under Article 10; technical documentation under Annex IV (Article 11); record-keeping and logging under Article 12; transparency toward deployers under Article 13; human oversight capabilities built into the system under Article 14; accuracy, robustness, and cybersecurity standards under Article 15; a quality management system under Article 17; and conformity assessment before market placement under Article 43, followed by registration in the EU database under Article 49.
The fine ceiling for non-compliance with provider obligations is €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For violations of the Article 5 prohibitions — the banned practices category — the ceiling rises to €35 million or 7% (Article 99(3)). For companies that are SMEs or start-ups, Article 99(6) caps the fine at the lower of the percentage amount and the fixed amount — a genuine proportionality protection that is worth knowing.
Deployer — Article 3(4)
A deployer is a natural or legal person who uses an AI system under their authority in the course of their professional activity, except where the system is used in the course of a personal non-professional activity.
The key phrase is "under their authority." You are a deployer if you control the context in which the system operates: you set the input parameters, you determine what the system's outputs are used for, and you are responsible for what happens downstream of the system's decisions. A law firm that subscribes to an AI contract-review tool and uses it for client work is a deployer. An individual using the same tool at home to review a personal lease is not covered.
Deployer obligations under Article 26 are lighter than provider obligations, but they are not light. For high-risk systems, deployers must ensure human oversight measures function as intended; assign a qualified person to oversee the system; monitor the system for risks; and — where the deployer is a public body or meets the conditions in Article 27(1) — conduct a Fundamental Rights Impact Assessment (FRIA) under Article 27 before deploying the system.
One practical point that catches many operators: most companies that buy and use third-party AI tools are deployers, not providers. That is the lower-obligation side of the dividing line. The part that bites is Article 26's instruction to implement the human oversight measures the provider built into the system. If the provider built in measures you are not using — because no one read the instructions for use — you are non-compliant as a deployer even though you built nothing.
How Provider and Deployer Status Can Stack
An organisation that develops an AI system for internal use is simultaneously a provider (developer) and deployer (user). A SaaS company that embeds a third-party model into its own product and ships it under its own brand is a provider with respect to its customers, even if it is also a deployer with respect to the underlying model. Role stacking is common; organisations need to assess each system separately.
Market Placement Definitions
Placing on the market — Article 3(9): the first making available of an AI system on the EU market, whether for payment or free of charge, including by remote access. The moment a system reaches the first user in the EU distribution chain, it has been "placed on the market" and provider pre-market obligations are triggered.
Putting into service — Article 3(11): making an AI system available to a deployer for first use within the EU, directly by the provider or through a third party. For enterprise software sold and deployed in-house, "putting into service" is typically the go-live moment.
Making available on the market — Article 3(10): any supply of an AI system for distribution or use on the EU market in the course of a commercial activity, whether for payment or free of charge. This is the broader category; "placing on the market" is the first instance; "making available" covers ongoing downstream supply.
These distinctions matter for importers and distributors. An importer (Article 3(14)) places on the EU market a system bearing the trademark of a non-EU provider. A distributor (Article 3(15)) makes that system available further down the chain. Importers take on obligations close to those of providers when the non-EU developer has not fulfilled its requirements; distributors face a lighter but still real duty to verify upstream compliance.
Substantial Modification and the Article 25 Role-Shift
Substantial modification is defined in Article 3(23) as a change to an AI system after it has been placed on the market or put into service that affects the system's compliance with the requirements of the Act, or results in a modification of its intended purpose.
This definition is the trigger for Article 25 — the provision that reallocates provider obligations along the value chain. If a downstream actor (a deployer, distributor, or importer) makes a substantial modification to a high-risk AI system, that actor becomes the new provider for the modified system. They inherit the full Article 16 obligation stack: risk management, technical documentation, conformity assessment, registration. The original provider's documentation does not cover the modified version.
In practice, "substantial modification" is the definition most organisations underestimate. Fine-tuning a model on your own data, integrating a third-party model into a new application with a materially different intended purpose, or changing the input-output design in ways that affect the system's risk profile — each of these can trigger Article 25. Cosmetic changes (UI reskins, localisation of displayed text) and pure security patches that do not alter system behaviour do not.
Worked example. A 60-person HR-tech company (Company A) licenses a CV-screening AI system from a specialist provider. The system scores applicant CVs on technical competence and flags candidates for recruiter review. Company A is a deployer; the specialist provider is the provider. Six months after deployment, Company A's development team integrates the model into their own ATS, fine-tunes it on three years of their proprietary hiring outcomes data, and extends its scope to score candidates' "culture fit" — a dimension the original system did not assess.
Result: Company A has made a substantial modification that changes the intended purpose and materially alters the model's behaviour. Under Article 25(1), Company A is now a provider. The original provider's Annex IV technical documentation does not cover the modified system. Company A must conduct its own conformity assessment under Article 43, produce fresh technical documentation under Article 11, and register the modified system in the EU database under Article 49 before it is used further.
The fine ceiling for non-compliance, as a provider of a high-risk system used in recruitment (Annex III, point 4), is €15 million or 3% of worldwide turnover.
GPAI Definitions: Model Versus System
The Act draws a distinction between a general-purpose AI model and a general-purpose AI system that matters for determining which obligations apply.
General-purpose AI model — Article 3(63): an AI model, including where trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks, and that can be integrated into a variety of downstream systems or applications. The archetypal examples are large language models and large multimodal models.
General-purpose AI system — Article 3(66): an AI system that is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use as well as for integration into other AI systems.
The practical divide is upstream versus downstream. A foundation model provider — an organisation that trains and releases a large-scale model — is subject to the GPAI model obligations in Chapter V (Articles 51–56), which include technical documentation for downstream providers, copyright compliance policies, and, for systemic-risk models (those trained above 10²⁵ FLOPs under Article 51), model evaluation and adversarial testing. A company that builds an application on top of that foundation model and ships it to end users has a general-purpose AI system; if it also falls under Annex III, it is also a high-risk AI system and the provider of that system carries the full Article 16 stack.
GPAI model obligations have applied since 2 August 2025 (Article 113(3)).
Biometric and Sensitive-Data Definitions
Several Article 3 definitions set the scope of the biometric provisions in Annex III (point 1) and Article 5.
Biometric data — Article 3(34): personal data resulting from specific technical processing relating to the physical, physiological, or behavioural characteristics of a natural person that allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data. Processing biometric data for the purposes of uniquely identifying natural persons is classified as special category data under GDPR and, for AI systems, attracts the most restrictive treatment under the EU AI Act.
Biometric categorisation system — Article 3(40): an AI system for the purpose of assigning natural persons to specific categories on the basis of their biometric data, including their physical, physiological, or behavioural characteristics, unless ancillary to another service and strictly necessary for objective technical reasons. Biometric categorisation systems intended to be used for law enforcement or in publicly accessible spaces face the tightest restrictions under Annex III, point 1(b).
Emotion recognition system — Article 3(39): an AI system for the purpose of identifying or inferring emotions or intentions of natural persons on the basis of their biometric data. Emotion recognition systems are treated as high-risk under Annex III and face transparency requirements under Article 50 (where a person is subject to emotion recognition, they must be informed). Prohibited use of emotion recognition systems in workplaces and educational institutions is covered under Article 5(1)(f).
Serious Incident — Article 3(49)
A serious incident is any incident or malfunction of an AI system that, directly or indirectly, leads or might lead to: death of a person or serious damage to a person's health; serious disruption of critical infrastructure; breach of obligations relating to fundamental rights; serious property damage; or environmental damage.
Providers of high-risk AI systems must report serious incidents to market surveillance authorities under Article 73. The reporting obligation is one of the ongoing post-market duties that providers carry after a system is placed on the market or put into service. Deployers also have an obligation to notify the provider of serious incidents or malfunctions that pose a risk.
"Serious incident" sits alongside "near miss" in the risk management documentation providers must maintain under Article 9. A system producing outputs that narrowly avoided a serious outcome — but did not cause one — should still be captured in the risk management record, because Article 72 post-market monitoring requires providers to track and assess incidents systematically, not just those that have caused harm.
How Confir Helps with Role and Definition Mapping
Most organisations approaching EU AI Act compliance for the first time have two immediate questions: am I a provider or deployer? and does what I operate qualify as an AI system? Confir's intake process answers both through plain-English scenario questions — no legal drafting required. The classification engine applies the Article 3 definitions in explicit rule-based logic: same answers produce the same role determination, and the rule that fired is visible in the audit record.
Once the role is established, Confir maps your obligations: Article 16 duties if you are a provider, Article 26 duties if you are a deployer, with the Article 25 substantial-modification trigger flagged if your intake indicates post-market changes to a system you received from a third party. The output is an obligation set tied to specific articles, not a generic checklist.
Compliance Dates to Carry Forward from Article 3 Analysis
Article 3 definitions apply immediately — the Act entered into force on 1 August 2024. However, the substantive obligations attached to those definitions activate on staggered dates:
- 2 February 2025 — Article 5 prohibitions (unacceptable-risk practices). Already in force. If you operate a prohibited system, the fine window is open.
- 2 August 2025 — GPAI model obligations (Chapter V). Already in force for GPAI providers.
- 2 August 2026 — General application of the Act, including Article 50 limited-risk transparency obligations.
- 2 December 2027 — High-risk Annex III stand-alone systems. Under the Digital Omnibus, agreed in May 2026, this is the revised date for the obligations in Articles 9–16, 26, 43, 47–49, and 72–73 that attach to stand-alone high-risk AI systems. The original 2 August 2026 date was deferred.
- 2 August 2028 — High-risk AI systems embedded as safety components in Annex I-regulated products.
Getting your Article 3 analysis done now — before the Article 26 deployer and Article 16 provider deadlines arrive — gives you time to address any Article 25 role-shift issues before they become enforcement exposure. The biometric prohibitions under Article 5 and the GPAI obligations under Articles 53 and 55 are already live.
Frequently Asked Questions
What is the difference between "placing on the market" and "putting into service" under Article 3?
"Placing on the market" (Article 3(9)) is the first making available of a system in the EU distribution chain — typically, the moment it is sold or licensed to the first EU customer. "Putting into service" (Article 3(11)) refers to the first use of a system directly by a deployer within the EU, where no prior market placement has occurred. For an enterprise that develops an AI system exclusively for its own internal use, "putting into service" is the relevant trigger — it is simultaneously provider and deployer, and the Article 16 obligations apply from first use.
Does the EU AI Act's AI system definition cover rule-based automation tools?
Not automatically. A purely rule-based system — fixed conditional logic with no training-data inference step — does not meet the Article 3(1) definition, which requires that the system infers how to generate outputs from the input it receives. Systems that combine rule-based logic with a machine-learning inference layer do qualify. The Commission's February 2025 guidelines clarify that the inference criterion is the critical threshold: apply it to the actual technical mechanism, not to how the system is marketed.
When does a deployer become a provider under Article 25?
Under Article 25(1), a deployer becomes a provider when it makes a substantial modification (Article 3(23)) to a high-risk AI system — one that changes its compliance status or alters its intended purpose. This includes fine-tuning a model on proprietary data in ways that materially change its behaviour, integrating it into a new application with a different use case, or expanding its scope to cover decision-making the original system was not designed for. The new provider must complete conformity assessment, produce technical documentation, and register the system before continuing to use the modified version.
What counts as a "serious incident" for Article 73 reporting purposes?
Article 3(49) defines a serious incident as an incident or malfunction of an AI system that leads or might lead to death or serious health damage, disruption of critical infrastructure, breach of fundamental rights obligations, serious property damage, or environmental damage. The word "might" is significant — a near miss qualifies if it posed a credible risk of serious harm even if no harm occurred. Providers of high-risk systems report to the relevant national market surveillance authority; deployers notify the provider.
What is a general-purpose AI model and why does the distinction matter?
A general-purpose AI model (Article 3(63)) is a model trained at scale on broad data that can perform a wide range of tasks and be integrated into downstream applications — typically a large language model or multimodal model. The distinction matters because GPAI model obligations (Chapter V, Articles 51–56) apply to the organisation that trains and distributes the model, not to businesses that build applications on top of it. If you are using a third-party foundation model to build a product, you are likely a provider of a general-purpose AI system (Article 3(66)), not a GPAI model provider. The GPAI model obligations — including technical documentation for downstream providers and, for systemic-risk models, adversarial testing — fell into force on 2 August 2025.
Are emotion recognition and biometric categorisation systems treated as high-risk?
Yes, in most deployment contexts. Biometric categorisation systems and emotion recognition systems are listed in Annex III, point 1. Emotion recognition systems face an additional prohibition under Article 5(1)(f) when used in workplaces and educational institutions. Both categories also trigger Article 50 transparency obligations: any person subjected to emotion recognition must be informed. Whether the Article 6(3) de-risking filter can apply to a specific biometric system depends on the deployment context — but any system that profiles natural persons cannot claim the Article 6(3) exemption regardless of other factors.
What are the penalty ceilings for Article 3 misclassification?
There is no separate fine tier for misclassification per se. The penalty attaches to the substantive obligation that goes unmet as a result of misclassification. Deploying a prohibited system (Article 5): up to €35 million or 7% of worldwide annual turnover under Article 99(3). Failing to meet provider or deployer obligations for a high-risk system (Articles 16, 26): up to €15 million or 3% under Article 99(4). Providing false information to a notified body or authority: up to €7.5 million or 1% under Article 99(5). For SMEs and start-ups, Article 99(6) caps fines at the lower of the percentage or the fixed amount.
Related guides
- risk classification requirements
- EU AI Act compliance framework
- EU AI Act compliance software solutions
- AI governance software solutions
- AI governance compliance framework
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →