AI Act Obligations for Providers

Source text: “This Regulation applies to:”

In practice: Map your organisation's role (provider or deployer) and determine whether your AI systems or their outputs reach EU users. Even if your company is based outside the EU, if your AI system's output is used in the EU, you must comply. Conduct a territorial scope assessment as a first compliance step.

Source text: “For AI systems classified as high-risk AI systems in accordance with Article 6(1) related to products covered by the Union harmonisation legislation listed in Section B of Annex I, only Article 6(1), Articles 102 to 109 and Article 112 apply. Article 57 applies only in so far as the requirements for high-risk AI systems under this Regulation have been integrated in that Union harmonisation legislation.”

In practice: If your AI system is a safety component of a product covered by Union harmonisation legislation listed in Annex I Section B (e.g., machinery, medical devices), identify which specific AI Act articles apply to your product and check whether the sectoral legislation has integrated AI Act requirements before applying Article 57.

Source text: “This Regulation does not apply to any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service. Such activities shall be conducted in accordance with applicable Union law. Testing in real world conditions shall not be covered by that exclusion.”

In practice: Organisations conducting pre-market AI research and development should ensure compliance with other applicable Union law (e.g., GDPR, product safety law) even if the AI Act does not yet apply. Once real-world testing begins, the AI Act's provisions on testing in real-world conditions apply and must be followed.

Source text: “Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used.”

In practice: Conduct an AI literacy gap analysis across all roles that interact with AI systems. Develop role-specific training programmes covering AI fundamentals, system-specific operation, ethical use, and risk awareness. Document training completion and periodically review literacy levels as AI systems evolve or new deployments occur.

Source text: “This Article shall not affect the prohibitions that apply where an AI practice infringes other Union law.”

In practice: Organisations should conduct a multi-framework compliance review for any AI practice, checking not only the AI Act's prohibited practices but also GDPR, non-discrimination law, consumer protection law, and competition law to ensure all applicable prohibitions are respected simultaneously.

Source text: “A provider who considers that an AI system referred to in Annex III is not high-risk shall document its assessment before that system is placed on the market or put into service. Such provider shall be subject to the registration obligation set out in Article 49(2). Upon request of national competent authorities, the provider shall provide the documentation of the assessment.”

In practice: Establish a pre-market documentation workflow that captures the non-high-risk assessment rationale, links it to the specific derogation condition relied upon, and triggers automatic registration in the EU database. Ensure the documentation is retrievable and can be provided to authorities on short notice.

Source text: “High-risk AI systems shall comply with the requirements laid down in this Section, taking into account their intended purpose as well as the generally acknowledged state of the art on AI and AI-related technologies. The risk management system referred to in Article 9 shall be taken into account when ensuring compliance with those requirements.”

In practice: Providers should document how each requirement in Section 2 is addressed in light of the AI system's intended purpose, and ensure the Article 9 risk management system explicitly cross-references compliance decisions for each requirement.

Source text: “Where a product contains an AI system, to which the requirements of this Regulation as well as requirements of the Union harmonisation legislation listed in Section A of Annex I apply, providers shall be responsible for ensuring that their product is fully compliant with all applicable requirements under applicable Union harmonisation legislation. In ensuring the compliance of high-risk AI systems referred to in paragraph 1 with the requirements set out in this Section, and in order to ensure consistency, avoid duplication and minimise additional burdens, providers shall have a choice of integrating, as appropriate, the necessary testing and reporting processes, information and documentation they provide with regard to their product into documentation and procedures that already exist and are required under the Union harmonisation legislation listed in Section A of Annex I.”

In practice: Providers should map existing conformity assessment documentation under applicable Union harmonisation legislation (e.g., Machinery Regulation, MDR) and identify where AI Act requirements can be integrated into those existing procedures, avoiding duplicate documentation while ensuring all AI Act requirements are explicitly addressed.

Source text: “A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.”

In practice: Create a formal risk management policy document specific to each high-risk AI system, assign ownership, and integrate it into your existing ISO 31000 or equivalent risk framework. Ensure the system is version-controlled and auditable.

Source text: “The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating. It shall comprise the following steps:”

In practice: Implement a living risk register that is updated at each development milestone and after deployment events. Schedule regular review cycles (e.g., quarterly) and link post-market monitoring data feeds directly into the risk assessment process. Document each iteration with timestamps and responsible parties.

Source text: “The risks referred to in this Article shall concern only those which may be reasonably mitigated or eliminated through the development or design of the high-risk AI system, or the provision of adequate technical information.”

In practice: When documenting your risk management system, explicitly scope each identified risk and justify whether it is addressable through design, development, or technical documentation. Risks that are entirely external and unmitigable through these means need not be included, but this exclusion must be documented and justified.

Source text: “The risk management measures referred to in paragraph 2, point (d), shall give due consideration to the effects and possible interaction resulting from the combined application of the requirements set out in this Section, with a view to minimising risks more effectively while achieving an appropriate balance in implementing the measures to fulfil those requirements.”

In practice: When designing risk management measures, conduct a cross-requirement impact analysis to identify how measures for one requirement (e.g., accuracy) may interact with or affect another (e.g., transparency or human oversight). Document trade-offs and the rationale for the chosen balance.

Source text: “The risk management measures referred to in paragraph 2, point (d), shall be such that the relevant residual risk associated with each hazard, as well as the overall residual risk of the high-risk AI systems is judged to be acceptable. In identifying the most appropriate risk management measures, the following shall be ensured: With a view to eliminating or reducing risks related to the use of the high-risk AI system, due consideration shall be given to the technical knowledge, experience, education, the training to be expected by the deployer, and the presumable context in which the system is intended to be used.”

In practice: Apply a risk hierarchy: first attempt to eliminate or reduce risks through design (e.g., algorithmic safeguards, input validation); if not fully eliminable, implement technical and organisational controls; finally, document residual risks in the instructions for use per Article 13 and provide deployer training. Record the rationale for each decision in the risk register.

Source text: “High-risk AI systems shall be tested for the purpose of identifying the most appropriate and targeted risk management measures. Testing shall ensure that high-risk AI systems perform consistently for their intended purpose and that they are in compliance with the requirements set out in this Section.”

In practice: Establish a structured testing programme that maps test cases to specific risk management measures and documents how each test confirms compliance with Section requirements; maintain test records as part of the technical documentation.

Source text: “The testing of high-risk AI systems shall be performed, as appropriate, at any time throughout the development process, and, in any event, prior to their being placed on the market or put into service. Testing shall be carried out against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose of the high-risk AI system.”

In practice: Define and document test metrics and probabilistic thresholds before testing begins; ensure at minimum a final pre-market test is conducted and results are recorded in the technical documentation with clear pass/fail criteria linked to the intended purpose.

Source text: “When implementing the risk management system as provided for in paragraphs 1 to 7, providers shall give consideration to whether in view of its intended purpose the high-risk AI system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups.”

In practice: Include a dedicated section in the risk management documentation assessing potential impacts on minors and other vulnerable groups (e.g., elderly, persons with disabilities); consult child protection standards such as UNCRC General Comment No. 25 when relevant.

Source text: “High-risk AI systems which make use of techniques involving the training of AI models with data shall be developed on the basis of training, validation and testing data sets that meet the quality criteria referred to in paragraphs 2 to 5 whenever such data sets are used.”

In practice: Establish a data quality checklist aligned with Article 10 paragraphs 2–5 before initiating any model training. Document dataset provenance, quality assessments, and governance practices as part of your technical documentation.

Source text: “Training, validation and testing data sets shall be subject to data governance and management practices appropriate for the intended purpose of the high-risk AI system. Those practices shall concern in particular:”

In practice: Implement a data governance framework that documents the origin of all datasets, the original purpose of personal data collection, and all preprocessing steps (annotation, labelling, cleaning, enrichment). Maintain this documentation as part of the technical file.

