The EU AI Act's GPAI Enforcement Just Became Real: What August 2026 Means for Builders and Privacy

August 2, 2026 is when the European Commission gains the power to fine general-purpose AI model providers up to 3% of global annual turnover or €15 million, whichever is higher. The obligations themselves have been live since August 2025. What changes now is that someone can actually punish you for ignoring them. If you ship GPAI models and serve EU users, the privacy, transparency, and documentation requirements you may have been treating as advisory just acquired teeth. This piece walks through what is actually enforceable, what got delayed (and what didn't), and where the real risk concentrates for technical founders.

Key Takeaways

• GPAI substantive obligations have applied since August 2, 2025. August 2, 2026 is when the Commission can investigate, request documentation, and impose fines. These are different dates, and conflating them is a common, costly mistake.
• The Digital Omnibus delayed high-risk AI system deadlines (recruitment, credit scoring, etc.) but left the GPAI enforcement date untouched. If your compliance plan assumed the Omnibus bought you more time on GPAI, it didn't.
• The Code of Practice for GPAI is voluntary, but it functions as the de facto compliance yardstick. Providers who don't sign it (or follow something demonstrably equivalent) face heavier scrutiny and the same fine exposure.
• Legacy models placed on the market before August 2, 2025 get until August 2, 2027 to comply. If you shipped a new model after that date, you're already in scope and enforcement starts now.
• Systemic-risk classification is a bright-line compute threshold (10²⁵ FLOPs), not a subjective call. Your architecture decisions are regulatory decisions.

What Actually Changes on August 2, 2026?

The Commission's enforcement and penalty powers over GPAI model providers become applicable. That includes the authority to request documentation and information, conduct evaluations, demand compliance measures or risk mitigation, and order market restrictions including recall and withdrawal. Before this date, the obligations existed on paper but the Commission lacked the procedural machinery to act on violations. Now it has that machinery.

The fine ceiling is 3% of global annual turnover or €15 million, whichever is higher. For a startup doing €5M in revenue, that's €15M. For a company doing €2B, that's €60M. The penalty is designed to scale, and the floor is designed to sting even if you're small.

Separately, Article 50 transparency duties land the same day. These cover chatbot disclosure (telling users they're interacting with AI), AI-content marking, and deepfake labeling. Article 50 enforcement sits with national market surveillance authorities, not the AI Office, so you're dealing with a different enforcement body for these obligations.

Didn't the Digital Omnibus Delay Everything?

No. This is the single most common misreading in the compliance space right now, and multiple trackers have flagged it. The Digital Omnibus, which was published in the Official Journal on July 24, 2026, reshuffles the timeline for high-risk AI systems. Standalone high-risk systems under Annex III (recruitment tools, credit scoring, educational assessment) got pushed to December 2, 2027. High-risk AI embedded in regulated products under Annex I got pushed to August 2, 2028.

GPAI enforcement was not touched. Obligations for providers of general-purpose AI models have been in force since August 2, 2025 and are not modified by the Digital Omnibus.

If you build a GPAI model that a downstream deployer uses in a high-risk system (say, a hiring tool), the deployer's obligations may have shifted. Yours did not. The asymmetry matters: your downstream customers might feel less pressure, but you face the same August 2 cliff.

One partial exception on Article 50: providers of generative AI systems placed on the market before August 2, 2026 have until February 2, 2027 to implement machine-readable marking of AI-generated content (watermarks, metadata). If you shipped before that date, you have six extra months on watermarking specifically. Not on the rest.

What Is the Code of Practice and Why Does It Matter If It's Voluntary?

The AI Office published the final Code of Practice for GPAI providers on July 10, 2025. It covers three chapters: Transparency, Copyright, and Safety and Security. Signing it is voluntary.

But voluntary here means something specific. Providers that don't adopt the Code or a comparable framework face a more complex compliance burden and closer scrutiny from the AI Office, with the same fine exposure. The Code is the path of least resistance to demonstrating compliance. If you choose a different path, you need to prove equivalence, which is harder, slower, and more expensive than just signing.

The AI Office has indicated it won't treat Code signatories as having broken commitments just because they haven't fully implemented everything immediately. This is a good-faith grace period for signatories, not a blanket deferral. The grace period ends with enforcement going live. If you signed and haven't implemented, you're in a better position than someone who didn't sign at all, but you're not safe.

The Signatory Taskforce held its first constitutive meeting on January 30, 2026. Governance infrastructure is already operating. This is not theoretical future apparatus.

Which Models Are in Scope Right Now?

Any GPAI model placed on the EU market after August 2, 2025 is subject to the full set of obligations and, as of August 2, 2026, enforcement. Legacy models released before August 2, 2025 get until August 2, 2027 to achieve full compliance. So if you're running a model you trained and released in 2024, you have another year. If you released or substantially updated a model after August 2025, you're in scope now.

"Placed on the EU market" is doing real work in that sentence. If your model is accessible to EU users or integrated into products serving EU customers, it's likely in scope regardless of where your company is incorporated. The Act's jurisdictional reach follows the market, not the headquarters.

What Does the Systemic-Risk Threshold Actually Mean for Architecture Decisions?

The Act creates two tiers of GPAI obligation. Models exceeding 10²³ FLOPs of training compute that are placed on the EU market must meet transparency and copyright-policy obligations. Models trained with more than 10²⁵ FLOPs are classified as posing systemic risk and face enhanced safety requirements.

The 10²⁵ FLOPs threshold is a bright line. It's not a subjective risk assessment, not a committee vote, not a "we'll know it when we see it" standard. It's a number. You either exceeded it during training or you didn't.

This makes the threshold a technical design decision, not just a legal one. If you're choosing between training a single large model and building a routing layer over smaller specialized models, the regulatory cost delta is now quantifiable. A collection of models each trained below 10²⁵ FLOPs carries fundamentally different compliance obligations than a single model trained above it, even if the aggregate capability is comparable. Model minimalism and privacy-preserving architecture (smaller models, task-specific fine-tuning, inference routing) aren't just engineering preferences anymore. They're regulatory arbitrage.

At Selina, we run a stack of frontier models routed per task. That's a product architecture decision, but it's also a compliance architecture decision. Smaller, specialized inference paths mean no single component triggers the systemic-risk threshold, and the privacy characteristics (encrypted-at-rest memory, short retention window for operational metadata) align with the transparency requirements rather than fighting them.

Is the Open-Source Exemption as Broad as People Think?

No. Open-source GPAI models are generally exempt from the heavy documentation requirements in the Transparency chapter, provided they don't pose systemic risk. But they must still comply with the Copyright chapter rules. And if an open-source model exceeds the 10²⁵ FLOPs systemic-risk threshold, the open-source exemption evaporates entirely.

If you're a startup fine-tuning an open-source base model, your exposure depends on whether you're considered a "provider" under the Act. If you substantially modify the model and place it on the market, you likely are. The exemption protects the upstream open-source developer from certain documentation burdens. It doesn't necessarily protect you.

How Does Vendor-Chain Liability Work Under GPAI Enforcement?

This is where enforcement gets uncomfortable for builders who rely on third-party models. Article 50 and GPAI enforcement extend to the vendor chain. If a third-party model provider embedded in your stack can't demonstrate compliance, that exposure flows downstream to you.

Concretely: if you build a product on top of a frontier model via API, and that model provider hasn't signed the Code of Practice or can't produce adequate documentation when the AI Office asks, your product inherits that gap. You need to know whether your upstream providers are Code signatories, what documentation they've filed, and whether the AI Office considers it adequate.

Major model providers have submitted compliance documentation to the AI Office, but its adequacy remains under review. The AI Office expects ongoing updates as models change. "We use a well-known provider" is not a compliance defense if that provider's documentation is found insufficient.

The practical implication: you need contractual provisions with your model providers that cover AI Act compliance, documentation access, and notification if their compliance status changes. If your provider agreements don't address this, fix them before August 2.

What Does Enforcement Look Like in Practice?

The AI Office, not national authorities, holds primary enforcement power over GPAI providers. National market surveillance authorities handle Article 50 transparency obligations for deployers. But for model providers, the AI Office is your regulator.

The AI Office's supervisory scope has been significantly extended under the Omnibus. Previously it only supervised GPAI models and AI systems where the same provider developed both model and system. Now its reach is broader.

What an enforcement action probably looks like in the first year: a documentation request, not a dawn raid. The AI Office asks for your model card, training data documentation, copyright policy, and (if you're above the systemic-risk threshold) your risk assessment and mitigation measures. If you can't produce them, or they're inadequate, the escalation path runs from compliance demands through risk-mitigation orders to fines.

The Commission also launched the EU Action Plan on Cybersecurity and Artificial Intelligence on July 7, 2026. This is separate from AI Act enforcement, but it signals that the security posture of AI systems is getting dedicated regulatory attention. If your model logging, access controls, and incident response are built for compliance, they double as security infrastructure. If they're not, you have two problems instead of one.

What Should You Actually Do Before August 2?

If you're a GPAI model provider serving the EU market, here is what concretely needs to be in place.

Is your model documentation complete?

You need a model card or equivalent documentation that covers training methodology, data sources, intended use, known limitations, and evaluation results. The Code of Practice's Transparency chapter provides the template. If you haven't produced this documentation, or it's a marketing-grade overview rather than a technical disclosure, it won't survive an AI Office review.

Do you have a copyright policy that meets the Copyright chapter requirements?

The Code of Practice requires a published policy on how you handle copyrighted training data, including how you respond to opt-out requests and how you document the provenance of training data. "We scraped the web" is not a policy.

Have you assessed whether you're above the systemic-risk threshold?

If your model was trained with more than 10²⁵ FLOPs, you face enhanced obligations around risk assessment, incident reporting, and adversarial testing. If you're close to the threshold, document your training compute precisely. The line is bright but the measurement has to be honest.

Are your vendor agreements updated?

If you use third-party models in your stack, your agreements need to address AI Act compliance, documentation sharing, and change notification. If your upstream provider loses compliance status, you need to know immediately, not when the AI Office sends you a letter.

Is your logging infrastructure built for both compliance and incident response?

The Cloud Security Alliance has argued that logging of model invocations, prompts, and output dispositions should be treated as a threat model, not merely a compliance exercise. This is correct. The same infrastructure that lets you respond to an AI Office documentation request also lets you investigate a security incident. Build it once, use it for both. The privacy constraints on that logging (what you retain, how long, who can access it) are where compliance and security genuinely intersect.

What Can You Safely Ignore?

Most of the "AI Act deadline" content published in the last two months conflates GPAI enforcement with high-risk system obligations. If you build models rather than deploy high-risk applications, the Annex III and Annex I timelines are your customers' problem, not yours directly. Understand them well enough to have informed conversations with downstream deployers. Don't restructure your compliance program around them.

The Transparency Guidelines published July 20, 2026 are practical and worth reading, but they primarily address deployers' Article 50 obligations. If you're a model provider, they're context, not your primary compliance document.

The debate about whether the AI Act will "stifle innovation" is noise for your purposes. The Act is law. It's enforceable in days. Whether it's good policy is a question for op-eds. Your question is whether your documentation, logging, and vendor agreements are ready for a review you can't decline.

Where Does This Leave Builders Who Actually Care About Privacy?

In a surprisingly strong position, if the infrastructure is real. The GPAI framework's transparency and documentation requirements assume that most providers will find compliance burdensome because it requires disclosing things they'd rather not disclose, and logging things they'd rather not log. If you built your product around privacy-preserving architecture from the start (encrypted storage, minimal data retention, clear data-flow documentation, task-routed inference rather than monolithic models), most of what the AI Office will ask for is documentation of things you already do.

The enforcement risk concentrates on providers who treated GPAI obligations as a future problem. The obligations have been live for a year. The enforcement is what's new. If you've been compliant since August 2025, August 2026 is a non-event for you operationally. If you haven't, you have days, not months.

The gap between "we take privacy seriously" and "here is our model card, our copyright policy, our training data documentation, our risk assessment, and our incident response logs" is the gap the AI Office will measure. Close it with documentation, not marketing.

If you want to see what a privacy-first AI assistant looks like in practice, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io