EU AI Act: requirements, deadlines and compliance actions

Article 5 bans placing on the market, putting into service or using AI for listed practices, including subliminal or manipulative techniques that cause significant harm, exploitation of vulnerabilities, social scoring by public or private actors leading to detrimental treatment, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and education institutions except for medical or safety reasons, biometric categorisation to infer protected characteristics, and real-time remote biometric identification in publicly accessible spaces for law enforcement outside narrow exceptions.

Practical action: Add a prohibited-practice screen to your AI intake or design-review process and document the outcome for every system already in use.

Evidence examples: Prohibited-practice screening record; AI system inventory

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 6.1.2 and Annex A control on AI system impact assessment; NIST AI RMF 1.0 GOVERN 1.1, MAP 1.1

Open the obligation page →Article 5 Pending review (a factual check against the official source, not a legal review)

Providers and deployers must take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account technical knowledge, experience, training, the context of use and the persons affected.

Practical action: Run role-based AI training and keep attendance and content records; the Commission's AI Office has indicated that literacy will be assessed proportionately.

Evidence examples: AI literacy training programme

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 7.2 Competence and 7.3 Awareness; NIST AI RMF 1.0 GOVERN 2.2

Open the obligation page →Article 4 Pending review (a factual check against the official source, not a legal review)

Providers of high-risk AI systems must establish, implement, document and maintain a continuous, iterative risk-management system across the system's lifecycle: identifying known and reasonably foreseeable risks to health, safety and fundamental rights, estimating and evaluating risks including from reasonably foreseeable misuse, evaluating post-market data, and adopting targeted risk-management measures, with testing before placing on the market.

Practical action: Set up a lifecycle risk register per high-risk system with test evidence and residual-risk acceptance.

Evidence examples: Risk register and treatment plan; Pre-market test reports

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clauses 6.1.2, 6.1.3, 8.2, 8.3 and Annex A controls on AI risk; NIST AI RMF 1.0 MAP, MEASURE and MANAGE functions

Open the obligation page →Article 9 Pending review (a factual check against the official source, not a legal review)

High-risk AI systems that use data-driven techniques must be developed on training, validation and testing data sets meeting quality criteria: appropriate governance practices covering design choices, data collection and origin, preparation, assumptions, availability and suitability, examination for possible biases, and measures to detect, prevent and mitigate bias. Data must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete for the intended purpose.

Practical action: Produce a data-provenance and bias-assessment record for each data set used to build the system.

Evidence examples: Dataset documentation (datasheet); Bias examination report

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A controls on data for AI systems; NIST AI RMF 1.0 MAP 2.3, MEASURE 2.1, MEASURE 2.11

Open the obligation page →Article 10 Pending review (a factual check against the official source, not a legal review)

Technical documentation must be drawn up before a high-risk system is placed on the market or put into service and kept up to date. It must demonstrate compliance with the Section 2 requirements and contain at least the elements in Annex IV, including a general description, development process, monitoring and control, risk-management description, and the applied standards. SMEs may use a simplified form provided by the Commission.

Practical action: Maintain an Annex IV-structured technical file under version control.

Evidence examples: Annex IV technical file

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 7.5 Documented information; Annex A control on system documentation; NIST AI RMF 1.0 GOVERN 1.4, MAP 3.x

Open the obligation page →Article 11 and Annex IV Pending review (a factual check against the official source, not a legal review)

High-risk AI systems must technically allow automatic recording of events (logs) over their lifetime to support traceability, post-market monitoring and operational monitoring. Deployers must keep the logs generated by the system, to the extent under their control, for a period appropriate to the intended purpose and at least six months unless other law provides otherwise.

Practical action: Define the log schema, retention and access controls, and confirm deployer retention meets the minimum.

Evidence examples: Logging specification and retention policy

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A control on event logging; NIST AI RMF 1.0 MEASURE 2.x, MANAGE 4.1

Open the obligation page →Article 12; Article 26(6) for deployers Pending review (a factual check against the official source, not a legal review)

High-risk AI systems must be designed so their operation is sufficiently transparent for deployers to interpret output and use it appropriately, and must be accompanied by instructions for use covering the provider's identity, the system's characteristics, capabilities and limitations, performance for the intended purpose and known foreseeable misuse, human-oversight measures, expected lifetime and maintenance.

