What the request path can prove
The AI Act's first year was compliance on paper. Since 2 August 2026, the Commission's enforcement powers over general-purpose AI, the Article 50 transparency obligations, and the penalty regime have applied. No infrastructure component makes you compliant — but a substantial part of what any obligation eventually requires is evidence, and evidence is either produced in the request path or reconstructed later at great expense.
It is an engineering map, written for the platform team that has to produce the artifacts: obligation → the artifact that evidences it → where it comes from. Your risk classification, conformity assessment and legal posture are yours and your counsel's.
What changes, precisely
Takes effect
- Commission enforcement powers over GPAI providers.
- Article 50 transparency obligations.
- The penalty regime.
Does not
The Annex III high-risk obligations were deferred to 2 December 2027 under the Digital Omnibus provisional agreement of 7 May 2026. They are a separate track, and anyone telling you high-risk obligations begin in August is working from stale information.
Prohibited practices have applied since 2 February 2025 and GPAI model rules since 2 August 2025. What arrives now is enforceability and penalty exposure.
Obligation, artifact, source
A table your platform team can work straight from. Most of it is what a governed request path records anyway; the Enterprise evidence pack then maps it to provisions as evidenced, partial or gap. Articles 12, 14 and 26 bind high-risk systems, from the date above.
| Evidence requirement | Artifact needed | Produced by Wäg as |
|---|---|---|
| Automatic record-keeping (Art. 12) | Every provider call and every refusal, in a record that shows tampering | Evidence ledger (open source): hash-chained, with Ed25519-signed checkpoints; in required mode, no evidence, no egress |
| Log retention (Art. 19, Art. 26(6)) | Records kept at least six months, and beyond the database if needed | Request logs 180 days and ledger traffic 365 days by default; write-once archive to S3, Azure or GCS (Enterprise) |
| Traceability of automated decisions | Which model served a request, and why | x-waeg-routed-model on every response, x-waeg-route-reason when intelligent routing chose; both in the request log |
| Human oversight is demonstrable | Evidence controls exist and are enforced, not advisory | Policy verdicts per request, fail-closed budget rejections, model allow-lists |
| Override and stop (Art. 14(4)(d)–(e)); oversight assigned to people (Art. 26(2)) | A named owner and approvers per agent; a person approved the risky action, or stopped the agent | Tool-policy approvals and kill-switch stops, with who and why, in the evidence ledger |
| Agent evidence an auditor can check | Runs, approvals, stops and the ledger for a window, in one signed file | Agent evidence packs (Enterprise): signed, checked with waeg evidence verify, with a per-provision mapping.json |
| Machine-readable marking of generated content (Art. 50(2)) | Marks a detector can read, and how much output carried them | Enterprise: C2PA credentials, watermarks, text fingerprints, a verify endpoint. Every build records mark coverage |
| Deployer labelling (Art. 50(4)) | Which answers are AI-generated or AI-modified | x-waeg-ai-label on every content answer, generated or modified: a hint; what you show your users is your decision |
| Data governance and minimization | Evidence sensitive data was controlled before egress | Pre-call, mid-stream and post-call scan verdicts with the action taken |
| Provider and location control | Where each request was sent, and that it stayed in allowed jurisdictions | Residency (enforce or observe), jurisdiction per request and in the ledger, register of information as CSV or JSON |
| Incident reconstruction | A reconstruction of what happened, including agent loops | Agent runs and spans, tool-call and approval ledger entries; MCP rows with server, tool, latency and error |
| Accountability and ownership | Attribution of usage to an org unit and a person | Org → team → user → key hierarchy with chargeback tags |
| Change control over AI configuration | Who changed which policy or budget, and when | Admin audit trail (Enterprise); every config revision is also hashed into the evidence ledger |
| Independent review | An auditor checks the evidence without seeing prompts | org_auditor role (Enterprise): read-only, verifies and exports the ledger, no request bodies |
| Erasure without losing the record (GDPR) | A person's data unlinkable, the evidence still intact | Per-person digest keys destroyed; the chain stays verifiable and the erasure is itself recorded |
Ledger exports and evidence packs verify offline against an Ed25519 key you pin (waeg ledger verify, waeg evidence verify), and the algorithm needs only SHA-256 and Ed25519, so an auditor need not trust the system that wrote them. The pack's mapping is guidance for the people assessing compliance, not a conformity assessment or legal advice.
Application instrumentation cannot get you there
Application-level logging produces evidence for the applications that implemented it. That is the whole problem: your obligations attach to your organization's AI use, not to the subset of it that somebody remembered to instrument. A control plane in the request path produces the same records for every workload behind the endpoint.
It is also the only layer that produces enforcement evidence rather than observation evidence. A record showing a request was rejected because it breached a policy is a materially different artifact from a record showing it was sent.
What Wäg does not do
Wäg is infrastructure, not a compliance programme. It does not classify your systems' risk category, produce conformity assessments, maintain technical documentation, register systems, perform fundamental-rights impact assessments, or determine whether you are a provider or a deployer. It produces evidence and enforces controls that you define. Everything else is yours, and most of it is a legal and organizational exercise rather than a technical one.
Seven things worth doing
- Inventory which applications call which providers today — and note how you know, because that is the part that decays.
- Establish a single ingress for model traffic, so the inventory stays true without maintenance.
- Attribute every request to an org unit and a person or service identity.
- Record routing decisions, not just requests. "Which model served this" is a separate fact from "this happened".
- Make data-handling controls enforced rather than advisory, and record their verdicts either way.
- Bring agent tool calls into scope — they are the largest evidence gap in most estates.
- Set retention on those records to match your obligations rather than your log budget — for deployer logs, at least six months.
One endpoint. Every model. Complete control.
Run it in your own infrastructure
Everything you need to run a control plane in production is Apache-2.0 and stays that way — routing, HA, caching, failover, budgets, policy, MCP, jobs and observability. Self-hosted, no account, no phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Not a working pull: the images are not public yet. Design partners receive the registry details privately.
Deploy in 5 minutesShape it as a design partner
Wäg is not publicly released yet. We are working with a small cohort of teams running multi-provider AI in production, and serious about governance and sovereignty, to harden the control plane on real workloads.
- Every Enterprise capability included, at no licence cost
- Hands-on migration — we do it with you, including from LiteLLM
- A direct line to the engineers building it, and real influence on what ships next