EU AI Act: practical steps for providers and deployers

EU AI Act: practical steps for providers and deployers

Checklist download: provider and deployer checklists

The Artificial Intelligence Act is Regulation (EU) 2024/1689. It is the Union’s horizontal law on the placing on the market, putting into service and use of AI systems, and on the placing on the market of general-purpose AI models. The European Parliament and the Council adopted it on 13 June 2024. It was published in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. Regulation (EU) 2026/1744 (the Digital Omnibus on AI) amended it with effect from 27 July 2026. The operative text is the consolidated version of 27 July 2026.

The Act does not treat every AI tool the same way. It splits duties by role and by risk. A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the system into service under its own name or trademark, whether for payment or free of charge. A deployer uses an AI system under its authority in a professional capacity. The same organisation can be both, and a deployer can become a provider if it white-labels a high-risk system, substantially modifies one, or changes an existing system’s intended purpose so that it becomes high-risk.

This guide is a working map of the steps those two roles actually have to take. It covers who is in scope, how to tell the two roles apart, the duties that already bind both of them (AI literacy and the Article 5 prohibitions), the Article 50 transparency rules that applied from 2 August 2026, the general-purpose AI model rules that the Commission can now enforce, and the high-risk duties that the Omnibus deferred to 2 December 2027 (Annex III systems) and 2 August 2028 (Annex I product systems). Facts below come from the Regulation as amended, from Commission guidelines and codes of practice, and from texts published by the AI Office.

A printable checklist for each role is available as a download. Use it as an internal workplan, not as a substitute for reading the legal text that applies to a given system.

The Regulation is directly applicable in the Member States. It has EEA relevance. Union data-protection law continues to apply to personal data processed in connection with the Act. Meeting the AI Act is not a substitute for the GDPR, and meeting the GDPR is not a substitute for the AI Act.

What the Act is

Article 1 states the purpose. The Regulation aims to improve the functioning of the internal market and to promote the uptake of human-centric and trustworthy AI, while ensuring a high level of protection of health, safety and fundamental rights in the Charter, including democracy, the rule of law and environmental protection, and while supporting innovation.

It lays down seven sets of rules: placing AI systems on the market, putting them into service and using them; prohibitions of certain practices; requirements for high-risk AI systems and obligations for the operators of those systems; transparency rules for certain AI systems; rules for general-purpose AI models; market monitoring, surveillance, governance and enforcement; and measures to support innovation, with particular focus on SMEs, including start-ups, and small mid-cap enterprises (SMCs).

An AI system is 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. The Commission published guidelines on that definition in February 2025. They are not binding. They record the Commission’s interpretation and will guide enforcement until the Court of Justice rules.

A general-purpose AI model is an AI model, including one 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. Models used only for research, development or prototyping before they are placed on the market are excluded from that definition. The Commission’s GPAI guidelines treat an indicative training-compute threshold of 10^23 FLOP as a practical marker of generality. That figure is guidance, not a statutory threshold. The statutory presumption of systemic risk sits at more than 10^25 FLOP.

The Act is risk-based. Four practical bands matter for day-to-day work:

1. Prohibited practices under Article 5. These are banned for providers and for deployers.
2. High-risk AI systems under Article 6 and Annexes I and III. These carry the heaviest product and use duties, most of which are not yet applicable.
3. Transparency-risk systems under Article 50. Chatbots, generative systems, deepfakes, certain public-interest text, emotion recognition and biometric categorisation sit here.
4. Minimal-risk systems. The Act does not add product rules for them. Literacy, the prohibitions, and any overlapping Union law (GDPR, product safety, consumer law) still apply.

Most office tools, spam filters and recommendation widgets fall in the last band unless a specific Article 50 or Annex III use is engaged.

Dates that actually apply

Article 113, as rewritten by the Omnibus, is the clock. Commentary written before 27 July 2026 will be wrong on high-risk dates.

Date	What applies
2 February 2025	Chapters I and II: definitions, scope, AI literacy, and the original Article 5 prohibitions.
2 August 2025	GPAI model rules (Chapter V), governance, and related provisions. Commission GPAI enforcement powers (including Article 101 fines) were held back until the general application date.
27 July 2026	Digital Omnibus on AI entered into force. High-risk dates moved. Article 4 literacy duty rewritten. New Article 5 prohibitions on non-consensual intimate material and child sexual abuse material added, with delayed application.
2 August 2026	General application date. Article 50 transparency rules apply. The AI Office and national authorities begin enforcing the Act, including GPAI fines.
2 December 2026	New Article 5(1) points (ba) and (bb) apply. Providers of generative systems already on the market before 2 August 2026 must complete Article 50(2) machine-readable marking.
2 August 2027	GPAI models placed on the market before 2 August 2025 must comply with Chapter V. National AI regulatory sandboxes must be operational.
2 December 2027	High-risk duties in Chapter III, Sections 1 to 3, apply to Annex III systems (Article 6(2)).
2 August 2028	Those high-risk duties apply to Annex I product systems (Article 6(1)).
2 August 2030	Public-authority high-risk systems already on the market, and certain large-scale IT systems, must be brought into line (Article 111).

