Summary
Coverage depends on the statutory AI definition and a territorial connection. A non-EU business can fall within scope when it supplies the EU market or its system's output is used in the EU. Free supply and internal business use can qualify. AI Act, arts. 2(1), 3(1), 3(3)–(4), 3(9)–(11).
Duties attach separately to the model, the finished system, and its deployment. An integrator can become a system provider without becoming the underlying model's provider. Rebranding, substantial modification, or conversion to a high-risk purpose can transfer provider responsibilities. AI Act, arts. 3(3), 3(63), 3(68), 25.
The July 2026 amendment is enacted law. Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027 for Annex III systems and 2 August 2028 for Article 6(1) product systems. These dates do not postpone every AI Act obligation. AI Act, art. 113; Regulation (EU) 2026/1744, arts. 1(40), 4.
Prohibited practices require an immediate design-and-use review under the applicable commencement dates. New prohibitions concerning non-consensual intimate material and specified child sexual abuse material apply from 2 December 2026. Transparency notices cannot legalise a prohibited practice. AI Act, arts. 5, 50(6), 113(a).
Article 50 generally applies from 2 August 2026. Human-facing disclosure and machine-readable marking are separate duties. Providers of synthetic-content systems placed on the market before that date have until 2 December 2026 for Article 50(2) marking. Scope exclusions and the separate legacy high-risk rule still require examination. AI Act, arts. 2, 50, 111(2), 111(4), 113.
High-risk status follows two distinct classification routes. Annex III contains specific uses; Annex I concerns qualifying regulated products. Machinery now sits in Annex I, Section B, where Article 2(2) limits direct AI Act application. A sector label alone cannot determine the applicable obligations. AI Act, arts. 2(2), 6; Annexes I, III.
High-risk providers need documented design controls and the applicable conformity route. Deployers have separate operating duties and, for specified uses, a fundamental rights impact assessment. Human approval does not itself remove high-risk status. AI Act, arts. 6(3), 8–27, 43, 47–49.
General-purpose model duties and exposure to enforcement have their own timetable. Qualifying open-source publication removes only specified duties. A release decision should record the legal role, classification, applicable date, supporting evidence, and unresolved release conditions for each component and use. AI Act, arts. 53–55, 101, 111(3), 113.
The regulated object and EU connection
The first assessment concerns the software's operation. Article 3(1) requires a machine-based system designed to operate with varying autonomy. It must infer, from inputs and for explicit or implicit objectives, how to generate outputs that can influence physical or virtual environments. Adaptiveness after deployment is optional. Predictions, recommendations, decisions, and generated content can qualify. A product name or an AI marketing claim cannot replace this functional assessment. AI Act, art. 3(1).
A fixed administrative workflow does not become an AI system merely because its supplier markets it as intelligent. Conversely, absence of continuous learning does not establish exclusion. The defensible technical record explains the inferential process, autonomy, inputs, objectives, outputs, and downstream effects. That record permits application of every statutory element rather than classification by branding. AI Act, art. 3(1).
The territorial test has several independent routes. Providers fall within scope when placing systems or general-purpose models on the EU market, regardless of establishment. EU-established deployers also fall within scope. Non-EU providers and deployers are covered where system output is used in the EU. The assessment therefore follows actual supply, operation, and output use; server location alone cannot resolve it. AI Act, art. 2(1)(a)–(c).
Commercial supply may be paid or free. Putting a system into service includes first use for the provider's own purposes in the EU. An employer's internally developed decision system can therefore create provider and deployer responsibilities without an external sale. A consumer's personal, non-professional use exemption does not exempt the business supplying that consumer. AI Act, arts. 2(10), 3(3)–(4), 3(9)–(11).
Exclusions require their stated conditions. They include exclusively military, defence, or national-security purposes; systems or models specifically developed and used solely for scientific research; and qualifying pre-market research, testing, or development. Real-world testing remains subject to the Act's specific provisions. A commercial pilot does not obtain a research exemption merely through its name. Article 2(12) also limits the exclusion for qualifying free and open-source systems: high-risk systems and systems covered by Articles 5 or 50 remain subject to the relevant rules. AI Act, art. 2(3), (6), (8), (12).
Responsibility across the supply chain
A provider develops, or commissions development of, a system or general-purpose AI model and places it on the market or puts the system into service under its own name or trademark. A deployer uses a system under its authority. An importer, located or established in the EU, places a system under the name or trademark of a person established in a third country on the EU market; a distributor, other than the provider or importer, makes a system available on the EU market. These definitions permit several roles within one organisation. The contractual description of a business as a customer or reseller does not displace its statutory activities. AI Act, art. 3(3)–(7).
A business integrating an external language model into its own branded recruitment application can be the application provider. The upstream supplier remains subject to any applicable general-purpose model duties. Integration alone does not establish that the integrator developed or placed the underlying model on the market as its provider. Separate records for the model, application, and employment use prevent allocation of every duty to a single supplier. AI Act, art. 3(3), (63), (66), (68); art. 53(1)(b).
Article 25 imposes high-risk provider duties on an operator that rebrands an existing high-risk system, substantially modifies it while it remains high-risk, or changes a system's purpose so it becomes high-risk. Rebranding is expressly subject to the qualification concerning contractual allocation of obligations in Article 25(1)(a). The changed-purpose route can catch repurposed general-purpose systems. An employer that adapts a general assistant into a candidate-ranking service must test the resulting role and intended use. Its original software purchase does not settle that later classification. AI Act, art. 25(1).
The amended cooperation duties require practical access to compliance evidence. Relevant previous providers must cooperate with a replacement provider, subject to the statutory exception where the original provider expressly excluded conversion to high-risk use. High-risk providers and relevant component or model suppliers must specify necessary information, technical access, capabilities, and assistance in writing. The written-agreement duty excludes qualifying publicly available free and open-source tools, services, processes, or components, but not general-purpose models. Contracts should address known limitations, testing access, change notices, and incident cooperation. The agreement allocates performance; it does not eliminate statutory liability. AI Act, art. 25(2), (4), as amended by Regulation (EU) 2026/1744, art. 1(12).
Practices that prevent lawful release or use
The prohibition assessment precedes high-risk preparation. A prohibited intended use cannot be cured by certification, a warning, or human approval. Article 5 prohibits specified practices subject to distinct conditions; it does not prohibit every persuasive interface or every biometric application. The relevant design, behaviour, harm threshold, and exception must be tested separately. AI Act, arts. 5, 50(6).
Subliminal techniques beyond a person's consciousness or purposefully manipulative or deceptive techniques fall within Article 5(1)(a) when they have the objective or effect of materially distorting behaviour by appreciably impairing informed decision-making, thereby causing a decision that would not otherwise have been taken and that causes, or is reasonably likely to cause, significant harm. Exploitation of vulnerability linked to age, disability, or social or economic circumstances has a separate material-distortion and significant-harm test. Ordinary persuasion does not necessarily satisfy these cumulative conditions. AI Act, art. 5(1)(a)–(b).
Social scoring is prohibited where the specified evaluation leads to detrimental treatment in unrelated contexts or unjustified or disproportionate treatment. Criminal-risk prediction based solely on profiling or personality traits is also prohibited. The latter rule permits qualifying support for human assessment based on objective, verifiable facts directly linked to criminal activity. These exceptions cannot justify a score that lacks the required factual basis. AI Act, art. 5(1)(c)–(d).
Article 5 also prohibits untargeted facial-image scraping from the internet or CCTV footage to create or expand facial recognition databases. Emotion inference in workplaces or educational institutions is prohibited except for medical or safety reasons. Emotion recognition has a biometric-data definition, so textual sentiment analysis requires separate classification. AI Act, arts. 3(39), 5(1)(e)–(f).
The biometric-categorisation prohibition concerns individual inference of race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation. It preserves specified labelling or filtering of lawfully acquired biometric datasets and categorisation of biometric data for law enforcement. These exceptions do not dispense with other applicable data protection rules. AI Act, arts. 2(7), 5(1)(g).
Real-time remote biometric identification in publicly accessible spaces for law enforcement has narrow statutory exceptions and authorisation safeguards. The permitted objectives concern specified victim searches, missing-person searches, serious threats, and suspects in qualifying serious offences. Necessity, proportionality, national authorisation, and the prescribed procedural safeguards remain material. One-to-one identity verification requires a separate assessment from remote identification. AI Act, arts. 3(35)–(42), 5(1)(h), (2)–(5); Annex II.
From 2 December 2026, additional prohibitions cover realistic intimate material concerning an identifiable person without the prescribed explicit consent. They also cover material or performances within Article 2(c) and (e) of Directive 2011/93/EU, subject to a “without right” defence under national law. For market supply or putting into service, the system must have that intended purpose, or satisfy a further cumulative test. The system must make that generation or manipulation reasonably foreseeable and reproducible without significant technical modification. It must also lack reasonable and adequate safeguards to reliably prevent the outcome, account for foreseeable misuse, and correct observed or reported misuse. Use is prohibited where the system is used for that purpose. AI Act, art. 5(1)(ba)–(bb), (1a)–(1b); art. 113(a).
The intimate-material rule requires freely given, specific, informed, unambiguous, and explicit consent. It excludes specified manipulation that neither increases exposure of intimate parts nor alters the nature of sexual activities. A general-purpose generator therefore needs an assessment of intended functions and foreseeable reproducible misuse, including the adequacy of safeguards. Mere theoretical capability and deliberate prohibited use are different statutory triggers. AI Act, art. 5(1), first subparagraph, point (ba), and art. 5(1a)–(1b).
High-risk classification by intended use
Annex III classification concerns the task for which the system is intended. Instructions, technical documentation, sales material, and promotional statements help define that purpose. A supplier cannot rely solely on a narrow disclaimer while promoting an incompatible decision-making function. Each intended use must be compared with the actual Annex III entry. AI Act, arts. 3(12), 6(2); Annex III.
The listed areas cover specified biometric uses; safety components for critical infrastructure; educational access and assessment; recruitment and worker management; certain essential services; law enforcement; migration and border control; and justice or democratic processes. Each area contains narrower descriptions. Creditworthiness assessment concerns natural persons and excludes financial-fraud detection. Insurance coverage concerns risk assessment and pricing for life and health insurance. Routine logistics for an election campaign do not themselves constitute the listed voter-influence use. AI Act, Annex III, points 1–8, especially 5(b)–(c), 8(b).
A candidate-ranking tool falls within the recruitment entry when it analyses or evaluates applicants. Human final approval does not erase the influence of the ranking. A scheduling tool that merely arranges interviews requires a different assessment because the recruitment entry does not cover every administrative function. These conditional outcomes follow from the task performed, rather than the employer's industry. AI Act, art. 6(2)–(3); Annex III, point 4(a).
Article 6(3) permits an exception for certain Annex III systems that do not pose significant risks to health, safety, or fundamental rights. The statutory conditions concern narrow procedural tasks, improvement of a previously completed human activity, specified pattern detection, or preparatory tasks. The assessment must address whether the system materially influences decision outcomes and satisfy the relevant condition. Annex III systems that profile natural persons remain high-risk regardless of that exception. This profiling rule does not classify every profiling tool in every sector as high-risk. AI Act, art. 6(3).
The provider must document an Article 6(3) determination before market placement or putting into service. Article 49(2) still requires registration of the provider and system. The 2026 amendment removed two Annex VIII information fields; it did not abolish this registration requirement. An internal statement that a system is low-risk is insufficient for this particular exception. AI Act, arts. 6(4), 49(2); Annex VIII, Section B; Regulation (EU) 2026/1744, art. 1(42).
Regulated products and the machinery distinction
The product route under Article 6(1) requires cumulative conditions. The AI must be a safety component of an Annex I product, or itself be such a product. The product must also require third-party conformity assessment under the listed legislation. Supplying software for use somewhere within a regulated industry does not satisfy this test. AI Act, art. 6(1).
The amended definition distinguishes a safety function from assistance, performance optimisation, service efficiency, convenience, automation, or quality control alone. A component still qualifies where its failure or malfunction endangers health and safety. Third-party assessment concerned solely with non-safety risks does not satisfy Article 6(1)(b). An efficiency feature's failure effects therefore require examination even where the supplier denies a safety purpose. AI Act, arts. 3(14), 6(1a)–(1c).
Section A and Section B of Annex I have different legal consequences. For qualifying Section B product systems, Article 2(2) limits direct application to Article 6(1), Article 60a, and Articles 102–112. Sandbox provisions apply only insofar as sector legislation incorporates the relevant high-risk requirements. The full high-risk provider package cannot simply be copied onto these systems. AI Act, art. 2(2).
The July amendment removed machinery from Section A and added Regulation (EU) 2023/1230 to Section B. It also requires sector-specific delegated acts reflecting relevant AI requirements, with application by 2 August 2028. That change concerns qualifying machinery-related systems. A factory's separate recruitment application does not become a Section B product system merely because its customer operates machinery. Regulation (EU) 2026/1744, arts. 1(41), 3; AI Act, arts. 2(2), 6.
For Section A products, Article 2(13) permits specified limitations where sector rules provide equivalent or greater protection. The Commission must specify affected systems, duties, conditions, and scope through delegated acts. A supplier cannot treat its own assertion of equivalent sector compliance as that legal instrument. The availability and terms of the relevant act must be established before relying on a limitation. AI Act, art. 2(13).
Transparency for interfaces and generated content
Article 50 creates several duties that can apply to one system. Their general application date is 2 August 2026, subject to scope and transitional provisions. A non-high-risk customer-support assistant can still trigger interaction disclosure and synthetic-text marking. Absence from Annex III does not resolve either obligation. AI Act, arts. 2, 50, 111, 113.
Providers must design systems that interact directly with people so those people are informed that they are interacting with AI. The exception concerns interaction that is obvious to a reasonably well-informed, observant, and circumspect person in the circumstances. A disclosure hidden in general terms may fail the requirement for clear information at the first interaction. The law also contains a limited law-enforcement exception. AI Act, art. 50(1), (5).
Providers of systems generating synthetic audio, images, video, or text must make outputs machine-readable as artificial and detectable as generated or manipulated. The technical solution must satisfy the statutory effectiveness and feasibility criteria. Ordinary assistive editing or processing that does not substantially alter the input or its semantics can qualify for an exception. A separate exception applies where use is authorised by law for detecting, preventing, investigating, or prosecuting criminal offences. A visible AI label alone does not establish machine-readable marking or detectability. AI Act, art. 50(2).
Deployers must inform people exposed to emotion recognition or biometric categorisation. Deployers must also disclose deepfakes. Both duties are subject to their respective statutory exceptions for legally permitted or authorised criminal-law uses; Article 50(3) additionally requires appropriate safeguards for third-party rights and freedoms. Evidently artistic, creative, satirical, fictional, or analogous works retain an appropriately adapted disclosure duty. The deepfake definition extends beyond human likenesses to specified objects, places, entities, or events that falsely appear authentic. AI Act, arts. 3(60), 50(3)–(4).
For AI-generated or manipulated text published to inform the public on matters of public interest, deployers must disclose artificial generation or manipulation unless a statutory exception applies. Human review or editorial control, combined with a natural or legal person's editorial responsibility, can remove that text-disclosure duty. This exception does not remove the provider's separate marking duty or the deepfake disclosure rule. Notices must be clear, distinguishable, timely, and accessible. AI Act, art. 50(4)–(6).
The new legacy marking period concerns Article 50(2) alone. It covers providers of synthetic-content systems placed on the market before 2 August 2026 and ends on 2 December 2026. It does not, by itself, extend interaction notices or deployer disclosure deadlines. The separate Article 111(2) rule must be considered where a system qualifies as a legacy high-risk system. AI Act, art. 111(2), (4).
General-purpose models and downstream applications
A general-purpose AI model has sufficient generality and capability to perform a wide range of distinct tasks and integrate into downstream systems. Its provider must maintain technical documentation and furnish required information to downstream providers. The provider must also implement an EU copyright-compliance policy and publish a sufficiently detailed training-content summary using the AI Office template. These duties do not replace the application provider's own system assessment. AI Act, arts. 3(63), 53(1).
The open-source exception is conditional. It requires the qualifying licence and publication of specified parameters, architecture, and usage information. It removes the Article 53(1)(a)–(b) documentation duties for qualifying models without systemic risk. Copyright-policy and public training-summary duties remain. A separate exemption can remove the authorised-representative requirement on comparable conditions; systemic-risk models cannot use these exemptions. AI Act, arts. 53(2), 54(6).
A model is presumptively of high-impact capability where cumulative training computation exceeds 10^25 floating-point operations. The Commission can designate systemic-risk models on other statutory grounds. A provider cannot treat computation below that threshold as conclusive exclusion. Notification is required without delay and within two weeks after the relevant condition is met or becomes known to be forthcoming; a substantiated rebuttal is possible. AI Act, arts. 51–52.
Systemic-risk providers must conduct model evaluations, including documented adversarial testing, assess and reduce EU-level systemic risks, report serious incidents, and protect model and infrastructure cybersecurity. Non-EU providers must appoint an EU authorised representative where Article 54 applies. Codes of practice offer a route to demonstrating compliance; other adequate means remain possible. They do not confer a general certificate covering every downstream product. AI Act, arts. 53(4), 54–56.
Chapter V applies from 2 August 2025. Providers of models placed on the market before that date have until 2 August 2027 under Article 111(3). Article 101's enforcement provision applies from 2 August 2026. The model release date and the application release date must therefore be recorded separately. AI Act, arts. 101, 111(3), 113(b).
The high-risk provider's evidence and release duties
For systems subject to the full high-risk regime, compliance requires operational design controls. Risk management must continue through the lifecycle and cover intended use, reasonably foreseeable misuse, and post-market information. Testing must use metrics and thresholds appropriate to the intended purpose. Identified residual risks require an assessment of acceptability. AI Act, arts. 8–9.
Providers using trained models must address training, validation, and testing data quality, suitability, representativeness, and bias. Technical documentation must demonstrate compliance before market placement or putting into service and remain current. Logging must support traceability. Instructions must explain capabilities, limitations, expected inputs, oversight measures, and relevant performance information. Documentation purchased from a model supplier supplies only part of this system-specific evidence. AI Act, arts. 10–13; Annex IV.
Human oversight must work in the actual use conditions. Appropriate measures must allow oversight personnel to understand limitations, detect anomalies, avoid automation bias, interpret outputs, and disregard, reverse, or stop outputs where required. Providers must also address accuracy, resilience, and cybersecurity over the lifecycle. Merely naming a human reviewer does not demonstrate the controls required by Article 14. AI Act, arts. 14–15.
The provider must operate a documented quality management system, complete the applicable conformity assessment, draw up the EU declaration, affix the required CE marking, and fulfil registration duties. Article 18 documentation must remain available for ten years after market placement or putting into service. Automatically generated logs under the provider's control must generally be kept for at least six months, unless applicable law requires otherwise. Providers established outside the EU must appoint an EU authorised representative before making the system available in the EU. These retention and representation duties require separate evidence. AI Act, arts. 16–19, 22, 43, 47–49.
SME and small mid-cap provisions permit specified simplifications in technical documentation and proportionate quality management. Article 63 offers certain independent SMEs a further simplified route for elements of that system. None creates a blanket exemption from the required level of protection. An enterprise must establish eligibility before using a size-based concession. AI Act, arts. 3(14a)–(14b), 11(1), 17(2), 63(1).
Conformity assessment, CE marking, and registration
A notified body is not mandatory for every high-risk system. Annex III systems within points 2–8 generally follow internal control under Annex VI. For Annex III biometric systems, the availability and complete application of relevant harmonised standards or common specifications determine the permitted route. Where the conditions for internal control are absent, the prescribed notified-body assessment applies. For high-risk systems within Article 75(1e), the AI Office is responsible for the required third-party assessment, and the Commission entrusts its performance to designated notified bodies acting on its behalf. AI Act, arts. 43(1)–(2), 75(1e).
For qualifying Section A product systems, the applicable sector conformity procedure incorporates the AI requirements and quality management assessment. The amended rule also addresses sector procedures that permit reliance on harmonised standards without third-party involvement. If a system qualifies under Section A and Annex III, the sector conformity procedure prevails. A provider could argue that the product route also controls commencement. Article 43(3) expressly resolves the conformity procedure, while Article 113(c) states separate classification-based dates without an express priority rule. Preparation for the earlier date is therefore a risk-control recommendation for dual-classified systems, rather than a definitive resolution of that timing question. AI Act, arts. 43(3), 113(c).
A harmonised standard confers a presumption only for requirements it covers and where its reference has been published in the Official Journal. Generic certification, a supplier's self-description, and membership of a voluntary code are not substitutes for identifying the applicable legal route. Article 42(3) recognises specified Cyber Resilience Act compliance conditions for cybersecurity; it does not establish compliance with unrelated AI duties. AI Act, arts. 40–43, especially 42(3).
EU database registration principally concerns Annex III systems, with special arrangements for specified sensitive uses. Critical-infrastructure systems under Annex III, point 2, use national registration. Public-authority deployers must also register the relevant use where required. Non-high-risk systems require no universal AI Act CE mark or registration merely because they contain AI; Article 49(2)'s documented-exception route remains distinct. AI Act, arts. 48–49, 71.
Deployers, affected people, and operating controls
High-risk deployers must follow instructions, assign competent personnel with adequate authority and support, and monitor operation. Where they control input data, it must be relevant and sufficiently representative for the intended purpose. They must retain controlled logs for the applicable period. Suspected qualifying risk requires notification and suspension; serious incidents trigger the prescribed escalation. These duties cannot be fulfilled solely through the provider's conformity documentation. AI Act, art. 26(1)–(6).
Employers must inform affected workers and their representatives before workplace deployment. Deployers using relevant Annex III systems to make or assist decisions concerning people must inform those people of the use. Article 86 creates a qualified right to explanations about the AI system's role and the main elements of an individual decision with legal or similarly significant effects that the affected person considers to have an adverse impact on their health, safety, or fundamental rights. It excludes the critical-infrastructure category and recognises specified legal restrictions and overlapping EU rights. AI Act, arts. 26(7), (11), 86.
A fundamental rights impact assessment is mandatory for specified deployers before first use of covered Annex III systems. It applies to public-law bodies, private entities providing public services, and deployers of natural-person creditworthiness or life-and-health-insurance risk and pricing systems. The critical-infrastructure category is excluded. The assessment must address affected groups, duration and frequency, risks, oversight, and measures for addressing harm and complaints. Results must be notified as required. AI Act, art. 27(1)–(3).
The amended Article 27 permits reuse of, or references to, relevant parts of a data protection impact assessment. It does not make the two assessments interchangeable. Article 27 concerns fundamental rights more broadly and retains its own actor and use conditions. Changes to the deployment may require an updated assessment. AI Act, art. 27(2), (4)–(5).
Importers and distributors have separate verification and withholding duties. Importers must check the provider's assessment, technical documentation, CE marking, declaration, instructions, and required EU representative. Distributors must perform their specified checks before further supply. Importers with sufficient reason to consider a system non-conforming, and distributors considering or having reason to consider it non-conforming with Section 2 requirements, must withhold it until it is brought into conformity; storage and transport must not compromise compliance. AI Act, arts. 22–24.
AI literacy, personal data, and bias testing
The amended Article 4 retains an affirmative duty on providers and deployers to take measures supporting AI literacy of staff and other persons operating or using AI systems on their behalf. It expressly does not require a guaranteed literacy level for each individual. Measures must reflect those persons' knowledge, experience, training, use conditions, and affected people. Role-specific instruction, escalation exercises, and records of attendance are practical ways to evidence those measures; Article 4 does not prescribe a universal certificate. AI Act, art. 4, as amended by Regulation (EU) 2026/1744, art. 1(5).
Article 4a permits exceptional processing of special-category personal data for strictly necessary bias detection and correction. Conditions include inadequacy of less intrusive data, reuse limitations, security and privacy measures, restricted documented access, confidentiality, and no transfer or access by other parties. Data must be deleted once bias is corrected or the retention period expires, whichever occurs first. Processing records must explain necessity and why other data were insufficient. AI Act, art. 4a(1).
The permission also reaches other system and model providers and deployers where bias detection meets the statutory risk condition. Possible biases must be likely to affect health, safety, or fundamental rights, or lead to discrimination prohibited by EU law. The same safeguards apply. Article 4a(2) creates no independent duty to undertake bias detection. The permission therefore neither authorises general sensitive-data collection nor permits unrestricted sharing with an external testing supplier. Other applicable data protection provisions continue to apply. AI Act, arts. 2(7), 4a(2).
AI Act classification does not establish that personal-data processing is lawful. Article 2(7) preserves the applicable EU rules on personal data, privacy, and confidentiality of communications. The high-risk timetable therefore does not suspend those separate requirements. AI Act, art. 2(7).
Consumer protection, employment protections, accessibility requirements, and sector product law remain relevant. The AI Act preserves the operation of applicable EU consumer and product-safety rules and specified worker protections. A release assessment must therefore distinguish AI Act readiness from permission to process data, make employment decisions, or supply a regulated product. AI Act, art. 2(7)–(9), (11); art. 50(5).
Sandboxes and testing before market release
An AI regulatory sandbox offers supervised development and testing under an agreed plan. Member States must have at least one national sandbox operational by 2 August 2027. Participation does not itself replace conformity assessment or remove authorities' corrective powers. Qualifying participants that observe the plan and conditions and follow official guidance in good faith receive the Article 57(12) protection against administrative fines. Liability for damage to third parties remains. AI Act, art. 57(1), (5), (7), (11)–(12).
Article 60 permits qualifying pre-market real-world testing outside sandboxes for Annex III and Section A product systems. The provider must satisfy the testing-plan, approval, registration, representation, data-transfer, duration, participant-protection, oversight, and reversibility conditions. Consent is required subject to the narrow law-enforcement alternative. The ordinary six-month limit permits one additional six-month period under the prescribed notification procedure. A commercial pilot cannot obtain these protections without satisfying the applicable conditions. AI Act, arts. 60(1)–(5), 61.
For Section B products, Article 60a permits Member States to establish a separate testing route. It requires a national arrangement notified to the Commission, an agreed testing plan, specified safeguards, and compliance with applicable sector provisions. Testing access therefore depends on the relevant Member State's adopted arrangements. Article 60's incident and liability provisions also apply through the cross-reference. AI Act, art. 60a(1)–(6).
Application dates and legacy releases
The AI Act entered into force on 1 August 2024. General provisions and the original prohibitions applied from 2 February 2025. General-purpose model duties, institutional provisions, and specified penalty provisions applied from 2 August 2025. Regulation (EU) 2026/1744 entered into force on 27 July 2026, before the general application date of 2 August 2026. The amended text, rather than the original future-date list, governs release planning. AI Act, art. 113; Regulation (EU) 2026/1744, art. 4.
The next distinct product-facing dates are 2 December 2026 for the new Article 5 prohibitions and legacy Article 50(2) marking; 2 August 2027 for pre-August-2025 general-purpose models; 2 December 2027 for the specified Annex III Chapter III provisions; and 2 August 2028 for the corresponding Annex I product provisions. Article 113(c) identifies Chapter III, Sections 1–3, with an exception for Article 6(5). Other provisions must be read with their own triggers and transitional rules rather than assigned one universal high-risk date. AI Act, arts. 111(3)–(4), 113(a)–(c).
Under amended Article 111(2), qualifying high-risk systems placed on the market or put into service before the relevant Chapter III date are generally brought within the Regulation only upon significant design changes from that date. Article 5 is expressly preserved. Providers and deployers of systems intended for public authorities must in any event comply by 2 August 2030. Specified Annex X large-scale IT systems have a separate transition ending on 31 December 2030. AI Act, art. 111(1)–(2).
Recital 39 of the 2026 amendment explains the legacy rule by reference to the first unit of a type and model. Later unchanged units can retain the transition where its conditions hold. Release evidence should therefore establish the actual first lawful EU placement or service date, system identity, and subsequent design history. A model's release date alone cannot establish the legacy status of a different downstream system. Regulation (EU) 2026/1744, recital 39; AI Act, arts. 3(9), (11), 111(2).
Legacy protection is not an unconditional exemption for every future version. Article 111(2)'s significant-design-change trigger must be assessed separately from Article 3(23)'s substantial-modification definition. Under Article 43(4), substantial modification of a regulated high-risk system requires a new conformity assessment. Predetermined learning-related changes documented in the initial assessment have a specific exception. Version-control records should preserve the basis for each of these distinct determinations. AI Act, arts. 3(23), 43(4), 111(2).
Monitoring, incidents, and enforcement exposure
High-risk providers must maintain post-market monitoring capable of testing continued compliance over the system's lifetime. The monitoring plan belongs in the technical documentation. The amended deadline for Commission guidance and a template is 2 September 2027; that guidance obligation does not replace the provider's own statutory duties when applicable. AI Act, art. 72.
Article 73 requires serious-incident reporting immediately after the relevant causal link or reasonable likelihood is established, subject to a fifteen-day outer limit from the provider's or, where applicable, the deployer's awareness. Specified widespread infringements or serious critical-infrastructure incidents require immediate reporting, with a two-day outer limit. Death-related incidents have a ten-day outer limit and the specified immediate-report trigger. The same awareness trigger governs the two- and ten-day outer limits. An initial incomplete report may be followed by a complete report. Sector exceptions can restrict the incidents reportable under this article. AI Act, art. 73(1)–(10).
The AI Office has exclusive competence over specified same-undertaking model-and-system providers and designated very large platform or search-engine systems. Article 75 excludes specified product, infrastructure, public-authority, financial, and justice cases from the first category. Ordinary third-party deployers do not enter its exclusive competence solely because they use such a provider's system. National and sector authorities retain their relevant functions. High-risk incidents within Article 75(1) competence are reported to the AI Office. AI Act, arts. 74–75, especially 75(1), (1a).
Article 99 provides maximum administrative fines of EUR 35 million or 7% of preceding-year worldwide turnover for prohibited practices; EUR 15 million or 3% for specified other infringements; and EUR 7.5 million or 1% for specified incorrect, incomplete, or misleading information. For undertakings, the higher ceiling ordinarily applies. SMEs receive the lower ceiling under Article 99(6). Small mid-cap enterprises receive that lower-ceiling treatment for paragraphs 4 and 5, but not the Article 5 prohibition tier. Actual penalties depend on the statutory factors and applicable procedures. AI Act, art. 99(3)–(7).
General-purpose model providers face the separate Article 101 ceiling of 3% of preceding-year worldwide turnover or EUR 15 million, whichever is higher, for the specified intentional or negligent conduct. The AI Office's system-enforcement powers under Article 75c also extend the Article 99(4) band to applicable provisions outside that paragraph's list. A blanket assertion that an unlisted obligation carries no possible penalty is therefore unsafe, including for literacy duties within that competence. Member States also prescribe penalties under amended Article 99(1). AI Act, arts. 75c(4), 99(1), 101(1).
Authorities can require corrective action, restrict supply, or order withdrawal or recall. Formal defects can themselves prevent continued supply. Any natural or legal person with grounds to allege infringement can complain under Article 85. Operators retain applicable rights of defence and judicial review; Article 75c(6) and Article 101(5) provide review of the respective EU-level fines. A commercial release decision must account for interruption and remediation exposure as well as monetary ceilings. AI Act, arts. 75c(6), 79–85, 99(10), 101(2)–(5).
