EU AI Act

Arts 102 to 110 amend nine other Union instruments so that AI systems that are safety components fall within their existing regimes: Regulation (EC) No 300/2008, Regulation (EU) No 167/2013, Regulation (EU) No 168/2013, Directive 2014/90/EU, Directive (EU) 2016/797, Regulation (EU) 2018/858, Regulation (EU) 2018/1139, Regulation (EU) 2019/2144 and Directive (EU) 2020/1828. They create no free-standing duty under this Regulation; any resulting obligation arises under the amended instrument.

• None. Typed out of the requirement denominator on 2026-08-20.

• None. See typed_out_reason on this node.

Art.111 sets transitional rules for AI systems already placed on the market or put into service and for general-purpose AI models already placed on the market, including the treatment of large-scale IT systems listed in Annex X. Art.112 requires the Commission to evaluate and review the Regulation on a stated schedule. Art.113 sets entry into force and the staged application dates: the prohibitions and the AI literacy duty from 2 February 2025, the general-purpose AI model provisions and governance from 2 August 2025, most high-risk obligations from 2 August 2026, and Art.6(1) with its corresponding obligations from 2 August 2027.

• Roadmap aligned with the Art.113 staged-application milestones
• Transition plan for pre-existing systems and GPAI models

• No staged-application roadmap

Art.95 provides for voluntary codes of conduct encouraging the voluntary application to non-high-risk AI systems of some or all of the Chapter III Section 2 requirements, and of further voluntary commitments on matters such as environmental sustainability, AI literacy, inclusive design and adverse impact on vulnerable persons. Art.96 requires the Commission to develop guidelines on the practical implementation of the Regulation. Neither creates an obligation.

• Tracking of Commission guidelines applicable to the activity

• Decisions taken without reference to applicable Commission guidelines

Art.97 sets the conditions under which the Commission exercises the power to adopt delegated acts, including its duration, revocation by the European Parliament or the Council, expert consultation, and the objection period. Art.98 establishes the committee assisting the Commission and applies Regulation (EU) No 182/2011 to the implementing acts made under this Regulation. Neither article addresses a provider, deployer, importer, distributor or authorised representative.

• None. Typed out of the requirement denominator on 2026-08-20.

• None. See typed_out_reason on this node.

Art.99 requires Member States to lay down the rules on penalties and other enforcement measures and sets the ceilings for administrative fines: up to EUR 35 million or 7 per cent of total worldwide annual turnover for infringement of the Art.5 prohibitions, up to EUR 15 million or 3 per cent for most other infringements, and up to EUR 7.5 million or 1 per cent for supplying incorrect, incomplete or misleading information. Art.100 sets administrative fines the European Data Protection Supervisor may impose on Union institutions, bodies, offices and agencies. Art.101 sets the fines the Commission may impose on providers of general-purpose AI models.

• Awareness of fine bands by infringement category
• Internal-violation handling proportionate to risk

• Underestimating Art.5 fine exposure (highest band)

Art.1 sets the subject matter of the Regulation. Art.2 sets its territorial and material scope, reaching providers placing AI systems on the Union market wherever they are established, providers and deployers in third countries where the output is used in the Union, deployers established in the Union, and importers and distributors. Art.3 defines AI system, provider, deployer, general-purpose AI model, systemic risk, fundamental rights impact assessment and the other terms the Regulation uses. None of the three imposes a duty on a regulated party; they establish what the Regulation covers and what its words mean. The AI literacy duty in Art.4, previously bundled here, is now carried as its own control at EUAI-Art.4.

• Documented scope assessment per AI system
• AI literacy programme records

• Treating non-EU operations as out-of-scope where output is used in the Union
• No AI literacy programme

Providers and deployers of AI systems must take measures to ensure, to their best extent, a sufficient level of AI literacy among their own staff and any other persons who deal with the operation and use of AI systems on their behalf. The measures must be calibrated to those persons' technical knowledge, experience, education and training, to the context in which the AI systems are to be used, and to the persons or groups of persons on whom the systems are to be used. The duty attaches to every AI system regardless of its risk class.

• A register of the staff and contracted persons who operate or use AI systems on the organisation's behalf
• Training content differentiated by role, prior technical knowledge and the deployment context
• Attendance, completion and comprehension records per cohort
• Evidence the literacy measures were revisited when a new AI system or a materially different use case was introduced
• Material addressing the groups the system is used on, where that shapes the risks staff must be able to recognise

• One generic awareness module issued to everyone regardless of role or technical starting point
• Training that covers the internal AI policy but not the capabilities and limits of the systems actually in use
• Contractors and outsourced operators excluded even though they operate the system on the organisation's behalf
• No refresh when the system or its use case changes, so literacy reflects a version no longer running

Prohibits a defined set of AI practices, including subliminal/manipulative techniques causing significant harm, exploitation of vulnerabilities, social scoring by public authorities, predictive policing based solely on profiling, untargeted scraping of facial images, emotion recognition in workplace/education, biometric categorisation inferring sensitive attributes, and real-time remote biometric identification (RBI) in publicly accessible spaces by law enforcement (subject to narrow exceptions).

• Pre-deployment screening against the Art.5 prohibition list
• Documented assessment that the system does not fall under a prohibited category

• Deploying an Art.5-prohibited practice
• Treating exceptions as routine basis

A provider of a general-purpose AI model must determine, and keep current, whether the model is a model with systemic risk. It is, where it has high impact capabilities evaluated on the basis of appropriate technical tools and methodologies including indicators and benchmarks, or where the Commission so decides on the criteria in Annex XIII. Cumulative computation used for training greater than 10^25 floating point operations creates a presumption of high impact capabilities. The thresholds, benchmarks and indicators may be amended by delegated act, so the assessment must be made and maintained against the criteria in force.

• A per model capability assessment naming the technical tools, indicators and benchmarks used
• The cumulative training compute calculation, with its method and inputs recorded
• The classification conclusion and its date, stating the version of the criteria it was made against
• A re-assessment trigger for further training runs, for fine tuning that adds compute, and for amendment of the thresholds by delegated act
• Where the Commission has designated the model, the designation and any reassessment request made under Art.52(5)

• Compute counted for the final pre-training run only, when the test is cumulative
• Assessment reduced to the floating point operations presumption, with no evaluation of high impact capabilities on other indicators
• Classification made once and never revisited as the model is further trained
• The delegated act route to amended thresholds not monitored, so the assessment stands against superseded criteria

Section header for Chapter V Section 1. Both articles it formerly bundled are now controls in their own right: EUAI-Art.51, the provider's duty to determine and keep current whether the model has systemic risk, and EUAI-Art.52, the duty to notify the Commission within two weeks and the procedure that follows.

