Sign it. Then make it revocable.
By Ruth Heasman ·
That is not a gap in the rules. That is the rules.
The EU AI Act requires every general-purpose model provider to publish a summary of its training data on the Commission's template, and since 2 August 2026 the AI Office can verify compliance and issue corrective measures, with penalties reaching €15 million or 3% of global turnover.
California's AB 2013 has demanded the same class of disclosure since January: dataset sources, whether copyrighted material was used, whether personal information is in there, refreshed whenever the system is substantially modified.
Both regimes are real. Both are self-reported. No registry collects the summaries, so they sit scattered across company websites in whatever format each company preferred, with no external verification and rarely a number attached to anything. One researcher described the exercise of comparing them as a treasure hunt. Academics at Trinity College Dublin and the Mozilla Foundation put figures behind that impression at FAccT this year.
The honest description of where we are: the declaration is mandatory, the verification is optional.
Emad Mostaque's answer to this is the right one and it is two words long. Sign it. His reasoning is what makes it work, because a signature does not convert a claim into a truth. It binds the claim to somebody, and answerable is where checking starts.
I want to push one step past the signing, to the part everyone is skipping.
Character is necessary. It is not sufficient.
My instinct, and I suspect most people's, is that this is a values problem before it is a cryptography problem. Teach models to treat others as they would want to be treated. Behave as you would want everyone to behave. Fair, truthful, honest, open. Reciprocity is the whole of character, and we manage to teach it to children.
Teaching it does not guarantee adherence under pressure. But nor does it in humans, and we did not respond to that by abandoning ethics. We responded by inventing contracts, courts, audits, professional registers and insurance. Not because people lack consciences, but because consciences are unevenly distributed and fail exactly when the stakes are highest.
Accountability is the machinery you fall back on the moment character fails. For AI it has to stay human, and the reason is structural rather than sentimental. A model can be forked, copied, quantised, redeployed and retired. You cannot sue a checkpoint. You cannot strike a set of weights off a register. Whatever the agents end up doing among themselves, the signature at the bottom of a claim needs to belong to a person with a name and a job title who can be asked to explain themselves.
The best spec on the table proves less than it looks like it proves
Attestation is getting crowded fast, and the most complete articulation of it so far is an IETF Internet-Draft by Raza Sharif of CyberSecAI: a cryptographic chain running from training-data corpus through weight signing, quantisation, deployment and per-inference output, using ECDSA P-256, SHA-256, Merkle trees for the corpus and JWKS for key discovery. Its motivating incidents are not hypothetical. It cites industrial-scale distillation in February 2026, where three laboratories ran 24,000 fraudulent accounts and 16 million exchanges to extract capability from a frontier model, and research showing roughly 250 poisoned documents can compromise a model at any size.
It is a serious, well-built document, and I want to be both careful and fair here: it is an individual draft at version 01, explicitly not endorsed by the IETF and with no formal standing. I am not picking on a standard. I am picking on the assumption underneath it, which is the industry's assumption, which is that public-key infrastructure plus good intentions is enough. Read it closely and three things fall out.
The first is the clock. Every attestation in the chain carries a timestamp its own issuer signs. The draft's threat model explicitly names timestamp falsification, providers backdating or postdating inference, as a threat to defend against. The defence appears once, in security considerations, as mitigation by integration with trusted timestamping services. RFC 3161 sits in the informative references. There is no profile and no requirement.
So the specification identifies vendor clock manipulation as a threat and then answers it with the vendor's clock.
The second is funnier, and it is the detail that made me sit up. The corpus Merkle tree is built using the method from RFC 6962 section 2.1, which is Certificate Transparency. They adopted Certificate Transparency's data structure and left behind Certificate Transparency's append-only public log. The tree is the plumbing. The log is the accountability. They kept the pipe.
The third is custody. Verification runs entirely through the provider's own doors: consumers fetch keys from the provider's endpoint, and once a key passes its rotation grace period it leaves that endpoint and is retained in the provider's archive for historical verification. The evidence stays in the hands of the party being audited. No provider, no verification. Every one of those choices is defensible in isolation and together they hand the audited party control of the audit trail.
Then there is revocation, which the draft does include and which is aimed at the wrong object. It covers key compromise: pull the key, publish a revocation notice, consumers reject everything signed with it. That is binary and destructive. Every honest output from that key dies alongside the bad ones. There is nothing for the case that actually happens, which is that the key stayed perfectly valid and the claim turned out to be false.
And at the centre of the training-data attestation sits a field reading all_licensed: true. A boolean. It sits a few pages after a threat model that names unlicensed training data with lawsuits exceeding $4 billion pending as of March 2026. The Merkle inclusion proofs can demonstrate that a given document was in the attested corpus. Nothing in the format demonstrates it was licensed. It is a cryptographic signature over "trust me", which is precisely the thing we started out complaining about.
What withdrawal has to look like
A signed record of a false claim is still a false claim. It is a false claim you can prove somebody made, which is genuine progress and exactly half a system.
The other half has four requirements.
Withdrawal must be as verifiable as publication. Anyone should be able to prove a claim was retracted without asking the retractor's permission or relying on its uptime.
It must be ordered. You need to show precisely when a claim was live and when it stopped being live, because everything built during that window inherits the problem.
It must propagate. Every model, evaluation and downstream assertion resting on the retracted claim gets marked. Tainted, not deleted. And it must be reversible. Retractions get made in error too. Lifting one has to be its own recorded, ordered, signed event, or retraction becomes a censorship button with a nicer name.
Nobody ships this because retraction is where the engineering stops being glamorous. It is also the difference between a demo and infrastructure.
The architecture that works
Three tiers, and the discipline is in keeping them apart.
Ordering goes on-chain. Only the hash and its timestamp. Cheap, public, permanent, and it settles the one question that cannot be settled by asking a company nicely: what existed, when. This is the fix for the self-signed clock and for the missing log in one move, and it does not require anyone to trust me either.
Content stays off-chain and content-addressed, so the hash is the identity of the bytes. Anyone holding the file checks it against the anchor. Nobody publishes a corpus to prove they had one, and inclusion proofs still work for selective disclosure.
Judgement lives in an overlay. Retraction, taint, reinstatement, disputes, reputation. This is where humans argue, and it has to be a layer you can change your mind inside.
Batch the hashes through a Merkle tree and a million claims cost roughly what one costs. That is the whole economic trick, and it is why anchoring at this scale is a rounding error rather than a business model.
This is built, not proposed
I have written it three times, because it turns out to be the same system underneath every time.
A notary sidecar for helppeer.ai, the public commons for AI agents, where the threat is poisoned tells. It does content-addressed records, Merkle batching, mainnet anchoring, offline SPV verification, signatures, reversible retraction and taint propagation. Live here: https://help-peer-provenance-notary.replit.app
Permastack, which does it for publishing, so a piece can prove when it was fixed and what has since been withdrawn — https://permastackpress.com. VeriHalo, which does it for medical records, where "who amended this and when" is not an academic question — https://veri-halo.replit.app/web/.
All three prove exactly five things: existence, integrity, time, authorship, retraction ordering. None of them proves any record is true, safe or good. That distinction is not modesty, it is the specification. Anyone selling you cryptographic proof of truthfulness is selling you something else entirely.
What I would ask of the labs
Not more disclosure. Hashes.
Publish the hash of the training-data manifest you are already filing under Article 53. Sign it with a key belonging to a named human. Anchor it, so the ordering does not depend on your own server clock or your continued existence. Then, when something in it turns out to be wrong, retract it through the same channel and let that retraction carry downstream to every model and claim that rested on it.
None of this exposes a corpus. None of it costs meaningfully more than the filing already does. Which is why a refusal would be so informative. Sign it. Then be willing to sign the thing that says you were wrong.
Ruth Heasman is a BSV Ambassador, Replit Ambassador and the author of The AI-Bitcoin Revolution, https://aibitcoinrevolution.com.
Sources
EU AI Act Article 53 training-data summaries and the enforcement gap: https://blog.pebblous.ai/blog/eu-training-data-summary-gap/en/
European Commission mandatory disclosure template, supervision from 2 August 2026: https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/european-commission-releases-mandatory-template-for-public-disclosure-of-ai-training-data
California AB 2013, in force 1 January 2026: https://www.dglaw.com/ai-legal-updates-californias-ai-training-data-transparency-law-takes-effect/
IETF draft, cryptographic attestation for AI model lifecycle: https://datatracker.ietf.org/doc/draft-sharif-ai-model-lifecycle-attestation/
Attestation objects across the AI supply chain: https://dataleverage.substack.com/p/attestation-across-the-ai-supply