Practical action: Ship an Article 13-structured instructions-for-use document with every high-risk system release.

Evidence examples: Instructions for use

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A controls on information for interested parties; NIST AI RMF 1.0 GOVERN 4.x, MAP 1.x

Open the obligation page →Article 13 Pending review (a factual check against the official source, not a legal review)

High-risk systems must be designed with human-machine interface tools so natural persons can effectively oversee them, understand capacities and limitations, avoid automation bias, interpret output, decide not to use the system, and intervene or stop it. Deployers must assign oversight to people with the necessary competence, training and authority. For certain remote biometric identification systems, action requires verification by at least two competent persons.

Practical action: Document oversight roles, the "stop" mechanism and override paths for each high-risk deployment.

Evidence examples: Human oversight procedure and role assignment

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A control on human oversight; NIST AI RMF 1.0 GOVERN 3.2, MANAGE 2.x

Open the obligation page →Article 14; Article 26(2) for deployers Pending review (a factual check against the official source, not a legal review)

High-risk AI systems must achieve an appropriate level of accuracy, robustness and cybersecurity and perform consistently throughout their lifecycle. Accuracy levels and metrics must be declared in the instructions; systems must be resilient to errors, faults and inconsistencies, address feedback loops in continuously learning systems, and resist attempts to alter use or performance, including data poisoning, model poisoning, adversarial examples and confidentiality attacks.

Practical action: Include AI-specific threat modelling and adversarial testing in your security programme.

Evidence examples: Accuracy metrics and test evidence; AI security assessment

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A controls on AI system verification and validation; ISO/IEC 27001:2022 Clause 8 and Annex A security controls; NIST AI RMF 1.0 MEASURE 2.5, 2.6, 2.7

Open the obligation page →Article 15 Pending review (a factual check against the official source, not a legal review)

Providers of high-risk AI systems must put in place a documented quality management system covering regulatory-compliance strategy, design and development procedures, testing and validation, technical specifications and standards, data management, the risk-management system, post-market monitoring, incident reporting, communication with authorities, record keeping, resource management and an accountability framework.

Practical action: Extend an existing ISO 9001 or ISO/IEC 42001 management system to cover the Article 17 elements.

Evidence examples: QMS manual and procedures

Framework mapping (original, editorial): ISO/IEC 42001:2023 Whole management system (Clauses 4–10); NIST AI RMF 1.0 GOVERN function

Open the obligation page →Article 17 Pending review (a factual check against the official source, not a legal review)

Before placing a high-risk system on the market, providers must complete the applicable conformity assessment (internal control or notified-body assessment depending on the system), draw up an EU declaration of conformity, affix the CE marking, and register the system in the EU database. Deployers that are public authorities must also register their use of Annex III systems.

Practical action: Determine the assessment route early; notified-body capacity may be limited around application dates.

Evidence examples: EU declaration of conformity; EU database registration record

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 9 Performance evaluation; internal audit

Open the obligation page →Articles 43, 47, 48 and 49; Annex VIII Pending review (a factual check against the official source, not a legal review)

Deployers of high-risk AI must take technical and organisational measures to use systems according to the instructions, assign human oversight, ensure input data is relevant where they control it, monitor operation, inform the provider and authorities of risks or serious incidents, keep logs, inform workers' representatives before deploying at the workplace, inform affected natural persons where decisions are made about them, and cooperate with authorities.

Practical action: Create a deployer checklist per high-risk system and a notice for affected individuals and workers.

Evidence examples: Deployment checklist and oversight assignment; Worker and affected-person notices

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A controls on responsible use of AI systems; NIST AI RMF 1.0 MANAGE 3.x, GOVERN 5.x

Open the obligation page →Article 26 Pending review (a factual check against the official source, not a legal review)

Before deploying most Annex III high-risk systems, deployers that are bodies governed by public law or private entities providing public services, and deployers using systems for creditworthiness assessment or life and health insurance pricing, must assess the impact on fundamental rights: the processes, period and frequency of use, categories of affected persons, specific risks of harm, human-oversight measures and mitigation, and notify the market-surveillance authority of the results.

Practical action: Reuse GDPR DPIA workflows and extend them with the Article 27 elements; the AI Office is to provide a template.

Evidence examples: Fundamental rights impact assessment report

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 6.1.4 AI system impact assessment; Annex A control on impact assessment; NIST AI RMF 1.0 MAP 5.1, MAP 5.2