• FLOPs assessment and notification to the Commission where the threshold is crossed
• Tracking of additions to the systemic-risk GPAI list

• Not notifying the Commission on crossing the FLOPs threshold

Where a general-purpose AI model meets the high impact capability condition in Art.51(1)(a), its provider must notify the Commission without delay and in any event within two weeks after that requirement is met or it becomes known that it will be met, including the information necessary to demonstrate that the requirement has been met. With the notification the provider may present sufficiently substantiated arguments that the model exceptionally does not present systemic risks because of its specific characteristics. A provider whose model the Commission has designated as presenting systemic risk may make a reasoned request for reassessment containing objective, detailed and new reasons arisen since the designation, at the earliest six months after the designation decision or after a decision maintaining it.

• The notification to the Commission, with its date measured against the two week deadline
• The supporting information demonstrating the Art.51(1)(a) condition is met
• Where relied on, the substantiated argument that the model does not present systemic risks, with the evidence behind it
• A monitoring process that detects the moment the condition is met or becomes known that it will be met, so the clock is not started late
• Records of any reassessment request, the new reasons relied on, and the six month eligibility calculation

• The two week clock read as running from public release rather than from the point the condition became known to be met
• Notification made with an assertion rather than the information that demonstrates the requirement is met
• No internal trigger linking a training run's cumulative compute total to the notification duty
• A reassessment request built on the original arguments rather than on new reasons arisen since the designation

Providers of general-purpose AI models must draw up and keep up to date the technical documentation of the model, including its training and testing process and the results of its evaluation, containing at least the Annex XI information, for provision on request to the AI Office and the national competent authorities; draw up, keep up to date and make available to providers who intend to integrate the model information and documentation containing at least the Annex XII elements and sufficient to let them understand the model's capabilities and limitations and meet their own obligations; put in place a policy to comply with Union law on copyright and related rights, including identifying and complying, through state of the art technologies, with a reservation of rights expressed under Art.4(3) of Directive (EU) 2019/790; and draw up and make publicly available a sufficiently detailed sum

• Model technical documentation checked against every Annex XI element, with training, testing and evaluation results included
• The downstream integrator pack checked against Annex XII, with evidence it is actually supplied to integrators
• The copyright compliance policy, naming the technologies used to identify and honour text and data mining reservations of rights
• The published training content summary following the AI Office template, with its publication location and date
• Where the open source exemption is claimed, evidence the licence and the published parameters, architecture and usage information meet the Art.53(2) conditions
• Where neither an approved code of practice nor a harmonised standard is followed, the documented alternative adequate means of compliance

• A training content summary published at a level of generality that is not sufficiently detailed against the template
• A copyright policy that states intent but names no technology for identifying reservations of rights
• The open source exemption claimed for a model with systemic risk, where it does not apply
• Downstream documentation limited to an interface reference, omitting the capability and limitation information integrators need to meet their own duties

Section header for Chapter V Section 2. Both articles it formerly bundled are now controls in their own right: EUAI-Art.53, the documentation, downstream information, copyright policy and training content summary duties, and EUAI-Art.54, the duty on third-country providers to appoint an authorised representative in the Union.

• GPAI technical documentation per Annex XI
• Public training-data summary per Annex XII
• Copyright-compliance policy

• No public training-data summary
• No copyright-compliance policy

A provider of a general-purpose AI model established in a third country must, before placing the model on the Union market, appoint by written mandate an authorised representative established in the Union, and must enable it to perform the mandated tasks. The mandate must empower the representative to verify that the Annex XI technical documentation has been drawn up and that the Art.53 and, where applicable, Art.55 obligations have been fulfilled; to keep a copy of that documentation and the provider's contact details at the disposal of the AI Office and the national competent authorities for ten years after the model was placed on the market; to provide information and documentation on reasoned request; and to cooperate with the AI Office and competent authorities on any action they take in relation to the model, including where it is integrated into AI systems placed on the Union mark

• The written mandate, showing it confers each of the Art.54(3) tasks
• Evidence the appointment predates the model being placed on the Union market
• The Annex XI documentation copy and the provider contact details held by the representative, with the ten year retention set
• Evidence the provider enables the representative, for example by giving it the access it needs to verify the documentation
• Where the open source exemption is claimed, the assessment showing the model does not present systemic risk

• No appointment at all, on the assumption that a model offered through a programmatic interface is not placed on the Union market
• A mandate that omits the verification task in point (a), leaving the representative unable to perform it
• The open source exemption claimed without checking the systemic risk carve-out that removes it
• The ten year retention clock never started, because the placing on the market date was not recorded

Providers of GPAI models with systemic risk shall additionally: perform model evaluation incl adversarial testing; assess and mitigate possible systemic risks; track, document and report to the AI Office and competent authorities serious incidents and possible corrective measures; and ensure an adequate level of cybersecurity protection for the model and its infrastructure.

• Model-evaluation reports (incl adversarial)
• Systemic-risk assessment and mitigation
• Serious-incident reporting records
• GPAI cybersecurity controls

• No adversarial testing for systemic-risk GPAI
• No serious-incident reporting

Art.56 requires the AI Office and the Board to encourage and facilitate the drawing up of codes of practice at Union level covering the Art.53 and Art.55 obligations, sets what those codes should aim to cover and how their adequacy is assessed, and allows the Commission to approve a code by implementing act and give it general validity. A provider may rely on an approved code to demonstrate compliance until a harmonised standard is published, but is not required to. The duty that bites on a provider, to demonstrate alternative adequate means of compliance where it neither adheres to an approved code nor complies with a harmonised standard, sits in Art.53(4) and is counted at EUAI-Art.53.

• GPAI code-of-practice signatory status (if any) and compliance evidence

• GPAI obligations claimed via a non-approved code

Art.64 establishes the AI Office within the Commission and provides for its expertise and capabilities. Art.65 establishes the European Artificial Intelligence Board, composed of one representative per Member State with the European Data Protection Supervisor as observer, and sets its structure and rules of procedure. Art.66 sets the Board's tasks, including advising on implementation, coordinating national competent authorities, contributing to guidance and harmonised standards and supporting cross-border cooperation. All three address Union and Member State institutions.

• Awareness of AI Office and Board guidance applicable to the activity

• Ignoring AI Office guidance and Board opinions on classification/interpretation

Art.67 establishes an advisory forum of stakeholders to advise the Board and the Commission. Art.68 establishes a scientific panel of independent experts to support enforcement, in particular on general-purpose AI models. Art.69 gives Member States access to the pool of experts. Art.70 requires each Member State to designate its national competent authorities, including at least one notifying authority and at least one market surveillance authority, and a single point of contact, and to ensure they have adequate resources. All four address Union institutions and Member States.

