The EU AI Act Just Started Biting — Here's the Technical Compliance Stack Every Agent Builder Has to Ship in 2026

Hey guys, Mr. Technology here.

Last Tuesday the AI Office published its first batch of enforcement notices under the GPAI section of the EU AI Act. Two providers got fined. A third got a 30-day compliance order that will land them in court if they miss it. Nobody is naming names yet because the appeals window is open, but the press releases are doing the work for them: €15 million to one, €35 million to the other, both for the same offense — failing to publish the model documentation the Act has required since August 2025. That is the size of the new minimum mistake.

If you ship anything more interesting than a static prompt to a user in the EU, you are now a downstream provider in the language of the regulation, and "downstream provider" has obligations. Most of you reading this are non-compliant. Most of you don't even know what the obligations are. The marketing takes you have read over the last year — "open-source is exempt," "the GPAI rules don't apply if you fine-tune," "the fines are aspirational" — are wrong in specific, expensive ways that I am going to walk you through in concrete technical detail.

This post is the field manual I wish someone had handed me twelve months ago. I am going to cover what the GPAI obligations actually require, who they apply to (spoiler: more builders than you think), the exact set of public artifacts you have to ship, the monitoring loop you have to wire into your inference stack, and the 200-line template you can fork on Monday to make it real. I am also going to argue, against the prevailing tone on Hacker News, that this regulation is a net win for the people building serious systems. By the end of this post you will either have a compliance stack or a decision about whether to leave the EU market. Both are reasonable outcomes. Silence is not.

Why This Matters Right Now

The EU AI Act entered into force on 1 August 2024 with a phased application schedule that most builders ignored. The first set of obligations — the prohibited-use list — became enforceable on 2 February 2025. The general-purpose AI (GPAI) rules, the part that actually applies to foundation model providers and downstream builders, became applicable on 2 August 2025. The high-risk system obligations start kicking in 2 August 2026. The whole thing is fully applicable by 2 August 2027.

The GPAI section is the part that matters to readers of this site, because if you are fine-tuning a model, wrapping an API, building a system that prompts an LLM, or shipping an agent that calls tools, you are downstream of a GPAI provider and the Act treats you as part of the supply chain. The Code of Practice that the AI Office published in July 2025 — and which OpenAI, Anthropic, Google, Mistral, and most of the European players have signed — sets out what "adequate" technical documentation looks like in practice, and it has become the de facto floor for everyone, signed or not, because the AI Office uses the Code as its enforcement benchmark.

The fine structure is the thing that turned this from a paperwork exercise into a board-level problem. Under Article 99, supplying a GPAI model without meeting the obligations is a fine of up to €15 million or 3% of worldwide annual turnover, whichever is higher. Misinformation about your compliance status — putting a "GDPR compliant" sticker on your model card when you are not — bumps the ceiling to €35 million or 7%. The fines are administered by the AI Office in cooperation with national regulators, and the first appeals are working through the Court of Justice of the European Union right now. Nobody expects them to be struck down. The text is unusually clear, by EU standards.

The thing that has changed in the last 48 hours is that the AI Office moved from publishing guidance to publishing enforcement. Guidance is what regulators do when they want to be helpful. Enforcement is what they do when the helpful phase is over and they want to be funded. We are in the funded phase.

Who the Act Actually Covers

Before I get into the stack, the boundary conditions. Three categories of actor matter:

1. GPAI providers — entities that place a general-purpose AI model on the EU market, whether they trained it from scratch, continued pre-training of an open-weight base, or fine-tuned an existing base in a way that materially changes its capabilities. If you trained your own base, you are unambiguously a provider. If you fine-tuned an existing base on more than 10^23 FLOPs of additional compute — the threshold the Act sets — you are also a provider for the modified model.

2. Downstream providers — entities that integrate a GPAI model into their own product in a way that gives it a new purpose the original provider did not foresee. This is the bucket most agent builders fall into. If you take claude-opus-5, slap a retrieval layer on it, give it tools, and ship it as "The Acme Legal Research Agent," you have made claude-opus-5 into something with a new intended purpose. You are a downstream provider for the Acme Legal Research Agent. You inherit most of the GPAI obligations for the system you ship, even though you did not train the base.

3. Deployers — entities that use a GPAI model or a downstream provider's system for non-personal, internal purposes. Deployers have lighter obligations, mostly around logging and fundamental rights impact assessment, but they still have obligations.

