On August 2, 2026, the European Commission gained the power to fine a general-purpose AI model provider up to 3 percent of global annual turnover. The obligations those fines attach to had been in force for a full year already. The fines had not. That gap is the single most misread fact about the AI Act, and it explains why a lot of teams spent 2025 writing policy documents that no regulator could act on and 2026 discovering they had no evidence to hand over.
The same date turned Article 50 transparency duties from a drafting exercise into an operating requirement for anyone running a chatbot, a content generator, or an emotion recognition tool that touches an EU user. Most of the coverage since has been a flat list of requirements. A flat list is the wrong shape. The Act assigns different duties to different parties at different dates, and the only way to work it is to figure out which role you hold per system, then map each duty to something an engineer builds.
What actually applied, and when
The staged timeline matters more than the headline date, because your exposure depends on which stage you are in.
| Date | What started applying |
|---|---|
| 1 Aug 2024 | Regulation entered into force |
| 2 Feb 2025 | Prohibited practices (Art. 5), AI literacy duty (Art. 4) |
| 2 Aug 2025 | GPAI model obligations (Ch. V), governance structures, national penalty regimes, notified bodies |
| 2 Aug 2026 | General application: Art. 50 transparency, Annex III high-risk regime, Commission fining power over GPAI providers (Art. 101) |
| 2 Aug 2027 | GPAI models placed on market before Aug 2025 must be brought into compliance; high-risk systems embedded in regulated products (Art. 6(1)) |
One caveat worth reading carefully before you build a plan around it. The Commission's digital omnibus package proposed pushing parts of the Annex III high-risk regime into late 2027 and 2028, tied to whether harmonised standards are actually ready. Legal analyses through 2026, including Cooley's summary of the August transparency deadline, have tracked movement here. Check the current consolidated text and your national implementing act before you plan around any high-risk date. The transparency and GPAI enforcement dates are the settled ones. Build against those first.
Provider duties: documentation is the deliverable
If you place a general-purpose AI model on the EU market, Article 53 gives you four baseline obligations regardless of model size:
- Technical documentation of the model covering training, testing, and evaluation, kept current (Annex XI)
- A documentation package for downstream providers so they can meet their own obligations (Annex XII)
- A copyright policy, including a mechanism to respect text and data mining reservations
- A publicly available summary of training content, on the template published by the AI Office
Free and open-source models get an exemption from the first two, provided parameters, architecture, and usage information are public. They do not get an exemption from the copyright policy or the training summary. And the exemption evaporates entirely if the model carries systemic risk.
Systemic risk is where the requirements change character. A model is presumed to carry it when cumulative training compute exceeds 10^25 FLOP. That triggers notification to the Commission within two weeks, plus Article 55 duties: state-of-the-art model evaluation including adversarial testing, assessment and mitigation of Union-level risks, serious incident reporting to the AI Office without undue delay, and adequate cybersecurity for both model weights and the physical infrastructure holding them. That last one is frequently skipped in compliance reviews because it reads like a security requirement rather than a regulatory one. It is both, and weight exfiltration is an explicitly contemplated incident category.
The GPAI Code of Practice is the path of least resistance here. Its three chapters (Transparency, Copyright, Safety and Security) function as a presumption-of-conformity route. Signing is voluntary. Not signing means demonstrating compliance by other means, to a regulator who has a signed alternative sitting on the desk for comparison.
The trap most teams walk into: you can become a provider without intending to. Commission guidance sets a threshold where fine-tuning an existing model makes you the provider of that modified model, keyed to the training compute of the modification relative to the original. Article 25 adds three more routes: putting your name or trademark on a high-risk system, making a substantial modification, or changing the intended purpose such that the system becomes high-risk. Teams that wrap a vendor model, brand it, and ship it to enterprise customers routinely assume they are deployers. Several of them are not.
Deployer duties: two disclosures, two different mechanisms
Article 50 is where the provider/deployer split gets sharp, and where the most common implementation error lives. The four operative paragraphs sit in different places:
| Paragraph | Who | What |
|---|---|---|
| 50(1) | Provider | Systems interacting with people must inform them they are interacting with AI, unless obvious |
| 50(2) | Provider | Synthetic audio, image, video, and text must be marked in a machine-readable format, detectable as artificially generated |
| 50(3) | Deployer | Emotion recognition and biometric categorisation systems: inform exposed persons |
| 50(4) | Deployer | Deep fakes must be disclosed. AI-generated text published to inform the public on matters of public interest must be disclosed unless human editorial review applies |
Here is the error. Teams read "transparency" and ship a footer that says "generated with AI." That footer addresses 50(4). It does nothing for 50(2), which asks for marking at generation time in a format a machine can verify. Those are different engineering problems with different owners, and only one of them can be solved in the UI layer.
Implementing 50(2) means a provenance pipeline. The C2PA content credentials specification is the interoperability standard most of the industry has converged on for media, and SynthID is the reference example of watermarking that survives common transformations. Both have honest limitations. Metadata gets stripped by most social platforms on upload, and text watermarking degrades under paraphrase. The Act's "as far as technically feasible" qualifier is carrying real weight. That is not a reason to skip it; it is a reason to document what you implemented and why, because the documentation is what a regulator will ask for.
For deployers of high-risk systems, Article 26 adds the operational layer: use per the provider's instructions, assign human oversight to trained and competent people, control input data relevance, monitor operation and suspend on risk, retain logs for at least six months, and inform worker representatives before deploying in the workplace. DLA Piper's analysis of deployer obligations for employers is worth reading if you run anything touching hiring, performance, or task allocation, because the workplace consultation duty catches teams that never thought of themselves as regulated. Article 27 requires a fundamental rights impact assessment for public bodies and for private entities doing credit scoring or life and health insurance risk assessment.
The method: one obligation, one artifact, one owner
The AI Act is not a checklist. Treating it as one produces a policy binder nobody can act on. The version that works is a map from each applicable obligation to a thing your team builds and can produce on demand.
| Obligation | Operating artifact | Owner | Evidence on request |
|---|---|---|---|
| Art. 50(1) interaction notice | Disclosure string in system prompt and first-turn UI, version controlled | Product | Git history of the string, screenshots |
| Art. 50(2) synthetic marking | Provenance manifest or watermark applied at generation | Platform eng | Sample outputs run through a verifier |
| Art. 50(4) deep fake / public-interest text | Label policy plus editorial review record | Editorial | Signed review log |
| Art. 53(1)(a) technical documentation | Model documentation regenerated on every retrain | ML eng | Doc version pinned to model hash |
| Art. 53(1)(b) downstream information | Integration doc pack | ML eng | Published doc and changelog |
| Art. 53(1)(d) training summary | Public summary on the AI Office template | Legal and data | Live URL |
| Art. 55(1)(c) incident reporting | Incident taxonomy and routing runbook with clock | Security on-call | Incident register |
| Art. 26(5) monitoring | Trace store, dashboards, alert thresholds | Platform eng | Coverage query |
| Art. 26(6) log retention | Retention policy enforced at the store | Platform eng | Retention config and audit |
| Art. 26(2) human oversight | Allowed-actions policy with approval gates | Ops | Approval records |
| Art. 86 explanation right | Per-decision trace with retrievable rationale | Platform eng | Sample explanation output |
Every row is something an engineer builds, not something a lawyer writes. If a row has no artifact, the obligation is not covered, no matter what the policy binder says. That is the whole method.
Several of these rows are systems you should already have for reasons unrelated to Brussels. The trace and retention requirements are the same infrastructure described in what regulated industries need from AI agent audit trails. The human oversight row is the allowed-actions governance document. The monitoring row is operator dashboards for AI workflows, and the data-control duty in Article 26(4) overlaps heavily with permission-aware agent design. Compliance work that produces no operational value is a sign you built the wrong artifact.
To avoid maintaining two vocabularies, pick one management framework and crosswalk to it. ISO/IEC 42001 gives you a certifiable AI management system, and the NIST AI Risk Management Framework gives you a govern/map/measure/manage structure that maps cleanly onto Articles 9 and 26. Harmonised European standards from CEN-CENELEC JTC 21 are the ones that will eventually confer presumption of conformity, and their delivery schedule is the main reason the high-risk dates keep moving.
What enforcement will actually look like
Penalty tiers are tiered by seriousness: up to 35 million euro or 7 percent of global turnover for prohibited practices, up to 15 million euro or 3 percent for most other breaches including Article 50 and GPAI provider duties, and up to 7.5 million euro or 1 percent for giving incorrect information to authorities. SMEs face the lower of the two figures rather than the higher.
Enforcement runs in two lanes that people conflate. The Commission and the AI Office supervise general-purpose models directly. National market surveillance authorities supervise AI systems in their territory, and a meaningful number of member states were late designating those authorities and passing penalty regimes, which means enforcement capacity is uneven across the bloc.
The realistic first year is information requests, not raids. The AI Office can demand documentation, require model evaluations, and order mitigation measures. What triggers the request is usually a complaint. Article 85 gives any natural or legal person the right to file one with a market surveillance authority, which puts your competitors, your users, and civil society organisations in the referral pipeline. Regulators also arrive with adjacent context already assembled: the EDPB's opinion on data protection aspects of AI models established positions on training data and legitimate interest that overlap directly with AI Act documentation duties.
The counter-intuitive part: for most companies the near-term financial risk is not the fine. It is procurement. Enterprise buyers have been inserting AI Act clauses into vendor contracts since 2025, and the request that stalls deals is not "are you compliant" but "send us your Annex XII documentation." Sales cycles die quietly while someone assembles a document that should have been generated automatically on the last model release. Public benchmarking efforts like the Stanford Foundation Model Transparency Index have shown how wide the disclosure gap runs even among well-resourced providers, and buyers have started using that as a diligence input.
The 30-day version
If you have done nothing, this is the order that produces the most coverage per unit of effort:
- Inventory. List every AI system touching EU users, customers, or employees. Include the ones shipped by a team that did not tell you. Most organisations find two to three times more systems than the initial estimate.
- Classify. Prohibited, high-risk, transparency-only, or minimal. Per system, not per company.
- Fix your role. Provider or deployer for each row. Run the Article 25 and fine-tuning-compute checks before you settle on deployer.
- Ship the cheap disclosures. Interaction notices and synthetic content marking are days of work and close the obligations that apply right now.
- Turn on retention. Six months is the floor for high-risk logs. Twelve is the practical setting, because incident investigations run long.
- Write the allowed-actions policy. Human oversight is not a checkbox; it is a document naming which actions require approval and who gives it.
- Assign owners and dates. An obligation without a named person is unowned.
How OpenNash Can Help
Most of the AI Act work that matters is engineering work with a compliance label on it. OpenNash builds production agent systems where the trace store, approval gates, allowed-actions policy, and incident routing exist because the system needs them to run safely, and satisfy the regulation as a side effect. Our delivery model is an audit that maps your systems and roles, a design phase that fixes guardrails and human approvals before anything ships, a build, and a deployment with full ownership handoff and documentation you own outright.
Not everyone should build. If you deploy one vendor chatbot and nothing else, your obligations are a disclosure string and a retention setting, and you do not need a partner for that. If you are on a regulated platform with a mature compliance module, use it. Custom work earns its keep when you are a provider rather than a deployer, when your workflows do not fit a product's assumptions, or when you need auditability and human handoff designed into the system rather than bolted onto it.
Book a call to map your obligation-to-artifact table against what you have actually built.
Start with the inventory. Everything downstream depends on knowing which systems you have and which role you hold for each one, and that is the step teams keep deferring because it is tedious rather than hard.
---
Two things to check before this publishes:
1. **High-risk timeline.** The digital omnibus changes to the Annex III dates were still moving through the legislative process as of my training data, so I hedged that paragraph and pointed readers at the consolidated text rather than asserting a specific new deadline. Verify against the current text if you want a firmer claim.
2. **Internal link slugs.** I used `/blog/<slug>/` with the four slugs from the topic notes. Two of them look truncated (`...what-regulated-industries-need-before`, `...what-operators`), and I could not confirm the permalink format because the shell returned corrupted output. Worth a `npx @11ty/eleventy` build and a link check.