Source text: “Training, validation and testing data sets shall be relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose. They shall have the appropriate statistical properties, including, where applicable, as regards the persons or groups of persons in relation to whom the high-risk AI system is intended to be used. Those characteristics of the data sets may be met at the level of individual data sets or at the level of a combination thereof.”

In practice: Conduct statistical analysis of your datasets to verify representativeness across relevant demographic groups. Document any known limitations and implement bias detection measures. Consider combining multiple datasets if a single dataset cannot meet all quality criteria.

Source text: “Data sets shall take into account, to the extent required by the intended purpose, the characteristics or elements that are particular to the specific geographical, contextual, behavioural or functional setting within which the high-risk AI system is intended to be used.”

In practice: When preparing datasets, map the deployment context of the AI system (e.g., specific country, user behaviour patterns, operational environment) and ensure the dataset reflects those characteristics. Document this contextual alignment in the technical documentation.

Source text: “To the extent that it is strictly necessary for the purpose of ensuring bias detection and correction in relation to the high-risk AI systems in accordance with paragraph (2), points (f) and (g) of this Article, the providers of such systems may exceptionally process special categories of personal data, subject to appropriate safeguards for the fundamental rights and freedoms of natural persons. In addition to the provisions set out in Regulations (EU) 2016/679 and (EU) 2018/1725 and Directive (EU) 2016/680, all the following conditions must be met in order for such processing to occur:”

In practice: Before processing special categories of personal data for bias detection, document why synthetic or anonymised data is insufficient, implement pseudonymisation and encryption, establish strict access controls with audit logs, and ensure compliance with GDPR Article 9 and applicable national law in addition to these AI Act conditions.

Source text: “For the development of high-risk AI systems not using techniques involving the training of AI models, paragraphs 2 to 5 apply only to the testing data sets.”

In practice: If your high-risk AI system uses rule-based logic, expert systems, or other non-training approaches rather than machine learning, you only need to apply Article 10's data governance requirements (relevance, representativeness, error-free, completeness) to your testing datasets. Document clearly that your system does not use training techniques to justify this scoped application.

GDPR Art. 9(1): “Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation shall be prohibited.”

GDPR Art. 9(2): “Paragraph 1 shall not apply if one of the following applies:”

GDPR Art. 9(3): “Personal data referred to in paragraph 1 may be processed for the purposes referred to in point (h) of paragraph 2 when those data are processed by or under the responsibility of a professional subject to the obligation of professional secrecy under Union or Member State law or rules established by national competent bodies or by another person also subject to an obligation of secrecy under Union or Member State law or rules established by national competent bodies.”

GDPR Art. 9(4): “Member States may maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data or data concerning health.”

Bridge: GDPR Article 9 is implemented as a control module in RuleMesh — the same control you would evidence here. Explore GDPR control modules →

Source text: “The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up-to date. The technical documentation shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in this Section and to provide national competent authorities and notified bodies with the necessary information in a clear and comprehensive form to assess the compliance of the AI system with those requirements. It shall contain, at a minimum, the elements set out in Annex IV. SMEs, including start-ups, may provide the elements of the technical documentation specified in Annex IV in a simplified manner. To that end, the Commission shall establish a simplified technical documentation form targeted at the needs of small and microenterprises. Where an SME, including a start-up, opts to provide the information required in Annex IV in a simplified manner, it shall use the form referred to in this paragraph. Notified bodies shall accept the form for the purposes of the conformity assessment.”

In practice: Establish a documentation management process that maps each Annex IV element to your AI system's design artefacts; if you are an SME, monitor the Commission's publication of the simplified form and adopt it as your standard template to reduce administrative burden while remaining audit-ready.

Source text: “Where a high-risk AI system related to a product covered by the Union harmonisation legislation listed in Section A of Annex I is placed on the market or put into service, a single set of technical documentation shall be drawn up containing all the information set out in paragraph 1, as well as the information required under those legal acts.”

In practice: Conduct a gap analysis between Annex IV of the AI Act and the technical documentation requirements of the applicable sectoral legislation (e.g., Machinery Regulation, MDR) and produce a single integrated document that cross-references both sets of requirements, clearly indicating where each obligation is addressed.

Source text: “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”

In practice: Ensure that your high-risk AI system's architecture includes built-in logging infrastructure from the design phase. Use structured log formats (e.g., JSON) and ensure logs are tamper-resistant and stored securely for the system's full operational lifetime.

Source text: “In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for:”

In practice: Design logging to capture events relevant to risk triggers (per Article 79(1)), post-market monitoring events (per Article 72), and deployer oversight events (per Article 26(5)). Map each log category to its regulatory purpose and document this mapping in your technical documentation.

Source text: “For high-risk AI systems referred to in point 1 (a), of Annex III, the logging capabilities shall provide, at a minimum:”

In practice: For biometric identification AI systems, implement structured logs that automatically capture: (1) session start/end timestamps, (2) the identifier or version of the reference database queried, and (3) the input data (or a reference/hash thereof) that produced a positive match. Ensure these logs are retained securely and are accessible for audit purposes.

Source text: “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 a system’s output and use it appropriately. An appropriate type and degree of transparency shall be ensured with a view to achieving compliance with the relevant obligations of the provider and deployer set out in Section 3.”

In practice: Implement explainability mechanisms (e.g., confidence scores, decision rationale outputs) and document how outputs should be interpreted. Conduct user testing with deployers to verify that transparency features are adequate for their operational context.

Source text: “High-risk AI systems shall be accompanied by instructions for use in an appropriate digital format or otherwise that include concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers.”

In practice: Prepare structured instructions for use in machine-readable digital formats (e.g., PDF, HTML) that are version-controlled and updated with each system change. Validate comprehensibility with representative deployer groups before market placement.

Source text: “The instructions for use shall contain at least the following information:”

In practice: Create a standardised template for instructions for use that includes a dedicated section for provider/authorised representative contact details and a structured description of system capabilities, known limitations, and any pre-approved performance changes. Ensure this is updated whenever a new conformity assessment is performed.

Source text: “High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.”

In practice: Ensure that your high-risk AI system's UI/UX design includes dashboards, alerts, and controls that allow human operators to monitor, intervene, and override AI decisions in real time. Document these interface features in your technical documentation.

Source text: “Human oversight shall aim to prevent or minimise the risks to health, safety or fundamental rights that may emerge when a high-risk AI system is used in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, in particular where such risks persist despite the application of other requirements set out in this Section.”

In practice: Conduct a risk assessment that explicitly identifies scenarios of foreseeable misuse and residual risks not covered by technical safeguards, and design oversight measures specifically targeting those gaps.

Source text: “The oversight measures shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system, and shall be ensured through either one or both of the following types of measures:”

In practice: Classify your AI system's autonomy level and context of use, then document whether oversight measures are built into the system or delegated to the deployer, ensuring both types are clearly specified in the instructions for use.

Source text: “For the purpose of implementing paragraphs 1, 2 and 3, the high-risk AI system shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate:”

In practice: Include in the instructions for use explicit sections on system limitations, known failure modes, automation bias risks, and guidance on interpreting outputs, including any available interpretation tools or methods.

Source text: “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 that they perform consistently in those respects throughout their lifecycle.”

In practice: Establish a lifecycle management plan that includes regular accuracy benchmarking, robustness testing, and cybersecurity assessments at each stage from design through decommissioning. Document baseline performance metrics and track deviations over time.

Source text: “The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use.”

In practice: Include a dedicated section in the instructions of use that clearly states the accuracy levels achieved during testing and the specific metrics used (e.g., precision, recall, F1-score), tailored to the intended use case and target deployer audience.