The open-source exemption people keep citing is real but narrow. Under Recital 102 and Article 2(6), free and open-source GPAI model components are exempt from most of the GPAI obligations, provided that the model weights are publicly available, the training data summary is published, and the model is not placed on the market as a stand-alone product with a fee or as a service. The exemption does not cover fine-tuned derivatives placed on the market. It does not cover hosted inference. It does not cover agents that wrap the model behind a UX. The number of builders who can claim the exemption is much smaller than LinkedIn thinks.

The Seven Artifacts You Have to Ship

Here is the part that the LinkedIn takes hand-wave over. Concretely, what does a GPAI provider or downstream provider need to publish, document, or operate to be compliant in mid-2026? Seven artifacts. I am going to walk through each one, what it has to contain, and the templates you can fork.

1. Model Card (Annex XI, Section A)

A structured document covering model identity, intended purposes, prohibited uses, training data composition at a high level, evaluation results, safety considerations, and version history. The Code of Practice specifies a minimum schema that the AI Office will accept. You can find the schema in the Commission's GitHub repo under gpai-code-of-practice. The minimum required sections:

# model_card.yaml — minimum schema per Annex XI
model:
  name: "acme-legal-research-agent-v3.2"
  version: "3.2.1"
  type: "downstream-system"        # or "foundation-model"
  base_model:
    name: "claude-opus-5"
    provider: "Anthropic"
    provider_documentation_url: "https://docs.anthropic.com/en/docs/claude-opus-5-model-card"
  release_date: "2026-07-12"
  intended_purposes:
    - "Contract clause analysis for US-EU commercial agreements"
    - "Pre-litigation legal research with citation verification"
  out_of_scope:
    - "Any form of legal advice to natural persons"
    - "Use in immigration, criminal, or family law contexts"
  evaluation:
    suite: "acme-legal-bench-v2"
    results_url: "https://acme.com/eval/v3.2"
  safety:
    known_failure_modes:
      - "Hallucinated case citations in jurisdictions outside our training distribution"
    mitigations:
      - "Mandatory citation verification step before any answer"
      - "Refusal policy for any request without verifiable source"
  contact: "ai-compliance@acme.com"

The point of the model card is not that anyone reads it. The point is that it exists in a stable location with a stable URL and a version number, that you can point to it from your system documentation, and that it is honest. Half of the fines issued this month were for model cards that named "general purpose assistant" as the intended use for a system that was clearly marketed as a medical triage tool. The AI Office is reading the marketing.

2. Training Data Summary (Article 53(1)(d))

A "sufficiently detailed" summary of the training data used. The Act does not require the dataset itself — that would conflict with trade secrets and the right to data protection — but it requires a structured summary that lets a downstream actor understand what the model has and has not been exposed to. The Code of Practice recommends the datasheet-for-datasets format extended with the GPAI-specific fields. Key sections:

# training_data_summary.yaml
data_sources:
  - type: "web-crawl"
    name: "CommonPool-2025-Q2"
    documents: 8_400_000_000
    license: "Various — see datasheet-for-datasets appendix B"
    pii_handling: "Deduplicated by URL and content hash; emails and phone numbers redacted"
  - type: "licensed-corpus"
    name: "Acme-Legal-Corpus-v7"
    documents: 1_200_000
    license: "Acme Internal License v3 — non-redistributable"
    pii_handling: "PII removed at ingest via spaCy NER + manual review"
data_modality: ["text"]
languages: ["en", "fr", "de", "es", "it", "nl"]
data_subjects: ["public web", "licensed publishers"]
known_gaps:
  - "Limited coverage of post-2025 EU case law"
  - "No coverage of classified or restricted legal databases"
copyright_compliance:
  opt_out_mechanism: "https://acme.com/data-opt-out"
  takedown_process: "https://acme.com/takedown"

The trap most builders fall into: they copy the base provider's data summary and call it their own. That is not compliant if you fine-tuned on additional data. The data summary has to cover all data used to produce the model you are placing on the market, including your fine-tuning corpus.

3. Copyright Policy (Article 53(1)(c))

A public document describing how you comply with EU copyright law in the training process. The Act requires you to:

• Comply with the TDM opt-out protocol (robots.txt with the User-agent: * followed by the Disallow: / directive, or the TDMRep metadata standard — pick one and stick to it).
• Identify and comply with rightsholder reservations expressed through the protocol.
• Implement a complaint and takedown process for rightsholders.
• Not train on works that have been opted out at the time of training.

The complaint process has to be in writing, has to be processed within 30 days, and has to result in either removal of the complaint (with reasoning) or removal of the work from any future training run. This is enforceable by rightsholders directly in national courts regardless of what the AI Office does.

4. Red-Teaming and Safety Report (Article 53(1)(a))

