EU AI Act (GPAI) Reality Check: What Changes Before vs After 2 August 2026 (and 2 November 2026)
What You'll Learn
- Why GPAI provider duties began on 2 August 2025 and what changes when enforcement starts on 2 August 2026.
- How Articles 53 and 55 divide ordinary GPAI duties from systemic-risk duties.
- What Article 50 requires for AI interaction, deepfakes, biometric tools, and public-interest text.
- Why 2 December 2026, 2 December 2027, and 2 August 2028 matter more than the old 2 November claim.
What the EU AI Act Covers
The EU AI Act is a regulation for placing AI systems and models on the Union market, putting them into service, and using them in the EU. It uses a risk-based structure. Some practices are prohibited. Certain uses are high-risk. Other systems carry transparency duties, while minimal or no-risk uses face no new AI Act requirements. The legal text sits beside existing rules on data protection, consumer protection, employment, product safety, and fundamental rights.
That structure matters for the GPAI debate. A model is not the same thing as the finished system that uses it. A provider may develop a general-purpose model and make it available to other developers. A downstream provider may integrate that model into a recruitment tool, customer service agent, or public-facing application. The duties can differ at each layer.
The Commission describes a GPAI model as one with significant generality that can perform a wide range of distinct tasks and integrate into different downstream systems. The definition is about capability and reuse, not about a marketing label. A model can be text-only and still fall within the category if it has the required generality.
For a plain-language introduction to connected agents, see the MCP guide and the MCP definition article. The legal question is not whether a product calls itself an agent. It is which model and system roles the product actually performs.
What Actually Changes on 2 August 2026
2 August 2026 is an enforcement milestone, not the birth date of GPAI compliance. The official AI Act timeline says that the majority of the Act’s rules begin to apply on that date and that enforcement starts for applicable rules. The Commission’s AI Office and Member State authorities gain practical enforcement responsibilities for GPAI models, prohibited practices, transparency rules, and AI literacy.
For GPAI providers, this means a shift in posture. The underlying provider obligations were already applicable from 2 August 2025. The AI Office has used the intervening period for technical compliance dialogues and has received information from providers. The next phase gives it stronger tools if those dialogues do not resolve a concern.
The Commission can request information and technical documentation. It can request access to a model for evaluation, require risk-mitigation measures, and use fines or market restrictions where the legal conditions are met. That does not mean every provider receives a fine on the date. It means the supervising authority has a live enforcement route rather than relying only on voluntary cooperation.
| Milestone | What it means | Who should care |
|---|---|---|
| 2 August 2025 | GPAI provider obligations became applicable | Model providers and downstream organisations |
| 2 August 2026 | Enforcement begins for applicable rules and Article 50 transparency rules apply | Providers, deployers, and authorities |
| 2 December 2026 | Article 50(2) transition for certain systems already on the market ends | Providers of covered pre-existing systems |
| 2 December 2027 | Annex III high-risk rules apply after the amended timeline | Providers and deployers of listed high-risk uses |
The safest reading is narrow. Do not tell a small business that every internal AI experiment becomes a GPAI enforcement case on 2 August. Do not tell a model provider that nothing changes because the paperwork began in 2025. The date changes the authority’s ability to test, question, and correct covered conduct.
GPAI Provider Duties Under Article 53
Article 53 sets the baseline for providers of GPAI models. First, the provider must document technical information about the model. That information must be available to the AI Office and national competent authorities when requested. Relevant information must also be made available to downstream providers so they can understand the model and meet their own obligations.
Second, the provider must maintain a policy for complying with Union copyright and related-rights law. This is not the same as publishing a list of every training item. It is a governance requirement that should connect legal review, data intake, rights reservations, and documented decisions.
Third, the provider must make a sufficiently detailed public summary of training content. The Commission has published a template that asks for an overview of the data used to train the model, including sources and top domain names, along with information about data processing. The point is to give affected parties enough information to understand the training inputs and exercise relevant rights under EU law.
These are provider duties at the model layer. They do not erase the duties of a downstream provider that turns a model into an AI system. A company building a system for hiring, credit, education, or public services must still assess the system’s own use and risk category.
| Article 53 area | Evidence to maintain | Why it matters downstream |
|---|---|---|
| Technical documentation | Model information that can be supplied to authorities and downstream providers | Supports system assessment and traceability |
| Copyright policy | Documented policy and operational review path | Connects training practice to Union copyright law |
| Training-content summary | Public summary using the Commission template | Improves visibility into training sources and processing |
| Downstream information | Information that lets integrators understand the model | Helps downstream providers meet system obligations |
The technical file should be treated as a working record, not a document assembled after an inquiry arrives. Model version, training process, evaluation evidence, known limitations, intended release route, and changes should remain connected. A provider that cannot reconstruct its own decisions will struggle to answer a targeted request even if the model itself performs well.
When a GPAI Model Has Systemic Risk
Systemic risk is a separate classification for the most capable models or models with an equivalent impact. The risk is not limited to a single defective output. The Act is concerned with large-scale harm, such as lowering barriers to chemical or biological weapons development, loss of control over advanced model capabilities, or other risks that can spread through a widely used model.
The Act uses a training-compute threshold of 10^25 FLOP as a marker for the most advanced models. The AI Office can update that threshold as the state of the art changes. The Commission can also designate a model based on equivalent impact, considering factors such as capability evaluations, the number of users, scalability, and access to tools.
The AI Office Q&A describes 10^23 FLOP as an indicative criterion in its scope guidance for identifying some GPAI models when combined with relevant generative capability. That is not the same as the 10^25 FLOP systemic-risk threshold. Mixing those values creates a serious compliance error.
A provider of a systemic-risk model must assess and mitigate systemic risks. It must perform model evaluations, keep track of and report serious incidents, and provide adequate cybersecurity for the model and its physical infrastructure. The records should show what was tested, which risks were identified, what controls were applied, and how unresolved risk was escalated.
For a separate view of how agent capabilities create security questions, compare this with the OWASP Top 10 guide for agentic AI. That article concerns application security. Article 55 concerns systemic risk at the GPAI model level. They can overlap, but they are not interchangeable checklists.
Who Is the Provider and Who Is the Deployer
The AI Act applies to providers placing GPAI models on the Union market whether they are established inside or outside the EU. A provider is the person or organisation that develops a GPAI model, or has it developed, and places it on the market for payment or free of charge. Market access is therefore more important than the location of the engineering team.
A downstream organisation can become a provider of a new model if it fine-tunes or otherwise modifies an existing GPAI model in circumstances covered by the Act. The Commission’s Q&A says Article 53 duties should generally relate to the modification, such as adding information about the fine-tuning to existing documentation. It also gives an indicative criterion that training compute for the modification is greater than a third of the original model’s training compute. That criterion is guidance, not a universal answer for every modification.
A deployer uses an AI system under its authority. A retailer, employer, hospital, school, or public body may be a deployer even when it did not build the underlying model. The deployer must look at the system’s purpose and context. A GPAI model used in a general drafting assistant is not automatically the same legal case as a system that ranks applicants for employment.
This role map prevents a common mistake. A company cannot transfer every responsibility to the model vendor simply because it buys an API. The vendor may own Article 53 documentation while the customer owns system-level deployment choices, notices, human oversight, and records about the use case.
Article 50 Transparency Rules
Article 50 applies from 2 August 2026. Its purpose is practical. People should know when they are interacting with an AI system or seeing certain AI-generated or manipulated content. The Commission’s guidance covers providers and deployers separately, which is why a single generic AI disclosure label may not answer every case.
Providers must design certain interactive AI systems so individuals are explicitly informed when they interact directly with AI. Providers must also add machine-readable marks that enable detection of certain generated or manipulated content. The technical method depends on the content type and the system design.
Deployers have information duties for emotion recognition and biometric categorisation tools, deepfakes, and text published to inform the public on matters of public interest where there has been no human review or editorial control. The public-interest text rule is not a command to label every article that used a spell checker. The scope depends on the system, the output, the publication purpose, and whether human review or editorial control occurred.
Deepfake duties cover generated or manipulated images, audio, and video that resemble existing persons, objects, places, entities, or events. Machine-readable marking supports detection by technical systems. Visible labelling helps people. A responsible implementation plans for both layers rather than treating a hidden metadata field as a complete user notice.
The Commission has published Article 50 transparency guidance and a code of practice. Adhering to the code can help demonstrate compliance. The guidance also permits alternative equivalently adequate means in the areas it covers. The code is a compliance tool, not a replacement for the regulation.
What the AI Office Can Do
The AI Office has exclusive enforcement powers for GPAI models, including models with systemic risk. It also has defined oversight for certain AI systems based on GPAI models when the model and system are developed by the same provider or undertaking. The AI Office can oversee some AI systems that constitute or are integrated into very large online platforms or very large online search engines.
Its practical powers include requesting information, asking for technical documentation, requesting access to a model for evaluation, requiring risk mitigation, and issuing fines within the limits of the Act. The AI Office FAQ says it may request a provider to restrict the making available on the market, withdraw, or recall a model when stronger action is needed.
The Commission says the AI Office’s first tool of choice has been technical compliance dialogue. That matters for tone and procedure. Enforcement is not the same as an automatic penalty notice. A dialogue can identify missing evidence, clarify a technical question, and give a provider a chance to correct its process. If dialogue is not enough, the formal powers matter.
Companies should prepare for a focused request, not a vague inspection. The request may ask for a model version, an evaluation protocol, a serious-incident record, the public training summary, or the basis for a risk decision. Each answer should point to an owner, an evidence location, and a date.
Fines and Corrective Measures
The Commission’s transparency announcement describes company fines of up to €15 million or 3% of global annual turnover, with proportionality taken into account for SMEs and small mid-cap companies. The AI Office FAQ describes a ceiling of 3% of global annual turnover for relevant GPAI enforcement powers and also refers to restrictions, withdrawal, or recall.
Do not turn those ceilings into a prediction of what a particular company will pay. The amount depends on the infringement, the operator, the conduct, and proportionality. A maximum figure is a legal boundary, not a forecast.
The more immediate business risk can be operational. A restriction, withdrawal, or recall can interrupt an API, delay a launch, force a model replacement, or require changes to downstream systems. A company that treats documentation as paperwork may discover that the missing evidence slows the technical response.
A board or risk committee should ask a narrow set of questions. Which legal role does the company hold? Which products rely on GPAI? Which model versions are in production? Where is the training-content summary? Which evaluations support the systemic-risk conclusion? Who can answer an AI Office request without searching across disconnected systems?
| Exposure | What can fail | Useful control |
|---|---|---|
| Evidence gap | Provider cannot answer a technical documentation request | Versioned model file with named owners |
| Transparency gap | People are not informed or content is not marked | Release tests for notices and machine-readable marks |
| Risk gap | Systemic-risk assessment lacks tests or incident records | Evaluation, incident, and mitigation register |
| Continuity gap | Restriction or recall disrupts a product | Fallback model and customer communication plan |
The Current Timeline After the AI Omnibus
The AI Omnibus changed the dates that matter for high-risk systems. It entered into force on 27 July 2026. The official timeline now places Annex III high-risk rules on 2 December 2027 and rules for high-risk AI embedded in regulated products under Annex I on 2 August 2028.
The current timeline also lists 2 December 2026 for new prohibitions related to non-consensual intimate material and child sexual abuse material, plus the transition for certain providers of systems already placed on the market before 2 August 2026 to comply with Article 50(2). It lists 2 August 2027 as the point by which Member States should have at least one AI regulatory sandbox operational.
That makes the old 2 November 2026 headline unsafe. The official EU timeline does not list 2 November 2026 as a general transparency or high-risk deadline. A date may have appeared in an earlier proposal, commentary, or internal planning document, but it should not be presented as the current law without a precise legal source.
| Date | Current official position | Editorial reading |
|---|---|---|
| 2 August 2026 | Article 50 applies and enforcement starts for applicable rules | Prepare evidence and notices now |
| 2 December 2026 | Article 50(2) transition and new prohibitions listed by the Service Desk | Check whether a pre-existing system is covered |
| 2 December 2027 | Annex III high-risk rules apply | High-risk use-case work has a later amended date |
| 2 August 2028 | Annex I product-embedded high-risk rules apply | Product conformity planning has a later amended date |
Readers should still check the consolidated legal text and the AI Act Service Desk because delegated acts, guidance, and sector-specific facts can affect an individual analysis. A timeline is a starting point. It is not a substitute for classifying the actual model and system.
Open Source Does Not Mean No Duties
The GPAI rules contain a limited treatment for qualifying free and open-source releases. The AI Office Q&A says the obligations to draw up and provide certain Article 53 documentation do not apply when the model is released under a free and open-source license and the parameters, architecture information, and usage information are publicly available.
That exception does not apply to GPAI models with systemic risk. The provider of a systemic-risk model still has duties to assess and mitigate systemic risks. An open release can make safeguards easier to remove or bypass, so the release path should be part of the risk assessment.
Open source also does not erase downstream obligations. A team that downloads a model and places a fine-tuned version on the Union market may have a different legal role from a team that uses the model for an internal experiment. An organisation that embeds the model into an AI system still needs to consider system-level rules and the context of use.
For teams comparing different model and tool layers, the AI agents guide provides adjacent technical context. The compliance conclusion must still come from the model release, the system purpose, and the applicable AI Act provisions.
A Practical Compliance Evidence Plan
Start with an inventory. List every GPAI model the organisation develops, modifies, places on the Union market, or integrates into a customer-facing system. Record the provider, version, release route, training status, system use, and owner. The inventory should distinguish a model from an AI system that depends on it.
Next, build an evidence map. Connect Article 53 technical documentation, copyright policy, training-content summary, downstream information, model evaluations, incident reports, and cybersecurity controls to named owners. If an item does not apply, record the reason. A blank field looks like an omission. A dated decision shows the classification work.
Then test the release path. Check whether the system informs people when required. Check visible labels and machine-readable marks for covered generated or manipulated content. Test the path from an output to its originating model and release record. This is the point where many teams find that a product label exists in a design document but not in the deployed service.
Finally, rehearse an authority request. Pick a model version and ask the owner to produce the technical file, risk decision, evaluation record, incident log, and public summary. The exercise should expose ownership and retrieval delays before a real request arrives.
The plan is not a promise that a system is lawful. It is a way to identify missing evidence while changes are still possible. A legal review should follow where the classification is uncertain or the product touches a regulated sector.
Claims to Avoid
Do not say that GPAI obligations begin on 2 August 2026. They became applicable on 2 August 2025. Say that enforcement powers and Article 50 transparency rules begin or apply on 2 August 2026.
Do not say that the AI Act requires every AI-generated sentence to carry the same label. The Article 50 rules distinguish direct interaction, deepfakes, biometric and emotion tools, and text on public-interest matters without human review or editorial control.
Do not use 10^23 FLOP as the systemic-risk threshold. The AI Office Q&A describes it as an indicative scope criterion in guidance. The Act’s training-compute marker for systemic risk is 10^25 FLOP, while equivalent impact can support designation through other criteria.
Do not treat the GPAI Code of Practice as a law or an automatic safe harbour. It is a way to demonstrate compliance when adequate. Providers can use other adequate means, and they must be able to explain why those means meet the obligations.
Do not present 2 November 2026 as a current general deadline. The official timeline lists 2 December 2026, 2 December 2027, and 2 August 2028 for the later milestones described above. Dates deserve the same source discipline as technical claims.
What to Do Next
If your organisation provides a GPAI model, check the Article 53 file first. Confirm that the technical documentation, copyright policy, public training-content summary, and downstream information are current for the model version that is actually available in the EU.
If your organisation deploys an AI system, classify the use and check Article 50 notices, labels, marks, and review controls. If the system uses a GPAI model with systemic risk, confirm that the provider’s risk information is available and that your own system controls do not create a separate gap.
Use the official AI Act Service Desk FAQ, the Commission overview, and the current consolidated EUR-Lex text as the starting record. For governance-role context, see the AI governance specialist article.
The practical lesson is simple. The August 2026 date is real, but it is not a universal cliff. The law had already started for GPAI providers. The change is that oversight, transparency, and correction now have a stronger operational path. The 2 November claim should be replaced with the current official timeline.
Frequently Asked Questions
SK Jabedul Haque
Building India's most trusted finance education platform — simplifying news, schemes and market trends so anyone can understand and invest confidently.
Read full bioNever miss an update
Get our clearest explainers on schemes, markets and money — read what matters, without the noise.
Explore more articles