EU AI Act GPAI Rules Went Enforceable in 2026: What Actually Applies to You

On August 2, 2026, the European Union’s rules governing general-purpose AI models became legally enforceable. Coverage of the milestone split into two camps almost immediately. One warned that every company touching an LLM now owes adversarial testing and incident reports to Brussels. The other shrugged and pointed out that most companies do not operate in Europe.

Both readings fail. The obligations land unevenly by design, and the line runs between building a model and using one. Knowing which side you sit on takes about ten minutes and saves a quarter of misdirected compliance work.

What Became Enforceable

The Act reaches general-purpose AI models, large language models included. Anyone who provides or deploys those models in Europe now owes three things: technical documentation, transparency disclosures, and copyright compliance policies. Penalties attach.

The reach extends past European companies. A business headquartered anywhere falls in scope when it serves European users or runs infrastructure inside the Union. Geography of incorporation decides nothing.

The Distinction Most Coverage Gets Wrong

Adversarial testing and incident reporting to European authorities generate the loudest headlines. Both attach to providers of high-impact models carrying systemic risk, generally those trained above 10^25 floating point operations.

That threshold captures frontier laboratories. It does not capture a lender calling an LLM through an API, a retailer running a support assistant, or a SaaS company embedding a model in a feature.

State it the other way in a room with someone who knows the file and you lose credibility on everything else you say about compliance. The distinction matters more than the headline.

Provider or Deployer, and Why the Word Matters

The Act assigns obligations by role rather than by size or sector, and the two roles carry different burdens.

A provider develops a model or has one developed and places it on the market under its own name. A deployer uses a model under its own authority in the course of business. Most companies reading this deploy.

The trap sits in the middle. Fine-tune an open-weight model substantially, put your name on the result, and offer it to others, and you may cross into provider territory for that model. The same applies when you white-label a model into a product customers understand as yours.

Three questions settle it. Does your name appear as the source of the model rather than of the application? Did you train or substantially modify the weights? Do third parties access the model itself rather than a product built on it? Two or more affirmatives warrant a conversation with counsel before you assume the deployer path.

What a Deploying Company Actually Owes

Three obligations, and none of them requires a research team.

Technical documentation. You describe what the system does, which models it calls, what data reaches them, and how outputs reach users. Most engineering organizations already hold this knowledge and have never written it down.

Transparency disclosures. Users learn when they interact with an AI system and when content came from one. This reads as a product requirement more than a legal one.

Copyright compliance policies. You establish a position on training data and generated output, which matters most when your product generates text, images, or code that customers publish.

The Obligation That Will Cost You Time

Vendor due diligence carries the real work, because liability flows downstream according to where you sit in the AI value chain.

You need to know, per model provider in your stack, whether they hold the technical documentation the Act requires, what transparency they publish, and what their copyright position states. A provider who cannot answer becomes a risk you inherit.

Build the register before you need it. Model provider, model identifier, what data reaches it, which product surfaces depend on it, and the provider’s compliance posture with a date attached. Our guide to AI security and compliance tools covers the platforms that maintain this kind of evidence continuously.

What the Documentation Actually Looks Like

Teams imagine a compliance artifact and produce a document nobody maintains. The useful version reads like an architecture record, which describes it exactly.

Per AI-enabled feature, one page. What the feature does for the user. Which model or models it calls, by explicit version. What data reaches the model, including anything that arrives incidentally in a prompt template. Where outputs land and who sees them. What happens when the model returns something wrong, and who catches it.

Per model, one entry in a register. Provider, version identifier, contract date, the provider’s stated compliance position, the date you verified that position, and a named owner.

Both artifacts already exist in fragments across most engineering organizations, scattered through design documents, vendor contracts, and somebody’s memory. The work involves collection rather than invention, which takes a week rather than a quarter for a mid-size product surface.

Keep them beside the code. A compliance document living in a legal folder goes stale within two releases. The same document in the repository, reviewed when the feature changes, stays accurate because the people changing the feature walk past it.

The Model Deployment Footprint Review

Run this once, then keep it current.

List every model your products call. Include the ones inside vendor features you did not build, since a CRM with an embedded assistant still routes your customer data through somebody’s model.
Mark which surfaces European users touch. Ambiguity here usually resolves toward inclusion.
Record the provider’s compliance position and the date you verified it.
Name an owner per model. Unowned entries decay within a quarter.
Flag anything pinned to a floating model alias. A provider who re-points an alias changes your system without telling you, which breaks both your documentation and your testing evidence.

That last point deserves emphasis. Pin explicit dated or versioned model identifiers, and treat any announced model change as a release requiring a full regression run before promotion.

Why This Matters Outside Europe

United States regulators tend to follow templates rather than invent them. The state privacy laws now operating across roughly twenty states borrowed structure from the GDPR rather than starting fresh, as our multi-state compliance framework covers in detail.

Expect the same pattern here. The documentation, transparency, and provenance obligations arriving from Brussels describe roughly what a thoughtful engineering organization would build anyway, and they describe what a United States regulator will likely ask for within two years.

Building the register now costs a week. Building it under a deadline costs a quarter and produces worse evidence.

Where the Line Sits for Financial Services

Regulated industries feel this first, because examiners already ask adjacent questions. A lender using an LLM for document processing faces no adversarial testing obligation, and it does face a vendor due diligence obligation that maps onto third-party risk management programs already in place.

The practical answer: extend the vendor risk process you run for any critical supplier to cover model providers. Our fintech compliance guide covers how that program fits alongside existing obligations.

The Takeaway

The obligations that bite hardest fall on the companies building frontier models, not on the companies using them through an API. What a deploying company owes reduces to documentation, disclosure, a copyright position, and knowing whether the providers in its stack comply.

Treat the Act as a leading indicator rather than a foreign inconvenience. The guardrails worth building for Brussels answer the questions Washington will ask next.