Source text: “High-risk AI systems shall be as resilient as possible regarding errors, faults or inconsistencies that may occur within the system or the environment in which the system operates, in particular due to their interaction with natural persons or other systems. Technical and organisational measures shall be taken in this regard. The robustness of high-risk AI systems may be achieved through technical redundancy solutions, which may include backup or fail-safe plans. High-risk AI systems that continue to learn after being placed on the market or put into service shall be developed in such a way as to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations (feedback loops), and as to ensure that any such feedback loops are duly addressed with appropriate mitigation measures.”

In practice: Implement fail-safe mechanisms and backup plans for high-risk AI systems, and for systems with post-deployment learning, establish monitoring pipelines to detect and mitigate feedback loops that could skew future outputs. Document all technical and organisational robustness measures taken.

Source text: “High-risk AI systems shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. The technical solutions aiming to ensure the cybersecurity of high-risk AI systems shall be appropriate to the relevant circumstances and the risks. The technical solutions to address AI specific vulnerabilities shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws.”

In practice: Implement AI-specific security controls including adversarial robustness testing, training data integrity verification, and model monitoring for anomalous behaviour. Develop and maintain an AI threat model that covers data poisoning, adversarial examples, and model evasion scenarios, and integrate these into the overall cybersecurity risk management framework.

Source text: “ensure that their high-risk AI systems are compliant with the requirements set out in Section 2;”

In practice: Establish an internal compliance checklist mapped to each requirement in Section 2 (risk management, data governance, transparency, human oversight, accuracy, cybersecurity) and conduct regular internal audits to verify ongoing conformity before and after market placement.

Source text: “indicate on the high-risk AI system or, where that is not possible, on its packaging or its accompanying documentation, as applicable, their name, registered trade name or registered trade mark, the address at which they can be contacted;”

In practice: Ensure that provider identification information (legal name, trade name/trademark, and a valid contact address) is affixed directly to the AI system interface, hardware, or clearly stated in the product documentation or packaging before market release.

Source text: “have a quality management system in place which complies with Article 17;”

In practice: Implement or adapt an existing ISO 9001-compliant QMS to incorporate AI-specific elements required by Article 17, including risk management procedures, data governance, post-market monitoring, and documentation practices. Microenterprises may use a simplified QMS as permitted under the Act.

Source text: “keep the documentation referred to in Article 18;”

In practice: Maintain up-to-date technical documentation as specified in Article 18 and Annex IV of the AI Act, including system descriptions, design specifications, risk management records, training data information, and conformity assessment results. Store documentation securely and make it available to competent authorities upon request.

Source text: “when under their control, keep the logs automatically generated by their high-risk AI systems as referred to in Article 19;”

In practice: Implement automated log retention mechanisms for high-risk AI systems under your control, ensuring logs are stored securely, tamper-proof, and accessible for the retention period specified in Article 19. Define clear procedures for when control transfers to a deployer, at which point the log-keeping obligation shifts accordingly.

Source text: “ensure that the high-risk AI system undergoes the relevant conformity assessment procedure as referred to in Article 43, prior to its being placed on the market or put into service;”

In practice: Establish a pre-launch checklist that maps each high-risk AI system to the correct conformity assessment pathway under Article 43 (internal control or third-party notified body). Document completion of the assessment before any commercial release or deployment.

Source text: “draw up an EU declaration of conformity in accordance with Article 47;”

In practice: Prepare and maintain an EU declaration of conformity template aligned with Article 47 requirements. Ensure it is signed by an authorised representative and updated whenever the system undergoes a substantial modification triggering a new conformity assessment.

Source text: “affix the CE marking to the high-risk AI system or, where that is not possible, on its packaging or its accompanying documentation, to indicate conformity with this Regulation, in accordance with Article 48;”

In practice: Determine whether the CE marking can be physically affixed to the AI system or product. If the system is purely digital, use a digital CE marking on accompanying documentation. Ensure the marking is visible, legible, and indelible as required by Article 48.

Source text: “comply with the registration obligations referred to in Article 49(1);”

In practice: Register the high-risk AI system in the EU database established under Article 71 before market placement. Ensure all mandatory fields are completed accurately and that any substantial modification is also registered. Assign a responsible person to maintain registration records.

Source text: “take the necessary corrective actions and provide information as required in Article 20;”

In practice: Establish a post-market monitoring and incident response procedure that triggers corrective action workflows when serious incidents or non-conformities are detected. Ensure clear escalation paths and documentation of all corrective measures taken and information provided to authorities.

Source text: “upon a reasoned request of a national competent authority, demonstrate the conformity of the high-risk AI system with the requirements set out in Section 2;”

In practice: Maintain a readily accessible compliance dossier including technical documentation, risk management records, conformity assessment results, and test data so that you can respond promptly to any authority request without delay.

Source text: “ensure that the high-risk AI system complies with accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882.”

In practice: Conduct an accessibility audit of the high-risk AI system's interfaces and outputs against the requirements of Directives 2016/2102 and 2019/882 during the design phase, and document how universal design principles have been embedded, including support for assistive technologies and accessible formats.

Source text: “Providers of high-risk AI systems shall put a quality management system in place that ensures compliance with this Regulation. That system shall be documented in a systematic and orderly manner in the form of written policies, procedures and instructions, and shall include at least the following aspects:”

In practice: Create a formal QMS document that maps each required aspect (compliance strategy, design control, quality assurance) to specific internal policies and procedures. Use ISO 9001 or sector-specific standards as a baseline and supplement with AI-specific controls.

Source text: “The implementation of the aspects referred to in paragraph 1 shall be proportionate to the size of the provider’s organisation. Providers shall, in any event, respect the degree of rigour and the level of protection required to ensure the compliance of their high-risk AI systems with this Regulation.”

In practice: Microenterprises and SMEs may implement a simplified QMS, but must document that all mandatory protection requirements are still met. Consider using the Commission's simplified QMS guidelines for microenterprises when available.

Source text: “For providers that are financial institutions subject to requirements regarding their internal governance, arrangements or processes under Union financial services law, the obligation to put in place a quality management system, with the exception of paragraph 1, points (g), (h) and (i) of this Article, shall be deemed to be fulfilled by complying with the rules on internal governance arrangements or processes pursuant to the relevant Union financial services law. To that end, any harmonised standards referred to in Article 40 shall be taken into account.”

In practice: Financial institutions (banks, insurers, etc.) should document how their existing internal governance frameworks under EU financial services law (e.g., CRD IV, Solvency II) satisfy the AI Act QMS requirements, and separately ensure compliance with Article 17(1)(g), (h), and (i) which are not covered by this equivalence.

Source text: “The provider shall, for a period ending 10 years after the high-risk AI system has been placed on the market or put into service, keep at the disposal of the national competent authorities:”

In practice: Establish a document retention policy specifically for high-risk AI systems that ensures all technical documentation (per Article 11), QMS records (per Article 17), and notified body approvals are stored securely and retrievable for at least 10 years from market placement date. Use a document management system with automated retention schedules.

Source text: “Providers of high-risk AI systems shall keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control. Without prejudice to applicable Union or national law, the logs shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data.”

In practice: Implement a log retention policy for all high-risk AI systems that defaults to a minimum of six months. Integrate this with your data governance framework to ensure alignment with GDPR retention limits and document any deviations justified by applicable law or the system's intended purpose.

Source text: “Providers that are financial institutions subject to requirements regarding their internal governance, arrangements or processes under Union financial services law shall maintain the logs automatically generated by their high-risk AI systems as part of the documentation kept under the relevant financial services law.”

In practice: Financial institutions should map their AI system log retention obligations to existing internal governance documentation requirements under applicable financial services law (e.g., MiFID II, CRD, Solvency II). Establish a unified record-keeping framework that satisfies both the AI Act and sectoral requirements, avoiding duplication while ensuring full compliance.