• Awareness of national competent authority and single point of contact

• Engaging only EU institutions where the national CA is the competent one

The Commission, in collaboration with the Member States, shall set up and maintain an EU database for high-risk AI systems listed in Annex III; providers (and where applicable deployers from the public sector) shall register the systems and provide the information set out in Annex VIII.

• EU-database registration entries per high-risk AI system
• Annex VIII information completeness

• Operating an Annex III system without registration

High-risk AI systems that make use of techniques involving the training of AI models shall use training, validation and testing data that meet the quality criteria in Art.10(2)-(5): appropriate data governance, examination for possible biases, identification of data gaps/shortcomings, statistically relevant datasets to the intended purpose, and considerations specific to the geographical, contextual, behavioural or functional setting of intended use.

• Data governance procedures
• Bias examination records and remediation
• Data-quality assessment per dataset

• Training data used without bias examination
• Datasets not representative of the deployment context

Technical documentation for a high-risk AI system shall be drawn up before the system is placed on the market or put into service and kept up to date. It shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the Section 2 requirements (incl Annex IV minimum content).

• Annex IV-compliant technical documentation per high-risk system
• Document version control and update on material change

• Out-of-date technical documentation
• Missing Annex IV elements

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system, ensuring a level of traceability appropriate to the intended purpose; logging capabilities for biometric remote-identification AI systems include the period of each use, the reference database against which input data has been checked, the input data for which the search led to a match, and the natural persons involved in the verification.

• Logging capability design evidence
• Log-retention policy aligned with the intended purpose

• Insufficient logging to reconstruct system operation
• Logs not retained over the system lifetime

High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the output and use it appropriately. Providers shall provide instructions for use including the system's intended purpose, level of accuracy/robustness/cybersecurity, foreseeable misuse, performance characteristics, human oversight measures, hardware/software requirements, lifetime and maintenance/care.

• Instructions for use covering the Art.13 content list
• Deployer-facing system documentation

• Generic IFU without the Art.13 content elements

High-risk AI systems shall be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which they are in use. Oversight measures shall enable persons to understand the relevant capacities and limitations and monitor operation, remain aware of automation bias, correctly interpret the output, decide not to use the output or override or reverse it, intervene in operation, and stop the system.

• Human-oversight design (UI, controls, alerts)
• Oversight-personnel training and authority

• Oversight is nominal (e.g. cannot stop the system in practice)
• No training for oversight personnel

High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and shall perform consistently in those respects throughout their lifecycle. Resilience to errors, faults and inconsistencies; protection against attempts by unauthorised third parties to alter use, output or performance (incl data poisoning, model poisoning, adversarial examples and confidentiality attacks).

• Accuracy/robustness measurements relevant to the intended purpose
• Adversarial/data-poisoning threat modelling and mitigation
• Cybersecurity controls aligned with state-of-the-art

• No adversarial-attack threat modelling
• Accuracy claims not supported by test evidence

Determine and record, for each AI system, whether it is high-risk. A system is high-risk where it is intended to be used as a safety component of, or is itself, a product covered by the Union harmonisation legislation listed in Annex I and that product must undergo third-party conformity assessment, or where it falls within an Annex III use case. Where the provider concludes that an Annex III system is not high-risk because it performs only a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing or influencing human assessment, or performs a preparatory task, that assessment must be documented before the system is placed on the market or put into service and produced to authorities on request. A system that performs profiling of natural persons is always high-risk and the derogation is not available to it.

• A classification record per AI system naming the Annex I legislation or the Annex III use case considered, and the conclusion reached
• The documented Art.6(3) assessment where an Annex III system is judged not high-risk, dated before placing on the market
• Evidence the profiling rule was applied, so any system profiling natural persons is classified high-risk regardless of the derogation
• A trigger that re-runs classification when Annex III is amended or the intended purpose changes
• Registration of the not-high-risk conclusion in the EU database as required by Art.49(2)

• Classification decided once at design time and never revisited when the intended purpose broadened
• The Art.6(3) derogation relied on without the documented assessment that is the condition of using it
• A profiling system routed through the derogation, which the Regulation forecloses
• Only Annex III considered, so a safety component falling under Annex I legislation is missed

Art.7 empowers the Commission to adopt delegated acts adding, modifying or removing use cases in Annex III, subject to the conditions and criteria it sets, and to remove a use case where the system no longer poses a significant risk to health, safety or fundamental rights. It addresses the Commission alone. The classification duty in Art.6, previously bundled here, is now carried as its own control at EUAI-Art.6.

• Documented Annex I / Annex III classification per AI system
• Re-classification review on Annex III updates

• Mis-classifying high-risk AI as non-high-risk

Providers of high-risk AI systems shall ensure compliance with the Section 2 requirements (Arts 9-15), taking into account the intended purpose, the generally acknowledged state of the art and the integration of the AI system into other systems.

• Compliance evidence package per high-risk system covering Arts 9-15

• No documented compliance with one or more of the Art.9-15 requirements

Providers shall establish, implement, document and maintain a risk management system as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, including identification and analysis of known and reasonably foreseeable risks, estimation/evaluation of risks arising from use and from misuse, and adoption of appropriate targeted risk-management measures.

• Risk management system documentation
• Lifecycle risk analysis records
• Post-deployment risk monitoring

• Risk register treated as one-off rather than continuous
• No misuse-scenario analysis

Providers must discharge the full set of provider duties for each high-risk AI system: ensure it meets the Chapter III Section 2 requirements; indicate their name, registered trade name or registered trade mark and a contact address on the system or, where that is not possible, on its packaging or accompanying documentation; hold a quality management system complying with Art.17; keep the Art.18 documentation; keep the automatically generated logs under Art.19 where they are under their control; put the system through the Art.43 conformity assessment before it is placed on the market or put into service; draw up the Art.47 EU declaration of conformity; affix the CE marking under Art.48; comply with the Art.49(1) registration duty; take corrective action and provide information under Art.20; demonstrate conformity to a national competent authority on reasoned request; and ensure the syste

• A per-system compliance file showing each of the Art.16 points (a) to (l) discharged, with a named owner
• The identification marking showing name, registered trade name or trade mark and contact address, as affixed
• Evidence the conformity assessment completed before the recorded placing-on-market date rather than after
• An accessibility conformance record against Directives (EU) 2016/2102 and (EU) 2019/882
• Records of conformity demonstrations made to national competent authorities on reasoned request

