The Day the AI Act Grew Teeth: GPAI Enforcement Goes Live

Posted on August 8, 2026 by Simon Roses

Read Time: 13 minutes

TL;DR

On August 2, 2026, the part of the EU AI Act everyone was quietly ignoring became enforceable: the AI Office can now fine providers of general-purpose AI models up to 3% of global annual turnover or €15 million, whichever is higher, and can demand your technical documentation, run its own evaluations of your model, order you to “take measures,” and in the worst case make you restrict, withdraw, or recall the model from the EU market. The obligations themselves have technically existed since August 2, 2025 — technical documentation, downstream transparency, a copyright policy that honors robots.txt and opt-outs, a public summary of training data — but until now they were rules without a referee. That changed. Models judged to carry systemic risk (trained above 10^25 FLOP) carry heavier duties that read like a security checklist written by a regulator: model evaluations, adversarial testing / red-teaming, a safety-and-security framework, serious-incident reporting to the AI Office, and cybersecurity protection of the model weights themselves. The voluntary Code of Practice buys you a lighter touch, not immunity. Models already on the market before August 2, 2025 get until August 2, 2027 to fall in line. This is the regulatory half of a two-part story — the civil-liability half, the new Product Liability Directive, is the post I’m publishing right after this one. Read together, the EU has built a pincer: a regulator that fines you, and a courtroom that bills you. Here’s my security-practitioner read of the regulatory jaw.

The dates that matter:

Date What happens
Aug 1, 2024 The AI Act enters into force
Aug 2, 2025 GPAI model obligations begin (for models placed on the market after this date)
Aug 2, 2026 Enforcement switches on — the AI Office / Commission can investigate, evaluate, order measures, and fine
Aug 2, 2027 Compliance deadline for GPAI models already on the market before Aug 2, 2025

The usual disclaimer, same as always: I am not a lawyer, and this is not legal advice — it’s a security practitioner reading a regulation the way I read an attack surface, looking for where the pressure actually lands and who ends up holding it. If you build or ship AI models into the EU, talk to actual counsel. What I can tell you is what this changes operationally for the people who build, secure, and deploy these models — because buried under the compliance language is a list of things I have been demanding on this blog for two years, now backed by a fine.

A note on framing before we start. This post is one of a pair. The EU is putting teeth behind AI on two different tracks at once, and they bite in different ways. This one — the AI Act’s rules for general-purpose AI — is regulatory: a public authority, the AI Office, with the power to investigate you and fine you. The companion piece, on the new Product Liability Directive, is civil: private plaintiffs and courts, strict liability, damages paid to the person your defective software harmed. I’m publishing them back to back on purpose, because if you only track one you’ll misjudge your exposure. A regulator fining you and a claimant suing you are two separate doors, and after this summer both are open.

I have been circling the regulatory door for a while — why “we use ChatGPT” isn’t an AI strategy, what happens when the model itself becomes the attacker, whether you can still tell an open-weight model from a frontier one. August 2 is the EU answering a slice of those questions with an enforcement budget attached.

What Actually Changed on August 2

Here’s the part that confuses people, so let me be precise: August 2, 2026 did not create new obligations. The substantive rules for general-purpose AI (GPAI) models kicked in a full year earlier, on August 2, 2025. What was missing until now was the enforcement machinery. For twelve months the AI Act’s GPAI chapter has been law you could technically break without anyone able to do much about it.

That grace period is over. As of August 2, 2026, the AI Office, the Commission’s dedicated AI enforcement body, has four concrete powers it did not have on August 1:

  1. Demand your documentation. It can require a GPAI provider to hand over technical documentation and information about the model.
  2. Evaluate your model. It can run its own assessments of your model to check compliance and investigate systemic risk — including requesting access.
  3. Order compliance measures. It can require you to “take appropriate measures” to bring the model into line.
  4. Pull the model. In the worst case it can make you restrict its availability, withdraw it, or recall it from the EU market.

One precision point worth keeping straight, because the lawyers reading this will: the AI Office is the operational body that investigates, evaluates, and builds the case, but the formal decision to fine under Article 101 is the European Commission’s. In practice you deal with the AI Office; the signature on the penalty is the Commission’s.

And behind all four sits the number that focuses minds: fines of up to 3% of global annual turnover or €15 million, whichever is higher, under Article 101. Note that’s the GPAI-specific ceiling; the Act’s headline 7%-of-turnover fines are for deploying prohibited AI practices, a different regime. But for a frontier lab, 3% of global turnover is a board-level number.

