Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.
Use the sections below to plan supplier checks, high-risk assessments, notices, monitoring and incident reporting.
Start with the AI tool and how you use or supply it. Assign duties to the organisation responsible for each step, then link each duty to evidence and a deadline. The same tool can create different duties for its provider, user, importer and distributor.
Record the tool, intended purpose, EU market or use connection, operator role and risk category. Check high-risk system duties, general-purpose AI (GPAI) model duties and transparency duties separately. A system can trigger more than one set of duties.
For high-risk AI systems, keep a role column for provider, authorised representative, importer, distributor, deployer, product manufacturer, and any third party supplying tools, services, components, or processes for integration.
Article 25 can move provider obligations to a distributor, importer, deployer, or other third party when they rebrand the system, substantially modify it, or change the intended purpose so that it becomes high-risk.
The original Article 5 prohibitions already apply and most GPAI duties have applied since 2 August 2025.
Regulation (EU) 2026/1744 entered into force on 27 July 2026, keeps the 2 August 2026 general application date, and moves Chapter III Sections 1-3, except Article 6(5), to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Article 6(1) systems.
Sources (2)
Supports the division of duties among providers, authorised representatives, importers, distributors, deployers, and value-chain actors for high-risk AI systems.
Obligations of providers and deployers of high-risk AI systems and other parties
Supports provider and public-authority deployer registration controls for covered Annex III high-risk AI systems.
Before placing on the market or putting into service
For a high-risk system, the provider must show how the system meets the design and operating requirements in Chapter III Section 2. Collect evidence for risk management, data, technical documentation, logging, instructions, human oversight, accuracy, robustness and cybersecurity.
Keep a deployer file showing that the system is used according to the provider's instructions, that oversight is assigned to people with competence, training, authority, and support, and that monitoring feeds provider and authority escalation when risk or a serious incident appears.
Build the provider quality management system (QMS) under Article 17 around approved procedures and records from the identified system version. EN 18286:2026, cited in the Official Journal on 14 October 2026, provides a voluntary route with presumption of conformity limited to covered requirements.
Check Annex ZA conditions, assign remaining obligations and link each procedure to operating evidence; adoption alone does not establish full AI Act compliance.
Sources (3)
Supports the required evidence families for high-risk AI systems: risk management, data governance, documentation, logs, information to deployers, oversight, accuracy, robustness, and cybersecurity.
Requirements for high-risk AI systems
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.
Choose the conformity assessment route before releasing a high-risk system. Article 43 allows some Annex III point 1 biometric systems to use provider-run internal control when the standards conditions are met. Otherwise they require assessment by a notified body under Annex VII.
Annex III points 2-8 use internal control unless a later amendment changes that route.
High-risk AI systems covered by Union harmonisation legislation listed in Annex I, Section A follow the conformity assessment procedure under that sector law, while applicable AI Act requirements become part of that assessment.
Regulation (EU) 2026/1744 allows later delegated acts to limit overlapping AI Act requirements where the Section A sector law provides equivalent protection. It also limits direct AI Act application for Article 6(1) systems related to Annex I Section B products and moves machinery into that sectoral route.
A new conformity assessment remains required after a substantial modification where the applicable AI Act route requires it. Under amended Article 43(3), when a Section A system also falls within Annex III, the provider follows the relevant Section A product-law procedure. Record both classification bases and the resulting sector route.
Sources (3)
Supports conformity assessment route selection, notified-body involvement, sector-law handling, and new assessment after substantial modification.
Conformity assessment
Supports adding registration status as a release gate for covered high-risk AI systems and public-authority deployments.
register themselves and their system in the EU database
Supports the amended Annex I Section A overlap mechanism, Annex I Section B direct-application limits, machinery sectoral treatment, and revised high-risk dates.
Prepare the technical file before supplying or first using a high-risk system and keep it current. Article 11 and Annex IV require information on the system, development, data, architecture, oversight, testing, cybersecurity, risks, standards, declaration and monitoring after release.
Version the documentation with the system. It must be clear enough for national competent authorities and notified bodies to assess compliance, and it should also support internal release decisions, incident investigations, and customer assurance.
Sources (1)
Supports the required structure and purpose of technical documentation for high-risk AI systems.
Technical documentation referred to in Article 11(1)
Check whether the deployer needs a fundamental rights impact assessment (FRIA) before use. Article 27 covers public-law bodies and private entities providing public services when they deploy Article 6(2) high-risk systems listed in Annex III. It also covers deployers of the creditworthiness and life or health insurance systems in Annex III points 5(b) and 5(c). It excludes the critical-infrastructure systems in point 2.
Record the use process, duration and frequency, affected people, risks, oversight, governance and complaint measures.
Article 50 transparency controls should be tracked separately from high-risk status. Direct-interaction notices and deployer disclosures remain tied to the 2 August 2026 general date. Regulation (EU) 2026/1744 gives provider-side synthetic-output marking and detection controls a transition to 2 December 2026 for systems placed on the market before 2 August 2026.
The controls cover direct interaction with natural persons, marking synthetic audio, image, video, or text outputs where applicable, notices for emotion recognition or biometric categorisation, deepfake disclosures, and disclosure for AI-generated public-interest text unless a stated exception applies.
GPAI model provider duties are another separate track. Article 53 requires model technical documentation, downstream information, a copyright policy, and a public summary of training content. Systemic-risk GPAI duties add model evaluation, adversarial testing, systemic-risk assessment and mitigation, serious-incident tracking and reporting, and cybersecurity protection.
The Article 53(2) exception removes only the technical-documentation and downstream-information duties where the model is released under a free and open-source licence allowing access, use, modification, and distribution, and its parameters, including weights, architecture information, and usage information are public.
It does not apply to systemic-risk models and does not remove the copyright policy or public training-content summary.
Sources (4)
Supports the scope and required content of fundamental rights impact assessments for covered high-risk deployments.
Fundamental rights impact assessment for high-risk AI systems
Supports transparency controls for direct AI interaction, synthetic output marking, emotion recognition or biometric categorisation notices, deepfakes, and AI-generated public-interest text.
Transparency obligations for providers and deployers of certain AI systems
Supports maintaining a dedicated GPAI provider workstream and using Commission guidance to assess whether GPAI obligations apply.
clarify the scope of the obligations for providers of general-purpose AI models
Supports the 2 December 2026 transition for provider-side synthetic-output marking and detection controls.
Real-world testing is outside the exclusion for pre-market research, testing and development. Before exposing people to the system, record the lawful route: an AI regulatory sandbox, Article 60 real-world testing, another permitted deployment basis, or ordinary AI Act requirements.
Obtain the required approvals and complete applicable compliance steps before supplying or using the tested system. The provider must close open findings, fix the intended purpose and role map, apply the relevant classification and conformity route, prepare user information, and transfer monitoring and incident responsibilities to the released system record.
Sources (2)
Primary source for AI regulatory sandboxes, real-world testing plans and conditions, informed consent, safeguards, and sandbox supervision.
Primary source for the pre-market research, testing and development exclusion and its real-world-testing boundary.
High-risk providers must monitor their systems after release. Under Article 72, actively collect, record and analyse performance data throughout the system lifetime to check continuing compliance. The amendment requires Commission guidance, including a voluntary monitoring-plan template, by 2 September 2027.
Incident evidence should connect deployer monitoring, provider investigation, authority reporting, and corrective action.
Article 73 requires providers of high-risk AI systems placed on the Union market to report serious incidents to the market surveillance authority of the Member State where the incident occurred, with shorter maximum reporting periods for widespread infringements, certain serious incidents, and deaths.
Under Article 75(1a), providers of high-risk AI systems subject to the AI Office's competence instead report those incidents to the AI Office.
Use separate rows for each AI system or GPAI model and include intended purpose, EU market or use facts, role, risk tier, high-risk or GPAI basis, required evidence, conformity route, transparency notice status, monitoring owner, incident escalation path, source citation, and reassessment trigger.
A buyer may still have deployer duties for high-risk use, including using the system according to instructions, assigning competent human oversight, monitoring operation, keeping logs under its control, informing workers or affected natural persons where required, and escalating risks or serious incidents. The buyer can also become a provider if it rebrands, substantially modifies, or changes the intended purpose in a way covered by Article 25.
The provider should have the Article 8-15 requirement evidence, Article 11 and Annex IV technical documentation, quality management records, conformity assessment evidence, EU declaration of conformity, CE marking evidence, registration record where required, deployer instructions, post-market monitoring plan, and serious-incident reporting procedure.
Sources (3)
Supports post-market monitoring, serious-incident reporting, investigation, corrective action, and reporting-period controls for high-risk AI systems.
Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems
Supports the GPAI systemic-risk incident-reporting workstream and the Commission reporting template for serious incidents involving GPAI models with systemic risk.
serious incidents involving general-purpose AI models
Supports the revised high-risk application dates, the Article 72 change from a mandatory harmonised template to Commission guidance with a voluntary template by 2 September 2027, and the Article 75(1a) serious-incident reporting route to the AI Office.
Review who owns each duty, what evidence is missing and which actions must happen before release.
Research which duties apply to your role and what evidence supports the compliance plan.
Review who owns each duty, what evidence is missing and which actions must happen before release.
"Registration"
"Before placing on the market or putting into service"
"register themselves and their system in the EU database"
"serious incidents involving general-purpose AI models"
"Guidelines for providers of general-purpose AI models"
"clarify the scope of the obligations for providers of general-purpose AI models"
"Fundamental rights impact assessment for high-risk AI systems"
"Fundamental rights impact assessment for high-risk AI systems"
"laying down harmonised rules on artificial intelligence"
"Technical documentation referred to in Article 11(1)"
"Conformity assessment"
"Transparency obligations for providers and deployers of certain AI systems"
"Obligations of providers and deployers of high-risk AI systems and other parties"
"Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems"
"Requirements for high-risk AI systems"
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.
High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.
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.
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.