• Point (l) accessibility treated as out of scope, which is the most commonly omitted limb of Art.16
• Identification present in the manual but not on the system, its packaging or its accompanying documentation
• The compliance file assembled after launch, so the sequencing Art.16(f) requires cannot be evidenced
• Provider status not recognised where a deployer rebranded or substantially modified a system and became the provider under Art.25

Section header for Chapter III Section 3 as it applies to providers and their authorised representatives. Each of the seven articles it formerly bundled is now a control in its own right: EUAI-Art.16 provider obligations, EUAI-Art.17 quality management system, EUAI-Art.18 documentation keeping, EUAI-Art.19 automatically generated logs, EUAI-Art.20 corrective actions and duty of information, EUAI-Art.21 cooperation with competent authorities, and EUAI-Art.22 authorised representatives.

• QMS documentation per Art.17
• 10-year documentation retention
• Authorised representative appointment for non-EU providers

• No QMS
• Documentation retention below 10 years
• Non-EU provider without authorised representative

Providers must put in place a quality management system that ensures compliance with the Regulation, documented systematically in written policies, procedures and instructions, covering at least: a regulatory compliance strategy including conformity assessment and management of modifications; design, design control and design verification techniques; development, quality control and quality assurance techniques; examination, test and validation procedures before, during and after development and the frequency at which they run; technical specifications and standards to be applied and, where harmonised standards are not applied in full, the means used instead; data management systems and procedures spanning acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention; the Art.9 risk management system; the Art.72 post-market monitoring system; Art.73

• The written quality management system covering all thirteen Art.17(1) aspects, with a cross-reference showing where each is addressed
• The accountability framework naming responsibilities of management and staff for each aspect
• Change management records for modifications to the high-risk AI system
• Test and validation procedures with their defined frequency, and completed records against them
• Where harmonised standards are not applied in full, the documented alternative means of meeting the Section 2 requirements
• For financial institutions, the mapping of which internal governance arrangements are relied on under Art.17(4), with evidence that points (g), (h) and (i) are still discharged separately

• An existing quality system adopted wholesale without checking it covers the AI-specific aspects (g), (h) and (i)
• The accountability framework named in policy but never allocated to identified roles
• Data management procedures documented for training data only, omitting acquisition, labelling, retention and deletion
• Proportionality read as permission to omit aspects rather than to scale the depth at which each is addressed

Providers must keep at the disposal of the national competent authorities, for ten years from the date the high-risk AI system was placed on the market or put into service, the Art.11 technical documentation, the documentation concerning the Art.17 quality management system, documentation of changes approved by notified bodies, the decisions and other documents issued by notified bodies, and the Art.47 EU declaration of conformity. Providers that are financial institutions maintain the technical documentation within the documentation kept under Union financial services law.

• A retention schedule setting ten years from placing on the market or putting into service for each of the five Art.18(1) document classes
• A recorded placing-on-market date per system, so the retention clock has a defensible start
• Notified body correspondence, approvals of changes and decisions held alongside the technical file
• Evidence the documentation stays retrievable and readable for the whole period, including across platform or format migration
• An arrangement addressing continued availability to authorities if the provider or its authorised representative ceases activity

• Retention measured from the last update rather than from placing on the market or putting into service
• Technical documentation retained while quality management documentation and notified body decisions are discarded
• Documents kept in a format or system that cannot be read out ten years later
• No retention arrangement for a system withdrawn from the market, where the ten years still runs

Providers must keep the logs referred to in Art.12(1) that their high-risk AI systems generate automatically, to the extent those logs are under their control. The logs must be kept for a period appropriate to the intended purpose of the system and in any event for at least six months, unless Union or national law provides otherwise, in particular Union law on the protection of personal data. Providers that are financial institutions maintain them within the documentation kept under Union financial services law.

• A documented log retention period per system, with the reasoning that ties it to the intended purpose
• Evidence the retained period is at least six months, or the Union or national law that displaces it
• A record of which logs are under the provider's control and which sit with the deployer, so the boundary is explicit
• Integrity controls showing retained logs have not been altered
• The data protection assessment reconciling log retention with storage limitation

• Six months treated as the target rather than the floor, where the intended purpose calls for longer
• Logs discarded on the deployer side while the provider assumed they were being retained
• Retention set by a default platform configuration rather than by a documented decision
• No reconciliation between the retention duty and a data protection deletion policy, so one silently overrides the other

A provider that considers, or has reason to consider, that a high-risk AI system it has placed on the market or put into service is not in conformity with the Regulation must immediately take the necessary corrective action to bring it into conformity, withdraw it, disable it or recall it as appropriate, and must inform the distributors of that system and, where applicable, the deployers, the authorised representative and the importers. Where the system presents a risk within the meaning of Art.79(1) and the provider becomes aware of it, the provider must immediately investigate the causes, in collaboration with the reporting deployer where applicable, and inform the competent market surveillance authorities and, where a certificate was issued for the system, the notified body concerned, of the nature of the non-compliance and of any corrective action taken.

• A non-conformity procedure naming the bring-into-conformity, withdraw, disable and recall options and who decides between them
• Non-conformity records showing the date the provider first had reason to consider the system non-conforming and the date action followed
• Notification records to distributors, deployers, the authorised representative and importers
• Root cause investigation records for risk cases, showing collaboration with the reporting deployer
• Notifications to the market surveillance authority and to the certifying notified body, stating the nature of the non-compliance

• The duty read as triggering on confirmed non-conformity rather than on having reason to consider it
• Corrective action taken while the downstream chain, in particular distributors and importers, is never informed
• No contact register for deployers, so the notification duty cannot physically be discharged
• The notified body that issued the certificate left out of the notification

On a reasoned request by a competent authority, providers must supply that authority with all the information and documentation necessary to demonstrate the conformity of the high-risk AI system with the Chapter III Section 2 requirements, in a language easily understood by the authority from among the official languages of the institutions of the Union as indicated by the Member State concerned. On a reasoned request they must also give the requesting authority access to the automatically generated logs referred to in Art.12(1), to the extent those logs are under their control. Information obtained by the authority is subject to the Art.78 confidentiality obligations.

• A named point of contact and a documented response process for reasoned authority requests
• The conformity documentation set held in, or demonstrably translatable into, the official Union languages indicated by the relevant Member States
• A register of requests received, what was provided and the response time
• A rehearsed ability to extract and hand over the Art.12(1) logs for a named system and period
• The language indication obtained from each relevant Member State, so translation is decided rather than guessed

• Documentation held only in English where the Member State has indicated a different official language
• Log extraction technically possible but never rehearsed, so a request cannot be answered inside the time allowed
• Requests handled ad hoc by whoever receives them, with no record of what was disclosed
• Art.78 confidentiality never addressed, so trade secrets are either over-disclosed or wrongly withheld

