Appearance
Commission guidance on general-purpose AI models
Chapter V of the EU AI Act (Regulation (EU) 2024/1689, as changed by Regulation (EU) 2026/1744) gives the rules for general-purpose AI (GPAI) models. The Commission gives guidance on the scope of these rules in its GPAI-scope Guidelines, Communication “C(2025) 7719 final” of 19 November 2025. These Guidelines are non-binding Commission interpretation, subject to the amended EU AI Act. For the obligations of GPAI model providers in Articles 53 to 55, see General-purpose AI models.
The GPAI model test
Article 3(63) test
An AI model is a GPAI model in Article 3(63) of the EU AI Act only if all of these conditions apply:
- The model “displays significant generality”.
- The model “is capable of competently performing a wide range of distinct tasks”. This condition applies “regardless of the way the model is placed on the market”.
- The model “can be integrated into a variety of downstream systems or applications”.
This includes models trained with large amounts of data using self-supervision at scale. Article 3(63) excludes AI models “that are used for research, development or prototyping activities before they are placed on the market”.
A GPAI model is not an AI system. Article 3(66) gives a different definition for a general-purpose AI system, which is “an AI system which is based on a general-purpose AI model”. See AI systems and GPAI models.
Commission guidance
The GPAI-scope Guidelines give an indicative criterion for the Article 3(63) test (paragraph (17)). On this indicative criterion, a model is considered a GPAI model when the two conditions that follow apply:
- Its training compute is more than 10²³ floating-point operations (FLOP).
- It can generate “language”, as text or audio, or it can generate “text-to-image” or “text-to-video”. In footnotes 3 and 4 of the Guidelines, text includes code, and audio includes “speech”.
In paragraph (18), 10²³ FLOP is approximately the typical compute to train a model with one billion parameters on a large quantity of data. Paragraph (16) tells providers that the Commission can change this method.
Exceptions
The criterion is indicative. Paragraph (20) of the GPAI-scope Guidelines gives two exceptions:
- A model that “meets the criterion” is not a GPAI model if, “exceptionally”, it “does not display significant generality” or “is not capable of competently performing a wide range of distinct tasks”.
- A model that “does not meet that criterion” is a GPAI model if, “exceptionally”, it “displays significant generality” and “is capable of competently performing a wide range of distinct tasks”.
The downstream integration condition and the full pre-market exclusion in Article 3(63) also apply.
The 10²³ FLOP criterion helps to find if a model is a GPAI model. It is different from the 10²⁵ FLOP presumption in Article 51(2), which is about systemic risk. See Classification of systemic risk.
Who is the provider
Article 3(3) of the EU AI Act gives the definition of a provider. For a GPAI model, the provider is a “natural or legal person, public authority, agency or other body” that does all of these:
- It develops the GPAI model, or it has the model developed.
- It places the model on the market “under its own name or trademark, whether for payment or free of charge”.
Placing on the market is “the first making available” of the model on the Union market (Article 3(9)). Making available on the market is “the supply of an AI system or a general-purpose AI model for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge” (Article 3(10)). In paragraph (47) of the GPAI-scope Guidelines, recital 97 gives these examples: “libraries, application programming interfaces (APIs), as direct download, or as physical copy”.
The GPAI-scope Guidelines give these examples of providers (paragraph (49)):
- Actor A develops a GPAI model and places it on the market. Actor A is the provider.
- Actor B develops a GPAI model for actor A, and actor A places it on the market. Actor A is the provider.
- Actor A develops a GPAI model and puts it in an “online repository hosted by actor C”. Actor A is the provider.
- A “collaborative or consortium” has a model developed for it and places the model on the market. The provider is “usually the coordinator of the collaborative or the consortium”. “Alternatively, the collaborative or the consortium might be the provider.”
Paragraph (50) tells providers to read these examples together with Article 3(3). The examples “require case-by-case assessment”.
The GPAI-scope Guidelines also give guidance for a GPAI model in an AI system (paragraphs (53)–(56)):
A provider of a GPAI model can integrate its model into its AI system. When that system is made available on the market or put into service, the model is also placed on the market. The obligations for the model apply together with the obligations for the AI system (recital 97, paragraph (54)). Recital 97 qualifies this rule for an own model used for purely internal processes. Model obligations do not apply if all of these conditions apply:
- The processes are “not essential for providing a product or a service to third parties”.
- The condition that “the rights of natural persons are not affected” applies.
Recital 97 also specifies that GPAI models with systemic risk “should always be subject to the relevant obligations under this Regulation”.
An upstream actor can make its model available for the first time to a downstream actor on the Union market. Then the upstream actor is the provider of the model. The downstream actor that integrates the model into an AI system can be the provider of the AI system (paragraph (55)).
An upstream actor can make its model available for the first time to a downstream actor “outside the Union market”. The downstream actor then integrates the model into an AI system. That AI system is placed on the market or put into service in the Union. In this example, the model is placed on the market at that time (paragraph (56)).
For that last example, the upstream actor is the provider of the model. But the upstream actor can have “excluded, in a clear and unequivocal way, the distribution and use of the model on the Union market”, “including its integration into AI systems that are intended to be placed on the Union market or put into service in the Union”. Then the downstream actor that integrates the model into the AI system is the provider of the model (paragraph (56)).
Article 54(1) gives this obligation to some providers of GPAI models: “Prior to placing a general-purpose AI model on the Union market, providers established in third countries shall, by written mandate, appoint an authorised representative which is established in the Union.” For this obligation, see General-purpose AI models.
Model lifecycle
The GPAI-scope Guidelines give the Commission interpretation of a GPAI model and its lifecycle “in a broad sense” (paragraph (22)). In this interpretation, the lifecycle starts when the large pre-training run starts. Footnote 6 of the Guidelines tells providers that this is the “foundational training run conducted on a large amount of data to build the model’s general capabilities”.
Paragraph (22) gives this guidance for a provider that continues to “develop” its model:
Any subsequent development of the model downstream of this large pre-training run performed by the provider or on behalf of the provider, whether before or after the model has been placed on the market, forms part of the same model’s lifecycle rather than giving rise to new models.
This interpretation does not stop the obligations of the provider. Paragraph (23) of the GPAI-scope Guidelines tells providers to do these tasks for the full lifecycle of each model:
- Keep the technical documentation and the information for downstream providers “up to date” (Article 53(1), points (a) and (b)).
- Apply the copyright policy (Article 53(1), point (c)). One policy for all models of the provider is permitted.
- Make the training summary of each model placed on the market “publicly available” (Article 53(1), point (d)).
- For a GPAI model with systemic risk, do the “systemic risk assessment and mitigation” of Article 55(1) continuously.
The Commission gives the conditions to change the training summary in its Explanatory Notice, Communication “C(2025) 8311 final” of 5 December 2025. Paragraph (29) of the Notice tells the provider to change the summary when it trains its model on more data that makes this change necessary. The provider does this at “six-month” intervals, or before that time if the new data makes a “materially significant update” of the summary necessary.
Paragraph (30) of the GPAI-scope Guidelines tells providers to monitor their compute for the full lifecycle of the model. The provider must notify the Commission when the cumulative training compute is above the Article 51(2) threshold. The provider must also notify when it knows that the compute will be above that threshold (Article 52(1)). See Notification.
When a different actor modifies the model, a different test applies. See When a model modifier becomes a provider.
When a model modifier becomes a provider
The GPAI-scope Guidelines give the Commission interpretation for downstream modifiers (paragraphs (57)–(68)). A downstream modifier is an actor that is “distinct from the original provider and not acting on its behalf” and that modifies a GPAI model. The downstream modifier can integrate the model into an AI system, but this is not necessary. In footnote 12, fine-tuning is one type of modification. The EU AI Act does not give the conditions in which a downstream modifier becomes a provider (paragraph (57)).
Footnote 13 of the Guidelines gives guidance on who modifies a model, the original provider or a downstream actor. This “must be assessed on a case-by-case basis”. In that footnote, “An important factor in this assessment may be who has the control over the model’s weights, for example, in case of fine-tuning via API.”
Test in paragraph (59)
In the Commission interpretation, not all modifications make the downstream modifier a provider (paragraph (58)). Paragraph (59) gives the test: the downstream modifier becomes the provider of the modified model “only if the modification leads to a significant change in the model’s generality, capabilities, or systemic risk”.
Compute criterion for modification
Paragraph (60) of the GPAI-scope Guidelines gives an indicative criterion for this test. On this indicative criterion, the downstream modifier is considered a provider if modification training compute exceeds one-third of the original model's training compute. For the definition of training compute, paragraph (60) refers to paragraph (115). See Training compute.
The criterion is indicative. It does not replace the test in paragraph (59). A compute value above or below 1/3 is not sufficient to find if the downstream modifier is a provider. Paragraph (64) tells providers that the criterion is “primarily forward-looking”, and that the Commission can change its method.
Paragraph (61) gives a different threshold for one condition only. This condition applies when the downstream modifier “cannot be expected to know” the training compute of the original model, and also “cannot estimate it”. Then the threshold is:
- 1/3 of 10²⁵ FLOP, if the original model is a GPAI model with systemic risk
- 1/3 of 10²³ FLOP, if the original model is not a GPAI model with systemic risk.
Obligations of the downstream modifier
The GPAI-scope Guidelines give this guidance on a downstream modifier that becomes a provider:
- The documentation in Article 53(1), points (a) and (b), is only about the modification (recital 109, paragraph (65)). The copyright policy and the training summary are only about the data used for the modification (Article 53(1), points (c) and (d)).
- The downstream modifier must also obey Article 54 on authorized representatives (paragraph (66)).
- If the original model is a GPAI model with systemic risk, the modified model is presumed to have high-impact capabilities. Then it is a GPAI model with systemic risk in Article 51(1), point (a). The downstream modifier must obey the obligations for these models and notify the Commission in Article 52(1) (paragraphs (67)–(68)).
Article 25(1) of the EU AI Act is a different rule. It makes a distributor, importer, deployer, or other third party the provider of a high-risk AI system in three conditions. It is not the test for a modified GPAI model. See Substantial modification.
Training compute
The Annex of the GPAI-scope Guidelines tells providers how to estimate training compute (paragraph (114)). Providers use these estimates for the thresholds of the EU AI Act and of the Guidelines.
Two definitions of training compute
In paragraph (115) of the GPAI-scope Guidelines, training compute has one of two definitions:
- For a model that is not a GPAI model with systemic risk: “the total amount of compute directly contributing to parameter updates in the model”.
- For systemic risk: “the cumulative amount of compute used to train the model if, and for the purpose of assessing whether, the model is a general-purpose AI model with systemic risk”.
Training compute to include
For cumulative training compute, recital 111 of the EU AI Act gives these examples: “pre-training, synthetic data generation and fine-tuning” (paragraph (116)). The GPAI-scope Guidelines give this guidance:
- As a general rule, providers include “all compute that contributed or will contribute to the model’s capabilities”. This includes all compute “directly contributing to parameter updates in the model” (paragraph (116)).
- If the model is trained on synthetic data that is “not publicly accessible”, the provider includes the compute used to generate that data. This includes the compute for data that the provider made and then discarded. For example, if the provider made 100 samples and selected only 10 for training, it includes the compute used to generate all 100 samples (paragraph (117)).
- When a model “has been created by combining model weights”, the compute “used to train the combined model weights should be included” (paragraph (118)).
Paragraph (119) gives examples of compute that it is not necessary to include. These examples “may change as technology evolves”:
- “compute used to generate synthetic data which is publicly accessible”
- “compute spent on purely diagnostic processes that do not contribute to enhancing model capabilities, such as model evaluations or red-teaming”
- “compute whose expenditure contributes to enhancing model capabilities only through lessons learnt by humans”, for example “experiments in synthetic data generation that fail and whose results are discarded”
- “compute used to train parent model(s) used in distillation”, and compute to train “auxiliary model(s) such as value functions or reward models”
- “recomputation of activations to save memory”.
Two methods to estimate training compute
The GPAI-scope Guidelines give two methods (paragraph (121)):
Hardware-based approach (Annex A.2.1). The provider estimates four values, for actual or expected use (paragraph (123)):
- the number of GPUs or other hardware units
- the “total duration of use”, in seconds
- their “peak theoretical performance”, in FLOP/second
- the “average percentage of GPU utilisation” for that time.
For hardware types with different peak performances, the provider uses a weighted average of those performances. The weights are the numbers of units of each type (paragraph (123)).
If the provider uses all counted units for the full period, multiply these four values to calculate the training compute (paragraph (124)). When the number of units changes, the provider can calculate each period with a constant count and add the estimates. These periods must include the full training time (paragraph (125)).
Architecture-based approach (Annex A.2.2). The provider estimates the number of operations directly from the architecture of the model (paragraph (127)). For some “dense large language models” that are “based on the transformer architecture”, the training compute is approximately 6 × the number of parameters × the number of training tokens (paragraph (129)).
All operations count the same, “independently of floating-point precision” (paragraph (122)).
Accurate estimates
Paragraph (120) of the GPAI-scope Guidelines lets providers use “any method” to estimate the training compute. The condition is that the estimate is, “in the providers’ best judgement, accurate within an overall error margin of 30% of the reported estimate”. Providers “are nevertheless expected to document the assumptions made in making their estimations, including the method of estimation, and the associated uncertainties”.
Free and open-source models
Articles 53(2) and 54(6) of the EU AI Act give exceptions for providers of models released “under a free and open-source licence”. The exceptions apply only if all of these conditions apply:
- The license “allows for the access, usage, modification, and distribution of the model”.
- The parameters of the model, “including the weights, the information on the model architecture, and the information on model usage, are made publicly available”.
- The model is not a GPAI model with systemic risk.
When these conditions apply, these obligations do not apply to the provider:
- the technical documentation in Article 53(1), point (a)
- the information and documentation for downstream providers in Article 53(1), point (b)
- the authorized representative in Article 54.
The copyright policy (Article 53(1), point (c)) and the training summary (Article 53(1), point (d)) apply to all providers of GPAI models. They also apply when the model is free and open-source (paragraph (72) of the GPAI-scope Guidelines).
License conditions
In paragraph (75) of the GPAI-scope Guidelines, the license must give all four rights: access, use, modification, and redistribution. If one of these rights is missing, the license is not free and open-source in the EU AI Act. Paragraph (80) gives examples of conditions “that would disqualify a licence”:
- “limitations to non-commercial or research-only use”
- “prohibitions on distributing the model or its components”
- “usage restrictions triggered by user scale thresholds”
- “requirements to obtain separate commercial licences for specific use cases”.
In paragraph (81), a license can contain “specific, safety-oriented terms that reasonably restrict usage in applications or domains where such use would pose a significant risk to public safety, security, or fundamental rights”. They must be “proportionate to the risks being mitigated”, and “based on objective, non-discriminatory criteria”.
Monetization
In paragraph (82) of the GPAI-scope Guidelines, the exceptions apply only if “no monetary compensation should be required in exchange for access, use, modification, and distribution of the model”. Paragraph (83) gives these examples of monetization:
- “a dual licensing model or a comparable approach that allows free academic use but requires payment for commercial usage or use over a certain scale”
- “technical support and other services that are indistinguishably linked to the model itself or its security, and without which the model would not work or be accessible, provided against payment”
- “users must purchase support, training, and maintenance services to access the model”
- the model is “exclusively hosted by the provider on its individual hosting platform or website that requires users to pay for access, including when users can freely access the platform or website but are served with paid advertisements”.
Paragraph (84) gives one more condition:
access, use, modification, or redistribution of the model requiring the collection or otherwise processing of personal data should be treated in same manner as monetisation strategies, unless that processing is exclusively and strictly limited to the security of the model and without any commercial or financial gain.
Paragraph (85) gives these examples that are not monetization:
- “paid services that do not affect the usability or free usage of the model and that are purely optional”
- “paid services or support are made available alongside the model, without any purchase obligation, as long as the model’s usage and free and open access are guaranteed”.
In paragraph (86), “The monetisation aspect is considered absent for transactions between microenterprises.”
Classification of systemic risk
Article 51(1) of the EU AI Act gives the conditions for the classification of a GPAI model as a GPAI model with systemic risk. One of these conditions must apply:
- (a) The model has high-impact capabilities, “evaluated on the basis of appropriate technical tools and methodologies, including indicators and benchmarks”.
- (b) The Commission makes a decision that the model has “capabilities or an impact equivalent to those set out in point (a)”. The Commission makes this decision ex officio or after a qualified alert from the scientific panel, with the criteria in Annex XIII.
Article 3(64) gives the definition of high-impact capabilities: “capabilities that match or exceed the capabilities recorded in the most advanced general-purpose AI models”. Article 3(65) gives the definition of systemic risk.
Article 51(2) gives a presumption. A GPAI model is presumed to have high-impact capabilities when its cumulative training compute is more than 10²⁵ FLOP. In paragraph (26) of the GPAI-scope Guidelines, the classification applies from the time when one of the two conditions of Article 51(1) applies. The provider must then obey the obligations for these models. Article 51(3) lets the Commission change the thresholds with delegated acts.
Notification
Article 52(1) of the EU AI Act gives this obligation. When the condition in Article 51(1), point (a), applies to a GPAI model, the provider must notify the Commission. The provider must do this “without delay and in any event within two weeks after that requirement is met or it becomes known that it will be met”. The notification must include “the information necessary to demonstrate that the relevant requirement has been met”.
The GPAI-scope Guidelines give this guidance on notification:
- A notification can be necessary before the training is complete. Providers estimate their cumulative training compute before the large pre-training run, and then monitor their compute (paragraph (30)).
- For a notification on the compute threshold, the information includes the compute that the provider estimates, in FLOP “with two significant figures”. It also includes the method of the estimate (paragraph (31)).
The Commission can designate a GPAI model “presenting systemic risks of which it has not been notified” (Article 52(1)). In paragraph (43) of the Guidelines, the provider that did not notify can also get a fine in Article 101.
Arguments against classification
With its notification, the provider can give arguments against the classification. Article 52(2) tells the provider that it “may present, with its notification, sufficiently substantiated arguments to demonstrate that, exceptionally, although it meets that requirement, the general-purpose AI model does not present, due to its specific characteristics, systemic risks”. These arguments do not replace the notification. If the arguments are not sufficiently substantiated, the Commission rejects them, and the model is a GPAI model with systemic risk (Article 52(3)).
The GPAI-scope Guidelines give two types of argument:
- The model does not have high-impact capabilities (paragraphs (33)–(36)). The provider gives information on the capabilities of the model, for example benchmark results. The Commission recommends that the provider adds other information, for example the architecture, the input and output modalities, and the “expected tool use”. The Commission examines if the arguments are sufficiently substantiated and “manifestly calling into question this presumption”. In paragraph (33), the Commission tells providers that it is their task to show that the presumption does not apply.
- The model “does not present systemic risks despite having high-impact capabilities” (paragraph (39)). In the Commission interpretation, arguments from mitigations “already or planned to be implemented are not suitable grounds”. The provider can use these mitigations for its systemic-risk mitigation in Article 55(1).
Paragraph (40) of the GPAI-scope Guidelines gives the results of the Commission decision:
- If the Commission rejects the arguments, the systemic-risk obligations apply from the time when the condition in Article 51(1), point (a), applied. The arguments do not stop these obligations while the Commission examines them.
- If the Commission accepts the arguments, the systemic-risk obligations stop when the provider gets the decision. The provider must notify the Commission again if a substantial change in the facts behind the “acceptance decision” occurs or becomes known to be forthcoming. The provider must also notify if it learns that the decision relied on “substantially incomplete, incorrect or misleading information”. For each notification, the provider must give the Commission all “relevant information”. Also, the decision does not prevent a subsequent designation of the model by the Commission.
Designation by the Commission
Article 52(4) of the EU AI Act lets the Commission designate a GPAI model “as presenting systemic risks”. The Commission does this ex officio or after a qualified alert from the scientific panel, with the criteria in Annex XIII. In paragraph (44) of the GPAI-scope Guidelines, the provider must obey the systemic-risk obligations from the time when it gets the designation decision.
Annex XIII, point (e), includes “the benchmarks and evaluations of capabilities of the model, including considering the number of tasks without additional training, adaptability to learn new, distinct tasks, its level of autonomy and scalability, the tools it has access to”. The autonomy of a model and its access to tools are criteria for a designation decision. They do not automatically make a model a GPAI model with systemic risk. The GPAI-scope Guidelines do not give guidance on AI agents.
Article 52(5) lets a provider send a “reasoned request” for reassessment of a designation in Article 52(4). The Commission “shall take the request into account” and has discretion to reassess systemic risk against the criteria in Annex XIII. The provider must give “objective, detailed and new reasons that have arisen since the designation decision”. The provider can “request reassessment” no earlier than six months after the designation decision. If the Commission maintains the designation after reassessment, the provider can “request reassessment” again no earlier than six months after that decision.
Codes of Practice
Article 56 of the EU AI Act gives the rules for codes of practice for GPAI models. A code of practice is a voluntary tool. It does not add obligations to the EU AI Act.
Use of a code. Providers of GPAI models “may rely on codes of practice within the meaning of Article 56 to demonstrate compliance” with Article 53(1) and Article 55(1), “until a harmonised standard is published” (Articles 53(4) and 55(2)). Providers that do not adhere to an approved code of practice, or that do not “comply with a European harmonised standard”, must show “alternative adequate means of compliance for assessment by the Commission”.
Adequacy. Regulation (EU) 2026/1744 replaced Article 56(6). The Commission, “taking utmost account of the opinion of the Board”, examines if the codes of practice include the obligations in Articles 53 and 55. The Commission must publish “its assessment of the adequacy of the codes of practice”.
No presumption of conformity. A GPAI model that complies with harmonized standards or parts of them has a presumption of conformity on these conditions (Articles 40(1), 53(4), and 55(2)):
- The references of those standards or parts are published in the Official Journal of the European Union.
- The presumption applies only to the obligations that those standards include.
A code of practice does not give a presumption of conformity (paragraph (97) of the GPAI-scope Guidelines, recital 41 of Regulation (EU) 2026/1744).
Paragraph (96) of the GPAI-scope Guidelines gives a procedure for approval of a code with an implementing act. This text is about Article 56(6) before Regulation (EU) 2026/1744. The new Article 56(6) does not contain this procedure.
The Commission page on the General-Purpose AI Code of Practice gives 10 July 2025 as its date of publication. The Commission and the AI Board found that the Code is “an adequate voluntary tool for providers of GPAI models to demonstrate compliance with the AI Act”. The Code has three parts: Transparency and Copyright for Article 53, and Safety and Security for Article 55.
The GPAI-scope Guidelines give this guidance on codes (paragraphs (91)–(93)). This guidance does not add obligations to the EU AI Act:
- For signatories of a code “assessed as adequate”, the Commission “will focus its enforcement activities on monitoring their adherence to the code of practice”. “Any opt-out from chapters of the code of practice results in losing the benefits of facilitating the demonstration of compliance in that respect.”
- For providers that do not adhere to such a code, paragraph (92) gives this guidance. They “are expected to demonstrate how they comply with their obligations under Chapter V of the AI Act via other adequate means”. They also report their measures to the AI Office. The Guidelines give an example: “carrying out a gap analysis” against such a code. These providers can get more requests for information and for access to do model evaluations.
- The Commission can use the commitments of a provider in such a code “as a mitigating factor when fixing the amount of fines” (paragraph (93), Article 101(1)).
Enforcement and application dates
For GPAI model providers, the Act has different enforcement dates and rules on when the Act applies, with more time to comply for models placed on the market before 2 August 2025 (Article 111(3)).
Use Modulos
Modulos gives the EU AI Act as two Frameworks: OFF-1 for the Organization and MFF-1 for each AI System. For the Requirements and the steps for GPAI model providers, see Operationalizing the EU AI Act in Modulos.
Sources
- GPAI-scope Guidelines: “Commission Guidelines on the scope of the obligations for providers of general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act)”, Communication from the Commission “C(2025) 7719 final”, 19 November 2025. Commission text. Commission page.
- Paragraphs (9), (16)–(18), (20), (22)–(23), (26), (30)–(31), (33)–(36), (39)–(40), (43)–(45), (47), and (49)–(51).
- Paragraphs (53)–(68), (72), (75), (80)–(86), (91)–(93), (96)–(97), and (114)–(129).
- Footnotes 3, 4, 6, 12, and 13.
- Training summary: “Explanatory Notice and Template for the Public Summary of Training Content for general-purpose AI models required by Article 53 (1)(d) of Regulation (EU) 2024/1689 (AI Act)”, Communication from the Commission “C(2025) 8311 final”, 5 December 2025. Paragraph (29). Commission text.
- EU AI Act: Regulation (EU) 2024/1689 of 13 June 2024, consolidated version of 27 July 2026. EUR-Lex.
- Articles 3(3), 3(9), 3(10), 3(63)–(66), 25(1), 40(1), 51 to 56, and 101.
- Articles 111(3) and 113, and Annex XIII.
- EU AI Act, recitals: Regulation (EU) 2024/1689 as published in the Official Journal on 12 July 2024. Recitals 97, 109, and 111. EUR-Lex.
- Digital Omnibus on AI: Regulation (EU) 2026/1744 of 8 July 2026, published in the Official Journal on 24 July 2026. Article 1, point (21), which replaces Article 56(6), and recital 41. EUR-Lex.
- General-Purpose AI Code of Practice: Commission page “The General-Purpose AI Code of Practice”, last changed on 7 October 2026. Commission page. Commission page “Commission Opinion on the assessment of the General-Purpose AI Code of Practice”, 1 August 2025. Commission page.
Disclaimer
This page gives general information. It is not legal advice.