# EU AI Act — High-Risk AI System Obligations Reference All obligations below apply to **providers** unless stated otherwise. Annex III systems: applies from **2 August 2026**. Annex I safety component systems: applies from **2 August 2027**. --- ## Art. 9 — Risk Management System **Purpose:** Identify and mitigate risks to health, safety, and fundamental rights throughout the AI system lifecycle. **Requirements:** - Continuous, iterative process maintained from development through decommissioning - Must cover **all phases**: development, testing, pre-deployment assessment, post-market monitoring - **5-step process:** 1. Identify all known and reasonably foreseeable risks (normal use, reasonably foreseeable misuse) 2. Estimate and evaluate risks under all intended and reasonably foreseeable uses 3. Evaluate risks emerging from post-market monitoring data 4. Adopt appropriate and targeted risk mitigation measures (Art. 9(4)) 5. Assess residual risk acceptability; document reasoning - **Risk mitigation priority hierarchy (Art. 9(4)):** 1. Design-based risk elimination first 2. Adequate mitigation measures if elimination not possible 3. Information provision to deployers and users - **Testing (Art. 9(7)):** Before market placement; against pre-defined metrics and probabilistic thresholds; representative test data - **Under-18 impact:** Special attention required for systems likely to adversely impact minors **Documentation required:** Risk management system must be documented and form part of technical documentation (Art. 11, Annex IV). --- ## Art. 10 — Data and Data Governance **Purpose:** Ensure training, validation, and testing datasets are appropriate for the intended purpose. **Dataset requirements (Art. 10(2)):** - Relevant to intended purpose - Sufficiently representative of the persons/contexts the system will encounter - Free of errors (where appropriate) - Complete for the intended purpose - Statistically appropriate for target geographic, contextual, and behavioral population **Data governance practices (Art. 10(3)):** - Design choices documentation - Data collection method documentation - Data origin examination and documentation - Annotation, labeling, cleaning, enrichment, and aggregation procedures - Bias examination and identification - Gap identification in relevant properties **Special category data (Art. 10(5)) — bias detection exception:** Processing of special-category personal data (GDPR Art. 9) permitted ONLY when ALL conditions met: 1. No adequate alternative data source exists 2. Technical and organizational protections are in place (anonymization, pseudonymization where possible) 3. Access controls ensure minimum necessary access 4. No third-party data transfer 5. Data deleted upon completion of bias detection 6. Documented justification maintained --- ## Art. 11 — Technical Documentation **Who:** Providers (before market placement), kept up-to-date throughout lifecycle. **Content specified in Annex IV:** - General description: intended purpose, provider identity, version, interactions with other systems - Detailed description of elements and development process: training methodologies, design choices, algorithms, data used - Information about training data (including general description, origin, annotation procedures, design choices) - Assessment of the measures required to interpret outputs and enable human oversight - Detailed description of the system design (architecture, source code or training code access if applicable) - Validation and testing: procedures, applied metrics, performance benchmarks, testing datasets - Risk management system documentation (Art. 9) - Changes made to system over lifecycle - List of harmonised standards applied (or description of alternative solutions for conformity) - EU Declaration of Conformity **Retention:** 10 years after market placement or putting into service. --- ## Art. 12 — Record-Keeping / Automatic Logging **Who:** Providers must build in automatic logging capability; deployers must retain logs. **Provider obligations:** - High-risk systems must be capable of automatically generating event logs throughout operation - Logging capability enables post-deployment reconstruction of circumstances surrounding risks - For biometric identification: logs must enable identification of persons involved and circumstances **Deployer obligations (Art. 26(6)):** - Retain automatically generated logs for **minimum 6 months** from use, or as required by applicable Union/national law (whichever longer) - Public sector deployers: stricter retention may apply under public records obligations --- ## Art. 13 — Transparency and Provision of Information to Deployers **Purpose:** Enable deployers to understand and correctly use the AI system. **System design requirement:** High-risk AI systems must be designed with sufficient transparency for deployers to interpret outputs and use appropriately. **Instructions for use must include:** - Provider identity, address, registration data - System characteristics, capabilities, and intended purpose - Performance metrics: level of accuracy, robustness, cybersecurity - Known or foreseeable circumstances that may lead to risks - System performance for specific persons/groups - Specifications for input data (data types, formats, dimensions) - Information on changes made vs prior versions - Human oversight measures (Art. 14) and technical measures to enable oversight - Computational resources required; expected system lifetime - Description of logging mechanisms (Art. 12) - Any predetermined modifications or updates **Format:** Concise, complete, correct, clear, relevant; provided in digital and, where appropriate, physical format; accessible to deployers in appropriate language. --- ## Art. 14 — Human Oversight **Purpose:** Enable effective human monitoring during operation to identify and correct AI errors. **System design obligations (providers, Art. 14(3)):** High-risk AI systems must be designed to allow natural persons to: - Understand system capabilities and limitations - Recognize **automation bias** (over-reliance on AI outputs) - Correctly interpret AI outputs (including interpretability features) - Decide not to use, or disregard, override, or reverse AI outputs - Intervene through a **stop button** or similar interrupt mechanism **Deployer implementation obligations (Art. 14(4)):** - Assign human oversight to natural persons with necessary competence, authority, and resources - Train oversight persons on system capabilities/limitations and automation bias risk **Biometric identification specific (Art. 14(5)):** - Minimum **two separate persons** must independently verify and confirm identification before action is taken **Proportionality:** Oversight measures are built in by providers proportionate to risks and level of autonomy; deployers may need to supplement with organizational measures. --- ## Art. 15 — Accuracy, Robustness, and Cybersecurity **Accuracy:** - System must achieve appropriate accuracy levels for intended purpose throughout its lifecycle - Declared accuracy levels and metrics must be in instructions for use (Art. 13) - Training, validation, and testing data must be statistically appropriate to achieve declared levels **Robustness:** - Resilience against errors, faults, or inconsistencies during operation and foreseeable misuse - Consistent performance throughout operational lifetime - Where appropriate: technical redundancy solutions, backup plans, fail-safe mechanisms - For continuous learning systems: eliminate/reduce risks of feedback loops amplifying biased outputs **Cybersecurity:** Resilience against attempts to alter use, outputs, or performance, including: - **Data poisoning attacks** (contaminating training data) - **Model poisoning attacks** (manipulating model weights) - **Adversarial examples** (crafted inputs causing misclassification) - **Confidentiality attacks** (extracting training data or model internals) - **Model flaws exploitation** (taking advantage of design weaknesses) **Technical solutions appropriate to context:** Air-gapping sensitive components, adversarial testing, input validation, output monitoring. --- ## Art. 16 — Provider Obligations (Complete 12-Item Checklist) Before placing on market or putting into service, providers must: 1. ☐ Ensure system complies with Section 2 requirements (Arts. 9–15) 2. ☐ Display name, trademark, and contact address on system, packaging, or documentation 3. ☐ Establish and implement quality management system (Art. 17) 4. ☐ Keep technical documentation (Art. 11, Annex IV) 5. ☐ Retain automatically generated logs (Art. 12) where under provider's control 6. ☐ Complete required conformity assessment (Art. 43) before market placement 7. ☐ Draw up EU Declaration of Conformity (Art. 47) 8. ☐ Affix CE marking (Art. 48) 9. ☐ Register in EU AI database (Art. 49) before market placement 10. ☐ Take immediate corrective action for non-conforming systems; notify authorities and deployers (Art. 20) 11. ☐ Demonstrate conformity upon request of national competent authority 12. ☐ Ensure accessible design where required (Directives 2016/2102, 2019/882) --- ## Art. 17 — Quality Management System (13 Required Components) Documented policies and procedures covering: 1. **Regulatory compliance strategy** including conformity assessment procedures and modifications management 2. **Design techniques** — procedures for designing, controlling, and verifying the AI system 3. **Development quality control** procedures 4. **Testing and validation** — before, during, and after development 5. **Technical standards application** — harmonised standards and common specifications 6. **Data management** — acquisition, labeling, storage, filtering, retention, cleaning procedures 7. **Risk management** per Art. 9 8. **Post-market monitoring** per Art. 72 9. **Serious incident reporting** per Art. 73 — communication with national authorities 10. **Authority communication** procedures for corrective actions and recalls (Art. 20) 11. **Record-keeping and documentation** — retention periods and access procedures 12. **Resource management** including supply-chain security measures 13. **Accountability framework** — clear responsibility assignment for all above components **Proportionality:** QMS must be proportionate to provider organization size. Existing sectoral QMS may be adapted/integrated. --- ## Art. 26 — Deployer Obligations 1. **Instructions compliance:** Use system in accordance with provider's instructions for use (Art. 13) 2. **Staff assignment:** Assign human oversight to persons with necessary competence, training, authority, and resources 3. **Input data control:** Where deployer controls input data — ensure it is relevant and sufficiently representative 4. **Continuous monitoring:** Monitor operations; if risk identified — notify provider/importer/distributor AND market surveillance authority; suspend use where appropriate 5. **Serious incidents:** Immediately notify provider, then importer/distributor and market surveillance authority 6. **Log retention:** Retain automatically generated logs for **at least 6 months** 7. **Worker notification:** In employment/worker management contexts — inform workers and representatives before deployment 8. **Public authority registration:** Public authorities must register use in EU AI database (Art. 60) before deployment; cannot use unregistered high-risk systems 9. **GDPR:** Conduct data protection impact assessments where required under GDPR Art. 35 10. **Fundamental Rights Impact Assessment:** Required for public authorities before deploying certain high-risk systems under Art. 27 --- ## Arts. 43–49 — Conformity Assessment and CE Marking ### Art. 43 — Conformity Assessment Paths **Annex III — Point 1 Systems (Biometrics):** Provider chooses between: - **(A) Self-assessment** — Internal control via Annex VI procedure; OR - **(B) Notified body** — Third-party assessment under Annex VII (QMS review + technical documentation assessment) Notified body (B) is **mandatory** when: - No harmonised standards covering the system exist - Standards exist but provider has not applied them (or only partially) - Common specifications are unavailable or not used - Standards published with restrictions that limit presumption of conformity **Annex III — Points 2–8 Systems (Areas 2–8):** Self-assessment only — no notified body assessment available. **Annex I Products (safety components):** Conformity assessment integrated into the existing conformity procedure for the product under Annex I legislation. **Law enforcement / immigration / EU institutions:** Market surveillance authority acts as notified body. **Substantial modifications:** Require full reassessment; except predetermined learning modifications documented in original technical file and declared in conformity declaration. ### Art. 47 — EU Declaration of Conformity - Drawn up by provider (or authorised representative); provider assumes full responsibility - Must confirm compliance with all applicable AI Act requirements (Section 2) - Must identify: system name, provider, version, intended purpose, conformity assessment procedure followed, standards applied - Machine-readable format; translation required into languages required by national authorities - Maintained for **10 years** from market placement ### Art. 48 — CE Marking - Visible, legible, indelible affixation on system, packaging, or documentation - Only affixed after successful conformity assessment and drawing up of EU Declaration of Conformity - Subject to general principles of CE marking (Regulation 765/2008) - Affixed before market placement; re-affixed if system substantially modified ### Arts. 49 and 60 — EU AI Database Registration **Provider registration (Art. 49):** - Before market placement (Annex III systems — Art. 6(2)) - Information includes: provider/representative identity; system description, intended purpose, accuracy; conformity assessment procedure; CE marking notified body (if applicable) - Provider registration covers all deployers and users of that system **Public authority deployer registration (Art. 60):** - Before deployment of registered high-risk systems - Additional system-specific information for public authority use **Database operation:** Operational from 2 August 2026 (Commission responsibility, Art. 71). **Publicly accessible information vs. restricted:** Most information public; some law enforcement/immigration information accessible only to competent authorities. --- ## Art. 27 — Fundamental Rights Impact Assessment (FRIA) **Who:** Public authorities and bodies deploying high-risk AI systems in Annex III Areas 1, 2, 4, 5(b–d), 6, 7, and 8. **Content:** - Description of the deployer's processes in which the system will be used - Time period, frequency, and number of persons affected - The specific categories of persons likely to be affected - Specific risks of harm to categories of affected persons - Human oversight measures (Art. 14) planned - Measures to address fundamental rights risks **Relationship to GDPR DPIA:** Where GDPR DPIA is also required, the FRIA may be conducted alongside or integrated into the DPIA.