A provider established in a third country must, before making its high-risk AI system available on the Union market, appoint by written mandate an authorised representative established in the Union, and must enable that representative to perform the tasks in the mandate. The mandate must empower the representative to verify that the Art.47 EU declaration of conformity and the Art.11 technical documentation have been drawn up and that an appropriate conformity assessment has been carried out; to keep the provider's contact details, a copy of the declaration, the technical documentation and any notified body certificate at the disposal of competent authorities for ten years after the system was placed on the market or put into service; to provide information, documentation and log access on reasoned request; to cooperate with competent authorities on any action relating to the system; and

• The written mandate, showing it confers each of the Art.22(3) tasks
• Evidence the appointment predates the system being made available on the Union market
• The document set held by the representative: provider contact details, EU declaration of conformity, technical documentation and any notified body certificate
• Evidence the provider enables the representative, for example by giving it access to the technical file and to the logs it may have to produce
• A documented mandate termination route and the notification path to the market surveillance authority

• A distributor or local subsidiary treated as the authorised representative without a written mandate
• A mandate that appoints a representative but does not confer the specific Art.22(3) tasks
• The representative holding a contract but not the documentation it is required to keep available
• Appointment made after the first sale into the Union rather than before

Importers of high-risk AI systems shall verify that the conformity assessment has been carried out, that the technical documentation is in place, that the CE marking and EU declaration of conformity are present, that an authorised representative has been appointed where required, and shall keep records and cooperate with authorities; importers shall not place a non-compliant system on the market.

• Importer verification checklist and records per system
• Cooperation evidence with authorities

• Placing a non-compliant high-risk AI system on the market

Distributors shall verify that high-risk AI systems bear the required CE marking and are accompanied by the EU declaration of conformity and instructions for use, and that storage/transport conditions do not jeopardise compliance; distributors shall not make available a system they have reason to believe is not in conformity.

• Distributor verification records
• Storage/transport conformity preservation

• Distributing a high-risk AI system without checking CE marking/IFU

Distributors/importers/deployers/other third parties become providers when they place on the market or put into service under their own name or trademark, substantially modify the system, or modify the intended purpose making it high-risk. The original provider shall cooperate with the new provider, providing access to information, technical access and other assistance reasonably needed.

• Documented allocation of provider status across the value chain
• Cooperation agreements between original and new providers

• Substantial modification without taking on provider obligations

Deployers shall use high-risk AI systems in accordance with the IFU; assign human oversight to appropriately competent natural persons; ensure input data is relevant and sufficiently representative; monitor operation and inform the provider of risks/incidents; retain automatically generated logs for at least 6 months (longer where required); inform workers/representatives where used in the workplace; carry out a DPIA where required under GDPR; and where a deployer is a public authority, register the system in the EU database.

• Deployer monitoring records
• Logs retained at least 6 months
• DPIA where applicable
• Workforce information for workplace deployment

• Deployer not following IFU
• No human-oversight assignment
• Logs deleted before 6 months

Before deploying a high-risk AI system referred to in Art.6(2) (Annex III), public-law-governed deployers (and certain private deployers providing public services + financial services) shall perform a fundamental rights impact assessment (FRIA) describing the deployment context, the categories of affected persons, the specific risks of harm to fundamental rights, the human-oversight measures, and the measures to be taken in case of materialisation of those risks; the deployer shall notify the market surveillance authority of the results.

• FRIA per in-scope deployment
• Notification to market surveillance authority

• No FRIA for in-scope deployments
• FRIA not refreshed on material change

Art.57 requires each Member State to establish at least one AI regulatory sandbox and sets what it must provide. Art.58 directs the Commission to adopt implementing acts on the detailed arrangements for sandboxes and lists what those arrangements must cover. Art.62 requires Member States to take measures for providers and deployers that are SMEs including start-ups, such as priority sandbox access, awareness raising and reduced conformity assessment fees. Art.63 allows microenterprises to comply with certain elements of the Art.17 quality management system in a simplified manner, which is a relief from a duty rather than a duty. The three operator-facing articles in the former Art.57-63 bundle are now controls in their own right: EUAI-Art.59 sandbox personal data conditions, EUAI-Art.60 testing in real world conditions and EUAI-Art.61 informed consent.

• Sandbox participation evidence
• Informed-consent records for real-world testing
• SME-tailored compliance measures

• Real-world testing without informed consent
• Personal-data processing in sandbox without Art.59 safeguards

Where personal data lawfully collected for other purposes is processed in an AI regulatory sandbox solely to develop, train and test an AI system, every one of the Art.59(1) conditions must be met cumulatively: the system is developed to safeguard a substantial public interest in one of the listed areas; the personal data is necessary because anonymised, synthetic or other non-personal data cannot effectively fulfil the Chapter III Section 2 requirement in question; effective monitoring mechanisms identify high risks to the rights and freedoms of data subjects and response mechanisms promptly mitigate them and stop the processing where necessary; the data sits in a functionally separate, isolated and protected processing environment under the prospective provider's control with access limited to authorised persons; originally collected data is shared further only in accordance with Union

• A condition by condition assessment against Art.59(1) points (a) to (j), each recorded as met before processing begins
• The necessity analysis showing anonymised, synthetic or other non-personal data was tested and found ineffective
• Environment design evidence showing functional separation, isolation, protection and an authorised access list
• Processing logs covering the whole period of sandbox participation
• Deletion evidence at the end of participation or at the end of the retention period
• The published project summary on the competent authority's website, and the Annex IV description of training, testing and validation with its results

• The conditions treated as a menu when they are cumulative, so one unmet condition removes the basis for the processing
• Necessity asserted with no attempt made at synthetic or anonymised data
• Personal data created in the sandbox shared outside it, which the Regulation forbids outright
• The public project summary omitted, since it is the only outward facing condition and the easiest to overlook

A provider or prospective provider testing an Annex III high-risk AI system in real world conditions outside a sandbox may do so only where every Art.60(4) condition is met: a real-world testing plan has been drawn up and submitted to the market surveillance authority of the Member State where the testing takes place; that authority has approved the testing and the plan, approval being understood as given after thirty days of silence unless national law requires an express authorisation; the testing has been registered with a Union-wide unique single identification number and the Annex IX information, in the secure non-public section for law enforcement, migration, asylum and border control systems; the provider is established in the Union or has appointed a Union legal representative; data transferred to third countries is covered by applicable Union safeguards; the testing lasts no lon