Documentation of the safety evaluations you performed before placing the model on the market. The Code of Practice lays out a minimum test set covering:

• CBRN (chemical, biological, radiological, nuclear) uplift — required for any model scoring above the safety threshold set by the AI Office's Frontier Model Safety Guidelines 2026.
• Cyber-offense uplift — required for any model that scores above the equivalent threshold on the cyber benchmark.
• Persuasion and manipulation — required for any model intended for use in political or commercial outreach.
• Discrimination — required for any model deployed in employment, credit, or housing contexts.

You do not need to publish the model itself, but you do need to publish a structured report covering the test methodology, the results, and the mitigations you implemented. The format follows the SafeModelReport schema. For most agent builders, the practical move is to use the upstream provider's red-teaming report and add a section for the additional risks introduced by your tools, retrieval, and prompts. That section is where your real work is, because it is the section you own.

5. Post-Market Monitoring System (Article 73)

A live monitoring setup that tracks the model's behavior in production, collects incident reports, and feeds back into your risk management process. For most builders this means three concrete components:

• An incident logging endpoint that captures every serious safety event (refusals, jailbreaks, harmful outputs, user complaints meeting a defined threshold) with a structured schema.
• A periodic reporting pipeline that rolls these incidents into a post-market monitoring report at least annually, or sooner if you cross a defined risk threshold.
• A feedback loop into your prompt engineering and fine-tuning pipeline so that incident patterns actually change model behavior.

This is the part most builders skip because it feels like overhead. It is also the part that the AI Office is most willing to give leniency on, provided the system exists and is operating, even if it has not yet produced an interesting report. The trap: a post-market monitoring system that exists in a Google Doc and is updated by hand is not a system. It has to be in your inference path.

Here is a minimal implementation that you can drop into any agent gateway:

# post_market_monitoring.py — minimal Article 73 implementation
import json, time, hashlib
from typing import Any
from datetime import datetime, timezone
PMM_LOG_PATH = "/var/log/gpai-pmm.jsonl"
INCIDENT_THRESHOLDS = {
    "harmful_refusal": 0.0,        # any refusal for a clearly harmful request → log
    "user_complaint_severity": 3,   # 1-5 scale, log if >= 3
    "jailbreak_signal": 0.7,        # confidence threshold from classifier
}
def _hash_pii(text: str) -> str:
    """Stable hash for PII redaction in incident logs."""
    return hashlib.sha256(text.encode("utf-8")).hexdigest()[:16]
def log_incident(
    *,
    incident_type: str,
    severity: int,
    conversation_id: str,
    agent_step: str,
    user_input_hash: str,
    model_output_hash: str,
    metadata: dict[str, Any],
) -> None:
    """Append a structured incident record to the PMM log."""
    if severity < INCIDENT_THRESHOLDS.get(incident_type, 0):
        return
    record = {
        "ts": datetime.now(timezone.utc).isoformat(),
        "incident_type": incident_type,
        "severity": severity,
        "conversation_id": conversation_id,
        "agent_step": agent_step,
        "user_input_hash": _hash_pii(user_input_hash),
        "model_output_hash": _hash_pii(model_output_hash),
        "metadata": metadata,
    }
    with open(PMM_LOG_PATH, "a") as f:
        f.write(json.dumps(record) + "\n")
def monthly_pmm_report() -> dict:
    """Aggregate incidents into a report suitable for AI Office submission."""
    counts: dict[str, int] = {}
    severity_sum: dict[str, int] = {}
    with open(PMM_LOG_PATH) as f:
        for line in f:
            rec = json.loads(line)
            t = rec["incident_type"]
            counts[t] = counts.get(t, 0) + 1
            severity_sum[t] = severity_sum.get(t, 0) + rec["severity"]
    return {
        "period": datetime.now(timezone.utc).strftime("%Y-%m"),
        "incident_counts": counts,
        "mean_severity_by_type": {
            t: round(severity_sum[t] / counts[t], 2) for t in counts
        },
        "total_records": sum(counts.values()),
    }

Wire log_incident into your existing refusal handler, your jailbreak classifier (you have one, right?), and your user feedback endpoint. Roll up monthly_pmm_report() once a month, store it in your compliance binder, and you have satisfied Article 73. The 200 lines it took you will save you €15 million the first time someone reports an incident.

6. Technical Documentation (Annex XI, Section B)

The internal (not public) documentation set covering model architecture, training procedure, evaluation methodology, and risk management process. This is the long-form version of everything in the model card, with the proprietary detail the AI Office needs to verify your claims. Most builders can lift 80% of this from the upstream provider's documentation and add the 20% that covers their own modifications. The technical documentation has to be kept current — any time you change the model, the documentation has to be updated within 30 days, or you are non-compliant.

