Search every question across sub-FAQs

Article 51 classifies a general-purpose AI model as a GPAI model with systemic risk if it has high-impact capabilities, or if the Commission designates it after an ex officio assessment or a qualified alert from the scientific panel using Annex XIII criteria.

The Act creates a compute-based presumption: a GPAI model is presumed to have high-impact capabilities when the cumulative computation used for training is greater than 10^25 floating point operations. Article 52 then requires notification to the Commission without delay and in any event within two weeks after the requirement is met or it becomes known that it will be met.

Article 55 duties apply in addition to Articles 53 and 54. Providers of GPAI models with systemic risk must evaluate the model with state-of-the-art protocols and tools, conduct and document adversarial testing, assess and mitigate systemic risks at Union level, track and report serious incidents, and protect the model and its physical infrastructure with adequate cybersecurity.

The Article 55 work should be continuous across development, placing on the market, and use. It should cover sources of systemic risk, post-market learning from incidents and misuse, corrective measures, and security risks such as model leakage, unauthorised releases, circumvention of safety measures, unauthorised access, and model theft.

The Article 53 copyright policy and public training-content summary are separate duties. The copyright policy is an internal compliance policy for Union copyright and related-rights law. The public summary is a transparency artifact about the content used for model training, published according to the AI Office template.

Open-source status can reduce some Article 53 documentation duties only when the licence and public availability conditions are met, and it does not remove the copyright-policy or training-summary duties. It also does not exempt GPAI models with systemic risk from the transparency-related obligations.

The Commission guidelines state that Chapter V obligations for GPAI model providers apply from 2 August 2025. They also state that Commission enforcement powers for these obligations enter into application on 2 August 2026, and that providers of GPAI models placed on the market before 2 August 2025 must take necessary compliance steps by 2 August 2027.

The same guidance says the guidelines are not legally binding and that authoritative interpretation of the AI Act is for the Court of Justice of the European Union. Treat the dates above as implementation milestones grounded in the cited Commission guidance, not as a complete enforcement calendar for every AI Act duty.

Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that is proportionate to the AI technologies and risks of the system. The system must actively and systematically collect, document, and analyse relevant data on the high-risk AI system's performance throughout its lifetime.

The monitoring system should be tied to a post-market monitoring plan that forms part of the Annex IV technical documentation. That means the plan should be maintained with the product file, not kept as an informal support-process note.

Deployers are not the Article 72 plan owner, but Article 26 makes them important monitoring inputs. Deployers must monitor high-risk AI systems on the basis of the instructions for use and, where relevant, inform providers under Article 72.

If a deployer has reason to consider that use in accordance with the instructions may present a risk under Article 79(1), 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, then the importer or distributor and the relevant market surveillance authorities; if the provider cannot be reached, Article 73 applies mutatis mutandis.

Provider handling should therefore separate ordinary performance feedback from nonconformity, risk, and serious-incident paths. Article 20 requires providers that consider or have reason to consider their high-risk AI system is not in conformity to immediately take corrective action to bring it into conformity, withdraw it, disable it, or recall it as appropriate.

The evidence should show that monitoring is systematic enough to evaluate continuing compliance, not just that incidents were logged. Keep the plan, the monitored signals, the analysis records, the outcomes, and the technical-documentation updates together so a reviewer can trace why a risk signal did or did not trigger corrective action, a conformity update, or a serious-incident report.

Annex IV also expects technical documentation to describe relevant lifecycle changes and the post-market performance-evaluation system, including the Article 72 monitoring plan. That makes change history part of the post-market monitoring evidence set.

Reopen the Article 72 review when the real-world system no longer matches the monitoring plan, instructions for use, technical documentation, or risk-management assumptions. The strongest triggers are changes that affect intended purpose, high-risk classification, performance, affected groups, human oversight, logs, integration context, or risk controls.

A distributor, importer, deployer, or other third party can become the provider for a high-risk AI system if it puts its name or trademark on the system, makes a substantial modification while the system remains high-risk, or modifies the intended purpose of a non-high-risk AI system so it becomes high-risk. Those lifecycle changes should not be treated as ordinary backlog items.