Open the obligation page →Article 27 Pending review (a factual check against the official source, not a legal review)

Providers must ensure AI systems intended to interact with people inform them they are dealing with AI unless obvious; providers of systems generating synthetic audio, image, video or text must mark output in a machine-readable, detectable format; deployers of emotion-recognition or biometric-categorisation systems must inform exposed persons; deployers must disclose deepfakes and AI-generated text published to inform the public on matters of public interest, subject to exceptions.

Practical action: Implement provenance marking (for example content credentials) and user-facing AI disclosures in product UX.

Evidence examples: Disclosure and watermarking design record

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A control on communication with interested parties; NIST AI RMF 1.0 GOVERN 4.x; NIST AI 600-1 content provenance suggestions

Open the obligation page →Article 50 Pending review (a factual check against the official source, not a legal review)

Providers of general-purpose AI models must keep technical documentation (Annex XI), provide information to downstream providers integrating the model (Annex XII), put in place a policy to comply with EU copyright law including the text-and-data-mining opt-out, and publish a sufficiently detailed public summary of training content using the Commission's template. Free and open-source models are exempt from the first two duties unless they present systemic risk. Adherence to the General-Purpose AI Code of Practice can demonstrate compliance.

Practical action: Prepare the Commission's training-content summary template and a documented copyright policy before release.

Evidence examples: Public summary of training content; Copyright compliance policy

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A controls on data provenance and documentation; NIST AI RMF 1.0 NIST AI 600-1 (Generative AI profile) — intellectual property and data privacy risks

Open the obligation page →Article 53 and Annexes XI–XII Pending review (a factual check against the official source, not a legal review)

A general-purpose model is presumed to have systemic risk when the cumulative compute used for training exceeds 10^25 floating-point operations, or when the Commission designates it. Providers must notify the Commission, perform model evaluations including adversarial testing, assess and mitigate systemic risks, track and report serious incidents, and ensure adequate cybersecurity for the model and infrastructure.

Practical action: Track training compute against the threshold and prepare a safety and security framework before launch.

Evidence examples: Model evaluation and red-teaming reports; Commission notification record

Framework mapping (original, editorial): NIST AI RMF 1.0 MEASURE 2.x; NIST AI 600-1

Open the obligation page →Articles 51, 52 and 55 Pending review (a factual check against the official source, not a legal review)

Providers must establish and document a post-market monitoring system proportionate to the nature of the AI technology and its risks, actively and systematically collecting and analysing performance data throughout the system's lifetime, based on a monitoring plan that is part of the technical documentation. The Commission is to adopt a template for the plan.

Practical action: Define performance and drift indicators, feedback channels and review cadence in a monitoring plan.

Evidence examples: Post-market monitoring plan and periodic reports

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 9.1 Monitoring, measurement, analysis and evaluation; NIST AI RMF 1.0 MANAGE 4.1, MEASURE 3.x

Open the obligation page →Article 72 Pending review (a factual check against the official source, not a legal review)

Providers of high-risk AI systems must report serious incidents to the market-surveillance authority of the Member State where the incident occurred, immediately after establishing a causal link (or reasonable likelihood) and no later than 15 days after becoming aware, with shorter limits for the most serious cases such as widespread infringements or death. Deployers must inform the provider and authorities when they identify a serious incident.

Practical action: Add AI serious-incident criteria and time limits to your existing incident-response playbook.

Evidence examples: AI incident response procedure; Incident log and authority notifications

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 10 Improvement; Annex A control on incident handling; NIST AI RMF 1.0 MANAGE 4.3

Open the obligation page →Article 73 Pending review (a factual check against the official source, not a legal review)

Importers must verify that the provider completed conformity assessment, drew up technical documentation, affixed CE marking and appointed an authorised representative where required, and must indicate their name and contact details on the system. Distributors must verify CE marking, the declaration of conformity and instructions, and refrain from making non-compliant systems available.

Practical action: Build AI Act checks into supplier onboarding and contract clauses.

Evidence examples: Supplier due-diligence checklist

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A controls on third parties and suppliers; NIST AI RMF 1.0 GOVERN 6.1, GOVERN 6.2

Open the obligation page →Articles 23 and 24 Pending review (a factual check against the official source, not a legal review)