01-enforcement-tree

Figure 1. How enforcement actually lands: a non-compliance gap that survives the AI Office’s escalation ladder — documentation request → model evaluation → compliance order — ends in a fine of up to 3% of global turnover or €15M, and at the extreme, restriction or withdrawal from the EU market.

So nothing about your model’s obligations changed this week. What changed is that ignoring them now has a price, a referee, and a stop button.

And here is the tell that this date is real. The EU’s Digital Omnibus — a simplification package the industry lobbied for hard, tabled in November 2025 and agreed this spring — postponed the AI Act’s high-risk deadlines, sliding the Annex III obligations to December 2027 and embedded systems into 2028. It left GPAI alone. Of all the deadlines Brussels was pressed to move, the one it would not move is the one this post is about. When a regulator blinks on nearly everything except the thing you are writing about, that thing is the priority.

Who This Actually Hits

The AI Act is fussy about roles, and the fine print matters. The GPAI obligations land on the provider of the model — the lab that trains and places the general-purpose model on the market. Think the obvious frontier names, but also the growing field of open-weight labs, and, importantly, anyone who fine-tunes or substantially modifies a model to the point of becoming, in effect, its new provider. The Commission’s own guidance puts a rough line on that: modify a model using more than about a third of its original training compute and you’re presumed to have become a provider yourself, with the obligations that follow. That clause is the one that pulls a lot of companies who think of themselves as mere “users” into scope without noticing.

If you’re a deployer — you build a product on top of someone else’s model — most of these GPAI duties are not directly yours yet (your day comes later, once the high-risk-system rules bite — a timeline the Digital Omnibus just pushed back and made conditional on technical standards). But you inherit the consequences: the transparency information your upstream provider must now give you is exactly the material your own compliance, and your own security review, depend on. Which is the first place a security practitioner should perk up: the Act is forcing your model vendor to tell you things they previously treated as trade secrets. Use that.

The Baseline: What Every GPAI Provider Now Owes

For every general-purpose model on the EU market, regardless of size, four duties:

Technical documentation. A detailed, maintained dossier on the model — architecture, training process, intended and excluded uses, energy consumption — retained for ten years and produced to the AI Office on request. This is the file that gets read aloud in an investigation.

Downstream transparency. You must publish contact details and respond to downstream providers’ requests with the information they need to integrate the model responsibly — the Code of Practice’s transparency guidance points at a short, days-long response window (law-firm readings cite roughly 14 days) — while still protecting legitimate IP and trade secrets. The “it’s all proprietary, figure it out yourself” era of model integration is ending.

A copyright policy with actual mechanics. Not a paragraph of intent — a working policy that respects technological protection measures, excludes known piracy sources, honors robots.txt and machine-readable opt-out signals, and gives rightsholders a contact and a complaint path. This is the provision the training-data lawsuits will hang on.

A public training-data summary. A filled-in AI Office template summarizing what the model was trained on. Not the dataset, but enough of a summary that the black box gets a label.

None of this is exotic to anyone who has run a mature engineering shop. What’s new is that it’s mandatory, enforceable, and discoverable.

Systemic Risk: When the Regulation Starts Speaking My Language

Here is the section that made me want to write this post. A subset of models, those with “high-impact capabilities” (presumed once training compute crosses 10^25 FLOP) plus any others the Commission designates, are classified as carrying systemic risk. And the obligations that attach to them could have come straight off one of my own engagement checklists:

  • A safety and security framework (the timing specifics here come from the Code of Practice’s safety-and-security chapter), stood up within weeks of notification and finalized before the model ships.
  • Model evaluations and adversarial testing — the Act says red-teaming out loud. State-of-the-art evaluation of the model’s dangerous capabilities is now a legal duty, not a nice-to-have your safety team fights for budget on.
  • Systemic-risk assessment and mitigation across the lifecycle: filtering, monitoring, input/output controls.
  • Serious-incident reporting to the AI Office and national authorities on staggered timelines — an actual incident-response obligation for models.
  • Cybersecurity protection of the model and its physical infrastructure — i.e., protect the weights. Weight exfiltration is now a compliance failure, not just an embarrassing headline.
  • Ten-year documentation retention, and a safety-and-security report including external evaluators’ findings.