A provider is the actor that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark. That test is about development control, commissioning, market placement, service launch, and branding, not only technical authorship.

A deployer is the actor using an AI system under its authority, except for personal non-professional use. A company can therefore be a deployer of a supplier system even when the supplier remains the provider, because the company controls the concrete use context, users, operating process, input data under its control, and internal oversight.

The AI Act uses 'operator' as an umbrella term that includes provider, product manufacturer, deployer, authorised representative, importer, and distributor. It is useful for scoping the full value chain, but it is not enough for assigning concrete duties because the named roles have different triggers.

An authorised representative is a Union-based person with a written mandate from a provider to carry out obligations and procedures on the provider's behalf. An importer places on the Union market an AI system bearing the name or trademark of a third-country person. A distributor is a supply-chain actor, other than provider or importer, that makes an AI system available on the Union market.

A product manufacturer can become the provider of a high-risk AI system when the high-risk AI system is a safety component of a product covered by listed Union harmonisation legislation and is placed on the market or put into service under the product manufacturer's name or trademark.

Article 25 is the role-shift rule for high-risk AI systems. A distributor, importer, deployer, or other third party is treated as the provider, and is subject to provider obligations, when one of three triggers is met: it puts its name or trademark on an already placed or put-into-service high-risk AI system; it makes a substantial modification to an already placed or put-into-service high-risk AI system so that it remains high-risk; or it changes the intended purpose of an already placed or put-into-service AI system, including a GPAI system, so that the system becomes high-risk.

When an Article 25 shift occurs, the initial provider is no longer considered the provider of that specific AI system for AI Act purposes, but must closely cooperate with the new provider and provide necessary information, technical access, and other reasonably expected assistance. That cooperation rule does not apply where the initial provider clearly specified that its AI system must not be changed into a high-risk system.

A GPAI model provider is not automatically the provider of every AI system that later integrates the model. The legal text defines a general-purpose AI model separately, and Annex XII requires transparency information for downstream providers that integrate the model into their AI systems.

Commission GPAI guidance gives practical examples: the actor that develops and places a GPAI model on the Union market is the provider; an actor that has a model developed on its behalf and places it on the market is the provider; and a downstream actor integrating a GPAI model into an AI system may be the provider of that AI system.

For downstream modifications, the Commission guidance says not every modification makes the modifier a GPAI model provider. The modifier becomes the provider of the modified GPAI model only where the modification leads to a significant change in the model's generality, capabilities, or systemic risk, with the guidance giving an indicative training-compute criterion for that assessment.

The evidence should prove the legal role, the factual trigger, and the boundary of responsibility. Avoid one generic AI owner record. Instead, keep a role matrix for each AI system and GPAI model version, because the same supplier relationship can involve several actors at different layers of the value chain.

For deployer duties, preserve records showing use according to instructions, human oversight assignment, monitoring based on instructions for use, incident escalation to provider/importer/distributor and authorities where relevant, logs under deployer control, worker information where workplace use is involved, and any required fundamental-rights impact assessment for covered high-risk deployments.

For a high-risk AI system, Article 11 makes technical documentation a pre-market or pre-service requirement. The file must be drawn up before the system is placed on the market or put into service, kept up to date, and written to demonstrate compliance with the high-risk requirements in Chapter III, Section 2.

The documentation should let a national competent authority or notified body understand the system without reverse-engineering the product. A usable file therefore starts with system identity and intended purpose, then shows how design, data, testing, risk controls, human oversight, cybersecurity, conformity, and post-market monitoring support that intended purpose.

Treat Annex IV as a technical-file table of contents. The first section identifies what the system is and how it is supplied. The second section explains how it was built. Later sections show how it is monitored, controlled, tested, changed, and assessed against the AI Act requirements.

The strongest documentation is traceable: every claim about system purpose, data, model behavior, oversight, cybersecurity, performance, and residual risk points to a controlled artifact such as a requirements record, architecture diagram, dataset sheet, test report, risk-control register, release note, user instruction, or conformity file.

