A practical map of the EU AI Act requirements that high-risk AI providers must build and deployers must operate.
Use it to connect Articles 8-16 and Article 26 to concrete controls, evidence records, supplier requests, and operational checks.
Structured answer sets in this page tree.
Cited legal and guidance references.
For a , map Articles 8-16 to the provider's design, evidence, conformity, registration, and lifecycle work, then map Article 26 to the deployer's operating controls. Check the legal route and date first. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and applies Chapter III Sections 1-3 from 2 December 2027 for Article 6(2) Annex III systems and from 2 August 2028 for Article 6(1) Annex I systems. Transition rules can produce a different result for systems already placed on the market or put into service before the controlling date.
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. A provider must ensure Section 2 compliance, identify itself on the system or accompanying documentation, maintain a quality management system, keep required documentation and logs where under its control, complete the relevant conformity assessment, draw up the EU declaration of conformity, affix CE marking where required, register where Article 49 applies, take corrective action, demonstrate conformity to competent authorities, and comply with applicable accessibility requirements.
Under amended Article 111(2), the high-risk operator rules apply to a system placed on the market or put into service before its Chapter III application date only if the system undergoes significant design changes from that date. The controlling date is 2 December 2027 for an Article 6(2) Annex III system and 2 August 2028 for an Article 6(1) Annex I system. 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.
The evidence file should start with the system's intended purpose and the Article 6 high-risk classification basis, then link each Section 2 requirement to a test, design control, or operational procedure. Annex IV expects technical documentation to cover the system description, design and development process, data requirements, monitoring and control information, risk management, validation and testing, accuracy and robustness metrics, discriminatory-impact testing where relevant, test logs, cybersecurity measures, and post-market monitoring information.
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.
Article 13 requires deployer-facing instructions that support correct operation. They should explain the provider identity, intended purpose, performance capabilities and limits, expected accuracy and metrics, robustness and cybersecurity expectations, foreseeable risk circumstances, output interpretation, input-data specifications, human oversight measures, maintenance needs, and log collection mechanisms.
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.
Article 26 is where the provider's evidence has to become deployer operations. Deployers of high-risk AI systems must use the system according to the instructions for use, assign human oversight to natural persons with the necessary competence, training, authority, and support, and ensure input data is relevant and sufficiently representative where the deployer controls that input data.
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 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.
A useful requirements review produces a traceable evidence pack. Each requirement should have a named owner, a source article, a system-specific control, a test or operating record, and a reviewer who can explain whether the evidence still matches the deployed system.
For supplier or downstream-provider situations, do not rely on a generic AI Act attestation. Ask for the exact information needed to operate the system: instructions for use, performance metrics, human oversight design, log format, monitoring and incident routes, technical documentation excerpts where appropriate, and written allocation of information and technical access where third-party tools, services, components, or processes are integrated into a .
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, DPIA or FRIA material where applicable, and incident notifications sent to the provider, distributor, importer, or authority.
Sorena can help structure the provider and deployer evidence pack for high-risk AI systems: requirement matrix, technical documentation, logs, oversight records, supplier requests, and monitoring checks.
Ask questions tied to cited sources about AI Act requirements, provider duties, deployer duties, technical documentation, logging, and oversight evidence.
Review your high-risk AI requirement matrix, evidence gaps, supplier dependencies, and deployer operating controls with Sorena.
"Monitor the system's behaviour"
"deployers ensure human oversight and monitoring"
"risk management"
"demonstrate the conformity of the high-risk AI system"