A fair note on sourcing: the Act itself sets these duties at the level of principle (Article 55); several of the concrete specifics above — the framework’s timing, the exact shape of the safety report — come from the Code of Practice’s safety-and-security chapter, which is the paved road for demonstrating you met the statutory bar. The duty is law; some of the detail is the Code.

Read that list and then reread what I wrote after the Hugging Face / OpenAI model-evaluation incident: most defenders have zero telemetry at the model and agent layer, and the tooling to run a full intrusion at machine speed is now something you can trigger by accident during your own safety testing. The AI Act just made the telemetry, the evaluation, and the incident reporting for that exact layer a regulated obligation for systemic-risk models. I don’t love every line of this Act, but I’m not going to pretend that mandating adversarial testing and weight security for the most capable models on Earth is the part worth complaining about. It’s the part I’ve been asking for.

There’s also a subtle security-economics point. Adversarial testing is only as good as the adversary. A regulation that requires red-teaming without defining rigor invites the checkbox version — a friendly internal team, a weekend, a green report. The labs that treat this as real offensive work (external, adaptive, incentivized to actually break the model) will produce safety evidence that means something; the ones that treat it as a compliance artifact will produce a document that looks great right up until someone reads it in an investigation. Same lesson as every compliance regime I’ve ever worked under: the artifact is only worth the honesty behind it.

The Open-Weight Wrinkle

This is where my open-weight models thesis collides with the Act, and it is the most interesting knot in the whole thing. The AI Act gives open-source / open-weight GPAI models a partial break: models released under a truly free and open license, with their parameters and architecture made public, are exempted from some of the baseline obligations — the technical documentation and the downstream-transparency duties — though not the copyright policy or the public training-data summary, which every provider owes regardless. The logic mirrors the open-source carve-out I described in the liability piece: you don’t want to crush the commons under paperwork.

But — and it’s the same but as everywhere else in EU tech law — the exemption evaporates the moment the model carries systemic risk. Cross the compute threshold, and open weights save you from none of the heavy duties: you still owe evaluations, adversarial testing, incident reporting, and weight security. Which lands in a peculiar spot given where the frontier is going. As I wrote last month, Chinese labs are shipping trillion-parameter open models that trade blows with US frontier systems, NVIDIA and Meta are shipping open too, and at VULNEX we already run our own offensive agent on an open-weight model. The Act’s structure means the most capable open models — precisely the ones the sovereignty argument is most excited about — inherit the most regulatory weight. Openness buys you a lighter touch only until your model gets good enough to matter.

For enterprises running open weights on their own hardware, there’s a quieter implication I’ll flag: if you fine-tune an open model far enough, you may become a provider in the Act’s eyes, and inherit obligations you assumed belonged to the lab you downloaded from. “We just run it locally” is not the force field people think it is.

The Code of Practice: A Lighter Touch, Not a Shield

The Commission published a GPAI Code of Practice (finalized in 2025, with chapters on transparency, copyright, and safety-and-security) as a voluntary route to demonstrate compliance. Signing it earns you what the AI Office calls increased trust — enforcement focused on your adherence to the Code rather than open-ended audits, and good-faith signatories aren’t going to get hit the instant the clock strikes if they’re visibly implementing.

Two things not to misread. First, the Code is not legally binding and not a safe harbor — adherence doesn’t immunize you from fines, it just gets weighed in your favor when the AI Office sizes one. Second, if you don’t sign, you don’t escape the obligations; you just have to demonstrate compliance some other way and explain your method to the regulator, which is more work, not less. The Code is the paved road. You can go off-road, but you still have to arrive at the same destination and show your route.

Is There a US Equivalent? Same Answer as Last Time: No

If you read the liability post, this will sound familiar, because the divergence is the same shape. There is no US federal equivalent to the AI Act’s GPAI regime. The 2023-era federal push toward AI safety obligations was rolled back; the 2026 posture is deregulatory, leaning on voluntary commitments and existing sectoral authorities rather than a horizontal statute with a dedicated enforcer and turnover-based fines. Some US states are moving on their own, but there is nothing that hands a regulator the power to demand a frontier lab’s documentation, evaluate its model, and pull it from the market.

So the same Brussels-effect logic applies as with GDPR and the PLD: a global lab is not going to maintain one model for Europe and a laxer one everywhere else. It’s cheaper to build to the EU bar once. Which means the AI Act is quietly setting the global floor for how the most capable models are documented and secured — decided in Brussels, exported by economics, with no US vote required. Between this, the Product Liability Directive, and the Cyber Resilience Act’s secure-by-design duties, the EU has spent 2026 becoming the de facto standards body for software and AI safety, and the US has spent 2026 explicitly declining the job.

