Which EU AI Act general-purpose AI obligations apply to your organization
If you build, fine-tune or host a general-purpose AI model, Chapter V of the AI Act requires every provider to keep Annex XI technical documentation for the AI Office, give Annex XII information to downstream providers, adopt an EU copyright policy that respects text and data mining opt-outs, and publish a training content summary on the AI Office template. These duties have applied since 2 August 2025, and the Commission can enforce them, including with fines, from 2 August 2026. Your first task is to decide whether you are a provider at all: a downstream party that modifies a model becomes its provider when, indicatively, the modification uses more than a third of the original training compute, so confirm that figure against the Commission's guidelines of 18 July 2025 before you assume you are only a deployer.
Two tiers change the duties. Free and open-source models with public weights, architecture and usage information are exempt from the two documentation duties and from appointing an authorised representative, but they keep the copyright policy and training summary, and the exemption falls away if the model has systemic risk. Models trained with more than 10^25 FLOP are presumed to have systemic risk, so you must notify the Commission within two weeks of meeting or foreseeing that threshold, and you then take on state-of-the-art evaluation including adversarial testing, systemic risk mitigation, serious incident reporting and protection of the model infrastructure. Check your training compute records now, because the Commission has said the threshold is under review.
Your organization owns these obligations, and the Code of Practice is a route to show compliance, not a substitute for it. An implementation partner can help you assemble the documentation, copyright policy, training summary and evidence trail, and can build the systems that hold them, but only you can sign the documents and answer to the AI Office. Ask any partner to show how the work maps to each Chapter V duty, and confirm with your legal team which signatory chapters of the Code of Practice you will rely on before you scope the work.
What every provider must produce
Every provider of a general-purpose AI model owes four deliverables under Article 53(1), whatever the model's size or license. Each one needs a named owner, a dated record and an artifact an assessor can open, so the gaps usually show up in ownership before they show up in the documents.
Annex XI technical documentation
This is the full technical file on the model, kept current and made available to the AI Office on request. An assessor will look for the training data description, compute used, architecture, evaluation results and known limitations, each traceable to a version of the model. Model engineering owns the content, and legal confirms the file is kept up to date at each release. Check that the file is versioned with the weights it describes.
Annex XII downstream information
This is the information package given to downstream providers who integrate the model into their own AI systems, so they can meet their own obligations. Expect a record of capabilities, limitations, intended integration use and the technical details a downstream team needs. Product or partner management owns the package, and the evidence is the version-matched copy sent to each recipient. Check that the recipients and the dates they received it are logged, because downstream providers will rely on it.
EU copyright policy
The provider must adopt a written copyright policy that respects text and data mining opt-outs expressed by rightsholders under EU law. An assessor will ask how crawlers and data sources honor those opt-outs, and how the provider documents that it did so during training. Legal and data governance own the policy, and crawler logs and exclusion records are the evidence. Check that the policy describes an operating process, not only a statement of intent.
Public training content summary
The provider must publish a summary of the content used for training, written on the AI Office template that the Commission presented on 24 July 2025. The summary is public, so it must match the internal records of data sources and must not disclose more than the template requires. Legal publishes the summary, and data engineering supplies the source inventory behind it. Check that the summary is reviewed against the training data record before each publication.
When free and open-source models are exempt
A free and open-source general-purpose AI model is exempt from two of the Chapter V documentation duties and from the requirement to appoint an authorised representative, but only when it has public weights, architecture and usage information and does not carry systemic risk. Under Articles 53(2) and 54(6), the exemption removes the Annex XI technical documentation duty, the Annex XII downstream information duty and the authorised representative obligation for non-EU providers. It does not remove the duty to adopt an EU copyright policy that respects text and data mining opt-outs, or the duty to publish a training content summary on the AI Office template under Article 53(1). A provider releasing an open model should plan both of those outputs regardless of the licence chosen.
The exemption is lost entirely if the model has systemic risk. Models trained with more than 10^25 FLOP are presumed to have systemic risk under Article 51(2), and the provider must notify the Commission within two weeks of meeting or foreseeing that threshold under Article 52(1). Once a model is in that tier, the open-weight status no longer shields it from the full set of duties, including state-of-the-art evaluations with adversarial testing, serious incident reporting and protection of the model and its infrastructure under Article 55. Confirm the training compute of each model against the threshold before release, and record the calculation, because the Commission has said the threshold is under review.
A licence alone does not establish the exemption. An Apache 2.0 or MIT licence on a repository does not prove that the weights, architecture and usage information are public in the sense the Act requires, and a licence that restricts commercial use or certain applications may undermine the open-source claim in the Commission's guidelines. Before relying on the exemption, check that each element is published, that the release is not in a restricted or systemic-risk tier, and that the provider can show this to the AI Office on request. Downstream teams that fine-tune an open model should also check the one-third compute test for becoming a provider of a modified model.
How the systemic-risk tier adds duties above 10^25 FLOP
The sequence starts with a training-compute threshold and ends with a protected model and a documented record of risk management. Each step produces evidence the AI Office can review, so a provider should be able to show it at every stage.
Measure training compute against the 10^25 FLOP threshold
The provider totals the training compute used for the model and compares it with 10^25 floating-point operations. Under Article 51(2), a model trained with more than that amount is presumed to have systemic risk. Finance, ML engineering and legal should agree the calculation method and keep the compute records with the model's technical documentation. The check is complete when the compute figure, its method and the date of the comparison are on file. The threshold is under review, so the provider should also track any change the Commission announces.
Notify the Commission of the systemic-risk threshold
Once the provider meets or foresees the threshold, it must notify the Commission within two weeks under Article 52(1). The notice is the point at which the systemic-risk regime starts for that model. Legal and compliance own the notification, and the AI Office receives it through the EU SEND platform. The step closes when the provider holds the submission record and a dated internal note showing when the threshold was first met or foreseen. Ask counsel to confirm how a foreseen threshold is documented before training begins.
Run state-of-the-art model evaluations
Under Article 55, the provider must evaluate the model using current, state-of-the-art protocols and tools, including adversarial testing. The evaluation team records test plans, the model version tested, results and any remediation. Evaluations usually involve safety engineers and, where the provider uses third parties, external testers. The output is an evaluation report that links each test to a documented risk. Organizations that want independent security testing of the model and its surrounding systems can scope that work with an implementation partner, but the provider remains responsible for the evaluation outcome.
Assess and mitigate Union-level systemic risks
The provider must identify risks that could have significant effects across the Union, assess how serious they are, and put mitigations in place. The assessment draws on the evaluation results, known misuse paths and downstream integration. Risk owners sign off on each mitigation, and the risk register records the residual risk and the review date. The step is complete when each identified Union-level risk has an owner, a mitigation and a documented decision on whether the residual risk is acceptable. Ask the provider's counsel to confirm how the Code of Practice safety and security chapter maps to these assessments.
Track and report serious incidents to the AI Office
The provider must keep a process for detecting serious incidents involving the model and report them to the AI Office under Article 55. Incident response teams, product owners and the security function share responsibility, with logs kept for each event. A report is complete when it records what happened, the model version involved, the mitigations applied and the follow-up actions. The reporting procedure should be tested before launch so the team knows who escalates and how the AI Office receives the report.
Protect the model and its infrastructure
Article 55 also requires adequate cybersecurity protection for the model and its physical infrastructure. Security engineering applies access controls, secrets management, monitoring and hardening to the training and serving environments, then records them in a security control register. Evidence includes configuration baselines, access reviews and penetration test results. The step is done when the controls are documented, tested and reviewed on a schedule the provider sets. Self-hosted platforms in the provider's own infrastructure can produce much of this evidence, provided the logs and configuration records are retained.
Keep the systemic-risk record current
The provider updates its documentation, evaluation results, risk assessments and incident records whenever the model, its training or its deployment changes. Compliance leads review the file against the threshold and the Commission's guidance, which is still under review. The output is a maintained technical file that an AI Office inquiry can be answered from without reconstruction. Ask whether the organization has assigned one owner for the file and whether its review cycle is written into the governance policy.
Using the General-Purpose AI Code of Practice to show compliance
The transparency chapter covers the documentation that providers keep and share, and it is the chapter most closely tied to the statutory documentation duties in Article 53. It asks providers to record how a model was built, what it can do, and where it may be used, so that the AI Office and downstream providers work from the same information. Signing this chapter commits a provider to follow the code's documentation approach, which it can then map onto its own records.
- Single model record: Keep one current record covering architecture, training compute, data sources at a category level, intended tasks and known limitations.
- Downstream information: Prepare the information that downstream providers need to build on the model, and track which versions each integrator received.
- Update triggers: Set a review step whenever training, fine-tuning or the model record changes materially, so documentation does not drift from the released model.
- Evidence retention: Store dated versions of each record together with the approval trail, since an assessor or the AI Office would ask to see both.
Before relying on the code for Article 53 purposes, check that each transparency commitment maps to a specific document you can produce on request.
The copyright chapter addresses two statutory duties: an EU copyright policy that respects text and data mining opt-outs, and a public training content summary. Article 53(1) requires both from every provider, and the Commission presented the mandatory summary template on 24 July 2025. Signing this chapter commits a provider to a documented approach to how training data is collected and how rightsholder interests are handled.
- Opt-out handling: Document how crawlers and data pipelines identify and honor machine-readable text and data mining opt-outs.
- Rights records: Record the licences, opt-out checks and exclusion lists applied during data collection, including data bought from third parties.
- Training summary: Publish a summary on the AI Office template and keep the underlying record that supports each statement in it.
- Complaints route: Name a contact point and a written process for rightsholder complaints, and log how each one was resolved.
Ask counsel to confirm whether the code's copyright commitments cover every data source your training pipeline uses, including licensed and synthetic data.
The safety and security chapter matters most for models with systemic risk. A model trained with more than 10^25 FLOP is presumed to carry systemic risk under Article 51(2), and Article 55 then requires state-of-the-art evaluations, including adversarial testing, an assessment of Union-level systemic risks, serious incident reporting and protection of the model and its infrastructure. Signing this chapter commits a provider to a documented safety and security framework that addresses those duties. xAI signed only this chapter.
- Systemic risk assessment: Maintain a written assessment of Union-level systemic risks and the mitigations applied to each.
- Adversarial testing: Schedule evaluations, including adversarial testing, and keep results tied to the exact model version tested.
- Incident reporting: Define how serious incidents reach the AI Office and set internal deadlines that leave room for the required notifications.
- Infrastructure protection: Apply access controls, logging and monitoring to model weights and to the training and serving environments.
Check first whether your model meets the systemic-risk presumption, because the Article 55 duties apply by statute whether or not you sign this chapter.
The Commission and the AI Board found the General-Purpose AI Code of Practice, published on 10 July 2025, adequate on 1 August 2025. The Commission's code page, updated 7 October 2026, lists signatories including Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI and OpenAI. xAI signed only the safety and security chapter. Signing is voluntary, produces no certificate, and does not replace the statutory duties in Chapter V.
- Chapter-level signing: A provider can sign some chapters and not others, so a name on the list does not tell you which commitments apply.
- Check the current list: Confirm signatory status on the Commission code page before you cite it in a contract or assessment file.
- No independent verification: Signing creates no conformity finding, and no independent body checks that signatories meet their chapter commitments.
- Statutory duties remain: Documentation, copyright policy and training summary duties under Article 53 apply to every provider, whether or not it signed.
When a model provider sits in your supply chain, ask which chapters it signed and what evidence supports each one, rather than accepting the signatory list as proof.
Deadlines for models placed before and after 2 August 2025
This sequence sorts each general-purpose AI model into the correct deadline group based on its placement date, so the provider knows which duties already apply, when the Commission can fine, and when legacy models must comply. The output is a dated record per model that the compliance file can rely on.
Confirm the placement date of each model
Start by fixing the date each model was first placed on the EU market, not the date it was trained or announced. Pull this from release records, contract and licensing files, and distribution logs, and ask the team that shipped the model to sign off on the date. The output is a register with one row per model and version, showing its placement date and whether any version was placed after 2 August 2025. Treat a missing or disputed date as an open item until it is resolved, because it decides which deadline applies.
Sort models into the two deadline groups
Divide the register into models placed on the market on or after 2 August 2025 and models placed before that date. Models in the first group were subject to the Chapter V obligations from the moment they were placed, while models in the second group have until 2 August 2027 to comply under the transition rule in Article 111(3). Record the reason for each assignment next to the row. The output is a grouped register that the legal or compliance lead reviews and approves.
Apply the obligations from 2 August 2025
For every model placed on the market on or after 2 August 2025, confirm that the Chapter V duties are already in force. These include keeping the Annex XI technical documentation, giving Annex XII information to downstream providers, adopting an EU copyright policy, and publishing a training content summary. Assign an owner to each duty and set the evidence location. The output is a gap list for each post-August 2025 model, ordered by the duties still missing.
Prepare for Commission enforcement from 2 August 2026
From 2 August 2026 the Commission can enforce the Chapter V obligations, including with fines of up to 3% of worldwide annual turnover or EUR 15 million, whichever is higher, under Article 101. Use the gap list from the previous step to prioritize closures before that date, and check whether the code of practice commitments your organization relies on are documented in the file. The output is a dated remediation plan that shows which gaps close before enforcement begins.
Schedule compliance for legacy models
For each model placed on the market before 2 August 2025, set the deadline of 2 August 2027 as the date by which full compliance must be in place. Do not assume a legacy model is exempt because it was released early, and do not treat a later substantial modification as a legacy placement without checking it under the modification guidance. The output is a dated plan per legacy model that lists the Chapter V duties to be completed before the deadline.
Check model versions and modifications
Review whether any legacy model has been updated, retrained, or fine-tuned by your organization in a way that could make it a new model placed on the market after 2 August 2025. Under the Commission's guidelines of 18 July 2025, a modification that uses more than a third of the original training compute can make the modifier the provider of the modified model, indicatively. Confirm this with legal counsel and the engineering records. The output is a documented decision for each version that either keeps it in the legacy group or moves it to the post-August 2025 group.
Record the deadline file for audit
Assemble one file that holds the final register, the placement evidence for each model, the gap lists, the remediation dates, and the modification decisions. Keep it under version control and date every entry so an assessor or the AI Office can trace each decision back to its source. Review the file whenever a new model is placed on the market or an existing model changes. The output is a dated compliance record that shows which deadline applied to each model and how the organization met it.
Who enforces Chapter V and what the fines are
Chapter V is enforced centrally, not by national authorities alone. The cards below set out who holds the enforcement powers, what the fine ceiling is, how the AI Office's competence reaches models embedded in a provider's own systems, and where submissions go, so that compliance planning reflects the actual enforcement path.
AI Office holds exclusive enforcement
Under Article 88, the Commission acting through the AI Office has exclusive powers to enforce the general-purpose AI model rules in Chapter V. National market surveillance authorities do not supervise these duties for the model itself. Check whether your compliance lead, legal counsel and regulatory contacts know that the AI Office, not a national regulator, is the body that will request documentation, ask questions and open proceedings for your general-purpose model.
Fines up to 3% or EUR 15 million
Under Article 101, the Commission may fine a provider up to 3% of worldwide annual turnover or EUR 15 million, whichever is higher. The Commission must take commitments made under a code of practice into account when it sets the amount. For a provider with large turnover, the percentage limb will usually be the higher figure, so finance and legal teams should model the exposure on group turnover rather than on the model business alone.
AI Office competence over own-model systems
Under Article 75(1), as amended in 2026, the AI Office is exclusively competent for AI systems built on a provider's own general-purpose model, with exceptions. A company that builds a product on its own model may therefore face AI Office supervision for the system, not only for the model. Confirm with counsel which of your systems rely on your own model and which exceptions could apply before assuming a single regulator.
Submissions through the EU SEND platform
The Commission says providers submit documents to the AI Office through the EU SEND platform. Technical documentation, downstream information and other filings should therefore be prepared in a format that can be uploaded and traced, with named owners and version control. Ask who in your organization holds access to the platform, how submissions will be recorded, and how you will show the AI Office the version of documentation that was in force on a given date.
How documentation reaches the AI Office
This sequence turns a general-purpose AI model's technical record into the documents the AI Office and downstream providers receive, with the provider keeping ownership of every file it submits. Each step closes with a check the provider can point to when asked how it complied.
Confirm the model is in scope
The provider, usually a legal or compliance lead with the model owner, first establishes that it places a general-purpose AI model on the EU market and whether it meets the generality test in Article 3(63). It then records the training compute estimate and checks it against the Commission's indicative 10^23 FLOP guidance and the 10^25 FLOP systemic-risk presumption. The output is a dated scope memo that states which duties apply, and the provider signs off on it internally.
Assemble the Annex XI technical file
The model team compiles the Annex XI technical documentation for the AI Office, covering the model's design, training process, data, compute and evaluation results. The compliance lead owns the file and assigns an owner to each section so that gaps are visible early. The file is complete when every Annex XI heading has a document, a version number and a named approver. Confirm the exact content list against the current text of the Act and the Commission's guidelines, since the file must match them.
Check the free and open-source exemption
If the model is released under a free and open-source licence with public weights, architecture and usage information, the provider checks whether the exemption from the two documentation duties applies under Articles 53(2) and 54(6). The check fails if the model carries systemic risk, so the provider confirms that status before relying on the exemption. The output is a written decision that states which Annex XI or Annex XII duties still apply, and the copyright policy and training summary remain in force either way.
Align Annex XII information for downstream providers
The provider prepares the Annex XII information that downstream providers need to meet their own obligations for systems built on the model. This package is drafted from the same source record as the Annex XI file so that the two never contradict each other. The provider's contract or documentation team sends it under a controlled version and logs each recipient. The check that closes the step is a matched reference table showing that every Annex XII statement traces to an Annex XI section.
Adopt the EU copyright policy
The provider documents an EU copyright policy that respects text and data mining opt-outs, covering how crawled and licensed content is identified and how rights reservations are honored during data collection. Legal counsel and the data engineering lead own the policy, and the training data team records the sources used. The policy is complete when it names the controls that apply to each data source and a person responsible for updates. Copyright duties apply even to open-source models, so this step runs for every provider.
Publish the training content summary
The provider completes the public training content summary on the AI Office template, which the Commission presented on 24 July 2025. The summary describes the training content at a level the Act requires, and the legal lead reviews it against the Annex XI record so that the public text and the technical file agree. The step closes when the summary is published in the location the provider has chosen and a copy is archived with the technical file. Confirm the current template version before publishing.
Submit the documents to the AI Office through SEND
The provider uploads the Annex XI documentation and related submissions to the AI Office through the EU SEND platform, as the Commission describes. A named submitter from the provider's compliance function handles the upload and keeps the transmission receipts. The provider holds the account credentials under its own access controls. The check that closes the step is a filed record of each submission with its version, date and receipt, which the provider can produce in response to a request from the AI Office.
Keep the file current and retain the record
The provider reviews the technical file and the training summary whenever the model is materially updated, and records the reason for each change. Each new version is checked against the scope memo, and any change in systemic-risk status triggers the notification duties in Articles 51 and 52. The output is a version history that shows what changed, who approved it and when it was sent. No independent certificate is issued for these obligations under the Act as supplied, so this record is the evidence the provider presents to the AI Office or to a market surveillance authority on request.
What must be in place before the AI Office or an assessor asks
A provider of a general-purpose AI model should be able to produce six artifacts on request, each with a named owner and a dated record. The AI Office can ask for documentation, training summaries and evaluation results, so these items need to exist before a request arrives, not be reconstructed afterward.
Model inventory with compute records
Keep a register of every general-purpose model you place on the EU market, build or substantially modify, with the training compute recorded for each. Compute determines whether the systemic-risk presumption applies, since the Act sets a threshold of 10^25 FLOP. To check this card, confirm that each model entry shows its estimated training FLOP, the date of calculation, and who signed off, and that the register is updated whenever you fine-tune a model someone else built.
Documentation owner and version control
Assign one named owner for the Annex XI technical documentation and the Annex XII information you pass to downstream providers. Store each version under change control so you can show which document applied on which date and which model release it described. To check this card, ask for the current owner, the change log for the last two model releases, and proof that the downstream information package matches the technical file for the same version.
Copyright policy and crawler opt-out process
The Act requires an EU copyright policy that respects text and data mining opt-outs. In practice this means documented crawler rules, a method for honoring machine-readable reservations of rights, and a record of how those rules were applied to each training run. To check this card, confirm that the policy names the crawlers and data sources used, states how opt-out signals are read and honored, and that a reviewer can trace a sample of excluded content to the training pipeline configuration.
Training data provenance register
Record the source, licence basis, collection date and processing steps for each dataset used in training. This register is the working base for the public training content summary, which must follow the AI Office template. To check this card, pick one published dataset and trace it from the summary back to the register entry, the collection record and the exclusion filters applied, then confirm that gaps are flagged rather than omitted.
Evaluation and red-teaming program
Providers of models with systemic risk must run state-of-the-art evaluations, including adversarial testing, and assess and mitigate Union-level systemic risks. Document the test plan, the adversarial scenarios, the tooling, the findings and the fixes or accepted residual risks for each model release. To check this card, ask for the evaluation report for the latest release, the list of red-team scenarios with dates, and evidence that findings were tracked to closure before the model was released.
Serious incident escalation path
Systemic-risk providers must report serious incidents to the AI Office, so you need a written path from detection to notification. Define what counts as a serious incident for your models, who decides, who drafts the report, and how the path is tested. To check this card, run a tabletop exercise against a simulated model misuse event, confirm that the escalation record shows the decision time and the person who approved the report, and verify that the contact route to the AI Office is documented.
Who owns each GPAI duty
This table compares six general-purpose AI duties under Chapter V across three columns: what the provider must own, what an implementation partner can prepare, and what the AI Office issues or enforces. Read each row as a split of responsibility, not a list of tasks handed to a vendor. The main takeaway is that the partner prepares systems and evidence, while only the AI Office and the Commission act on the provider's submissions and enforce the rules.
| Duty | Owned by the organization | Prepared with an implementation partner | Issued or enforced by the AI Office |
|---|---|---|---|
| Technical documentation | Accountable for accuracy, completeness and sign-off of the Annex XI content | Builds the document repository, templates, version control and evidence links | Receives the documentation on request and can require it for enforcement |
| Copyright policy | Adopts and publishes the EU copyright policy respecting text and data mining opt-outs | Configures crawler and dataset controls, opt-out handling and records of rights checks | Enforces the policy as part of Chapter V supervision |
| Training content summary | Approves the public summary on the AI Office template | Collects dataset provenance records and drafts the summary from them | Reviews the published summary and may request supporting detail |
| Systemic-risk evaluation | Decides risk scope, accepts results and owns mitigation decisions | Plans and runs adversarial testing, logs results and tracks remediation | Supervises compliance for models with systemic risk |
| Serious incident reporting | Decides whether an event is serious and signs the report to the AI Office | Sets up detection, triage workflows and report drafting with evidence capture | Receives reports and can take enforcement action |
| Authorised representative (non-EU providers) | Appoints the representative in writing and keeps the documentation for the required period | Maintains the document package the representative holds and the handover process | Relies on the representative for contact and document access |
Where an implementation partner fits and where it stops
An implementation partner helps you prepare the evidence for general-purpose AI obligations, but the duties stay with your organization as the model provider. DeployOpen can plan and prepare self-hosted systems inside your own cloud accounts, data centers or air-gapped networks. That work typically covers the logging that records training and evaluation runs, the technical documentation pack organized against Annex XI and the information packs for downstream providers under Annex XII, the copyright policy and the public training content summary drafted on the AI Office template, and, for models with systemic risk, evaluation and red-teaming support aimed at the adversarial testing duty in Article 55. Work is scoped in a written, fixed-scope agreement that names the systems, deliverables, responsibilities and timelines before anything starts. Ask any partner to show you which artifacts it will produce, who owns each one, and where they will be stored.
DeployOpen does not submit documents to the AI Office as your representative, does not issue certifications or attestations, and does not guarantee a regulatory outcome. Submissions, including those made through the EU SEND platform, are filed by the provider, and only independent auditors, assessors or certification bodies issue reports or certificates. Your legal and compliance teams remain responsible for deciding whether a model is general-purpose, whether it carries systemic risk, whether an open-source exemption applies, and whether a downstream modification has made your organization the provider. Confirm with counsel the scope and status of any open-source exemption before you rely on it, and confirm the current training-compute threshold guidance with the Commission, since the Commission says the systemic-risk threshold is under review.
Common questions about GPAI obligations
Does fine-tuning a general-purpose AI model make us its provider?
It can, but only if the modification is large enough. Under the Commission's guidelines of 18 July 2025, a downstream party that modifies a model becomes the provider of the modified model when the modification uses more than a third of the original model's training compute, indicatively. Below that line, the original provider usually keeps the provider role, although you still need to check what you have changed and whether you place the result on the market under your own name. Measure the compute used, keep records of the training run, and compare them against the guidelines before you assume either outcome. Your legal team should confirm the position for each model you adapt.
Do we need an EU authorised representative if we are based outside the EU?
Yes, in most cases. Article 54 requires non-EU providers to appoint an EU authorised representative before placing a general-purpose AI model on the EU market. The representative must keep the technical documentation for 10 years, which makes the appointment a standing operational duty, not a one-time filing. Free and open-source models with public weights, architecture and usage information are exempt from this duty, but not if they carry systemic risk. Confirm your status against the Act text, and agree in writing who holds the documentation, how it is produced, and how the representative receives updates.
What must the public training content summary contain?
The summary must follow the mandatory template that the Commission presented on 24 July 2025, and it must describe the training content at the level the template requires. Every provider must publish it, including open-source providers, because the exemption for free and open-source models does not cover this duty. Start by inventorying your data sources: datasets, crawled material, licensed content and user data, along with their broad categories and origins. Keep that inventory versioned with each training run. Confirm the template fields directly on the Commission's site before drafting, since the detail you need to record depends on what the template asks for.
Can our own team handle GPAI compliance without an outside partner?
A capable engineering and legal team can do much of it, and the Act does not require outside help. The work splits into three parts: technical documentation and evidence from training runs, a written copyright policy that respects text and data mining opt-outs, and the public summary. Outside help is most useful for scoping, for building repeatable evidence pipelines, and for reviewing the systemic-risk duties if your model crosses the presumption threshold. Keep ownership of the decisions inside your organization. An implementation partner can prepare systems and evidence, but only an independent auditor or assessor issues reports or certificates.
What does GPAI compliance require from our engineers and legal team?
Engineering owns the evidence and legal owns the position. Engineers need to record training compute, dataset provenance, model architecture, evaluation results and version history in a form that can be exported to the AI Office. Legal needs to maintain the copyright policy, interpret the modification and open-source rules for each model, and review the training summary before publication. For models with systemic risk, security engineers must add adversarial testing, incident reporting and infrastructure protection. Agree a single owner for the technical file so that updates after each release are not lost.
Which deadlines apply to a general-purpose AI model released last year?
The answer depends on when the model was placed on the market. The obligations have applied since 2 August 2025, and the Commission can enforce them, including with fines, from 2 August 2026. Models placed on the market before 2 August 2025 must comply by 2 August 2027, under Article 111(3) and Article 113. A model released last year, after August 2025, therefore falls under the earlier obligations and the Commission's enforcement powers already apply to it. Check the exact placing-on-the-market date with your legal team, and confirm the transitional rules in the consolidated text.
Who enforces the GPAI rules, and what are the maximum fines?
The Commission, acting through the AI Office, enforces the general-purpose AI model rules in Chapter V, and it can fine providers up to 3% of worldwide annual turnover or EUR 15 million, whichever is higher, under Article 101. Commitments made under the code of practice are taken into account. These are the fines for GPAI providers specifically, separate from the higher tiers that apply to prohibited practices under Article 99. Read the enforcement article in the consolidated text before setting internal priorities, because the enforcement route differs from the one used for AI systems.
How DeployOpen scopes and prepares GPAI evidence
DeployOpen works on the evidence side of general-purpose AI obligations: the technical documentation, downstream information, copyright policy and training content summary that a provider must hold. We prepare systems and records inside your own infrastructure, and the organization keeps ownership of its compliance decisions and submissions.
How we scope
- We confirm which models your organization places on the EU market and whether you are their provider or a downstream modifier.
- We map each Chapter V duty to the systems, repositories and teams that hold the underlying evidence.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We set up documentation pipelines so model cards, training records and evaluation results are versioned in your environment.
- We configure logging and access controls on self-hosted platforms so records of model changes can be retrieved on request.
- We test the evidence trail end to end, checking that each claim traces to a stored artifact an assessor could review.
How we hand over
- We deliver a documentation set mapped to Chapter V duties, with owners, update triggers and retention settings named for each item.
- We document the copyright policy workflow and training content summary process, so your legal and engineering teams can run them.
- We provide runbooks for submitting documents to the AI Office, which your team carries out under its own authority.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered.
- We update documentation when a model is retrained, fine-tuned or moved past a compute threshold that changes its obligations.
- Independent auditors and certification bodies issue any reports or certificates; DeployOpen prepares the systems and evidence they review.