Source text: “Providers of high-risk AI systems which consider or have reason to consider that a high-risk AI system that they have placed on the market or put into service is not in conformity with this Regulation shall immediately take the necessary corrective actions to bring that system into conformity, to withdraw it, to disable it, or to recall it, as appropriate. They shall inform the distributors of the high-risk AI system concerned and, where applicable, the deployers, the authorised representative and importers accordingly.”

In practice: Establish an internal non-conformity detection and escalation procedure that automatically triggers corrective action workflows and stakeholder notifications; maintain an up-to-date contact list of all distributors, deployers, authorised representatives, and importers for rapid communication.

Source text: “Where the high-risk AI system presents a risk within the meaning of Article 79(1) and the provider becomes aware of that risk, it shall immediately investigate the causes, in collaboration with the reporting deployer, where applicable, and inform the market surveillance authorities competent for the high-risk AI system concerned and, where applicable, the notified body that issued a certificate for that high-risk AI system in accordance with Article 44, in particular, of the nature of the non-compliance and of any relevant corrective action taken.”

In practice: Implement a documented incident investigation protocol that includes collaboration procedures with deployers and a structured notification template for market surveillance authorities and notified bodies; ensure the nature of non-compliance and corrective actions are clearly recorded and communicated without delay.

Source text: “Providers of high-risk AI systems shall, upon a reasoned request by a competent authority, provide that authority all the information and documentation necessary to demonstrate the conformity of the high-risk AI system with the requirements set out in Section 2, in a language which can be easily understood by the authority in one of the official languages of the institutions of the Union as indicated by the Member State concerned.”

In practice: Maintain a ready-to-share compliance documentation package (technical documentation, conformity assessment records, risk management files) translated into the official EU language(s) of the Member States where the system is deployed, so it can be provided promptly upon any reasoned authority request.

Source text: “Upon a reasoned request by a competent authority, providers shall also give the requesting competent authority, as applicable, access to the automatically generated logs of the high-risk AI system referred to in Article 12(1), to the extent such logs are under their control.”

In practice: Implement a log management system that clearly identifies which automatically generated logs are under the provider's control, and establish a documented process for securely sharing those logs with competent authorities upon request, including access controls and audit trails for such disclosures.

Source text: “Prior to making their high-risk AI systems available on the Union market, providers established in third countries shall, by written mandate, appoint an authorised representative which is established in the Union.”

In practice: Third-country AI providers should identify and formally appoint an EU-based authorised representative well before market entry, ensuring the mandate is in writing and covers all required tasks under Article 22.

Source text: “The provider shall enable its authorised representative to perform the tasks specified in the mandate received from the provider.”

In practice: Providers should include in the mandate explicit provisions granting the authorised representative access to documentation, technical information, and authority to act on compliance matters, and should not obstruct the representative's activities.

Source text: “Where the circumstances referred to in paragraph 1 occur, the provider that initially placed the AI system on the market or put it into service shall no longer be considered to be a provider of that specific AI system for the purposes of this Regulation. That initial provider shall closely cooperate with new providers and shall make available the necessary information and provide the reasonably expected technical access and other assistance that are required for the fulfilment of the obligations set out in this Regulation, in particular regarding the compliance with the conformity assessment of high-risk AI systems. This paragraph shall not apply in cases where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system and therefore does not fall under the obligation to hand over the documentation.”

In practice: Original providers should include clear contractual clauses specifying whether their AI system may be modified into a high-risk system, and if so, establish data-sharing and technical support protocols in advance to facilitate smooth handover of compliance responsibilities.

Source text: “The provider of a high-risk AI system and the third party that supplies an AI system, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation. This paragraph shall not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence. The AI Office may develop and recommend voluntary model terms for contracts between providers of high-risk AI systems and third parties that supply tools, services, components or processes that are used for or integrated into high-risk AI systems. When developing those voluntary model terms, the AI Office shall take into account possible contractual requirements applicable in specific sectors or business cases. The voluntary model terms shall be published and be available free of charge in an easily usable electronic format.”

In practice: High-risk AI system providers should establish a supplier management programme that includes standardised written agreements covering information sharing, technical access, and compliance support obligations. Review existing supplier contracts to ensure they meet this requirement before the regulation applies.

Source text: “Paragraphs 2 and 3 are without prejudice to the need to observe and protect intellectual property rights, confidential business information and trade secrets in accordance with Union and national law.”

In practice: When drafting cooperation agreements or sharing technical documentation under paragraphs 2 and 3, include appropriate confidentiality clauses and IP protection provisions. Consider using non-disclosure agreements and data room arrangements to share sensitive technical information securely.

Source text: “With the exception of certificates unduly issued, and where a designation has been suspended or restricted, the certificates shall remain valid in one of the following circumstances:”

In practice: Develop a certificate validity decision tree for use by notifying authorities when a suspension or restriction occurs; ensure written confirmations and timelines are documented within one month and that providers are notified immediately if a substitute notified body must be engaged within three months.

Source text: “Where providers of high-risk AI systems or general-purpose AI models do not comply with the common specifications referred to in paragraph 1, they shall duly justify that they have adopted technical solutions that meet the requirements referred to in Section 2 of this Chapter or, as applicable, comply with the obligations set out in Sections 2 and 3 of Chapter V to a level at least equivalent thereto.”

In practice: Providers choosing not to follow common specifications should prepare detailed technical documentation justifying how their alternative solutions achieve at least equivalent compliance, and retain this documentation for review by market surveillance authorities.

Source text: “For high-risk AI systems listed in point 1 of Annex III, where, in demonstrating the compliance of a high-risk AI system with the requirements set out in Section 2, the provider has applied harmonised standards referred to in Article 40, or, where applicable, common specifications referred to in Article 41, the provider shall opt for one of the following conformity assessment procedures based on: In demonstrating the compliance of a high-risk AI system with the requirements set out in Section 2, the provider shall follow the conformity assessment procedure set out in Annex VII where: For the purposes of the conformity assessment procedure referred to in Annex VII, the provider may choose any of the notified bodies. However, where the high-risk AI system is intended to be put into service by law enforcement, immigration or asylum authorities or by Union institutions, bodies, offices or agencies, the market surveillance authority referred to in Article 74(8) or (9), as applicable, shall act as a notified body.”

In practice: Map your AI system to Annex III point 1 and check whether applicable harmonised standards under Article 40 or common specifications under Article 41 exist. If they do, you may use internal control (Annex VI); if not, engage a notified body under Annex VII. For law enforcement use cases, contact the designated market surveillance authority early as it will serve as the notified body.

Source text: “For high-risk AI systems referred to in points 2 to 8 of Annex III, providers shall follow the conformity assessment procedure based on internal control as referred to in Annex VI, which does not provide for the involvement of a notified body.”

In practice: If your high-risk AI system falls under Annex III points 2–8 (e.g., education, employment, essential services, law enforcement, migration, justice), you must self-certify using the internal control procedure in Annex VI. Establish a robust internal quality management system and document all technical evidence required by Annex VI to demonstrate compliance.

Source text: “For high-risk AI systems covered by the Union harmonisation legislation listed in Section A of Annex I, the provider shall follow the relevant conformity assessment procedure as required under those legal acts. The requirements set out in Section 2 of this Chapter shall apply to those high-risk AI systems and shall be part of that assessment. Points 4.3., 4.4., 4.5. and the fifth paragraph of point 4.6 of Annex VII shall also apply. For the purposes of that assessment, notified bodies which have been notified under those legal acts shall be entitled to control the conformity of the high-risk AI systems with the requirements set out in Section 2, provided that the compliance of those notified bodies with requirements laid down in Article 31(4), (5), (10) and (11) has been assessed in the context of the notification procedure under those legal acts. Where a legal act listed in Section A of Annex I enables the product manufacturer to opt out from a third-party conformity assessment, provided that that manufacturer has applied all harmonised standards covering all the relevant requirements, that manufacturer may use that option only if it has also applied harmonised standards or, where applicable, common specifications referred to in Article 41, covering all requirements set out in Section 2 of this Chapter.”