My Read: What Security and AI Teams Should Actually Do

Strip the compliance vocabulary and August 2 is an operational to-do list. Most of it is what a serious AI security program should already be doing; the difference is that “we’ll get to it” now has a regulator attached.

1. Know your role before the AI Office decides it for you. Provider, downstream provider, or deployer changes everything about what you owe. And watch the fine-tuning tripwire: modify a model enough and you become a provider. Map every model in your stack — including the open-weight one running on a box in the research team’s closet — to a role, on paper, now. This is the AI Strategy Vacuum made concrete: you cannot govern models you haven’t inventoried.

2. Treat red-teaming and evaluation as evidence, not theater. If you touch a systemic-risk model, adversarial testing is now a legal duty — so do the real version. External, adaptive, adversary-incentivized, documented. The report you generate is both your safety evidence and, someday, an exhibit. A red-team artifact that lists a capability you then shipped anyway is worse than none.

3. Weight security is compliance now — protect the crown jewels like it. The Act names cybersecurity protection of the model and its infrastructure. Threat-model weight exfiltration explicitly: access controls, egress monitoring, insider risk, the supply chain around your training and serving infra. The model-is-the-attacker incident showed what happens at that layer with no telemetry. Instrument it.

4. Build the incident-reporting muscle before you need it. Serious-incident reporting to the AI Office is on staggered timelines. That means you need detection, classification, and a reporting runbook for model incidents — not just your classic IT SOC. If you can’t tell when your model did something reportable, you can’t report it in time.

5. Use your upstream provider’s new transparency duties. If you’re a deployer, your model vendor now owes you integration and risk information within days. That’s not just paperwork — it’s the raw material for your own security review of a model you didn’t train. Ask for it. In writing.

6. Sign the Code of Practice with clear eyes. For providers, it’s the lower-friction path and it counts in your favor. Just don’t mistake it for a shield, and don’t sign chapters you can’t actually implement — a broken commitment is worse than an honest “we’re doing it our own way.”

7. If you’re a US provider, don’t read the home-front deregulation as cover. Your government stepping back from AI rules shrinks your EU exposure by exactly zero: place a model on the EU market and the AI Office can still demand its documentation, evaluate it, fine you, and pull it. Same Brussels-effect logic as the liability piece — the EU bar is the one you end up building to, whatever Washington decides.

So What

For a decade, “we’re all in on AI” has been a slide, not a system. The AI Act is the EU deciding that if you place the most capable models on Earth into a market of 450 million people, you will document them, test them adversarially, secure their weights, report when they go wrong, and answer to someone with the power to fine you and unplug you. That’s not red tape. That’s the deal every other high-consequence engineering field accepted long ago, arriving — late, imperfect, but arriving — for AI.

I’ve spent this blog arguing that the model and agent layer is under-secured and barely instrumented. It is strange to watch a regulator show up and mandate a chunk of exactly that. I’ll take the win and keep my skepticism for the enforcement — because a rule is only as real as the first fine, and we’re about to find out how serious the AI Office is.

And remember this is only the first jaw. The regulator can fine you; the Product Liability Directive lets the person you harmed sue you, no fault required, EULA disclaimers void, in December. One summer, two doors, both now open. Build for both.

02-pincer-graph

Figure 2. The pincer — an insecure or non-compliant AI product reaches realized liability by two convergent tracks: the AI Act’s regulatory jaw (the AI Office, from August 2) and the Product Liability Directive’s civil jaw (strict liability, from December).

Stay paranoid. Red-team for real. Protect your weights.

Further Reading:

Questions or feedback? Reach out via:

Need help getting your models and AI systems ready for the AI Act era? VULNEX offers:

  • AI system and model security assessments (evaluation, adversarial testing / AI red teaming, open-model threat modeling)
  • GPAI role mapping and governance gap analysis (provider vs. deployer, fine-tuning exposure, model inventory)
  • AI incident-response readiness and model-layer telemetry design
  • Secure-by-design review for AI-driven products and agentic systems

For AI security strategy — where model and agent risk meets board-level decisions — see vulnex.ai.

Contact: info@vulnex.com

This entry was posted in AI, Privacy, Security, Technology and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.