• The real-world testing plan and evidence of its submission to and approval by the market surveillance authority
• The registration record carrying the Union-wide unique single identification number and the Annex IX information
• The written agreement with each co-operating deployer setting out roles and responsibilities
• Records showing the testing duration against the six month limit, with the prior notification and explanation for any extension
• Evidence of qualified oversight, naming who oversaw the testing and the authority they held to intervene
• A demonstrated reversal mechanism showing predictions, recommendations or decisions can be effectively reversed and disregarded
• Withdrawal and deletion records for any subject who withdrew

• Testing started on the assumption of tacit approval where national law requires an express authorisation
• The six month limit exceeded by treating a second phase as a new test rather than an extension requiring prior notification
• Oversight assigned to the development team without the authority to stop the test
• Reversibility asserted at design level with no evidence that a decision already acted on could actually be reversed

Before a subject participates in testing in real world conditions under Art.60, freely given informed consent must be obtained after the subject has been duly informed, in concise, clear, relevant and understandable terms, of the nature and objectives of the testing and the possible inconvenience of participating; the conditions under which the testing will be conducted, including the expected duration of their participation; their rights and the guarantees regarding their participation, in particular the right to refuse and the right to withdraw at any time without any resulting detriment and without giving reasons; the arrangements for requesting the reversal or disregarding of the system's predictions, recommendations or decisions; and the Union-wide unique single identification number of the testing together with contact details for the provider or its legal representative. The conse

• The consent information sheet covering all five Art.61(1) points in plain language
• Dated, documented consent records for every subject of the testing
• Evidence a copy was given to each subject or their legal representative
• The reversal request arrangements as communicated to subjects, and records of any request made under them
• A readability or comprehension check on the consent material, since the standard is concise, clear, relevant and understandable

• Consent bundled into general terms of service rather than obtained specifically for the testing
• The unique identification number and provider contact details omitted, so a subject cannot follow up
• Consent recorded as a system flag with no dated document and no copy given to the subject
• Withdrawal described as available but with no route a subject could actually use

Chapter III Section 4 builds the conformity assessment infrastructure. Member States designate notifying authorities (Art.28); conformity assessment bodies apply for notification (Art.29) and are notified through the Commission (Art.30); notified bodies must meet the Art.31 requirements and benefit from the Art.32 presumption of conformity; further articles govern subsidiaries and subcontracting (Art.33), the operational obligations of notified bodies (Art.34), identification numbers and lists (Art.35), changes to notifications (Art.36), challenges to competence (Art.37), coordination (Art.38) and recognition of third-country bodies (Art.39). A provider's own duty to use a notified body where one is required is carried at EUAI-Art.43.

• Notified-body engagement records where conformity assessment requires notified-body involvement

• Conformity assessment performed by a non-notified body where Art.43 requires one

Art.40 provides that a high-risk AI system or general-purpose AI model in conformity with harmonised standards whose references are published in the Official Journal is presumed to conform with the corresponding requirements, and directs the Commission's standardisation requests. Art.42 provides a presumption of conformity with the Art.10(4) data governance requirement for systems trained on data reflecting the specific geographical, behavioural, contextual or functional setting of intended use, and with the Art.15 cybersecurity requirement for systems certified under Regulation (EU) 2019/881. Both operate in the operator's favour rather than imposing anything. The one duty in the former Art.40-42 bundle, the Art.41(5) obligation to justify equivalent technical solutions where common specifications are not followed, is now carried at EUAI-Art.41.

• Use of harmonised standards or common specifications to claim presumption of conformity
• Standards-version tracking

• Conformity claimed without harmonised-standard or common-specification basis

Where the Commission has adopted common specifications by implementing act for the Chapter III Section 2 requirements or for the Chapter V Sections 2 and 3 obligations, a provider of a high-risk AI system or of a general-purpose AI model that does not comply with them must duly justify that it has adopted technical solutions meeting those requirements or obligations to a level at least equivalent. Conformity with the common specifications, or with parts of them, gives a presumption of conformity to the extent those specifications cover the requirement or obligation in question.

• A register of the common specifications in force for the requirements the system or model is subject to
• For each specification not followed, a documented equivalence justification naming the technical solution adopted and the requirement it satisfies
• Evidence supporting the equivalence claim, such as test results or analysis, rather than an assertion of equivalence
• A review trigger for when a common specification is adopted, amended or repealed on publication of a harmonised standard
• The presumption of conformity claim scoped to the parts of the specification actually applied

• Equivalence asserted without the evidence that would let an assessor test the claim
• The presumption of conformity claimed across a whole requirement when only part of the specification was applied
• No monitoring of the Official Journal, so a newly adopted specification goes unnoticed
• Common specifications confused with harmonised standards, so the wrong instrument is cited as the conformity basis

Providers must put each high-risk AI system through the correct conformity assessment procedure before it is placed on the market or put into service. For Annex III point 1 biometrics systems, where harmonised standards or common specifications have been applied, the provider chooses between internal control under Annex VI and assessment of the quality management system and the technical documentation with the involvement of a notified body under Annex VII; where such standards do not exist, were not applied, were applied only in part, or were published with a restriction, the Annex VII procedure must be followed. For Annex III points 2 to 8, internal control under Annex VI applies without notified body involvement. For systems covered by the Union harmonisation legislation in Section A of Annex I, the procedure required by that legislation applies and the Section 2 requirements form par

• A decision record per system showing which Annex VI or Annex VII route applies and the reason
• Completed conformity assessment records dated before placing on the market or putting into service
• Where a notified body was required, its engagement, its certificate and its identification number
• A substantial modification procedure setting out the criteria applied, with re-assessment records where it was triggered
• For continuously learning systems, the pre-determined changes as recorded in the Annex IV technical documentation at the initial assessment

• Internal control chosen for an Annex III point 1 biometrics system where harmonised standards were only partly applied, which closes that route
• Substantial modification judged informally, so a re-assessment that was due is never run
• Post-market retraining treated as pre-determined when it was never recorded as such at the initial assessment
• Assessment completed under the Annex I sectoral legislation without the Section 2 requirements being folded into it

Section header for Chapter III Section 5. The five operator-facing articles it formerly bundled are now controls in their own right: EUAI-Art.43 conformity assessment, EUAI-Art.46 derogation from conformity assessment, EUAI-Art.47 EU declaration of conformity, EUAI-Art.48 CE marking and EUAI-Art.49 registration. Art.44, on the certificates a notified body issues, their validity, renewal, restriction, suspension and withdrawal, and Art.45, on the information a notified body must give its notifying authority and other notified bodies, address notified bodies only and are not separately counted.

• Conformity-assessment records and certificate retention
• EU declaration of conformity
• CE marking on high-risk AI
• EU-database registration

• No EU DoC
• No registration in the EU database