In practice: If your AI system is a safety component of a product regulated under Annex I Section A legislation (e.g., medical devices, machinery), integrate the AI Act's Section 2 requirements into your existing conformity assessment. Verify that your notified body has been assessed against Article 31(4), (5), (10) and (11). If opting out of third-party assessment, ensure harmonised standards covering all Section 2 AI Act requirements have been applied.

Source text: “High-risk AI systems that have already been subject to a conformity assessment procedure shall undergo a new conformity assessment procedure in the event of a substantial modification, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer. For high-risk AI systems that continue to learn after being placed on the market or put into service, changes to the high-risk AI system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in point 2(f) of Annex IV, shall not constitute a substantial modification.”

In practice: Establish a change management process that evaluates every modification to a high-risk AI system against the 'substantial modification' threshold. Pre-determine and document in the technical documentation (Annex IV point 2(f)) any anticipated post-deployment learning changes at the time of initial conformity assessment to avoid triggering a new assessment for those changes.

Source text: “Where a notified body finds that an AI system no longer meets the requirements set out in Section 2, it shall, taking account of the principle of proportionality, suspend or withdraw the certificate issued or impose restrictions on it, unless compliance with those requirements is ensured by appropriate corrective action taken by the provider of the system within an appropriate deadline set by the notified body. The notified body shall give reasons for its decision. An appeal procedure against decisions of the notified bodies, including on conformity certificates issued, shall be available.”

In practice: Providers should establish internal processes to respond promptly to notified body findings of non-compliance, including a corrective action plan with clear timelines. Notified bodies should document their decisions with detailed reasoning and ensure that an accessible, transparent appeal mechanism is in place and communicated to providers.

Source text: “By way of derogation from Article 43 and upon a duly justified request, any market surveillance authority may authorise the placing on the market or the putting into service of specific high-risk AI systems within the territory of the Member State concerned, for exceptional reasons of public security or the protection of life and health of persons, environmental protection or the protection of key industrial and infrastructural assets. That authorisation shall be for a limited period while the necessary conformity assessment procedures are being carried out, taking into account the exceptional reasons justifying the derogation. The completion of those procedures shall be undertaken without undue delay.”

In practice: Operators seeking emergency authorisation should document the exceptional justification thoroughly and immediately initiate the conformity assessment procedure in parallel, tracking progress to ensure timely completion.

Source text: “For high-risk AI systems related to products covered by Union harmonisation legislation listed in Section A of Annex I, only the derogations from the conformity assessment established in that Union harmonisation legislation shall apply.”

In practice: Providers of high-risk AI systems embedded in products covered by Annex I Section A legislation (e.g., medical devices, machinery) should consult the applicable sectoral Union harmonisation legislation to identify the correct derogation procedures, rather than relying on the general AI Act derogation provisions.

Source text: “The provider shall draw up a written machine readable, physical or electronically signed EU declaration of conformity for each high-risk AI system, and keep it at the disposal of the national competent authorities for 10 years after the high-risk AI system has been placed on the market or put into service. The EU declaration of conformity shall identify the high-risk AI system for which it has been drawn up. A copy of the EU declaration of conformity shall be submitted to the relevant national competent authorities upon request.”

In practice: Establish a document management system that stores EU declarations of conformity in machine-readable format (e.g., XML or PDF/A with metadata) with automated retention tracking for 10 years per system. Tag each declaration with the system identifier and placement date to facilitate retrieval upon regulatory request.

Source text: “The EU declaration of conformity shall state that the high-risk AI system concerned meets the requirements set out in Section 2. The EU declaration of conformity shall contain the information set out in Annex V, and shall be translated into a language that can be easily understood by the national competent authorities of the Member States in which the high-risk AI system is placed on the market or made available.”

In practice: Prepare a template EU declaration of conformity aligned with Annex V and maintain translated versions for each target Member State market. Assign a compliance officer to verify that the declaration explicitly references all Section 2 requirements met by the system before market placement.

Source text: “Where high-risk AI systems are subject to other Union harmonisation legislation which also requires an EU declaration of conformity, a single EU declaration of conformity shall be drawn up in respect of all Union law applicable to the high-risk AI system. The declaration shall contain all the information required to identify the Union harmonisation legislation to which the declaration relates.”

In practice: Map all applicable Union harmonisation legislation for each high-risk AI product (e.g., Machinery Regulation, Medical Devices Regulation) and create a unified declaration template that references each applicable legal act and its specific requirements, avoiding separate declarations that may create inconsistencies.

Source text: “By drawing up the EU declaration of conformity, the provider shall assume responsibility for compliance with the requirements set out in Section 2. The provider shall keep the EU declaration of conformity up-to-date as appropriate.”

In practice: Implement a change management process that triggers a review of the EU declaration of conformity whenever the AI system undergoes modifications, updates to its intended purpose, or changes in the regulatory environment. Assign a named responsible person for maintaining the declaration's currency.

Source text: “The CE marking shall be subject to the general principles set out in Article 30 of Regulation (EC) No 765/2008.”

In practice: Ensure your CE marking process for high-risk AI systems aligns with the New Legislative Framework principles in Regulation (EC) No 765/2008, including correct placement, visibility, and the prohibition on misleading markings.

Source text: “For high-risk AI systems provided digitally, a digital CE marking shall be used, only if it can easily be accessed via the interface from which that system is accessed or via an easily accessible machine-readable code or other electronic means.”

In practice: If your high-risk AI system is delivered digitally (e.g., via API or SaaS), implement a digital CE marking accessible directly from the user interface or via a QR code or URL linking to the declaration of conformity.

Source text: “The CE marking shall be affixed visibly, legibly and indelibly for high-risk AI systems. Where that is not possible or not warranted on account of the nature of the high-risk AI system, it shall be affixed to the packaging or to the accompanying documentation, as appropriate.”

In practice: For physical AI-embedded products, ensure the CE marking is directly on the device in a durable, clearly visible manner. For systems where direct affixing is impractical, place the marking prominently on packaging or user documentation.

Source text: “Where applicable, the CE marking shall be followed by the identification number of the notified body responsible for the conformity assessment procedures set out in Article 43. The identification number of the notified body shall be affixed by the body itself or, under its instructions, by the provider or by the provider’s authorised representative. The identification number shall also be indicated in any promotional material which mentions that the high-risk AI system fulfils the requirements for CE marking.”

In practice: After obtaining a notified body certificate, ensure the notified body's identification number is placed immediately after the CE marking on the product, packaging, and documentation, and is also included in all marketing materials referencing CE compliance.

Source text: “Where high-risk AI systems are subject to other Union law which also provides for the affixing of the CE marking, the CE marking shall indicate that the high-risk AI system also fulfil the requirements of that other law.”

In practice: For AI systems that fall under multiple EU regulations (e.g., Medical Devices Regulation, Machinery Regulation), ensure the CE marking and accompanying EU declaration of conformity explicitly reference all applicable Union laws to demonstrate comprehensive compliance.

Source text: “Before placing on the market or putting into service a high-risk AI system listed in Annex III, with the exception of high-risk AI systems referred to in point 2 of Annex III, the provider or, where applicable, the authorised representative shall register themselves and their system in the EU database referred to in Article 71.”

In practice: Establish an internal pre-launch checklist that includes EU database registration as a mandatory gate before any high-risk AI system (Annex III, excluding point 2) is released to market. Assign a dedicated compliance officer or authorised representative to manage and maintain registration records.

Source text: “Before placing on the market or putting into service an AI system for which the provider has concluded that it is not high-risk according to Article 6(3), that provider or, where applicable, the authorised representative shall register themselves and that system in the EU database referred to in Article 71.”