Two traps sit in that table. First, the Omnibus did not postpone Article 50, GPAI enforcement, or the original prohibitions. Second, Article 111(2) says that high-risk systems already placed on the market or put into service before the relevant Chapter III date are not pulled into the new high-risk duties unless their design is significantly changed, except that providers and deployers of high-risk systems intended to be used by public authorities must still comply by 2 August 2030. Planning for Annex III use in 2027 still has to start now, because conformity assessment, quality management and a fundamental rights impact assessment are not weekend tasks.

Who is in scope

Article 2(1) applies the Regulation to:

• providers placing AI systems on the market or putting them into service in the Union, or placing general-purpose AI models on the Union market, whether they are established in the Union or in a third country
• deployers of AI systems established or located in the Union
• providers and deployers established or located in a third country, where the output of the AI system is used in the Union
• importers and distributors of AI systems
• product manufacturers who place an AI system on the market or put it into service together with their product and under their own name or trademark
• authorised representatives of providers that are not established in the Union
• affected persons located in the Union

The third-country output rule is the one that catches a UK, US or South African firm whose AI output is used in the Union. Recital 21 and Article 2(1)(c) do not require the provider or deployer to have an establishment in the Union. A website, an event platform, a hiring tool or a credit engine whose outputs are used by people or organisations in the Union can be enough. Output that never leaves a purely domestic, non-Union context is outside that connecting factor. Content published on a website that Union users can reach is not, on that fact alone, outside it.

Article 2 then carves out several activities. The Act does not apply to areas outside Union law, or to Member State national-security competences. It does not apply to AI systems placed on the market, put into service or used exclusively for military, defence or national security purposes. It does not apply to systems that are not placed on the market or put into service in the Union where the output is used in the Union exclusively for those purposes. Scientific research and development, and research, testing or development before placing on the market or putting into service, are out, except for testing in real-world conditions. Deployers who are natural persons using AI in a purely personal non-professional activity are out. Free and open-source systems are out unless they are placed on the market or put into service as high-risk systems or as systems that fall under Article 5 or 50.

The Act does not stop Member States from maintaining more favourable worker-protection rules on employer use of AI, or from encouraging collective agreements that go further.

Provider or deployer

Role is a legal fact, not a branding choice. Article 3 supplies the tests.

The provider is the person who develops the system or model, or has it developed, and then places it on the market or puts the AI system into service under its own name or trademark. Payment is irrelevant. An internal tool put into service for the organisation’s own use under its own name can make that organisation a provider. A company that buys an API and wraps it in a product sold under its own mark is a provider of that AI system.

The deployer is the person using the system under its authority, other than in a personal non-professional activity. Recital 13 says the notion covers any natural or legal person, including a public authority, using an AI system under its authority except for personal non-professional use. Depending on the type of system, use may affect persons other than the deployer.

Putting into service is the supply of an AI system for first use directly to the deployer, or for own use in the Union, for its intended purpose. Placing on the market is the first making available of an AI system or general-purpose AI model on the Union market. Intended purpose is the use the provider intends, as stated in the instructions for use, promotional or sales materials, statements and technical documentation.

Other operators sit on the supply chain. An importer is established in the Union and places on the market a system that bears a third-country name or trademark. A distributor makes a system available on the Union market without being the provider or the importer. An authorised representative is established in the Union and holds a written mandate from a third-country provider. Operator is the umbrella term for all of those roles plus the product manufacturer.

A bank that licenses a third-party CV-screening tool and uses it on applicants is a deployer. The vendor that placed that tool on the market under its own name is the provider. If the bank then resells the same tool under the bank’s mark, Article 25 can move the bank into the provider seat for that high-risk system.

When a deployer becomes a provider

Article 25 is the trap that most commercial deployers need to check before they customise a system.

A distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system, and takes on the Article 16 duties, in any of three cases:

1. it puts its name or trademark on a high-risk AI system already placed on the market or put into service (contractual allocation of duties does not stop the Regulation treating it as provider)
2. it makes a substantial modification to a high-risk AI system already placed on the market or put into service, in such a way that the system remains high-risk
3. it modifies the intended purpose of an AI system, including a general-purpose AI system, that was not classified as high-risk, so that the system becomes high-risk under Article 6

Substantial modification is a change after placing on the market or putting into service that was not foreseen or planned in the initial conformity assessment, and that either affects compliance with the Chapter III, Section 2 requirements or changes the intended purpose for which the system was assessed.

When any of those three cases occurs, the original provider is no longer the provider of that specific system. It must cooperate with the new provider and hand over the information, technical access and assistance reasonably needed for conformity assessment, including technical documentation, known limitations and failure modes, and targeted access for testing and validation. That handover duty does not apply if the original provider clearly specified that its system is not to be changed into a high-risk AI system.