Where a high-risk AI system is to be placed on the market or put into service before its conformity assessment is complete, for exceptional reasons of public security, protection of the life and health of persons, environmental protection or protection of key industrial and infrastructural assets, an authorisation must be obtained from the market surveillance authority on a duly justified request. The authorisation runs for a limited period while the conformity assessment procedures are carried out, and those procedures must be completed without undue delay. In a duly justified situation of urgency, law enforcement or civil protection authorities may put such a system into service before authorisation provided the authorisation is requested during or after the use without undue delay; if it is refused, use must stop with immediate effect and all results and outputs of that use must be di

• The duly justified request to the market surveillance authority, naming the exceptional ground relied on
• The authorisation received, with its scope and expiry recorded
• A plan and progress evidence showing the conformity assessment is being completed without undue delay while the authorisation runs
• For urgency use before authorisation, a record of when use began and when the authorisation was requested
• A stop and discard procedure able to demonstrably purge all results and outputs if the authorisation is refused

• Urgency use started with the authorisation request left until the deployment is challenged
• The derogation treated as open ended, with no conformity assessment actually progressing
• No technical means to identify and discard the outputs produced under a refused authorisation
• The Annex I carve-out overlooked, so an Art.46 derogation is claimed where only the sectoral derogation is available

The provider must draw up a written, machine readable, physical or electronically signed EU declaration of conformity for each high-risk AI system, keep it at the disposal of the national competent authorities for ten years after the system was placed on the market or put into service, and submit a copy on request. The declaration must identify the system it was drawn up for, state that the system meets the Chapter III Section 2 requirements, contain the information set out in Annex V, and be translated into a language easily understood by the national competent authorities of each Member State where the system is placed on the market or made available. Where other Union harmonisation legislation also requires a declaration, a single declaration covering all applicable Union law must be drawn up and must identify the legislation it relates to. By drawing it up the provider assumes respon

• The signed EU declaration of conformity per system, in machine readable form
• Its content checked line by line against every element of Annex V
• Translations covering each Member State where the system is placed on the market or made available
• A single combined declaration where other Union harmonisation legislation also requires one, identifying every instrument covered
• Version history showing the declaration was updated when the system or the basis of its conformity changed

• One declaration issued for a product family where each high-risk AI system needs its own
• A declaration drawn up at launch and never updated after a substantial modification
• Machine readability omitted, which Art.47(1) requires alongside the physical or electronic signature
• Separate declarations issued under each instrument where a single combined declaration is required

The provider must affix the CE marking to the high-risk AI system visibly, legibly and indelibly or, where that is not possible or not warranted by the nature of the system, to its packaging or accompanying documentation. For high-risk AI systems provided digitally a digital CE marking must be used, and only where it can easily be accessed through the interface from which the system is accessed or through an easily accessible machine readable code or other electronic means. Where a notified body was involved in the conformity assessment, its identification number must follow the marking and must also appear in any promotional material stating that the system fulfils the CE marking requirements. The general principles in Art.30 of Regulation (EC) No 765/2008 apply, and where other Union law also provides for CE marking the marking indicates conformity with that law as well.

• Evidence of the marking as affixed, including a capture of the digital marking and the path by which a user reaches it
• The justification where the marking sits on packaging or documentation rather than on the system itself
• The notified body identification number shown alongside the marking where a notified body was involved
• A review of promotional material confirming the identification number appears wherever CE conformity is claimed
• A check of the marking against the general principles in Art.30 of Regulation (EC) No 765/2008

• A digital CE marking placed where a user cannot easily reach it from the interface the system is accessed through
• The notified body number on the certificate but absent from the marking and from marketing claims
• CE marking affixed before the conformity assessment concluded
• Marking applied to packaging by default, without the justification the Regulation requires for not marking the system itself

Before placing on the market or putting into service an Annex III high-risk AI system other than one listed under Annex III point 2, the provider or, where applicable, the authorised representative must register itself and the system in the EU database. The same duty applies before placing on the market or putting into service an AI system that the provider has concluded is not high-risk under Art.6(3). Deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, must register themselves, select the system and register its use before putting the system into service or using it. For Annex III points 1, 6 and 7 systems in law enforcement, migration, asylum and border control management, registration goes into the secure non-public section of the database and is limited to the listed Annex VIII and Annex IX items. Annex III point

• Registration confirmations for the operator and for each system, dated before placing on the market or putting into service
• Registration of the not-high-risk conclusion where the Art.6(3) derogation was relied on
• Public authority deployer registrations recording the selection of the system and the registration of its use
• Evidence that law enforcement, migration, asylum and border control registrations were made in the secure non-public section with only the permitted fields
• National level registration evidence for Annex III point 2 systems

• The Art.49(2) duty missed entirely, because concluding a system is not high-risk feels like the end of the obligation rather than the trigger for one
• Public authority deployers assuming the provider's registration covers their use as well
• Registration completed after go-live rather than before
• Sensitive area systems registered in the public section of the database

Providers must establish and document a post-market monitoring system proportionate to the nature of the AI technologies and to the risks of the high-risk AI system. That system must actively and systematically collect, document and analyse relevant data on the performance of the system throughout its lifetime, whether provided by deployers or collected through other sources, so the provider can evaluate the system's continuous compliance with the Chapter III Section 2 requirements, including where relevant an analysis of interaction with other AI systems. The system must be based on a post-market monitoring plan that forms part of the Annex IV technical documentation and follows the template adopted by the Commission. Where an equivalent post-market monitoring system and plan already exist under Section A of Annex I legislation, the required elements may be integrated into them provided

• The documented post-market monitoring system, with the reasoning behind its proportionality recorded
• The post-market monitoring plan following the Commission template, held within the Annex IV technical documentation
• Collected performance data with evidence that it is analysed rather than merely stored
• A record of the channel through which deployer supplied data reaches the provider
• Periodic evaluations of continuous compliance with the Section 2 requirements, and the actions they triggered
• Where relevant, the analysis of interaction with other AI systems

• Monitoring reduced to availability and error rate telemetry, which does not evaluate compliance with the Section 2 requirements
• A plan written but never made part of the technical documentation
• No route for deployer supplied data, so the largest source of real world performance signal goes unused
• Interaction with other AI systems never analysed, because the system is monitored in isolation

Section header for the post-market monitoring and serious incident provisions of Chapter IX. Both articles it formerly bundled are now controls in their own right: EUAI-Art.72, the duty to establish, document and operate a post-market monitoring system on a plan following the Commission template, and EUAI-Art.73, the duty to report serious incidents within the applicable deadline and to investigate afterwards.