In practice: Providers who invoke the Article 6(3) derogation to classify their system as non-high-risk should document their assessment thoroughly and ensure EU database registration is completed before market placement, as this registration is mandatory regardless of the non-high-risk conclusion.

Source text: “For high-risk AI systems referred to in points 1, 6 and 7 of Annex III, in the areas of law enforcement, migration, asylum and border control management, the registration referred to in paragraphs 1, 2 and 3 of this Article shall be in a secure non-public section of the EU database referred to in Article 71 and shall include only the following information, as applicable, referred to in: Only the Commission and national authorities referred to in Article 74(8) shall have access to the respective restricted sections of the EU database listed in the first subparagraph of this paragraph.”

In practice: Organisations deploying AI systems in law enforcement, migration, asylum, or border control must ensure their EU database registrations are submitted to the secure non-public section and include only the information fields specified in Annex VIII Sections A (points 1-10 excl. 6,8,9), B (points 1-5, 8, 9), and C (points 1-3). Implement strict access controls to ensure only authorised authorities can view these entries.

Source text: “High-risk AI systems referred to in point 2 of Annex III shall be registered at national level.”

In practice: For AI systems falling under Annex III point 2, identify the relevant national competent authority in each Member State where the system will be deployed and ensure national-level registration is completed before use. Maintain records of national registrations separately from EU database registrations.

Source text: “Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. This obligation shall not apply to AI systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties, unless those systems are available for the public to report a criminal offence.”

In practice: Implement a clear, upfront disclosure mechanism (e.g., a banner, voice prompt, or on-screen message) at the start of any AI-human interaction. Document the rationale if you claim the 'obvious' exception, and maintain records of any law enforcement authorisation relied upon.

Source text: “Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated. Providers shall ensure their technical solutions are effective, interoperable, robust and reliable as far as this is technically feasible, taking into account the specificities and limitations of various types of content, the costs of implementation and the generally acknowledged state of the art, as may be reflected in relevant technical standards. This obligation shall not apply to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data provided by the deployer or the semantics thereof, or where authorised by law to detect, prevent, investigate or prosecute criminal offences.”

In practice: Implement technical watermarking or metadata-based provenance marking (e.g., C2PA standards) in your AI output pipeline. Ensure the solution is interoperable with industry standards and document why any exception (assistive editing, law enforcement) applies.

Source text: “The information referred to in paragraphs 1 to 4 shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposure. The information shall conform to the applicable accessibility requirements.”

In practice: Configure your AI system's disclosure mechanism to trigger automatically at the very first user interaction or exposure event. Ensure the disclosure meets accessibility standards (e.g., WCAG, EU Web Accessibility Directive) including for users with disabilities.

Source text: “A general-purpose AI model shall be classified as a general-purpose AI model with systemic risk if it meets any of the following conditions:”

In practice: Providers of general-purpose AI models should proactively assess their model's capabilities against published benchmarks and indicators. Maintain documentation of capability evaluations and monitor for Commission decisions or scientific panel alerts that could trigger systemic risk classification.

Source text: “A general-purpose AI model shall be presumed to have high impact capabilities pursuant to paragraph 1, point (a), when the cumulative amount of computation used for its training measured in floating point operations is greater than 1025.”

In practice: Providers training large AI models should track and document the total cumulative floating point operations used across all training phases (pre-training, fine-tuning, synthetic data generation). If the 10^25 FLOP threshold is approached or exceeded, initiate the notification process to the AI Office without delay.

Source text: “Where a general-purpose AI model meets the condition referred to in Article 51(1), point (a), the relevant provider shall 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. That notification shall include the information necessary to demonstrate that the relevant requirement has been met. If the Commission becomes aware of a general-purpose AI model presenting systemic risks of which it has not been notified, it may decide to designate it as a model with systemic risk.”

In practice: Establish an internal monitoring process to track compute thresholds and model capability benchmarks. Set up an automated alert when training FLOPs approach the Article 51(1)(a) threshold so the legal team can prepare the notification package well before the two-week deadline.

Source text: “Providers of general-purpose AI models shall:”

In practice: Establish automated documentation workflows that capture training processes, model evaluations, and copyright compliance measures. Create standardized information packages for downstream providers and implement copyright scanning tools to identify and respect reservation of rights.

Source text: “Providers of general-purpose AI models shall cooperate as necessary with the Commission and the national competent authorities in the exercise of their competences and powers pursuant to this Regulation.”

In practice: Establish clear points of contact and procedures for responding to regulatory requests. Maintain readily accessible documentation and designate staff authorized to engage with authorities on compliance matters.

Source text: “Providers of general-purpose AI models may rely on codes of practice within the meaning of Article 56 to demonstrate compliance with the obligations set out in paragraph 1 of this Article, until a harmonised standard is published. Compliance with European harmonised standards grants providers the presumption of conformity to the extent that those standards cover those obligations. Providers of general-purpose AI models who do not adhere to an approved code of practice or do not comply with a European harmonised standard shall demonstrate alternative adequate means of compliance for assessment by the Commission.”

In practice: Monitor the development of industry codes of practice and harmonised standards. If not following established frameworks, document alternative compliance measures thoroughly and prepare for Commission assessment.

Source text: “Prior to placing a general-purpose AI model on the Union market, providers established in third countries shall, by written mandate, appoint an authorised representative which is established in the Union.”

In practice: Third-country providers should identify and formally appoint an EU-based legal entity or individual as their authorised representative before any market launch, ensuring the mandate is in writing and covers all required tasks under Article 54.

Source text: “The provider shall enable its authorised representative to perform the tasks specified in the mandate received from the provider.”

In practice: Providers should establish clear internal procedures, grant access to relevant documentation, and provide ongoing support so that the authorised representative can effectively perform all mandated tasks without obstruction.

Source text: “The mandate shall empower the authorised representative to be addressed, in addition to or instead of the provider, by the AI Office or the competent authorities, on all issues related to ensuring compliance with this Regulation.”

In practice: Ensure the written mandate explicitly grants the authorised representative authority to receive and respond to all official communications from the AI Office and national competent authorities, and establish internal escalation procedures so the representative can act promptly on behalf of the provider.

Source text: “In addition to the obligations listed in Articles 53 and 54, providers of general-purpose AI models with systemic risk shall:”

In practice: Establish a dedicated systemic risk management programme that includes scheduled adversarial testing protocols, a risk register covering Union-level systemic risks, and an incident reporting pipeline with defined escalation paths to the AI Office and relevant national authorities. Document all evaluations and corrective actions thoroughly.

Source text: “Providers of general-purpose AI models with systemic risk may rely on codes of practice within the meaning of Article 56 to demonstrate compliance with the obligations set out in paragraph 1 of this Article, until a harmonised standard is published. Compliance with European harmonised standards grants providers the presumption of conformity to the extent that those standards cover those obligations. Providers of general-purpose AI models with systemic risks who do not adhere to an approved code of practice or do not comply with a European harmonised standard shall demonstrate alternative adequate means of compliance for assessment by the Commission.”

In practice: Actively participate in the development of codes of practice facilitated by the AI Office and monitor the publication of relevant harmonised standards. If neither a code of practice nor a harmonised standard is available or chosen, prepare documented alternative compliance evidence for Commission assessment, such as internal audit reports, third-party assessments, or technical specifications.

Source text: “The AI Office and the Board shall aim to ensure that the codes of practice cover at least the obligations provided for in Articles 53 and 55, including the following issues:”

In practice: Providers of general-purpose AI models should prepare documentation covering training data summaries and systemic risk identification processes in anticipation of code of practice requirements, aligning with Articles 53 and 55 obligations.