Article 16 lists what a provider of a high-risk AI system owes: compliance with the Section 2 requirements, its name and contact details on the system or its documentation, a quality management system, retention of documentation and logs, conformity assessment, an EU declaration of conformity, CE marking, registration, corrective action when needed, cooperation with authorities on request, and accessibility in line with the EU accessibility directives.

Practical action: Map each Article 16 point to an owner and an evidence location in a compliance matrix for every high-risk system.

Evidence examples: Provider compliance matrix

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 5.3; Annex A.3.2; NIST AI RMF 1.0 GOVERN 1.1, GOVERN 2.1

Open the obligation page →Article 16 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

For ten years after a high-risk AI system is placed on the market or put into service, the provider must keep at the disposal of national competent authorities the technical documentation, the quality management system documentation, any changes approved by a notified body, the notified body's decisions and other documents, and the EU declaration of conformity. Financial institutions keep these as part of their sector record-keeping.

Practical action: Set a ten-year retention class for the technical file, QMS records and conformity documents of each high-risk system.

Evidence examples: Retention schedule for AI conformity records; Technical file archive index

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 7.5.3; Annex A.6.2.7; NIST AI RMF 1.0 GOVERN 1.4

Open the obligation page →Article 18 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Providers must keep the event logs that a high-risk AI system generates under Article 12, to the extent those logs are within their control, for a period appropriate to the system's intended purpose and in any case for at least six months, unless Union or national law on personal data sets a different period. Financial institutions keep the logs under their sector rules.

Practical action: Configure log retention for hosted or API-served high-risk systems to at least six months with a documented rationale for any longer period.

Evidence examples: Log retention configuration and policy; Sample log export demonstrating retention period

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.6.2.8; NIST AI RMF 1.0 MEASURE 2.4, MANAGE 4.1

Open the obligation page →Article 19 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A provider that considers, or has reason to consider, that a high-risk system it has placed on the market is not in conformity must immediately correct it, withdraw it, disable it or recall it as appropriate, and inform the distributors, deployers, authorised representative and importers. Where the system presents a risk to health, safety or fundamental rights and the provider becomes aware of that risk, it must immediately investigate the causes together with the reporting deployer and inform the market surveillance authorities and, where relevant, the notified body.

Practical action: Add a non-conformity and recall procedure for AI products with a supply-chain notification list and an authority-notification step.

Evidence examples: Corrective action and recall procedure for AI systems; Non-conformity investigation record

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 10.2; Annex A.8.4; NIST AI RMF 1.0 MANAGE 2.4, MANAGE 4.3

Open the obligation page →Article 20 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

On a reasoned request from a national competent authority, a provider of a high-risk AI system must supply all the information and documentation needed to show that the system meets the Section 2 requirements, in a language the authority can readily understand, and must give the authority access to the automatically generated logs it holds. Authorities must treat what they receive as confidential under Article 78.

Practical action: Keep an authority-request playbook with a named contact, the documentation index and a pre-agreed export format for logs.

Evidence examples: Regulator request handling procedure; Log of authority requests and responses

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 7.5; Annex A.8.3; NIST AI RMF 1.0 GOVERN 1.4, GOVERN 4.2

Open the obligation page →Article 21 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Before making a high-risk AI system available in the Union, a provider established outside the EU must appoint, by written mandate, an authorised representative established in the Union. The representative verifies that the EU declaration of conformity and technical documentation exist and that conformity assessment was done, keeps the provider's contact details and the documentation available for ten years, supplies information to authorities, cooperates with them, and must end the mandate if the provider acts contrary to the Regulation.

Practical action: Sign a written mandate with an EU-established representative and give them a controlled copy of the technical file and declaration.

Evidence examples: Written mandate of authorised representative; Representative's documentation checklist

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 5.3; Annex A.10.2; NIST AI RMF 1.0 GOVERN 2.1, GOVERN 6.1

Open the obligation page →Article 22 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system, with all Article 16 duties, if it puts its own name or trademark on a system already on the market, makes a substantial modification to a high-risk system that stays high-risk, or changes the intended purpose of a system so that it becomes high-risk. The original provider then ceases to be provider for that system but must cooperate and supply the information and access needed for the new provider to comply.

Practical action: Add a reclassification check to change control so that white-labelling, fine-tuning or repurposing a high-risk system triggers the provider workstream.

