High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.
See what to build, what to document and what to check during use under Articles 8-16 and 26.
For a , Articles 8-15 set the system requirements, Article 16 assigns provider duties, and Article 26 sets deployer duties. Start with the correct classification, sector rules and application date, then use the evidence lists below.
Check the product-law route before assigning duties. Annex I Section A products may need both AI Act high-risk controls and sector-law controls. Section B products follow amended Article 2(2): only Article 6(1), Article 60a and Articles 102-112 apply directly. Articles 57-59 apply only where high-risk requirements have been integrated into sector law.
For Section A, an Article 2(13) limitation needs an applicable delegated act; existing sector controls alone do not establish an exemption.
Article 8 is the gateway: high-risk AI systems must comply with the requirements in Section 2, taking account of the system's intended purpose and the state of the art.
For product-regulated systems, the AI Act requirements can be integrated with existing product documentation and testing where the product is also covered by Union harmonisation legislation.
Article 16 then turns those requirements into provider obligations. The provider must meet Section 2 requirements, identify itself on the system or accompanying documentation, and maintain quality management. Keep required documentation and logs under provider control. Complete the assessment, declaration, CE marking and registration where required.
Take corrective action, demonstrate conformity to authorities and meet applicable accessibility requirements.
For systems supplied or first used before their Chapter III application date, amended Article 111(2) applies the high-risk operator rules only if significant design changes occur from that date. Annex X large-scale IT systems follow the separate rule in Article 111(1).
Chapter III Sections 1-3, except Article 6(5), apply from 2 December 2027 for Article 6(2) Annex III systems and 2 August 2028 for Article 6(1) Annex I systems.
This transition rule uses a different test from the Article 43 substantial-modification rule that reopens conformity assessment, so record the first placement or service date, type and model, change description, and legal test instead of treating every software update alike.
Article 111(2) also requires providers and deployers of high-risk systems intended for public-authority use to take the necessary steps to comply by 2 August 2030.
Article 17 governs the provider quality management system alongside the Section 2 system requirements. EN 18286:2026 was cited in the Official Journal on 14 October 2026. Its presumption of conformity is limited to covered requirements and Annex ZA conditions; keep separate evidence for uncovered obligations and for the system requirements in Articles 8-15.
Sources (5)
Supports the Article 8-16 high-risk AI requirements and provider obligations described in this section.
High-risk AI systems shall comply with the requirements laid down in this Section
Commission overview confirming that high-risk AI providers need risk assessment, dataset quality, logging, documentation, human oversight, robustness, cybersecurity, accuracy, conformity assessment, registration, declaration of conformity, and CE marking.
high level of robustness, cybersecurity and accuracy
Supports the revised Chapter III application dates, amended Article 111 transition rule, and Article 6 safety-component clarifications.
Article 1 and the Annex cite EN 18286:2026. Article 2 and recital 6 establish effect from publication on 14 October 2026, limited to requirements covered by the standard.
Official publication announcement identifying the Article 17 quality-management standard. Check Annex ZA in an authorised copy for detailed coverage conditions.
Start the technical file with the intended purpose and high-risk classification. Link each requirement to a design measure, test or procedure. Include the Annex IV material: system and development descriptions, data, monitoring, risks, validation, accuracy and robustness metrics, relevant discrimination testing, signed test logs, cybersecurity and monitoring after release.
Article 12 gives logging specific legal purposes. The system must technically allow automatic event recording over its lifetime, and the logs must be useful for identifying risk or substantial modification, supporting post-market monitoring, and enabling deployers to monitor operation under Article 26.
Providers and deployers should agree which logs are under each party's control, what retention rule applies, and how log access will work when a competent authority asks for evidence.
Sources (2)
Supports the technical documentation, data governance, testing, logging, and retention evidence required for high-risk AI systems.
The technical documentation shall be drawn up before that system is placed on the market
Identifies Commission-requested harmonised-standard areas that align with the requirements evidence, including risk management, data governance, record keeping, human oversight, accuracy, robustness, and cybersecurity.
risk management
Write instructions that let deployers operate the system correctly. Article 13 requires provider identity, intended purpose, capabilities and limits, accuracy metrics, robustness and cybersecurity information, foreseeable risks, output interpretation, input requirements, oversight, maintenance and log collection.
Article 14 requires oversight by natural persons with enough information and control to monitor the system, understand limitations, avoid automation bias, interpret outputs, disregard or reverse outputs, and interrupt the system where appropriate.
Article 15 requires the system to perform consistently at an appropriate level of accuracy, robustness, and cybersecurity throughout its lifecycle and to be resilient against AI-specific attacks such as data poisoning, model poisoning, adversarial examples, model evasion, confidentiality attacks, and model flaws.
Sources (2)
Supports the transparency, human oversight, accuracy, robustness, and cybersecurity requirements in Articles 13-15.
to interpret a system's output and use it appropriately
Provides standards-based support for practical AI cybersecurity evidence, including threat modelling, AI-specific attacks, documentation, testing, and monitoring.
Document data, models and prompts
If your organisation uses a high-risk system, follow the provider's instructions. Assign human oversight to people with the necessary competence, training, authority and support. Where you control input data, ensure it is relevant and sufficiently representative.
Deployers must monitor operation on the basis of the instructions for use. If use according to those instructions may result in a risk, the deployer must inform the provider or distributor and the relevant market surveillance authority without undue delay and suspend use.
If the deployer identifies a serious incident, it must immediately inform the provider first and then the importer or distributor and relevant market surveillance authorities. Deployers must also keep automatically generated logs under their control for an appropriate period, at least six months unless other Union or national law provides otherwise.
For financial institutions subject to Union financial-services governance requirements, Article 26(5) deems the monitoring obligation fulfilled through compliance with the relevant internal-governance arrangements, processes and mechanisms. Article 26(6) requires those institutions to maintain logs within their financial-services documentation.
Record the applicable regime and existing records rather than assuming the exception removes all deployer duties.
Sources (2)
Supports the Article 26 deployer duties for use according to instructions, human oversight, input data, monitoring, incident escalation, logs, workplace notice, registration, DPIA support, and notices to affected natural persons.
Deployers shall monitor the operation of the high-risk AI system
Commission overview supporting the operational split between providers, deployers, authorities, post-market monitoring, and serious-incident reporting.
deployers ensure human oversight and monitoring
Give every requirement a named owner, legal reference, system-specific measure and evidence link. Assign a reviewer who can check whether the evidence still matches the deployed version.
For suppliers and companies integrating models, request system-specific evidence. Request instructions, performance metrics, oversight design, log format, monitoring contacts, incident routes and relevant technical-file extracts. For third-party tools, services, components or processes integrated into a high-risk system, agree in writing who provides the information and technical access needed.
Confirm the high-risk classification and intended purpose, then map the system to Articles 8-15 before release and Article 16 provider duties. If the organization is deploying another provider's system, add Article 26 checks for instructions, human oversight, monitoring, input-data quality, logs, and incident escalation.
Keep technical documentation, data-governance records, risk management files, validation and testing reports, accuracy and robustness metrics, cybersecurity controls, instructions for use, quality management documentation, automatically generated logs under provider control, conformity assessment evidence, EU declaration of conformity, CE marking evidence where applicable, and registration evidence where Article 49 applies.
Keep the provider instructions, oversight assignments and training, input-data checks where the deployer controls input data, monitoring records, logs under deployer control for the required retention period, workplace or affected-person notices where applicable, registration checks for public-sector use, data protection impact assessment (DPIA) or fundamental rights impact assessment (FRIA) material where applicable, and incident notifications sent to the provider, distributor, importer, or authority.
Sources (2)
Supports the provider and deployer evidence pack across Articles 8-16, Article 26, Annex IV, conformity evidence, logging, and registration.
demonstrate the conformity of the high-risk AI system
Supports practical cybersecurity evidence for supplier, testing, monitoring, documentation, and AI-specific threat controls.
Monitor the system's behaviour
Check your provider evidence, supplier requests and deployer operating procedures with Sorena.
"High-risk AI systems shall comply with the requirements laid down in this Section"
"The technical documentation shall be drawn up before that system is placed on the market"
"to interpret a system's output and use it appropriately"
"Deployers shall monitor the operation of the high-risk AI system"
"demonstrate the conformity of the high-risk AI system"
"baseline security requirements for AI models and systems"
"Document data, models and prompts"
"Monitor the system's behaviour"
"The AI Act is the first-ever comprehensive legal framework on AI worldwide."
"high level of robustness, cybersecurity and accuracy"
"deployers ensure human oversight and monitoring"
"European harmonised standards serve several crucial functions"
"risk management"
Clear answers on AI Act scope, risk categories, provider and user duties, general-purpose models, disclosures, rights, assessments and deadlines.
Find the AI Act deadline for your system or model. Check high-risk dates, transparency duties, older-model transitions and the evidence to prepare.
Check who needs an Article 27 fundamental rights impact assessment, what it must contain and how DPIA reuse, notification and registration work.
Collect model documentation, integration information, copyright records and training summaries. Add testing, incident and security records for systemic risk.
Set up high-risk AI monitoring, identify serious incidents and check reporting deadlines, recipients, deployer escalation and corrective action.
Check the AI Act fine tiers, smaller-organisation caps, GPAI provider fines and the facts authorities consider when deciding a penalty.
Check serious-incident harm, preserve evidence and choose the reporting deadline and recipient for high-risk AI systems and systemic-risk GPAI models.
See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.
Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.
Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.
Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.
Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.
Classify an AI tool or model before purchase or release. Check EU scope, prohibited uses, high-risk rules, transparency and GPAI duties.
Check each AI tool, decide which duties apply, and give every action an owner and evidence link.
Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.
Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.
Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.
Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.
Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.
Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.
Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.
Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.
Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.
Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.
Check provider, deployer, importer and distributor roles, when changes create provider duties, and how model and system responsibilities differ.
Find the assessment route for high-risk AI, when a notified body is required, and which declaration, CE-marking and registration records you need.
Check whether software counts as AI, how models differ from systems, when embedded AI is high-risk, and which scope and role evidence to keep.
Understand high-risk AI monitoring under Article 72: the provider plan, deployer feedback, logs, corrective action, incidents and change reviews.
See which industry AI uses fall under Annex III, when Article 6(3) can apply, and what providers must document and register.
See what Article 11 and Annex IV require in high-risk AI technical documentation, from system identity and testing to monitoring and retention.
Check general-purpose model duties, systemic-risk classification, open-source conditions, copyright, training summaries, incidents and application dates.
Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.
Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.
Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.