Source text: “The AI Office shall aim to ensure that participants to the codes of practice report regularly to the AI Office on the implementation of the commitments and the measures taken and their outcomes, including as measured against the key performance indicators as appropriate. Key performance indicators and reporting commitments shall reflect differences in size and capacity between various participants.”

In practice: Organisations participating in codes of practice should establish internal reporting mechanisms to track KPI performance and commitment implementation, ensuring reports are proportionate to their size and capacity and submitted to the AI Office on a regular basis.

Source text: “AI regulatory sandboxes established under paragraph 1 shall provide for a controlled environment that fosters innovation and facilitates the development, training, testing and validation of innovative AI systems for a limited time before their being placed on the market or put into service pursuant to a specific sandbox plan agreed between the providers or prospective providers and the competent authority. Such sandboxes may include testing in real world conditions supervised therein.”

In practice: Providers seeking to enter a sandbox should prepare a detailed sandbox plan covering the AI system's intended purpose, testing methodology, risk mitigation measures, timeline, and data governance arrangements before approaching the competent authority.

Source text: “Providers and prospective providers participating in the AI regulatory sandbox shall remain liable under applicable Union and national liability law for any damage inflicted on third parties as a result of the experimentation taking place in the sandbox. However, provided that the prospective providers observe the specific plan and the terms and conditions for their participation and follow in good faith the guidance given by the national competent authority, no administrative fines shall be imposed by the authorities for infringements of this Regulation. Where other competent authorities responsible for other Union and national law were actively involved in the supervision of the AI system in the sandbox and provided guidance for compliance, no administrative fines shall be imposed regarding that law.”

In practice: Sandbox participants should document all guidance received from competent authorities and maintain records of their adherence to the sandbox plan and terms, as this documentation will be critical evidence of good faith compliance if any regulatory infringement is alleged.

Source text: “In the AI regulatory sandbox, personal data lawfully collected for other purposes may be processed solely for the purpose of developing, training and testing certain AI systems in the sandbox when all of the following conditions are met:”

In practice: Establish a documented legal basis for further processing under Article 6(4) GDPR, implement a Data Protection Impact Assessment (DPIA) aligned with Article 35 GDPR, and deploy real-time monitoring dashboards to detect and mitigate risks to data subjects during sandbox experimentation.

Source text: “Paragraph 1 is without prejudice to Union or national law which excludes processing of personal data for other purposes than those explicitly mentioned in that law, as well as to Union or national law laying down the basis for the processing of personal data which is necessary for the purpose of developing, testing or training of innovative AI systems or any other legal basis, in compliance with Union law on the protection of personal data.”

In practice: When relying on Article 59(1) for sandbox processing, verify that no applicable Union or national law explicitly excludes such further processing; also check whether an alternative legal basis under GDPR (e.g., Article 6(1)(e) or Article 9(2)(g)) may be more appropriate and document the chosen basis clearly.

Source text: “The testing of high-risk AI systems in real world conditions under this Article shall be without prejudice to any ethical review that is required by Union or national law.”

In practice: Before commencing real-world testing, check whether applicable Union or national law (e.g., research ethics regulations, clinical trial rules) requires an independent ethical review and obtain that approval in addition to the Article 60 regulatory approvals.

Source text: “Providers or prospective providers may conduct the testing in real world conditions only where all of the following conditions are met:”

In practice: Submit the real-world testing plan to the competent market surveillance authority well in advance of the planned testing start date; track the 30-day approval window and check whether national law provides for tacit approval or requires explicit authorisation. Register the testing in the EU database (or secure non-public section for law enforcement/migration/asylum/border control systems) before commencing.

Source text: “Any subjects of the testing in real world conditions, or their legally designated representative, as appropriate, may, without any resulting detriment and without having to provide any justification, withdraw from the testing at any time by revoking their informed consent and may request the immediate and permanent deletion of their personal data. The withdrawal of the informed consent shall not affect the activities already carried out.”

In practice: Implement a clear and accessible consent withdrawal mechanism before testing begins, and establish a documented process for immediate and permanent deletion of personal data upon withdrawal request; ensure that withdrawal does not trigger any negative consequences for the subject and that the process is communicated clearly in the testing information sheet.

Source text: “Any serious incident identified in the course of the testing in real world conditions shall be reported to the national market surveillance authority in accordance with Article 73. The provider or prospective provider shall adopt immediate mitigation measures or, failing that, shall suspend the testing in real world conditions until such mitigation takes place, or otherwise terminate it. The provider or prospective provider shall establish a procedure for the prompt recall of the AI system upon such termination of the testing in real world conditions.”

In practice: Establish a documented incident response and recall procedure before commencing real-world testing. Define clear thresholds for what constitutes a 'serious incident' and assign responsible personnel to trigger reporting and mitigation actions immediately upon detection.

Source text: “Providers or prospective providers shall notify the national market surveillance authority in the Member State where the testing in real world conditions is to be conducted of the suspension or termination of the testing in real world conditions and of the final outcomes.”

In practice: Implement a formal notification workflow that automatically triggers communication to the relevant national market surveillance authority whenever real-world testing is suspended, terminated, or concluded. Document final outcomes in a structured report.

Source text: “The provider or prospective provider shall be liable under applicable Union and national liability law for any damage caused in the course of their testing in real world conditions.”

In practice: Before commencing real-world testing, conduct a legal review of applicable Union and national liability frameworks. Consider obtaining appropriate insurance coverage and establishing contractual indemnification arrangements with deployers and other parties involved in the testing.

Source text: “For the purpose of testing in real world conditions under Article 60, freely-given informed consent shall be obtained from the subjects of testing prior to their participation in such testing and after their having been duly informed with concise, clear, relevant, and understandable information regarding:”

In practice: Develop a standardised informed consent form for real-world testing that clearly explains the AI system's purpose, testing duration, potential inconveniences, and the subject's right to withdraw at any time without justification or detriment. Have legal counsel review the form to ensure it meets the 'freely given' and 'informed' standards.

Source text: “The informed consent shall be dated and documented and a copy shall be given to the subjects of testing or their legal representative.”

In practice: Implement a consent management process that timestamps and archives all consent records, and automatically generates a copy for the subject or their legal representative. Store records securely and ensure they are retrievable for audit purposes by market surveillance authorities.

Source text: “Paragraph 1 of this Article shall not be interpreted as exempting those operators from fulfilling any other requirements or obligations laid down in this Regulation, including those established in Articles 9, 10, 11, 12, 13, 14, 15, 72 and 73.”

In practice: Microenterprises must not interpret the simplified QMS derogation as a general exemption. Maintain full compliance with all substantive obligations under Articles 9, 10, 11, 12, 13, 14, 15, 72, and 73, and build these into operational processes even when using a simplified QMS structure.

Source text: “Providers shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.”

In practice: Create a dedicated post-market monitoring policy document that maps the monitoring intensity to the risk level of each AI system. For lower-risk high-risk AI systems, a lighter monitoring cadence may suffice, while higher-risk systems should have more frequent and rigorous monitoring protocols.

Source text: “The post-market monitoring system shall actively and systematically collect, document and analyse relevant data which may be provided by deployers or which may be collected through other sources on the performance of high-risk AI systems throughout their lifetime, and which allow the provider to evaluate the continuous compliance of AI systems with the requirements set out in Chapter III, Section 2. Where relevant, post-market monitoring shall include an analysis of the interaction with other AI systems. This obligation shall not cover sensitive operational data of deployers which are law-enforcement authorities.”

In practice: Implement automated data pipelines to collect performance metrics from deployed AI systems, and establish a structured process for deployers to submit performance feedback. Ensure your data collection framework explicitly excludes sensitive operational data from law enforcement deployers and document this exclusion in your monitoring plan.