For most organisations using ChatGPT, Copilot or Gemini as off-the-shelf tools, inside the provider’s intended purpose and without rebranding the model as their own high-risk product, Article 25 will not fire. It can fire where a firm:

• white-labels a recruitment or credit-scoring engine
• fine-tunes or re-purposes a general-purpose system so that it is used to filter job applications, score credit, or decide education admissions
• embeds a third-party model in a product that is itself a safety component of an Annex I product, and places that product on the market under its own name

Article 25(4) also requires a written agreement between the provider of a high-risk system and a third party that supplies a model, tools, services, components or processes used or integrated in that system, covering the information, capabilities, technical access and other assistance needed for compliance. Open-source tools other than general-purpose AI models, made accessible to the public under a free and open-source licence, are outside that contract rule.

Practical step: before a customisation, integration or rebrand, record whether the intended purpose will remain the provider’s intended purpose, whether the change is a substantial modification, and whether the organisation’s name will sit on a high-risk system. If any of the three Article 25 gates is met, treat the project as a provider project from that point.

Shared duties: literacy and prohibitions

Two chapters already bind providers and deployers alike, regardless of whether the system is high-risk.

AI literacy

Article 4, as replaced by the Omnibus, requires providers and deployers to take measures to support the development of AI literacy of their staff and of other persons dealing with the operation and use of AI systems on their behalf. The measures must take into account technical knowledge, experience, education and training, the context in which the systems are to be used, and the persons or groups on whom the systems are to be used. The provision states, in terms, that this obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.

That is a weaker duty than the original text, which required measures to ensure, to their best extent, a sufficient level of literacy. The duty to act remains. There is still no statutory certificate and no mandated test. The Commission and the Member States must support those efforts, in particular for SMEs, and must publish practical examples on the single information platform. The European Artificial Intelligence Board is to adopt recommendations setting common objectives.

AI literacy, in Article 3, means skills, knowledge and understanding that allow providers, deployers and affected persons to make an informed deployment of AI systems, and to gain awareness of the opportunities and risks of AI and possible harm it can cause, taking into account their rights and obligations under the Regulation.

For high-risk systems, literacy is not the whole story. Article 26(2) still requires the deployer to assign human oversight to natural persons who have the necessary competence, training, authority and support. That is a result-oriented staffing rule, not a general literacy slogan.

Practical steps that satisfy Article 4 in a proportionate way:

• map who operates or oversees each AI system, including contractors
• give those people role-specific instruction on what the system does, what it must not be used for, known limitations, and how to escalate incidents
• keep a short record of the measures taken (who, what, when), without pretending the record proves a personal “level”
• for any future high-risk use, train the named oversight persons to the Article 14 and 26(2) standard

Prohibited practices

Article 5 prohibits placing on the market, putting into service or using listed practices. The original list has applied since 2 February 2025. Two further prohibitions apply from 2 December 2026. The Commission published guidelines on the original prohibitions in February 2025.

The practices that are already banned include:

• subliminal, purposefully manipulative or deceptive techniques that materially distort behaviour and cause, or are reasonably likely to cause, significant harm
• exploitation of vulnerabilities due to age, disability, or a specific social or economic situation, with the same harm test
• social scoring of natural persons over time based on social behaviour or predicted personality characteristics, where the score leads to unrelated or disproportionate detrimental treatment
• individual criminal-offence risk assessment or prediction based solely on profiling or personality traits (support for human assessment of involvement already based on objective, verifiable facts linked to criminal activity is carved out)
• untargeted scraping of facial images from the internet or CCTV to create or expand facial recognition databases
• emotion recognition in workplaces and education institutions, except where the system is intended to be placed on the market or put into service for medical or safety reasons
• biometric categorisation that infers race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation (labelling or filtering of lawfully acquired biometric datasets, and certain law-enforcement categorisation, are carved out)
• ‘real-time’ remote biometric identification in publicly accessible spaces for law enforcement, except for the narrow, authorised cases in Article 5(1)(h) and 5(2) to (7)

From 2 December 2026, Article 5(1)(ba) and (bb) also prohibit systems that generate or manipulate realistic intimate depictions of an identifiable person without that person’s freely given, specific, informed, unambiguous and explicit consent, and systems that generate or manipulate child sexual abuse material within the meaning of Directive 2011/93/EU, subject to a national-law “without right” defence.

Article 5(1a) splits provider and deployer fault for those two new bans. Placing on the market or putting into service is prohibited where generation or manipulation of that material is the intended purpose, or where it is a reasonably foreseeable and reproducible outcome and the system lacks reasonable and adequate technical safety measures and other safeguards. Use is prohibited only where the deployer uses the system for the purpose of generating or manipulating that material. Accidental generation, and use for lawful purposes, are not caught as deployer use-bans, even if the provider’s safeguards were inadequate.

Practical steps:

• screen the inventory against Article 5 before any new tool goes live
• ban emotion-recognition plugins in HR and training products unless a documented medical or safety purpose exists
• treat untargeted facial scraping, social scoring of staff or customers, and “nudification” features as prohibited, not as product ideas to be mitigated later
• from now through 2 December 2026, providers of generative image, video and audio systems need a documented safeguard plan (data cleaning, refusal training, output filters, abuse reporting) that will stand up to Article 5(1a)
• deployers need an acceptable-use rule that forbids using any system to generate non-consensual intimate material or child sexual abuse material

Non-compliance with Article 5 attracts the top fine: up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher. For SMEs, including start-ups, the lower of the percentage and the amount applies.

Inventory and classification

Every later duty depends on knowing what the organisation actually uses or sells. The Act does not require a GDPR-style Article 30 record for all AI. Without an inventory, though, Article 5, Article 50 and the 2027 high-risk rules cannot be applied in a defensible way.

For each system or model, record:

• name, vendor, and whether it is used under the organisation’s authority or placed on the market / put into service under the organisation’s name
• whether it is an AI system, a general-purpose AI model, or neither (apply the Article 3 definitions and the Commission definition guidelines)
• intended purpose, as the provider states it, and the organisation’s actual use
• whether output is used in the Union
• whether Article 5 could be engaged
• whether Article 50 is engaged (direct interaction with natural persons; generation of synthetic content; emotion recognition or biometric categorisation; deepfakes; public-interest text)
• whether Annex III or Annex I could make it high-risk from 2 December 2027 or 2 August 2028
• whether Article 25 could recast the organisation as provider
• personal data involved (for the GDPR overlay)
• named owner, oversight persons, and where logs and instructions for use are kept

Annex III high-risk areas, for that screening, are:

1. biometrics (remote biometric identification, biometric categorisation, emotion recognition), insofar as permitted
2. safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity
3. education and vocational training (access, admission, evaluation of learning outcomes, level assignment, exam-cheating detection)
4. employment, workers’ management and access to self-employment (recruitment, selection, decisions on terms, promotion or termination, task allocation based on behaviour or personal traits, performance monitoring)
5. access to essential private and public services and benefits, including creditworthiness (other than fraud detection), life and health insurance risk assessment and pricing, and emergency dispatch
6. law enforcement (insofar as not already prohibited)
7. migration, asylum and border control management
8. administration of justice and democratic processes

Article 6(3) then takes some Annex III systems back out of high-risk where they do not pose a significant risk of harm, including by not materially influencing the outcome of decision-making, if they only perform a narrow procedural task, improve a completed human activity, detect decision-making patterns without replacing human assessment, or perform a preparatory task. Profiling of natural persons always remains high-risk. A provider that relies on Article 6(3) must document the assessment before placing the system on the market or putting it into service, and must still register under Article 49(2).

The Commission published draft high-risk classification guidelines on 19 May 2026. A final version is expected before the Annex III duties apply. Until then, treat the draft as the Commission’s working interpretation, not as the Regulation itself.

Provider duties

This section is for organisations that place AI systems or general-purpose AI models on the Union market, or put AI systems into service under their own name. It is also for organisations that Article 25 treats as providers.

Providers of general-purpose AI models

Chapter V has applied since 2 August 2025. From 2 August 2026 the Commission, through the AI Office, can enforce it, including with fines. Providers of models placed on the market before 2 August 2025 have until 2 August 2027 to comply.

Article 53 requires every GPAI provider to:

• draw up and keep up to date technical documentation of the model, including training, testing and evaluation, containing at least the Annex XI information, for the AI Office and national competent authorities on request
• draw up, keep up to date and make available to downstream providers of AI systems the information they need to understand capabilities and limitations and to comply with the Act, containing at least the Annex XII elements
• put in place a policy to comply with Union copyright and related rights, and in particular to identify and comply with, including through state-of-the-art technologies, a reservation of rights under Article 4(3) of Directive (EU) 2019/790 (the text-and-data-mining opt-out)
• draw up and make publicly available a sufficiently detailed summary of the content used for training, according to the AI Office template

Points (a) and (b) (technical documentation and downstream documentation) do not apply to models released under a free and open-source licence that allows access, use, modification and distribution, where the parameters, including the weights, architecture information and usage information, are publicly available. That open-source relief does not apply to models with systemic risk.

A model is classified as presenting systemic risk if it has high-impact capabilities, or if the Commission designates it under Annex XIII criteria. High-impact capabilities are presumed where cumulative training compute exceeds 10^25 FLOP. The provider must notify the Commission without delay and in any event within two weeks after the threshold is met or it becomes known that it will be met. The Commission publishes a list of systemic-risk models.

Article 55 then adds, for systemic-risk models: state-of-the-art model evaluation including adversarial testing; assessment and mitigation of systemic risks at Union level; tracking, documentation and prompt reporting of serious incidents to the AI Office; and an adequate level of cybersecurity for the model and its physical infrastructure.