Evidence examples: Change-control reclassification assessment; Cooperation clause with original provider

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 4.1; Annex A.10.2; NIST AI RMF 1.0 GOVERN 6.1, MAP 1.1

Open the obligation page →Article 25(1) and 25(2) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A provider of a high-risk AI system and any third party that supplies AI systems, tools, services, components or processes used in or integrated into it must set out, in a written agreement, the information, capabilities, technical access and other assistance needed for the provider to meet its obligations, based on the generally acknowledged state of the art. Suppliers of free and open-source tools and components other than general-purpose AI models are outside this duty. The AI Office may publish voluntary model terms.

Practical action: Insert AI Act information, access and assistance clauses into contracts with model, data and component suppliers.

Evidence examples: Supplier agreement with AI Act information and access clauses; Supplier register with agreement status

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.10.3; NIST AI RMF 1.0 GOVERN 6.1

Open the obligation page →Article 25(4) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A provider that considers a system listed in Annex III to be outside the high-risk tier because it meets one of the Article 6(3) conditions, such as performing a narrow procedural task or only preparing a human assessment, must write down that assessment before placing the system on the market or putting it into service, register the system in the EU database under Article 49(2), and hand over the assessment on request from a national competent authority.

Practical action: Record a reasoned Article 6(3) assessment in the design file and register the system before launch rather than relying on an informal judgement.

Evidence examples: Article 6(3) classification assessment; EU database registration entry

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 6.1.2; Annex A.6.2.7; NIST AI RMF 1.0 MAP 1.5, MAP 3.1

Open the obligation page →Article 6(4); Article 49(2) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

To the extent a deployer controls the data fed into a high-risk AI system, it must make sure that input data is relevant to, and sufficiently representative for, the system's intended purpose. The duty sits with the deployer even though the provider designed the system, because the deployer chooses what the system is run on.

Practical action: Define input-data quality checks for each high-risk system, including population coverage and field validation, and review them with the provider's instructions.

Evidence examples: Input-data quality checklist; Input-data validation results

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.7.4, A.7.6; NIST AI RMF 1.0 MAP 2.3, MEASURE 2.2

Open the obligation page →Article 26(4) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Deployers must monitor a high-risk AI system's operation against the provider's instructions and feed observations to the provider under Article 72. If they have reason to think the system as used may present a risk to health, safety or fundamental rights, they must inform the provider or distributor and the market surveillance authority without undue delay and suspend use. On a serious incident, they must immediately inform the provider, then the importer or distributor and the authorities. Financial institutions meet this through their internal governance rules.

Practical action: Give each high-risk system an operational owner with a kill-switch authority and a written escalation route to the provider and the authority.

Evidence examples: Operational monitoring log; Suspension and escalation procedure

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 9.1; Annex A.6.2.6, A.8.4; NIST AI RMF 1.0 MANAGE 2.4, MANAGE 4.1, MANAGE 4.3

Open the obligation page →Article 26(5) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Before putting a high-risk AI system into service or using it at the workplace, a deployer that is an employer must tell the workers' representatives and the affected workers that they will be subject to the system. The information is given following the procedures and rules on informing workers and their representatives under Union and national law and practice, which may include works-council consultation.

Practical action: Add an AI Act notice step to the HR technology change process and consult the works council where national law requires it.

Evidence examples: Worker and works-council notification; Consultation minutes

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.8.5; NIST AI RMF 1.0 GOVERN 5.1, MAP 1.6

Open the obligation page →Article 26(7) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Deployers that are public authorities or Union institutions, bodies, offices or agencies must register their use of an Annex III high-risk AI system in the EU database before putting it into service. If they find that the system they intend to use has not been registered in the database by its provider, they must not use it and must inform the provider or distributor.

Practical action: Check the EU database entry for the provider's system as a procurement acceptance criterion, then register the deployment before go-live.

Evidence examples: EU database deployer registration record; Procurement acceptance checklist with registration check

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.8.2, A.8.5; NIST AI RMF 1.0 GOVERN 1.6, MAP 1.1

Open the obligation page →Article 26(8); Article 49(3) and 49(4) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Where a deployer of a high-risk AI system is required to carry out a data protection impact assessment under Article 35 of the GDPR or Article 27 of the Law Enforcement Directive, it must draw on the information the provider supplied under Article 13, such as the intended purpose, performance, limitations and human-oversight measures, when producing that assessment.