Source text: “The post-market monitoring system shall be based on a post-market monitoring plan. The post-market monitoring plan shall be part of the technical documentation referred to in Annex IV. The Commission shall adopt an implementing act laying down detailed provisions establishing a template for the post-market monitoring plan and the list of elements to be included in the plan by 2 February 2026. That implementing act shall be adopted in accordance with the examination procedure referred to in Article 98(2).”

In practice: Begin drafting your post-market monitoring plan now using the structure of Annex IV as a guide, and monitor the Commission's publication of the implementing act template expected by 2 February 2026. Ensure your technical documentation framework is flexible enough to incorporate the template once published.

Source text: “For high-risk AI systems covered by the Union harmonisation legislation listed in Section A of Annex I, where a post-market monitoring system and plan are already established under that legislation, in order to ensure consistency, avoid duplications and minimise additional burdens, providers shall have a choice of integrating, as appropriate, the necessary elements described in paragraphs 1, 2 and 3 using the template referred in paragraph 3 into systems and plans already existing under that legislation, provided that it achieves an equivalent level of protection. The first subparagraph of this paragraph shall also apply to high-risk AI systems referred to in point 5 of Annex III placed on the market or put into service by financial institutions that are subject to requirements under Union financial services law regarding their internal governance, arrangements or processes.”

In practice: If your high-risk AI system falls under existing Union harmonisation legislation with an established post-market monitoring system, conduct a gap analysis to determine which additional elements from Article 72 paragraphs 1-3 need to be integrated. Document the integration decision and demonstrate that the combined system achieves equivalent protection to a standalone AI Act monitoring system.

Source text: “Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred.”

In practice: Establish an internal incident classification procedure that identifies when an event qualifies as a 'serious incident' under the AI Act, and maintain a registry of relevant market surveillance authority contacts per Member State where your AI system is deployed.

Source text: “The report referred to in paragraph 1 shall be made immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link, and, in any event, not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident. The period for the reporting referred to in the first subparagraph shall take account of the severity of the serious incident.”

In practice: Implement an internal escalation and triage process that starts the 15-day reporting clock from the moment any team member becomes aware of a potential serious incident, and document the causal link assessment as part of the incident record.

Source text: “Notwithstanding paragraph 2 of this Article, in the event of a widespread infringement or a serious incident as defined in Article 3, point (49)(b), the report referred to in paragraph 1 of this Article shall be provided immediately, and not later than two days after the provider or, where applicable, the deployer becomes aware of that incident.”

In practice: Create a separate fast-track reporting procedure for widespread infringements and fundamental rights-related incidents, with a 48-hour internal escalation trigger and pre-drafted notification templates ready for immediate submission to market surveillance authorities.

Source text: “Notwithstanding paragraph 2, in the event of the death of a person, the report shall be provided immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship between the high-risk AI system and the serious incident, but not later than 10 days after the date on which the provider or, where applicable, the deployer becomes aware of the serious incident.”

In practice: Establish a specific mortality-related incident protocol that triggers an immediate internal alert and initiates the reporting process as soon as a causal link to the AI system is suspected, with a hard deadline of 10 days from awareness.

Source text: “Following the reporting of a serious incident pursuant to paragraph 1, the provider shall, without delay, perform the necessary investigations in relation to the serious incident and the AI system concerned. This shall include a risk assessment of the incident, and corrective action. The provider shall cooperate with the competent authorities, and where relevant with the notified body concerned, during the investigations referred to in the first subparagraph, and shall not perform any investigation which involves altering the AI system concerned in a way which may affect any subsequent evaluation of the causes of the incident, prior to informing the competent authorities of such action.”

In practice: Establish a documented incident response procedure that separates the investigation workflow from any system modification pipeline. Ensure that any planned changes to the AI system post-incident are pre-cleared with the competent authority before implementation.

Source text: “For high-risk AI systems referred to in Annex III that are placed on the market or put into service by providers that are subject to Union legislative instruments laying down reporting obligations equivalent to those set out in this Regulation, the notification of serious incidents shall be limited to those referred to in Article 3, point (49)(c).”

In practice: Providers subject to sector-specific Union legislation with equivalent incident reporting requirements should map those obligations against Article 73 to confirm they qualify for this limitation, and document this assessment to demonstrate compliance to market surveillance authorities.

Source text: “For high-risk AI systems which are safety components of devices, or are themselves devices, covered by Regulations (EU) 2017/745 and (EU) 2017/746, the notification of serious incidents shall be limited to those referred to in Article 3, point (49)(c) of this Regulation, and shall be made to the national competent authority chosen for that purpose by the Member States where the incident occurred.”

In practice: Providers of AI systems embedded in medical devices should identify the national competent authority designated by each Member State for this purpose and establish a direct notification channel to that authority, ensuring notifications are scoped to Article 3(49)(c) incidents only.

Source text: “Without prejudice to the powers provided for under Regulation (EU) 2019/1020, and where relevant and limited to what is necessary to fulfil their tasks, the market surveillance authorities shall be granted full access by providers to the documentation as well as the training, validation and testing data sets used for the development of high-risk AI systems, including, where appropriate and subject to security safeguards, through application programming interfaces (API) or other relevant technical means and tools enabling remote access.”

In practice: Providers of high-risk AI systems should establish secure, auditable access mechanisms (e.g., dedicated API endpoints with access logging) to allow market surveillance authorities to inspect training, validation, and testing datasets without compromising security or intellectual property.

Source text: “Where, in the course of that evaluation, the market surveillance authority finds that the AI system concerned is high-risk, it shall without undue delay require the relevant provider to take all necessary actions to bring the AI system into compliance with the requirements and obligations laid down in this Regulation, as well as take appropriate corrective action within a period the market surveillance authority may prescribe.”

In practice: Providers should have a compliance readiness plan for high-risk AI requirements so that if reclassified, they can act swiftly within the authority-prescribed timeframe to avoid penalties.

Source text: “The provider shall ensure that all necessary action is taken to bring the AI system into compliance with the requirements and obligations laid down in this Regulation. Where the provider of an AI system concerned does not bring the AI system into compliance with those requirements and obligations within the period referred to in paragraph 2 of this Article, the provider shall be subject to fines in accordance with Article 99.”

In practice: Providers should immediately initiate compliance gap analyses upon receiving a reclassification notice and document all remediation steps taken to demonstrate good-faith efforts and avoid fines under Article 99.

Source text: “The provider shall ensure that all appropriate corrective action is taken in respect of all the AI systems concerned that it has made available on the Union market.”

In practice: Providers should maintain a comprehensive inventory of all AI systems placed on the Union market so that when corrective action is required, they can efficiently identify and remediate all affected systems, not just the one under evaluation.

Source text: “Where the provider of the AI system concerned does not take adequate corrective action within the period referred to in paragraph 2 of this Article, Article 79(5) to (9) shall apply.”

In practice: Providers should establish internal escalation protocols and timelines for responding to market surveillance authority requests; failure to act within the specified period triggers full Article 79 enforcement, including potential market withdrawal orders.

Source text: “Where, in the course of the evaluation pursuant to paragraph 1 of this Article, the market surveillance authority establishes that the AI system was misclassified by the provider as non-high-risk in order to circumvent the application of requirements in Chapter III, Section 2, the provider shall be subject to fines in accordance with Article 99.”

In practice: Providers must ensure their risk classification decisions are documented, objective, and defensible; intentional misclassification to avoid high-risk obligations constitutes a sanctionable infringement under Article 99 and should be treated as a serious compliance risk.

Source text: “The provider or other relevant operator shall ensure that corrective action is taken in respect of all the AI systems concerned that it has made available on the Union market within the timeline prescribed by the market surveillance authority of the Member State referred to in paragraph 1.”

In practice: Providers should maintain an up-to-date inventory of all AI systems placed on the Union market and establish a corrective action management process that can be triggered promptly upon receipt of a market surveillance authority directive, including tracking deadlines per system.