AI transparency isn't a UI problem. It's a distributed systems problem.
The EU AI Act doesn't just introduce new disclosure rules - it exposes a missing architectural layer in enterprise AI.
In two weeks, a quiet part of the EU AI Act becomes applicable.
Most of the discussion around it is about what users should see. Banners. Labels. Watermarks.
I think that’s missing the real engineering problem.
A simple example
Imagine a customer support assistant.
A user opens your website and starts a conversation. The request passes through an AI gateway, which selects a model based on company policy. The model generates a response. The frontend displays it together with an AI disclosure.
Everything looks correct.
Now fast-forward three months. An auditor — or simply your own security team — asks a few seemingly straightforward questions:
Which model generated this response?
Which policy was active at that moment?
Was the AI disclosure actually shown to the user — and when?
Can you prove all of this?
Most organizations can answer parts of these questions.
Very few can answer all of them with evidence.
We’ve solved this problem before
The instinctive answer is: “we already log everything.”
Logging is necessary. It isn’t sufficient. Logs describe isolated events — model selected, request completed, page published, banner rendered — but they can’t tell you whether those events belong to the same piece of content.
We’ve hit this wall before.
Microservices turned one request into fifty independent systems.
The solution wasn’t more logging.
It was distributed tracing: one identifier, propagated across every system a request touches.
AI-generated content is creating the same architectural problem — except the object being traced isn’t an HTTP request. It’s a piece of content, moving through generation, review, publication and translation over weeks instead of milliseconds.
And this time, correlation isn’t enough. Traces are sampled — dropping data is the design. They’re retained for weeks — auditors ask about years. Any service can emit spans into any trace — and rewrite them after the fact — with no signatures and no identity binding.
A trace tells you what probably happened, for debugging. This problem needs a record that proves what happened, for accountability.
That’s the difference between logging and provenance.
The information already exists
Every system already knows part of the story. The gateway knows which provider, model and policy were used. The application knows whether disclosure was rendered. The editorial workflow knows who approved the content. The CMS knows when it was published. Individually those records are correct. Collectively they cannot reconstruct the lifecycle.
The problem isn’t missing information. It’s missing continuity.
What the law actually asks
The quiet part of the AI Act is Article 50, its transparency chapter. It applies from 2 August 2026. Providers must design chatbots so people know they’re talking to AI. Deployers must label deepfakes and certain AI-generated text. Getting it wrong can cost up to €15 million or 3% of worldwide turnover — whichever is higher.
But Article 50(2) is the part worth reading twice: generative outputs must be “marked in a machine-readable format and detectable as artificially generated or manipulated”, through technical solutions that are “effective, interoperable, robust and reliable” as far as technically feasible. Machine-readable. Interoperable. Protocol words, not UI words.
(One timing nuance: the just-adopted Digital Omnibus gives systems already on the market until 2 December 2026 for the machine-readable marking. The disclosure duties still start on 2 August.)
One thing Article 50 never says: keep records. The Act’s logging obligations apply only to high-risk systems - a different chapter entirely. The proof pressure comes from enforcement instead. Market surveillance authorities can demand documentation from any operator. And the EU’s new Code of Practice on AI-content transparency - finalized in June, voluntary — makes the trade explicit: sign it, and you get a recognized way to show compliance; don’t, and you prove to authorities, case by case, that your own measures are good enough.
The law says: disclose and mark.
Enforcement asks: can you show that you did?
The obligations span roles; the evidence spans systems; the systems share no identifiers.
The exemption that proves the point
A marketing team drafts an article with an LLM. An editor rewrites it. Legal reviews it. The CMS publishes it; a translated version gets syndicated. Months later, somebody asks whether this content originated from AI and whether transparency obligations were met.
Now read Article 50(4). Its text-disclosure duty is narrow to begin with: it only covers AI-generated text published to inform the public on matters of public interest. And even where it applies, it exempts content that has undergone “a process of human review or editorial control” where someone “holds editorial responsibility for the publication of the content”.
Both limbs are questions of fact. What was this published for? Did a human review it — and who owned that responsibility?
The legally decisive artifact isn’t the label. It’s the evidence.
The statute never says “build an evidence chain.” It just makes relying on its exemptions untenable without one.
The missing layer: operational provenance
There’s already a standard for part of this story. C2PA (Content Credentials) gives you asset provenance: a signed history that travels with the file. It matters, and adoption is growing. But manifests are routinely stripped when content crosses platforms, the standard barely covers text - the dominant enterprise output - and by design it says nothing about the operator’s runtime: which policy was in force, why the router picked that model, whether disclosure duties were met.
What organizations increasingly need alongside it is operational provenance: a verifiable record of every decision surrounding an AI generation, across every system that touches it.
Asset provenance travels with the file. Operational provenance survives on the server, where a C2PA manifest can reference it, not replace it.
None of the cryptography is new. That’s a feature. It’s the same append-only, verifiable-log pattern Certificate Transparency and sigstore proved at internet scale. What doesn’t exist yet is that pattern applied to AI runtime decisions — across systems.
A control plane for AI operations
The next generation of AI infrastructure won’t stop at routing requests to models. It will treat every generation as an operational event that accumulates evidence over its lifetime:
AI generation → runtime policy applied → disclosure shown → human review completed → content published → evidence exported.
Almost everything in that chain belongs to the surrounding operational ecosystem, not the model. That’s why solving transparency exclusively inside an AI gateway will never be enough. Every serious gateway logs today — that’s not the gap. The gap is that the gateway’s record ends at its own boundary. Nothing downstream — the frontend’s disclosure, the editor’s review, the CMS’s label — can attach to it.
Where Talon fits
This is the direction we’re exploring with Talon.
Talon isn’t trying to become a legal compliance platform. It doesn’t decide when Article 50 applies. It doesn’t render disclosures. It doesn’t watermark images. Those responsibilities belong to applications, CMS platforms and legal teams.
Talon records the operational provenance of each AI generation: which agent initiated it, which provider and model were selected, which effective policy governed the decision, why routing occurred. Each record is signed and independently verifiable against a published integrity specification.
The next step is letting downstream systems extend that record with their own evidence. A frontend recording that disclosure was presented. A CMS recording that labeling was applied. An editorial workflow recording that human review completed, the exact fact the text exemption turns on.
The result isn’t a prettier dashboard. It’s a verifiable operational history.
One honest caveat: attached evidence is attested, not omniscient. The chain proves which system claimed what, when, under which identity not that every claim is true. That’s how every audit regime works. What changes is that the claim becomes tamper-evident and durably bound to the generation it describes.
Beyond the regulation
It’s tempting to frame all of this around the AI Act. But even without regulation, the same questions keep arriving — from customers, partners, procurement teams and internal auditors.
What happened?
Who approved it?
Which policy applied?
Can you prove it?
Those aren’t legal questions. They’re operational questions. Article 50 just makes them harder to ignore.
A Monday-morning test: pick one AI-generated output that shipped last quarter and reconstruct its full story — model, policy, disclosure, review, publication — with evidence, not recollection. If you can’t, start small. Mint a stable generation ID at the point of generation. Sign the record. Propagate the ID as far downstream as it will go.
We spent decades building infrastructure to answer one question: what happened to this request?
AI introduces a different question: what happened to this piece of generated content?
I suspect the next generation of AI infrastructure will be built around answering it.
If you’re solving this differently, I’d genuinely like to hear how.