Annex IV does not stop at design-time evidence. It asks for the harmonised standards applied in full or in part when their references have been published in the Official Journal of the European Union. If no such harmonised standards have been applied, the file must describe the solutions adopted to meet the high-risk requirements and list other relevant standards and technical specifications applied.

The same file should include a copy of the EU declaration of conformity and a detailed description of the post-market system used to evaluate performance. Article 72 makes the post-market monitoring plan part of the Annex IV technical documentation.

Article 43 uses different routes for different high-risk AI systems. For high-risk systems listed in point 1 of Annex III, the provider may use Annex VI internal control only when it demonstrates compliance by applying harmonised standards under Article 40 or, where applicable, common specifications under Article 41.

For that same Annex III point 1 category, Annex VII notified-body assessment is required when harmonised standards and common specifications are not available, when the provider has not applied the relevant harmonised standard or has applied only part of it, when available common specifications have not been applied, or when a harmonised standard has been published with a restriction for the restricted part.

For high-risk AI systems in points 2 to 8 of Annex III, Article 43 says providers follow Annex VI internal control, with no notified-body involvement. For high-risk AI systems covered by the Union harmonisation legislation listed in Section A of Annex I, the provider follows the conformity assessment required by that product law, and the AI Act Section 2 requirements become part of that assessment.

Annex VI internal control is still a formal conformity assessment. The provider verifies that its quality management system complies with Article 17, examines the technical documentation to assess compliance with Chapter III Section 2 requirements, and verifies that design, development, and post-market monitoring are consistent with the technical documentation.

The evidence should therefore be more than a checklist. Article 11 requires technical documentation to be drawn up before placing the high-risk AI system on the market or putting it into service, kept up to date, and written so competent authorities and notified bodies can assess compliance. Annex IV lists expected content, including intended purpose, system versions, development methods, data requirements, human oversight, validation and testing, cybersecurity, risk management, standards used, the EU declaration of conformity, and post-market monitoring.

Annex VII adds notified-body review of both the provider's quality management system and the technical documentation for the AI system. The provider's application includes provider identity, the AI systems covered by the same quality management system, technical documentation for each system, quality-management documentation covering Article 17, procedures to keep the system adequate and effective, and a declaration that the same application was not lodged with another notified body.

The notified body examines whether the quality management system satisfies Article 17 and examines the technical documentation. Where needed, it may require further evidence or tests, carry out tests itself, and, after other reasonable means are insufficient, request access to training and trained models subject to applicable protection for intellectual property and trade secrets. If the system conforms, the notified body issues a Union technical documentation assessment certificate; if not, it refuses and gives reasons.

After approval, Annex VII creates an ongoing change and surveillance track. Intended changes to the approved quality management system, the covered system list, or an AI system change that could affect compliance or intended purpose must be brought to the notified body. The notified body carries out surveillance of the approved quality management system, including periodic audits.

The conformity assessment route should close into release evidence. Article 47 requires the provider to draw up a written, machine-readable, physical, or electronically signed EU declaration of conformity for each high-risk AI system, keep it available to national competent authorities for 10 years, identify the system, state conformity with the Section 2 requirements, include Annex V information, translate it for relevant national competent authorities, and keep it up to date.

Article 48 requires CE marking for high-risk AI systems. For digital high-risk AI systems, a digital CE marking can be used only when it is easily accessible through the system interface or through an accessible machine-readable code or other electronic means. Where a notified body was responsible for the Article 43 conformity assessment, its identification number follows the CE marking and is also indicated in promotional material that mentions CE conformity.

Article 49 registration is separate from CE marking and must be checked before release. Providers or authorised representatives register themselves and Annex III high-risk AI systems in the EU database before placing them on the market or putting them into service, except for point 2 of Annex III. Providers also register systems they concluded are not high risk under Article 6(3). Public authorities, Union institutions, bodies, offices, agencies, and persons acting on their behalf have deployer registration duties for covered Annex III systems before use.