# EU AI Act obligations for high-risk systems What a high-risk AI system must meet, what its provider and its deployers must do, and the evidence a market surveillance authority asks for. Source: https://sted.digital/docs/standards/eu-ai-act/high-risk-obligations · Last reviewed 17 October 2026 · Strand Standards and regulations A high-risk AI system must meet EU AI Act Articles 9 to 15 (risk management, data governance, Annex IV technical documentation, logging, information for deployers, human oversight, accuracy and security). Its provider meets Articles 16 and 17 and passes a conformity assessment (Article 43); deployers meet Articles 26 and 27. These apply from 2 December 2027 or 2 August 2028. ## The requirement in plain English **What the system must meet.** The provider designs the system so that: - a risk management process runs across its whole life, identifies foreseeable risks including misuse, and tests the system against set metrics before release (EU AI Act Article 9); - training, validation and test data are governed for relevance, representativeness, errors and bias (EU AI Act Article 10); - technical documentation covering at least Annex IV exists before release and stays current; small and mid-cap firms may use the Commission's simplified form (EU AI Act Article 11); - it records events automatically so its working can be traced (EU AI Act Article 12); - deployers get instructions for use that state its purpose, accuracy, limits and risks (EU AI Act Article 13); - people can oversee it effectively, understand its limits, resist over-reliance, override it and stop it (EU AI Act Article 14); - it achieves an appropriate level of accuracy, robustness and cybersecurity: resilient to errors and faults, and secure against attacks such as data poisoning and adversarial inputs (EU AI Act Article 15). **What the provider must do.** EU AI Act Article 16 lists the duties. The main ones are a documented quality management system (EU AI Act Article 17), proportionate to the provider's size, which the 2026 amendment spells out for small and mid-cap firms; keeping the documentation for 10 years (EU AI Act Article 18) and its logs for at least six months (EU AI Act Article 19); a conformity assessment before release (EU AI Act Article 43); a signed EU declaration of conformity (EU AI Act Article 47); the CE marking (EU AI Act Article 48); and registration in the EU database for Annex III systems (EU AI Act Article 49). A provider outside the EU appoints an authorised representative in it (EU AI Act Article 22). After release, the provider runs post-market monitoring (EU AI Act Article 72) and reports serious incidents within 15 days of becoming aware, two days for a widespread infringement or critical-infrastructure disruption, and 10 days for a death (EU AI Act Article 73). For most Annex III systems the conformity assessment is internal control: the provider checks itself against the requirements. Remote biometric systems can need a notified body. A system inside an Annex I product, such as a medical device, is assessed inside that product's own procedure, with one technical file. **What the deployer must do (EU AI Act Article 26).** Use the system as the instructions say; give oversight to people with the competence, authority and support to exercise it; keep input data relevant where you control it; monitor the system and tell the provider and the authority about risks and serious incidents; keep the logs you control for at least six months; and tell workers' representatives and affected workers before using it at work. People subject to a decision made with an Annex III system must be told so. **Fundamental rights impact assessment (EU AI Act Article 27).** Public bodies, private organisations providing public services, and deployers using credit scoring or life and health insurance pricing assess the system's impact on fundamental rights before first use and notify the results to the market surveillance authority. It can build on a [data protection impact assessment](/docs/standards/gdpr/dpias). This is guidance to help you understand the requirement, not legal advice. ## What good looks like A 40-person consumer lender builds its own credit-scoring model. That makes it the provider and, because it uses the model, a deployer too, and credit scoring brings in the fundamental rights impact assessment. It runs the work inside its existing management system. The head of data owns the risk management file, updated at each model release. Each training dataset has a data sheet covering source, period, known gaps and the bias checks run. The technical file follows Annex IV section by section and is versioned with the model. Oversight is designed, not assumed. Two credit officers review every decline the model recommends near the cut-off, see the top factors behind each score, and can override it; their overrides are logged and reviewed monthly for signs of over-reliance. Logs are kept for two years, the period the lender's complaints process needs. Before release the compliance lead runs the internal-control conformity assessment, the CEO signs the declaration, and the system is registered. The impact assessment is done once, reviewed at each major release, and its summary is notified to the authority. Post-market monitoring tracks approval rates by group every quarter. ## Evidence an auditor expects - **Technical documentation** (required, Annex IV): the market surveillance authority checks it matches the system version on the market. - **Risk management file** (required): known and foreseeable risks, test results against the set metrics, and the residual risk judgement. - **Data governance records** (required): how each dataset was chosen, prepared and checked for bias. - **Instructions for use** (required): accuracy figures, limits and oversight measures written for deployers, not marketing. - **Quality management system documents** (required): written policies, procedures and instructions covering each Article 17 point. - **Conformity assessment, declaration and registration** (required): the assessment record, the signed declaration and the EU database entry. - **Deployer records**: oversight assignments and training, retained logs, worker notices, and the impact assessment with its notification where Article 27 applies. ## Common mistakes ### Oversight on paper only Naming a human reviewer is not oversight if they approve 400 decisions an hour. Article 14 expects people who understand the system's limits and have the time and authority to override it. Measure override rates and review time. ### Instructions for use written as a brochure Deployers need the accuracy metrics, the groups the system performs worse for, and the conditions it was not tested in. A vague document leaves both parties exposed. ### Assuming the provider keeps every log Deployers must keep the logs under their own control. Agree with the provider who holds what, and check retention in your hosting settings. ### Missing the impact assessment as a private firm Lenders and insurers often assume Article 27 is for the public sector. Credit scoring and life and health insurance pricing bring private deployers in. ### Changing the model without reassessing A substantial modification needs a new conformity assessment. Define in the technical file which changes were planned in advance and which would count as substantial. ### Building a second quality system Article 17 does not need a separate system. An existing ISO 42001, ISO 13485 or ISO 9001 system can carry it if every Article 17 point is covered. ## How Sted helps For each high-risk AI system Sted's knowledge base carries an EU AI Act High-Risk Conformity Record (REC-AIHC), under the AI System Lifecycle Procedure (PRC-AISL), recording the role held, the conformity assessment and its outcome, the declaration of conformity and CE marking, where the Annex IV technical documentation is held and how it is maintained, and the EU database registration. Records are part of the Full Management System plan. Under the AI System Lifecycle Procedure (PRC-AISL) Sted's knowledge base carries a record for each stage of an AI system's life, the AI Development Plan (REC-AIDP), Dataset Record (REC-DSET), Experiment Record (REC-AIER), Model Evaluation Report (REC-AIME), Bias and Fairness Assessment Record (REC-AIBF), Deployment Readiness and Integration Test Record (REC-AIDR), Post-Deployment Monitoring Plan (REC-PDMP) and Post-Deployment Monitoring Record (REC-AIPD), tagged to the ISO 42001 Annex A lifecycle, data and resource controls. Records are part of the Full Management System plan. Sted's knowledge base holds seven record templates under the Incident Management Procedure (PRC-IMP), among them the Information Security Incident Record (REC-ISI), the Data Protection Incident Record (REC-DPI), the Cardholder Data Incident Record (REC-CDI), the Medical Device Incident Record (REC-MDI), the AI / Algorithmic Incident Record (REC-AII) and the Incident Response Plan Test Record (REC-IRPT), which comes with a suggested annual frequency. Records are part of the Full Management System plan. Sted holds the conformity record and the lifecycle evidence. It does not run the conformity assessment, register the system or report an incident; the provider does. ## Related guides and terms - [Risk classification](/docs/standards/eu-ai-act/risk-classification): how to know the system is high-risk in the first place. - [ISO 42001 operation and the AI system lifecycle](/docs/standards/iso-42001/ai-system-lifecycle): the management controls that carry most of this work. - [GDPR DPIAs](/docs/standards/gdpr/dpias): the data protection assessment a fundamental rights impact assessment can build on. - [ISO 27001](/docs/standards/iso-27001): the security management system that supports the Article 15 cybersecurity requirement. - [Incident response guide](/docs/guides/incident-response-and-breach-notification): handling an incident before the serious-incident clock runs out. - [EU AI Act timeline](/docs/standards/eu-ai-act/timeline): when these duties apply to your system. ## Frequently asked questions Q: Does every deployer of high-risk AI need a fundamental rights impact assessment? A: No. EU AI Act Article 27 requires it from public bodies, private organisations providing public services, and any deployer using a system to score creditworthiness or to price life and health insurance. It is done before first use and its results are notified to the market surveillance authority; an existing data protection impact assessment can supply part of it. Q: How long must logs from a high-risk AI system be kept? A: At least six months, unless another law, such as data protection law, sets something different. The duty falls on the provider for logs under its control (EU AI Act Article 19) and on the deployer for logs under its own control (EU AI Act Article 26). Keep them longer where your own incident or audit needs require it.