Providers established in third countries must, before placing a GPAI model on the Union market, appoint in writing an authorised representative established in the Union, unless the open-source exception in Article 54(6) applies (again, not for systemic-risk models).

The GPAI Code of Practice is a voluntary route to demonstrate Article 53 and 55 compliance until a harmonised standard is published. Signatories can rely on it. Non-signatories must demonstrate alternative adequate means. The Commission’s GPAI guidelines (July 2025) explain who is a GPAI provider, what counts as a significant modification of a model, and how to use the EU SEND platform for notifications, incident reports and, for non-signatories, reports on how they intend to comply.

Practical steps for a GPAI provider:

1. Decide whether each model is a GPAI model under Article 3 and the Commission guidelines.
2. Measure or estimate training compute against the 10^25 FLOP presumption. If the threshold is met or foreseeable, notify the AI Office within two weeks via EU SEND.
3. Keep Annex XI technical documentation and Annex XII downstream documentation current.
4. Adopt a copyright policy that can actually detect and honour Article 4(3) TDM reservations.
5. Publish the training-content summary on the AI Office template.
6. If the model presents systemic risk, stand up evaluation, adversarial testing, incident reporting and cybersecurity commensurate with Article 55. Adhere to the GPAI Code of Practice or document an equivalent method.
7. If established outside the Union, appoint an Article 54 authorised representative.
8. From 2 August 2026, treat AI Office information requests, evaluations and possible Article 101 fines as live enforcement, not as a future regime.

Providers of AI systems: Article 50 transparency

Article 50(1) and (2) applied from 2 August 2026. They bind providers, not deployers. The Commission published guidelines on 20 July 2026. A Code of Practice on transparency of AI-generated content sits next to those guidelines. Adherence is voluntary. Providers that do not adhere have to demonstrate equivalent means for marking and labelling.

Article 50(1). Providers must ensure that AI systems intended to interact directly with natural persons are designed and developed so that those persons are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. Law-enforcement systems authorised to detect, prevent, investigate or prosecute criminal offences are carved out, unless they are available for the public to report a criminal offence.

The duty is a design duty. A vendor of a customer-service chatbot must build the disclosure in. A company that merely licenses that chatbot as a deployer does not take on Article 50(1) by using it. That company still has to choose a provider that has designed the disclosure, because an undeclared chatbot offered to Union users is a non-compliant system on the market.

Article 50(2). Providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text must ensure that outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. Technical solutions must be effective, interoperable, robust and reliable as far as technically feasible, taking account of content types, cost and the state of the art. The duty does not apply to the extent the system performs an assistive function for standard editing, or does not substantially alter the input or its semantics, or is authorised for criminal-law purposes.

This is watermarking and content credentials, not a visible caption for the end user. Visible deepfake labels are a deployer duty under Article 50(4).

Providers of generative systems already on the market before 2 August 2026 have until 2 December 2026 to comply with Article 50(2). There is no equivalent grace period for Article 50(1), or for deployer labelling under Article 50(3) and (4).

Practical steps for a system provider:

1. Identify systems that interact directly with natural persons. Build in a clear, accessible disclosure at first interaction unless the Commission guidelines would treat the AI character as obvious in that context.
2. Identify systems that generate synthetic audio, image, video or text. Implement machine-readable marking that meets Article 50(2), or document why the standard-editing exception applies.
3. Join the transparency Code of Practice or keep an equivalent technical file.
4. Put the same requirements into contracts with downstream deployers only where the deployer needs to preserve marks (do not shift a provider design duty onto the customer by contract and call that compliance).
5. If the system is already on the market, treat 2 December 2026 as the hard date for marking, not as a reason to wait on disclosure design.

Providers of high-risk AI systems

Chapter III, Sections 1 to 3 (classification, requirements, and operator obligations) apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Providers who will be on that clock should build the machinery now. Harmonised standards from CEN and CENELEC were not available for the original 2 August 2026 date. That delay is why the Omnibus moved the high-risk clock.

Article 16 is the provider’s list. Before placing a high-risk system on the market or putting it into service, the provider must:

• ensure compliance with the Section 2 requirements (Articles 9 to 15): risk management, data and data governance, technical documentation, record-keeping, transparency and provision of information to deployers, human oversight, and accuracy, robustness and cybersecurity
• identify itself on the system, packaging or documentation
• operate a quality management system under Article 17
• keep the Article 18 file for 10 years after the system is placed on the market or put into service (technical documentation, QMS documentation, notified-body documents, EU declaration of conformity)
• keep automatically generated logs, to the extent under its control, for at least six months
• complete the Article 43 conformity assessment
• draw up the EU declaration of conformity and affix CE marking
• register in the EU database under Article 49(1) (Annex III, with the critical-infrastructure exception)
• take corrective action and inform the chain under Article 20
• demonstrate conformity to a national competent authority on reasoned request
• meet accessibility requirements in Directives (EU) 2016/2102 and (EU) 2019/882

