EU AI Act · Article 50
Applies since 2 August 2026 — disclosure is now a feature, not a policy.
The dates that bind
2026-01-01 shipped
California trio in force
AB 2013 training-data transparency, SB 53 frontier transparency (TFAIA), and the CPPA risk-assessment / ADMT / cyber-audit regulations all took effect.
Who: Anyone offering generative AI to Californians · source ↗
2026-07-27 shipped
Digital Omnibus in force
Regulation (EU) 2026/1744 amended the AI Act: standalone high-risk duties deferred to 2 Dec 2027 and embedded-product duties to 2 Aug 2028 — but 2 Aug 2026 was left untouched.
Who: Everyone in EU scope · source ↗
2026-08-02 LIVE NOW
Article 50 transparency APPLIES
Chatbots must disclose they are AI; synthetic audio/image/video/text must be machine-readable marked and detectable; deepfakes and AI-generated text on matters of public interest must be labelled. AI Office and national enforcement powers switch on the same day.
Who: Any product that chats or generates content · source ↗
2026-12-02 next up
Legacy grace ends (Art 50(2) only)
Systems already on the market before 2 Aug 2026 get until this date for the marking-and-detection duty ONLY. Chatbot disclosure and deepfake labelling had no grace period at all.
Who: Pre-existing generative systems · source ↗
2027-01-01 ahead
US ADMT duties begin
Colorado SB26-189 developer documentation duties begin, and California CPPA ADMT requirements for significant decisions apply.
Who: Automated decisions in hiring, lending, housing, healthcare · source ↗
2027-12-02 ahead
EU high-risk (standalone)
Chapter III obligations for Annex III standalone high-risk systems apply — deferred ~16 months by the Digital Omnibus.
Who: High-risk system providers/deployers · source ↗
2028-08-02 ahead
EU high-risk (embedded)
Annex I embedded-product high-risk obligations apply.
Who: Regulated products with AI inside · source ↗
Article 50, as engineering work — four duties; only one has a grace period
| Article | The duty | What you actually build | Grace? |
|---|---|---|---|
| Art 50(1) | Tell people it is AI | A persistent, unmissable disclosure in any chat surface — not buried in ToS. Applies from 2 Aug 2026 with no grace period. | none |
| Art 50(2) | Mark synthetic output machine-readably | Embed provenance in generated media/text (e.g. C2PA-style manifests, watermarks) so it is detectable downstream. This is the one duty with a legacy grace period — to 2 Dec 2026 — for systems on the market before 2 Aug 2026. | to 2 Dec 2026 |
| Art 50(3) | Notify emotion-recognition / biometric categorisation | Explicit notice to exposed individuals before processing. | none |
| Art 50(4) | Label deepfakes and public-interest AI text | Visible labelling on deepfakes and on AI-generated text published on matters of public interest. No grace period. | none |
Compliance as routing policy — what a gateway can enforce, and what this one does today
The useful insight for a router: most of this is enforceable at the routing layer. Residency, retention and provider allow-lists are request parameters, not paperwork — with a defined failure mode when no compliant provider can serve the request. Here's the honest status of each in this gateway.
| Control | What it does | Request shape | Status here |
|---|---|---|---|
| Zero data retention | Force endpoints that do not store prompts or completions. | provider.zdr: true | roadmap OpenRouter documents this shape; our gateway does not enforce it yet — the honest status. |
| No training on your data | Exclude providers that retain or train on inputs. | provider.data_collection: "deny" | roadmap Needs a per-provider retention flag in the catalog. |
| Data residency | Keep processing in-region (e.g. EU-only). | eu.openrouter.ai / region-pinned endpoints | roadmap Provider-side capability; would become a routing constraint. |
| Provider pinning + fail-closed | Pin approved providers and ERROR rather than silently falling back to a non-compliant one. | only / order + allow_fallbacks: false | partial today Our gateway already scopes providers via X-Switchboard-Providers; fail-closed (no fallback outside the allowed set) follows from it. |
| AI disclosure stamping | Stamp responses as AI-generated to help satisfy Art 50(1). | response header / disclosure field | roadmap A natural gateway feature: one flag, applied to every routed response. |
MCP tool access control — a reference architecture, not a routing control
Cloudflare's MCP Portals (docs published 2026) are a different layer from the five routing controls above: those govern which model provider a completion routes to, this governs which MCP tool servers an agent is allowed to call and with what credentials. This gateway has no MCP tool-serving surface yet, so nothing below is a shipped or roadmap status for this app — it is the pattern to build to when that surface exists.
| Mechanism | What it does |
|---|---|
| Unified auth | Users authenticate once to Cloudflare Access; per-server OAuth to upstream MCP servers is layered on top, or an admin can pre-configure shared credentials instead. |
| Tool curation | Admins enable/disable individual tools, rename them via aliases, and rewrite descriptions — server-level Allow policies control which users even see a tool exists. |
| Namespacing | Tools are auto-prefixed with a server ID (e.g. github_list_issues), splitting on the first underscore only, so tool names can contain underscores without colliding. |
| Context-budget modes | minimize_tools strips schemas and exposes a search tool; search_and_execute hides all upstream tools behind query/execute wrappers — both exist purely to cut token spend on large tool sets. |
| Code Mode | Collapses every tool into two JS execution methods running in isolated Workers, so credentials never enter the model's context window. |
| Traffic visibility | Optional routing through Cloudflare Gateway puts every tool call in the same HTTP logs as the rest of an org's traffic, with DLP scanning available. |
Article 50 disclosure and the routing controls above assume the gateway's only job is choosing a model. An agentic surface that calls tools (file systems, ticketing, internal APIs) needs the access-control question answered too — who can invoke which tool, with which credentials, logged where. Cloudflare's answer is the most complete public reference architecture found for that question as of this research pass; it is cited here, not implemented. Cloudflare docs — MCP Portals ↗
Pre-flight prompt screening — the one control here that actually runs shipped — requires a TypeSafe API key; inert without one
The five routing controls above are graded honestly: none of them ship yet. This one does, which is why it is recorded separately rather than folded into that scoreboard. Before the router forwards a prompt to a third-party provider, it can ask Jev — TypeSafe’s System One decision model — two yes/no questions about that prompt, and get calibrated probabilities back in roughly a tenth of a second for a fraction of a cent. Screening before egress is the part of a data-protection story that is usually hand-waved; here it is a code path you can read.
| Mechanism | What it does |
|---|---|
| Personal data detection | A Noul question asks whether the prompt contains names, email addresses, phone numbers, account numbers or government identifiers. Above 0.5 the app raises a warning advising a local or EU-hosted model before the prompt leaves the building. It advises rather than blocks — silently dropping a user’s prompt on a probability is worse than telling them what the probability is. |
| Instruction-override detection | A second Noul asks whether the prompt tries to override or leak the instructions of the system processing it. This is TypeSafe’s own Guardrails-for-LLMs pattern, applied to the router’s ingress rather than an app’s. |
| Both ride along free | They are asked in the same request as the job-type classification. One state ingest answers all seven questions in the same parallel pass, and Jev bills input tokens only, so screening adds essentially nothing over the classification that was happening anyway. |
| The limits are stated, not buried | A probability is not a determination. Jev reads state literally, does not treat it as hostile by default — TypeSafe says so plainly — and no calibration curve has been published by anyone, so these numbers are untested against real-world frequencies. Treat the screen as a prompt for human judgment, never as a compliance guarantee or a lawful basis. |
Article 50 transparency and the GDPR data-minimisation duty both turn on knowing what you sent and to whom. A router that forwards prompts across providers is exactly where that knowledge gets lost. Screening at the routing boundary is the cheapest place to recover it — and because the model returns a probability rather than a verdict, the decision about what to do with it stays with the operator. See it run on the Jev page →
Frameworks & standards
EN 18286:2026
2026-07-31CEN-CENELEC JTC 21
First European standard published in support of the AI Act — a sector-neutral quality-management system aimed squarely at the Article 17 QMS duty.
⚠ OJEU citation — which is what actually confers the Article 40 presumption of conformity — had not happened yet as of publication.
ISO/IEC 42001
—ISO/IEC
Broader organisational AI-governance management system. EN 18286 Annex D maps across to ISO/IEC 42001 Annex A controls.
⚠ Complementary, not a drop-in substitute: an existing 42001 programme is reusable input for EN 18286, not automatic conformity.
NIST AI RMF 1.0
2026-04-07NIST
Under revision as part of the White House AI Action Plan; a concept note for a Critical Infrastructure profile landed 7 Apr 2026. COSAiS overlays and the Cyber AI Profile (IR 8596) remain drafts.
⚠ US buyers still ask for RMF mapping, so evidence stays useful across the revision.
Code of Practice on Transparency of AI-generated Content
2026-06-10EU AI Office
Final code assessed adequate by the Commission and AI Board. Section 1 = provider marking/detection (Art 50(2)); Section 2 = deployer deepfake/text labelling (Art 50(4)). ~190 organisations signed by 31 Jul 2026.
⚠ Signing is the cheapest defensible route; not signing means proving equivalence to each market surveillance authority.
Enforcement
Penalty ceilings
Prohibited practices (Art 5)up to €35M or 7% of worldwide annual turnover
GPAI obligations & most other breachesup to €15M or 3%
Supplying incorrect informationup to €7.5M or 1%
Enforcement powers of the AI Office and national competent authorities apply from 2 August 2026 — covering prohibited practices, GPAI provider obligations and Article 50 transparency, including model evaluations, requests for information and corrective measures.
🇺🇸 The US picture
The US pattern inverted in 2026: Colorado retreated from a duty-of-care model (SB24-205) to ADMT disclosure under SB26-189 with obligations from 1 Jan 2027, while California's training-data (AB 2013) and frontier-transparency (SB 53) laws went live 1 Jan 2026. Executive Order 14365 then put state AI laws under federal challenge, so treat US state rules as configuration, not hard-coded assumptions.
⚖ Engineering guidance, not legal advice. Dates and figures are cited to primary sources and were verified on 2026-08-18; the Digital Omnibus amendments are recent and US state rules are under active federal challenge, so re-check before relying on any of it.
Primary sources — every date above traces to one of these
EU AI Act Article 50 FAQ (Commission) ↗Regulation (EU) 2026/1744 — Digital Omnibus on AI (EUR-Lex) ↗Commission guidelines on Art 50 transparency (20 Jul 2026) ↗Code of Practice on Transparency of AI-generated Content ↗AI Act enforcement (Commission) ↗EN 18286:2026 (CEN-CENELEC) ↗Colorado SB26-189 (ADMT) ↗California AB 2013 (training-data transparency) ↗California SB 53 (TFAIA) ↗NIST AI Risk Management Framework ↗AI Act Evaluation Benchmark (arXiv 2603.09435) ↗Cloudflare docs — MCP Portals ↗ ↗