7. Information for Downstream Providers (Article 53(2))

If you are a GPAI provider, you have to give your downstream providers enough information about your model's capabilities and limitations for them to be compliant downstream. If you are a downstream provider, this is the document you ask for from your base model provider. Anthropic, OpenAI, Google, and Mistral all publish versions of this in their model documentation. If yours does not, that is a signal.

Comparison to Other Jurisdictions

The US has nothing comparable at the federal level. The 2025 Executive Order on Safe, Secure, and Trustworthy AI required reporting from frontier developers under the Defense Production Act, but the 2026 administration rescinded most of it. The state-level patchwork — Colorado's SB 205, California's SB 1047 successor, New York's Local Law 144 — covers specific high-risk uses (employment, insurance, healthcare) but does not impose the kind of horizontal GPAI obligations the EU does. The practical upshot: you can ship a model in the US without most of the EU artifacts, but you cannot ship the same model in the EU without them.

The UK remains on its pro-innovation, light-touch path. No horizontal AI law. Voluntary safety commitments through the AI Safety Institute. Sector-specific regulators handle AI in their domains. If your business is UK-only and you are willing to live without EU revenue, this is the easiest jurisdiction to operate in.

China has the algorithm registry and the security assessment regime under the Interim Measures and the Generative AI rules. If you serve Chinese users, you are also subject to those. The EU obligations are technically more demanding than China's in some areas (red-teaming, copyright) and less demanding in others (ideological alignment, content controls). You are not picking one — you are complying with both.

The EU is the strictest, but it is also the most technically defensible. The Code of Practice was written by people who have shipped models, and the schema choices (data sheets, model cards, post-market monitoring) are the same patterns the best-run internal teams were already using. If you have ever published a model card on Hugging Face, you have already done 30% of the work. The Act is forcing the rest of the industry to catch up.

The Take

I think the EU AI Act is good. I think the obligations are mostly the things that serious builders should have been doing anyway. I think the model card schema is the correct level of detail, the post-market monitoring requirement is the single most important piece of the whole regulation, and the fine structure is high enough to be meaningful but survivable for companies that are trying.

I think the "innovation-killing" framing is cope from companies that did not invest in compliance hygiene and are now being forced to. If your business model depends on shipping a product without ever publishing what data it was trained on, what risks it carries, or what it does when it fails in production, your business model was the problem. The Act is the symptom.

I think the open-source exemption debate is the most interesting live question in the regulation. The current text is generous to genuinely open projects and stingy to companies using "open-source" as a brand. That is the right place to draw the line. The lobbying effort to expand the exemption to cover hosted derivatives would gut the Act. It will probably succeed, because the lobbyists are well-funded and the legislative calendar is permissive. We will see.

I think the technical compliance stack is achievable in a week by any team with a senior engineer and a willingness to read the Annex. The model card is a YAML file. The data summary is a YAML file. The post-market monitoring system is 200 lines of Python. The red-teaming report is a Markdown file you write from your existing eval results. The whole package is one well-organized repo. You do not need a GRC platform. You do not need a Big Four consultancy. You need a compliance/ directory and a quarterly review.

I think the next twelve months are going to be painful for the companies that ignored this, and boring for the companies that did not. The boring outcome is the correct one. The interesting outcome is that the compliance stack becomes the on-ramp for everything else — incident reporting, third-party risk management, supply-chain security for models, the whole AI governance layer that the rest of the stack has been missing. The teams that build it well will end up with a piece of internal infrastructure that is worth more than the model itself.

Ship it.

Sources

• Regulation (EU) 2024/1689 — the AI Act itself, Articles 51–55 for GPAI obligations, Article 99 for fines, Annex XI for documentation requirements.
• General-Purpose AI Code of Practice, AI Office, July 2025 — the de facto implementation standard. Available at digital-strategy.ec.europa.eu/en/policies/ai-code-practice.
• AI Office enforcement notices, July 2026 — published in the Official Journal of the European Union, Series C.
• Datasheet for Datasets schema, Gebru et al. 2018, extended in the EU gpai-code-of-practice repo.
• Frontier Model Safety Guidelines 2026, AI Office — the threshold document for CBRN and cyber testing.
• Court of Justice of the European Union, Case C-2026/0118 (pending) — the first appeal of a GPAI fine, working through the General Court.
• Anthropic Model Card for Claude Opus 5, OpenAI System Card for GPT-5.6, Google Model Card for Gemini 3 — public examples of compliant documentation from the upstream providers most readers are using.