Practical action: Attach the provider's instructions for use to the DPIA template and cross-reference the Article 27 fundamental rights impact assessment where one is required.

Evidence examples: Data protection impact assessment citing the provider's Article 13 information

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 6.1.4; Annex A.5.2; NIST AI RMF 1.0 MAP 3.1, MEASURE 2.10

Open the obligation page →Article 26(9) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A deployer using a high-risk post-remote biometric identification system in a criminal investigation must request authorisation from a judicial or independent administrative authority in advance or within 48 hours, unless the use is only the initial identification of a potential suspect on objective and verifiable facts. Use is limited to a targeted search; if authorisation is refused, use stops and the data is deleted. No adverse legal decision may rest solely on the output, each use is documented, and the deployer reports annually to the market surveillance and data protection authorities.

Practical action: Build the authorisation request, 48-hour clock and deletion step into the investigation workflow and schedule the annual report.

Evidence examples: Authorisation request and decision record; Annual report on post-remote biometric identification use

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.9.2, A.9.4; NIST AI RMF 1.0 GOVERN 1.1, MANAGE 1.3

Open the obligation page →Article 26(10) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Deployers of Annex III high-risk AI systems that take decisions about natural persons, or help take them, must inform those persons that they are subject to the system. The notice is separate from any explanation owed under Article 86 and from the worker notice in Article 26(7). In law-enforcement contexts the duty follows the information rules of the Law Enforcement Directive.

Practical action: Add a plain-language AI-use notice to application forms, decision letters or account terms for each affected decision process.

Evidence examples: Affected-person notice template and placement record

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.8.5; NIST AI RMF 1.0 GOVERN 5.1, MANAGE 4.1

Open the obligation page →Article 26(11) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text must ensure the output is marked in a machine-readable format and detectable as artificially generated or manipulated. The technical solution must be effective, interoperable, robust and reliable as far as the state of the art allows, taking account of content type and cost. Systems that only perform assistive editing or do not substantially alter the input, and law-authorised criminal-detection uses, are outside the duty.

Practical action: Implement watermarking or content credentials on generated output and keep test evidence that the mark survives common transformations.

Evidence examples: Provenance marking design and robustness test report; Output sample with embedded machine-readable mark

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.8.2, A.6.2.4; NIST AI RMF 1.0 MEASURE 2.7, MANAGE 4.1

Open the obligation page →Article 50(2) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A deployer of an emotion recognition system or a biometric categorisation system must inform the natural persons exposed to it that the system is operating and must process their personal data in line with the GDPR, the Law Enforcement Directive and the EU institutions data protection regulation. Systems permitted by law to detect, prevent or investigate criminal offences are excepted, subject to safeguards. Use in workplaces and schools is separately banned by Article 5 except for medical or safety reasons.

Practical action: Place a visible notice at the point of capture and confirm a lawful basis for the biometric processing before switch-on.

Evidence examples: Exposure notice and signage; Lawful-basis record for biometric processing

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.8.5; NIST AI RMF 1.0 GOVERN 5.1, MEASURE 2.10

Open the obligation page →Article 50(3) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A deployer that generates or manipulates image, audio or video content that is a deep fake must disclose that the content has been artificially generated or manipulated, with lighter treatment for evidently artistic, creative, satirical or fictional works so that the disclosure does not spoil the work. A deployer that publishes AI-generated text to inform the public on matters of public interest must disclose this unless the text passed human review or editorial control and someone holds editorial responsibility. The disclosure must reach people clearly at the latest at first exposure.

Practical action: Adopt a labelling standard for published synthetic media and a newsroom rule that AI-drafted public-interest text is either labelled or editorially signed off.

Evidence examples: Synthetic media labelling standard; Editorial sign-off record for AI-drafted text

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.9.2, A.8.5; NIST AI RMF 1.0 GOVERN 5.1, MANAGE 4.1

Open the obligation page →Article 50(4) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A provider whose general-purpose AI model meets the Article 51(1)(a) high-impact capability condition, which is presumed once cumulative training compute exceeds 10^25 floating-point operations, must notify the Commission without delay and in any event within two weeks of the condition being met or of learning that it will be met. The notification may include arguments that the model nonetheless does not present systemic risk; the Commission decides and keeps a public list of designated models.