Section 2 is the product-safety core. Article 9 requires a documented risk-management system across the lifecycle. Article 10 requires training, validation and testing data that are relevant, representative, free of errors as far as possible, and complete, with bias detection and correction. Article 11 and Annex IV set the technical documentation. Article 12 requires logging that can trace operation. Article 13 requires instructions for use that a deployer can actually follow, including intended purpose, limitations, accuracy metrics, human-oversight measures and log-collection mechanisms. Article 14 requires human oversight designed into the system. Article 15 requires an appropriate level of accuracy, robustness and cybersecurity.

Article 17 QMS content is specified: compliance strategy, design control, development quality, testing, technical specifications, data management, the Article 9 risk system, post-market monitoring (Article 72), serious-incident reporting (Article 73), authority communication, record-keeping, resource management, and an accountability framework. Implementation must be proportionate to the provider’s size, including for SMEs, start-ups and SMCs, without dropping the required level of protection. The Omnibus extended the simplified QMS route in Article 63 from microenterprises to all SMEs, including start-ups.

Third-country providers of high-risk systems must appoint an Article 22 authorised representative in the Union before making the system available on the Union market. Importers and distributors have their own pre-market checks (Articles 23 and 24).

Post-market, Article 72 requires a monitoring system. Article 73 requires reporting of serious incidents. Article 20 requires immediate corrective action (bring into conformity, withdraw, disable or recall) if the provider has reason to consider the system is not in conformity, and immediate investigation and authority notification if the system presents an Article 79(1) risk.

Practical steps to take before 2 December 2027 (Annex III) or 2 August 2028 (Annex I):

1. Confirm high-risk classification under Article 6, including any Article 6(3) derogation, and keep that assessment on file.
2. Stand up the Article 17 QMS, sized to the organisation, with named management responsibility.
3. Build the Article 9 risk file and the Article 10 data file in parallel with development, not after freeze.
4. Write instructions for use that a deployer can operate: intended purpose, out-of-scope uses, metrics, residual risks, human-oversight interface, log export.
5. Design the Article 14 oversight interface so that a trained human can understand, override and stop the system.
6. Plan the Article 43 route (internal control vs notified body) against the standards and common specifications that exist at the time.
7. Prepare EU declaration of conformity, CE marking and Article 49 registration.
8. If established outside the Union, appoint the Article 22 representative.
9. Put Article 25(4) supply-chain clauses in contracts with model and component suppliers.
10. Write the Article 72 post-market monitoring plan before launch, including how deployer feedback under Article 26(5) will be received.

Deployer duties

This section is for organisations that use AI systems under their authority and do not, for those systems, meet an Article 25 provider test. Most companies, agencies, schools, hospitals and public bodies sit here for most of their tools.

Everyday use of AI tools

For a minimal-risk system (a writing assistant used to draft internal notes, a spam filter, a meeting transcriber used with a lawful GDPR basis), the Act’s extra product rules do not apply. The deployer still has to:

• take Article 4 literacy measures for the people who operate the tool
• keep the use outside Article 5
• comply with the GDPR where personal data are processed
• check that the vendor is the provider for Article 50(1) and (2) if the tool faces natural persons or generates synthetic content, so that Union users are not interacting with an unmarked or undisclosed system
• watch Article 25 if the organisation starts wrapping the tool as its own product or changing the intended purpose toward an Annex III use

Vendor onboarding is the practical control. Before a tool is used on Union output, the deployer should obtain, in writing: the provider’s name and role; whether the tool is an AI system; the intended purpose; how Article 50(1) and (2) are met if relevant; how prohibited practices are excluded; where Union output will be processed; and a contact for serious incidents. Contract clauses that merely say “the vendor will comply with the AI Act” are not a substitute for knowing which duties sit on which party.

Article 50 duties that sit on the deployer

Article 50(3) and (4) applied from 2 August 2026. There is no 2 December 2026 grace period for deployers.

Emotion recognition and biometric categorisation (Article 50(3)). Deployers of those systems must inform the natural persons exposed of the operation of the system, and must process personal data in accordance with the GDPR, Regulation (EU) 2018/1725 or Directive (EU) 2016/680, as applicable. A criminal-law carve-out exists. Emotion recognition in the workplace or in education is in any event prohibited by Article 5(1)(f) unless the medical or safety exception applies, so the Article 50(3) notice is not a route to run a banned HR mood scanner.

Deepfakes (Article 50(4), first subparagraph). A deep fake is AI-generated or manipulated image, audio or video content that resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful. Deployers of a system that generates or manipulates such content must disclose that the content has been artificially generated or manipulated. Criminal-law use is carved out. Where the content forms part of an evidently artistic, creative, satirical, fictional or analogous work or programme, disclosure is limited to revealing the existence of such generated or manipulated content in an appropriate manner that does not hamper the display or enjoyment of the work.