• Post-market monitoring plan and records
• Serious-incident reporting within the Art.73 deadlines

• No post-market monitoring plan
• Missed serious-incident reporting deadlines

Providers of high-risk AI systems placed on the Union market must report any serious incident to the market surveillance authorities of the Member State where the incident occurred. The report must be made immediately after the provider has established a causal link between the AI system and the incident, or the reasonable likelihood of such a link, and in any event no later than fifteen days after becoming aware of it. That deadline is two days in the event of a widespread infringement or an incident consisting of a serious and irreversible disruption to the management or operation of critical infrastructure, and ten days where a person has died. An initial incomplete report may be submitted where necessary to ensure timely reporting, followed by a complete report. After reporting, the provider must without delay carry out the necessary investigations including a risk assessment of the

• An incident procedure distinguishing the fifteen day, ten day and two day deadlines, naming who classifies an incident
• Incident records showing the date of awareness, the date the causal link was established or judged reasonably likely, and the date reported
• Reports made to the market surveillance authority of the Member State where the incident occurred
• Post-report investigation records including the risk assessment of the incident and the corrective action taken
• Evidence the competent authorities were informed before any change was made to the system that could affect a causal evaluation
• Where used, the initial incomplete report and the complete report that followed it

• A single fifteen day deadline applied to every incident, missing the two day and ten day cases
• The clock started from confirmed causation rather than from the reasonable likelihood of a causal link
• The system patched immediately after an incident, destroying the evidence a causal evaluation needs, without first informing the authorities
• Reports sent to the provider's home authority rather than to the authority of the Member State where the incident occurred

Chapter IX Section 3 sets the enforcement machinery: market surveillance and control of AI systems on the Union market (Art.74), mutual assistance and control of general-purpose AI systems (Art.75), supervision of real world testing by market surveillance authorities (Art.76), the powers of authorities protecting fundamental rights (Art.77), confidentiality (Art.78), the national procedure for AI systems presenting a risk (Art.79), the procedure for systems the provider classified as non-high-risk under Art.6(3) (Art.80), the Union safeguard procedure (Art.81), compliant AI systems that nonetheless present a risk (Art.82) and formal non-compliance (Art.83). Where these articles touch an operator they do so by way of an order a market surveillance authority issues in a particular case.

• Records of cooperation with market surveillance authorities
• Compliance with national procedures under Arts 79-82

• Non-cooperation with market surveillance authorities

Art.84 requires the Commission to designate one or more Union AI testing support structures performing the tasks listed in Art.21(6) of Regulation (EU) 2019/1020 in the field of AI. Art.85 gives any natural or legal person with grounds to consider this Regulation infringed the right to lodge a complaint with the relevant market surveillance authority, which handles it under its own procedures. Neither imposes a duty on a regulated party. The two operator-facing articles in the former Art.84-87 bundle are now controls in their own right: EUAI-Art.86, the deployer's duty to explain an individual decision to an affected person, and EUAI-Art.87, the application of Directive (EU) 2019/1937 to the reporting of infringements of this Regulation.

• Public complaint channel to the market-surveillance authority
• Explanation-on-request procedure for high-risk AI decisions
• Whistleblower protection extended to AI Act infringements

• No explanation procedure for affected persons under Art.86

A deployer must, at the request of an affected person who has been subject to a decision the deployer took on the basis of the output of an Annex III high-risk AI system other than one listed under Annex III point 2, and which produces legal effects or similarly significantly affects that person in a way they consider to have an adverse impact on their health, safety or fundamental rights, provide clear and meaningful explanations of the role of the AI system in the decision-making procedure and of the main elements of the decision taken. The duty does not apply where Union or national law provides an exception or restriction, and applies only to the extent the right is not otherwise provided for under Union law.

• A documented procedure for receiving and answering explanation requests, with an owner and a response time
• Explanation templates per decision type, covering both the role of the AI system in the procedure and the main elements of the decision
• A register of requests received and the explanations given
• An analysis of which deployed systems fall within Art.86, including which decisions produce legal or similarly significant effects
• The recorded assessment of any Union or national law exception relied on, and of any overlap with a right already provided elsewhere in Union law

• No inbound channel at all, so the right exists on paper and cannot be exercised
• An explanation of how the model works in general, rather than the role it played in this decision and the main elements of that decision
• The duty assumed to sit with the provider, when Art.86 addresses the deployer
• A data protection access response reused unchanged, which answers a different question and omits the role of the system in the decision procedure

Directive (EU) 2019/1937 applies to the reporting of infringements of this Regulation and to the protection of persons who report them. An organisation within the scope of that Directive must therefore make its internal reporting channels and procedures available for infringements of this Regulation, acknowledge and follow up such reports within the timeframes that Directive sets, preserve the confidentiality of the reporting person's identity, and protect reporting persons against retaliation on the same terms as for the other areas of Union law the Directive covers.

• Internal reporting channel documentation showing infringements of this Regulation are within its declared scope
• The published description of the reporting procedure, naming AI Act infringements among the reportable matters
• Acknowledgement and follow-up records evidencing the Directive's timeframes are met for AI related reports
• Training or communication showing staff know AI Act infringements can be raised through the channel
• Non-retaliation measures, and records of protection applied to any reporting person

• A reporting channel scoped to financial and bribery matters, which excludes AI Act infringements by omission
• The scope updated in policy but not in the channel's intake categories, so reports are misrouted
• No follow-up record, so compliance with the Directive's timeframes cannot be evidenced
• Confidentiality of the reporting person's identity not maintained through the AI specific investigation route

Chapter IX Section 5 gives the Commission exclusive powers over the obligations of general-purpose AI model providers: enforcement of those obligations (Art.88), monitoring actions (Art.89), qualified alerts of systemic risk from the scientific panel (Art.90), the power to request documentation and information (Art.91), the power to conduct evaluations including model access (Art.92), the power to request measures including mitigation or withdrawal (Art.93), and the procedural rights of the economic operators concerned (Art.94).

• Records of responses to Commission documentation and information requests
• Mitigation evidence in response to GPAI risk alerts

• Non-cooperation with Commission GPAI requests

Providers and deployers of certain AI systems (incl those interacting with natural persons, emotion recognition, biometric categorisation, generative AI producing synthetic content, deepfakes, and AI-generated/manipulated text for public-interest information) shall inform users that they are interacting with AI, label synthetic content in a machine-readable format, and disclose deepfakes and AI-generated public-interest text (subject to free-expression and artistic exceptions).

• User-facing AI-interaction notification
• Machine-readable labelling of synthetic content
• Deepfake/AI-text disclosure

• No disclosure that the user is interacting with AI
• Synthetic content not machine-readably labelled