Practical action: Track cumulative training compute per model against the threshold and pre-draft the notification and any rebuttal arguments.

Evidence examples: Training compute tracking record; Notification to the Commission

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 4.2; Annex A.8.3; NIST AI RMF 1.0 GOVERN 1.1, MAP 1.1

Open the obligation page →Article 52(1) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Providers of general-purpose AI models must draw up and keep up to date technical documentation covering the training and testing process and evaluation results, as set in Annex XI, and supply it to the AI Office or national authorities on request. They must also keep current the Annex XII information for providers that integrate the model into their own AI systems, so those providers understand its capabilities and limitations and can meet their own duties. Free and open-source models without systemic risk are exempt from both duties.

Practical action: Maintain a model card and technical file aligned to Annexes XI and XII with version control tied to each model release.

Evidence examples: Annex XI technical documentation; Annex XII downstream integration documentation

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.6.2.7, A.8.2, A.10.4; NIST AI RMF 1.0 GOVERN 1.4, MAP 2.2, MEASURE 2.1

Open the obligation page →Article 53(1)(a) and 53(1)(b); Annexes XI and XII Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Before placing a general-purpose AI model on the Union market, a provider established in a third country must appoint, by written mandate, an authorised representative established in the Union. The representative checks that the Annex XI documentation exists and the Article 53 duties are met, keeps a copy of the documentation and the provider's contact details for ten years after market placement, provides information to the AI Office on request, cooperates with authorities, and must end the mandate if the provider breaches the Regulation. Open-source models without systemic risk are exempt.

Practical action: Appoint an EU representative under a written mandate covering document retention and AI Office liaison before the model reaches EU users.

Evidence examples: Written mandate of authorised representative for GPAI; Representative's verification of Annex XI documentation

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 5.3; Annex A.10.2; NIST AI RMF 1.0 GOVERN 2.1, GOVERN 6.1

Open the obligation page →Article 54 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Providers of general-purpose AI models with systemic risk must keep track of, document and report without undue delay to the AI Office and, where relevant, to national competent authorities the relevant information about serious incidents and the possible corrective measures to address them. The General-Purpose AI Code of Practice sets out timelines and content that providers may follow to demonstrate compliance.

Practical action: Define serious-incident criteria for the model, a tracking log and an AI Office notification template with owner and clock.

Evidence examples: Serious incident tracking log for the model; AI Office incident notification

Framework mapping (original, editorial): ISO/IEC 42001:2023 Clause 10.2; Annex A.8.4; NIST AI RMF 1.0 MANAGE 4.3, MEASURE 3.1

Open the obligation page →Article 55(1)(c) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

Providers of general-purpose AI models with systemic risk must ensure an adequate level of cybersecurity protection for the model and for the physical infrastructure it runs on, which in practice covers protection of model weights, training and inference environments, and access controls against theft, tampering and unauthorised release. Codes of practice and harmonised standards may be used to show compliance.

Practical action: Apply a documented security standard to weight storage, training clusters and inference endpoints, with penetration tests and insider-risk controls.

Evidence examples: Model and infrastructure security assessment; Weight access control records

Framework mapping (original, editorial): ISO/IEC 27001:2022 Clause 8.1; Annex A 5.15, A 8.24; NIST AI RMF 1.0 MEASURE 2.7, MANAGE 2.2; MITRE ATLAS AML.M0005, AML.M0001

Open the obligation page →Article 55(1)(d) Verified 26 Sep 2026 (a factual check against the official source, not a legal review)

A person affected by a decision that a deployer took on the basis of the output of an Annex III high-risk AI system, other than critical-infrastructure systems, which produces legal effects or similarly significantly affects them in a way they consider adverse to their health, safety or fundamental rights, has the right to obtain from the deployer clear and meaningful explanations of the role the system played in the decision and the main elements of the decision. The right does not apply where Union or national law provides an exception.

Practical action: Set up a request channel and an explanation template that names the system's role, the key inputs and the human decision points for each affected process.

Evidence examples: Explanation request procedure and template; Register of explanation requests and responses

Framework mapping (original, editorial): ISO/IEC 42001:2023 Annex A.8.5, A.9.2; NIST AI RMF 1.0 GOVERN 5.1, MANAGE 4.1

Open the obligation page →Article 86 Verified 26 Sep 2026 (a factual check against the official source, not a legal review)