Typical cases: an AI video of a real speaker who did not record it; a synthetic voice of an identifiable person; an image of a real venue or public figure presented as a photograph of an event that did not occur. A clearly illustrated cartoon, or a spoof labelled as fiction, is not treated the same way as a photorealistic clip of a named executive.

Public-interest text (Article 50(4), second subparagraph). Deployers of a system that generates or manipulates text published with the purpose of informing the public on matters of public interest must disclose that the text has been artificially generated or manipulated. The duty does not apply where the use is authorised for criminal-law purposes, or where the AI-generated content has undergone a process of human review or editorial control and a natural or legal person holds editorial responsibility for the publication.

That editorial exception is the one that matters for newsrooms, in-house communications teams and agencies. If a human edits the piece and a named person or organisation takes editorial responsibility, the Act does not require a public “this text is AI-generated” label. Using a model to draft, then publishing without review, on a matter of public interest, does require disclosure.

Article 50(5) requires the information in paragraphs 1 to 4 to be provided in a clear and distinguishable manner at the latest at the time of the first interaction or exposure, and to meet accessibility requirements.

The Commission’s Article 50 guidelines and the transparency Code of Practice give examples of in-scope and out-of-scope cases, including standard editing. Deployers that do not adhere to the Code must demonstrate equivalent labelling for deepfakes and for uncovered public-interest text.

Practical steps:

1. Inventory image, audio, video and public-facing text workflows that use generative tools.
2. Adopt a labelling rule for deepfakes that matches Article 3(60) and Article 50(4). Keep an artistic-work variant that still discloses existence of AI generation without wrecking the work.
3. For public-interest text, either run a documented human editorial process with a responsible person, or disclose AI generation.
4. If emotion recognition or biometric categorisation is used at all, confirm it is not an Article 5 ban, then inform exposed persons at first exposure.
5. Do not treat chatbot disclosure or watermarking as the deployer’s design job. Treat them as provider-selection criteria, and test that the marks survive the organisation’s publishing pipeline.

High-risk use by deployers

Article 26 applies from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems, subject to Article 111 for systems already on the market. The operational list is short and specific.

Use according to instructions. The deployer must take appropriate technical and organisational measures to use the system in accordance with the instructions for use.

Human oversight. Oversight must be assigned to natural persons with the necessary competence, training, authority and support. A rubber-stamp reviewer without the power to stop the system does not meet Article 26(2).

Input data. To the extent the deployer controls input data, those data must be relevant and sufficiently representative in view of the intended purpose.

Monitoring and incident reporting. The deployer must monitor operation on the basis of the instructions and, where relevant, inform the provider under Article 72. If use in accordance with the instructions may present an Article 79(1) risk, the deployer must, without undue delay, inform the provider or distributor and the market surveillance authority, and suspend use. A serious incident must be reported immediately, first to the provider, then to the importer or distributor and the market surveillance authorities. If the provider cannot be reached, Article 73 applies mutatis mutandis.

Logs. Automatically generated logs under the deployer’s control must be kept for a period appropriate to the intended purpose, of at least six months, unless other Union or national law, including data-protection law, provides otherwise.

Workplace information. Before putting a high-risk system into service or using it at the workplace, an employer-deployer must inform workers’ representatives and the affected workers that they will be subject to the system, in accordance with Union and national worker-information rules.

Public registration. Public authorities, Union institutions, bodies, offices and agencies must register under Article 49 before putting into service or using an Annex III high-risk system (other than critical-infrastructure systems in Annex III, point 2). If the system is not in the EU database, they must not use it and must inform the provider or distributor.

DPIA overlap. Where a GDPR (or LED) data-protection impact assessment is required, deployers must use the Article 13 information from the provider to carry it out.

Decisions about people. Deployers of Annex III high-risk systems that make decisions, or assist in making decisions, related to natural persons must inform those persons that they are subject to the use of the system (without prejudice to Article 50). Law-enforcement use follows Directive (EU) 2016/680 Article 13.

Cooperation. Deployers must cooperate with competent authorities on the system.

Financial-sector deployers subject to Union internal-governance rules are deemed to meet the monitoring and log-keeping duties by complying with those sectoral rules.

Practical steps to take before the high-risk application date, if Annex III use is planned:

1. Stop treating “AI in recruitment” or “AI in credit” as a vendor feature. Classify it as a future Article 26 operation.
2. Obtain the provider’s instructions for use, intended purpose, metrics and residual-risk statement, and refuse tools that cannot supply them.
3. Name oversight persons, train them, and write a stop-the-system procedure they can actually use.
4. Define input-data standards (relevance, representativeness, prohibited fields).
5. Decide where logs will be stored and who can export them for six months or longer.
6. Draft the worker-information notice with HR and, where they exist, worker representatives.
7. If the organisation is a public body or provides public services, or deploys credit scoring or life/health insurance pricing systems, plan the Article 27 assessment.
8. Build the Article 86 explanation process into customer and staff decision letters.

