AI hardware & compute: key go-global obligations

Screen every AI capability offered in the EU, or whose output is used in the EU, against the Article 5 prohibition list (manipulation and deception, exploitation of vulnerabilities, social scoring, individual criminal-offence prediction from profiling, untargeted facial-image scraping, emotion recognition at work and in education, biometric categorisation inferring protected characteristics, real-time remote biometric identification for law enforcement, and from 2 Dec 2026 the generation of non-consensual intimate imagery and child sexual abuse material). Remove or technically block any hit before placing the system on the market, and keep the assessment on file.

Draw up and keep up to date model technical documentation covering the training and testing process and evaluation results, containing at least the Annex XI elements, and provide it to the AI Office and national competent authorities on request. Separately, supply downstream AI system providers with information and documentation containing at least the Annex XII elements so they can understand the model’s capabilities and limitations and meet their own obligations. Models released under a genuinely free and open-source licence with public weights, architecture and usage information are exempt from both, unless the model has systemic risk.

Draw up and publish a sufficiently detailed summary of the content used for training, using the official AI Office template. It must set out the composition of data sources (including large datasets and main domain names) and how data was obtained and processed, so that rightsholders and other parties with legitimate interests can exercise their rights under Union law. The summary must match the model as actually trained and be updated with each release.

Put in place and operate a policy to comply with Union copyright law, in particular identifying and respecting rights reservations expressed under Article 4(3) of Directive (EU) 2019/790 using state-of-the-art technologies (for example robots.txt and machine-readable opt-out signals). The policy must cover crawling, dataset procurement, fine-tuning data and synthetic-data pipelines.

Continuously account for cumulative training compute. Under Art. 51(2), a GPAI model trained with cumulative compute greater than 10^25 floating-point operations is presumed to have high-impact capabilities and is therefore classified as a model with systemic risk. Notify the Commission within two weeks of meeting, or knowing it will meet, that condition, with supporting evidence. A provider may submit substantiated arguments with the notification that, exceptionally, the model does not present systemic risk.

In addition to Articles 53 and 54, providers of models with systemic risk must perform model evaluation under standardised state-of-the-art protocols, including documented adversarial testing; assess and mitigate possible Union-level systemic risks; keep track of, document and report serious incidents and corrective measures to the AI Office without undue delay (and to national competent authorities where appropriate); and ensure an adequate level of cybersecurity for the model and its physical infrastructure.

Before placing a GPAI 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 verifies that the Annex XI technical documentation has been drawn up and that the Article 53 (and where applicable Article 55) obligations have been met, keeps a copy of that documentation and the provider’s contact details at the disposal of the AI Office for 10 years after the model is placed on the market, supplies information on reasoned request, and cooperates with regulators on that model. Free and open-source models with public weights, architecture and usage information are exempt unless they present systemic risk.

AI systems intended to interact directly with natural persons (chatbots, voice assistants, customer-service and sales agents) must be designed so that users are informed they are interacting with an AI system, unless this is obvious to a reasonably well-informed, observant and circumspect person. The information must be given clearly and distinguishably at the latest at the first interaction and must meet accessibility requirements.

Providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, with technical solutions that are effective, interoperable, robust and reliable. Systems performing an assistive function for standard editing, or that do not substantially alter the deployer’s input data or its semantics, are out of scope. Compliance may be demonstrated by adhering to the Code of Practice on Transparency of AI-generated Content, the voluntary code published on 10 June 2026; non-adherents must demonstrate compliance by alternative equivalently adequate means.

Deployers of emotion recognition or biometric categorisation systems must inform the natural persons exposed to them and process personal data in line with the GDPR. Deployers generating or manipulating image, audio or video content constituting a deep fake must disclose that it is artificially generated or manipulated; the same applies to AI-generated or manipulated text published to inform the public on matters of public interest, unless the content underwent human review with a natural or legal person holding editorial responsibility. For evidently artistic, creative, satirical or fictional works the disclosure may be limited to an appropriate manner that does not hamper enjoyment of the work.

Assess each system against Art. 6(1) (a safety component of, or itself, a product covered by the Union harmonisation legislation in Annex I) and Art. 6(2) (the Annex III use cases). The AI Omnibus inserted Art. 6(1a)-(1c): systems used solely for non-safety-related user assistance, performance optimisation, service efficiency, automation, convenience or quality control do not qualify as safety components, but systems whose failure or malfunction would endanger health and safety do. Where a provider concludes under Art. 6(3) that an Annex III system is not high-risk, it must register itself and that system in the EU database before placing it on the market.

Establish, implement, document and maintain a continuous iterative risk management process across the system lifecycle: identify and analyse known and reasonably foreseeable risks to health, safety and fundamental rights under intended use; estimate risks that may arise under intended use and reasonably foreseeable misuse; evaluate further risks using post-market monitoring data under Art. 72; and adopt targeted risk management measures so that each residual risk and the overall residual risk are judged acceptable.

For high-risk systems using model-training techniques, training, validation and testing datasets must meet the Art. 10(2)-(4) quality criteria: design choices, data origin and collection, preparation, assumptions, assessment of sufficiency, examination for and mitigation of bias, handling of data gaps, and representativeness for the intended persons and the geographic and contextual setting. For systems not using training techniques, these apply only to testing datasets. The AI Omnibus deleted the former Art. 10(5) and inserted Art. 4a, permitting processing of special categories of personal data for bias detection and correction under strict conditions.

Draw up the technical documentation before the system is placed on the market or put into service and keep it up to date. It must contain at least the Annex IV elements in a clear and comprehensive form allowing national competent authorities and notified bodies to assess compliance. As amended by the AI Omnibus, Art. 11(1) allows SMEs including start-ups and small mid-cap companies (SMCs) to use a simplified form published by the Commission, which notified bodies must accept.

High-risk systems must technically allow automatic recording of events over their lifetime, with logging capabilities sufficient to identify situations that may cause the system to present a risk within the meaning of Art. 79(1) or to undergo a substantial modification, to support post-market monitoring under Art. 72, and to enable deployer monitoring under Art. 26(5). Providers must keep the automatically generated logs under their control for at least six months unless other Union or national law provides otherwise; deployers must do the same for logs under their control. For remote biometric identification systems the logs must at minimum record the start and end of each use, the reference database, the input data that produced a match, and the identity of the persons verifying results.