Fundamental rights impact assessment

Article 27 is a deployer duty, not a provider duty. It applies, prior to deploying an Article 6(2) high-risk system (except critical-infrastructure systems in Annex III, point 2), to:

• deployers that are bodies governed by public law
• private entities providing public services
• deployers of the Annex III, point 5(b) and (c) systems (creditworthiness / credit score of natural persons, and life and health insurance risk assessment and pricing)

The assessment must describe the processes in which the system will be used; the period and frequency of use; the categories of persons likely to be affected; the specific risks of harm to those persons, taking account of the provider’s Article 13 information; the human-oversight measures; and the measures to be taken if those risks materialise, including internal governance and complaint mechanisms.

It is required for the first use. Similar cases may rely on a previous FRIA or on an impact assessment carried out by the provider. If elements change, the deployer must update the file. After the assessment, the deployer notifies the market surveillance authority using the AI Office template, unless Article 46(1) applies. Overlap with a GDPR DPIA may be handled by cross-reference.

Right to an explanation

Article 86 gives an affected person the right to obtain from the deployer clear and meaningful explanations of the role of the high-risk AI system in the decision-making procedure and the main elements of the decision, where the deployer took a decision on the basis of the output of an Annex III high-risk system (other than critical infrastructure) that produces legal effects or similarly significantly affects the person in a way they consider to have an adverse impact on health, safety or fundamental rights. The right applies only to the extent Union law does not already provide it, and not where Union or national law creates a compliant exception.

This is a deployer-facing right. The provider’s Article 13 instructions have to make that explanation possible. A deployer that cannot explain the role of the system should not be using it to decide on people.

Enforcement and fines

From 2 August 2026 the AI Office and Member State market surveillance authorities share enforcement. The AI Office has exclusive competence over GPAI models (Articles 88 to 94) and, after the Omnibus, a refined exclusive competence over certain AI systems built on GPAI models by the same provider or the same undertaking, with sectoral exceptions. National authorities remain responsible for most deployers and for other systems. The European Data Protection Supervisor supervises Union institutions, bodies, offices and agencies.

Article 99 sets three administrative-fine bands for operators:

Band	Ceiling	Typical trigger
Highest	EUR 35 million or 7% of worldwide annual turnover, whichever is higher	Article 5 prohibitions
Middle	EUR 15 million or 3%, whichever is higher	Provider duties (Art 16), deployer duties (Art 26), Article 50, authorised representatives, importers, distributors, specified Article 25 duties
Lowest	EUR 7.5 million or 1%, whichever is higher	Incorrect, incomplete or misleading information to notified bodies or national competent authorities

For SMEs, including start-ups, each fine is the lower of the percentage and the amount. For SMCs, that “whichever is lower” rule applies to the middle and lowest bands. Member States decide to what extent fines apply to their own public authorities. GPAI providers also face Commission fines under Article 101, which became applicable on 2 August 2026.

Directive (EU) 2019/1937 (whistleblower protection) applies to reporting of infringements of the Act. The Commission operates an AI Act complaints tool and a whistleblower tool.

How the Act sits next to the GDPR

Article 2(7) leaves the GDPR, Regulation (EU) 2018/1725, the ePrivacy Directive and the Law Enforcement Directive in place, without prejudice to the Act’s own bias-detection legal basis in Article 4a and the sandbox rules in Article 59. A high-risk recruitment system that processes personal data needs a GDPR lawful basis, Article 13/14 notices, retention limits and, where Article 35 applies, a DPIA, in addition to AI Act classification and, in time, Article 26.

Article 4a, inserted by the Omnibus, lets providers of high-risk systems, and in defined cases other providers and deployers, process special-category data where that is strictly necessary for bias detection and correction, subject to the listed safeguards. Paragraph 2 does not create a duty to run that processing. It is a legal basis with a padlock, not a mandate.

Article 50(3) expressly sends emotion-recognition and biometric-categorisation deployers back to the GDPR. Article 26(9) sends high-risk deployers to the provider’s Article 13 file when they conduct a DPIA. A FRIA may cross-refer to a DPIA; it does not replace one.

Controller and processor under the GDPR are not the same offices as provider and deployer under the AI Act. A deployer of a high-risk hiring tool will often be the GDPR controller. A cloud provider of a GPAI model will often be a GDPR processor for the prompts, and an AI Act provider for the model. Map both statutes onto the same system rather than assuming one mapping.

For the GDPR itself, see GDPR compliance: the ultimate guide.

Sources

• AI Act, consolidated text (EUR-Lex, 27 July 2026)
• Digital Omnibus on AI, Regulation (EU) 2026/1744
• Commission AI Act hub
• Navigating the AI Act (Commission Q&A)
• Guidelines on prohibited AI practices
• Guidelines for GPAI providers
• Guidelines on Article 50 transparency
• High-risk classification guidelines
• Code of Practice on Transparency of AI-generated Content
• Provider and deployer checklists