How to prove your AI disclosure was live on a specific date
Getting the disclosure right is the easy half. The hard half arrives later, when someone asks what your site showed on a date that has already passed — and every answer you have is one you wrote yourself.
This is not a hypothetical framing. Article 50 duties are checked from outside: an authority, or a competitor drafting a complaint, opens your site and reads what it says today. But the question that follows is almost always historical — was it there in October, when the complaint says it wasn't? — and the burden of showing that runs toward you. Regulators work from documented evidence. This page is about what actually carries weight, ranked, and what each method genuinely proves.
Why "we've always had it" is not an answer#
Four properties separate a claim from evidence. Most compliance records have one or two.
- Independence
- Was the record made by someone other than the party it benefits?
- Time-binding
- Is the date fixed by something other than a field you could edit?
- Tamper-evidence
- Would a later change be detectable?
- Content fidelity
- Does it capture what a visitor saw, including the parts that only exist after JavaScript runs and a widget is opened?
That last one is the quiet killer for chatbot disclosure, and it eliminates most of the obvious answers before the other three get a turn.
The methods, ranked#
1. Screenshots in a shared drive#
The default, and the weakest. A PNG has no independent time — file metadata is editable, and the folder's "modified" date reflects the drive, not the capture. It was made by you, about you. And in practice the set is incomplete: someone screenshots the desktop view, not the mobile one, and not the state after the widget opened.
Not worthless: a screenshot is much better than nothing, and it captures content fidelity (a widget actually opened) that crawlers miss. It just carries no weight on the other three properties.
2. Configuration exports and vendor dashboards#
"Here is the greeting text in our Intercom settings." This proves what the setting says now. It does not show the setting was live then, or that it rendered. Nor does it show that a CSS change did not hide it, or that the mobile view matched. Vendors keep audit logs of setting changes at some plan tiers, which helps — but it is the vendor's record of your configuration, not a record of your page.
The gap is bigger than it sounds. The most common finding in any external check is a disclosure that exists in configuration and does not reach the visitor.
3. Your own server logs and deployment history#
Strong on time-binding, weak on independence and content fidelity. A git commit shows when a template changed; it does not show what the rendered page looked like to a visitor in Berlin on a phone, and it says nothing at all about a third-party widget whose content never passes through your repository.
4. Third-party web archives#
The Internet Archive's Wayback Machine is genuinely independent and genuinely time-bound, and if your page happens to be captured on a useful date it is excellent evidence. Three limits:
- Coverage is not on demand. Most sites are crawled irregularly. You cannot count on a capture existing for the month you need.
- An archive captures the document. The interaction happens after a click, and it captures none of it. A crawler fetches HTML. The Article 50(1) disclosure arrives a click later, in the first message the chat panel prints. An archived page can show a page with a chat widget on it and tell you nothing about what the widget said.
- No mobile pair. You get one rendering, where the duty needs desktop and mobile compared.
Worth doing anyway, and free. Just do not mistake it for coverage of the chatbot duty.
5. A notary or a solicitor's affidavit#
High independence, high cost, and a snapshot of one moment. Fine for a specific dispute already in progress; not a way to hold twelve months of evidence across a site that changes.
6. A sealed, dated capture from an external scan#
This is the category DisclosureProof is in, so read the next section as an explanation of the mechanism rather than a neutral survey — and read the limits, because they are the part most vendors leave out.
What a sealed evidence record actually proves#
Our scanner loads your site in a real browser from outside your network, opens the chat widget the way a visitor would, reads the first message before anyone types, checks the mobile layout separately, samples published media for machine-readable marking, and looks for visible labels on article-like pages. It stores the captures — screenshots, DOM, the transcript of what the widget said — as artifacts.
Those artifacts and the findings are serialised into a deterministic manifest (fixed key order, sorted arrays) and hashed with SHA-256. The hash is signed. That gives you two separable guarantees, and we keep them separate on purpose:
Integrity is independently provable. The manifest hash is a plain SHA-256 over a deterministic serialisation. Anyone — your counsel, a regulator, the other side — can run shasum -a 256 over the manifest file and compare, or use the hash-in-your-browser button on our verification page, which never contacts our server. If a single byte of the evidence changed, the hash does not match. No trust in us is required for this step.
Authenticity is not independently provable, and we say so. The seal is an HMAC under a secret key, not a public-key signature. That makes it tamper-evident, but only we can confirm a given signature is ours. A verifier who does not trust us can still prove the evidence is unaltered; they cannot, on their own, prove it came from us. That is a real limitation of the current version, it is stated on the verification page as well as here, and an asymmetric signature is the obvious upgrade.
Two more properties worth stating plainly. The capture is independent in the sense that matters — it was made by a third party, from outside, without your input into what it recorded. And signature verification is stateless, so a genuine pack still verifies after its scan ages out of our retention: a purged record must never make a real pack look forged.
What it does not prove#
- It seals the scan it came from, not your site in general
- A record dated 4 November is evidence about 4 November. It says nothing about 3 November.
- It is not a compliance verdict
- Findings are recorded as detected, not detected, or could not verify. We never say "compliant", and no scan can, because Article 50 turns on facts a crawler cannot see — the 50(4) editorial-responsibility carve-out being the clearest example.
- A hash is not a seal
- The hash proves the bytes are unchanged. The signature is the separate claim about origin. Conflating the two is the most common way this gets oversold.
- Retention is finite
- A purchased Evidence Pack is retained for 365 days from purchase, not indefinitely. Download and keep your own copy.
What to do, whatever tooling you use#
The methods above are complementary, and the practical answer for most teams is a stack:
- Establish a cadence
- Evidence of a single day is weak; a series showing the disclosure present across months is what answers "when did you fix it?" A quarterly rhythm is the realistic floor, monthly is better, and around a widget migration or a redesign you want one on each side of the change.
- Capture both viewports every time
- Desktop-only records miss the most common regression.
- Capture the interaction as well as the page
- The disclosure lives after a click.
- Record the negative findings too
- A record that shows a gap on 4 November and the same check clean on 20 November is a remediation timeline — considerably better than no record of either. This is also why "only keep the clean ones" is bad instinct.
- Keep the artifacts where you will still have them
- Off the vendor's platform, in your own storage, with the hash written down.
Every scan produces a sealed, dated record, including the free homepage scan. Anyone can verify one without an account. If the cadence is the part you won't keep up manually, that is what scheduled re-scans and drift alerts are for.
Common questions
Are screenshots enough to prove a disclosure was live?
They are much better than nothing and they capture something crawlers miss — that a widget actually opened — but they are weak evidence on their own. A PNG has no independent time, since file metadata is editable and folder dates reflect the drive rather than the capture, and the record was made by the party it benefits. Use them, but do not rely on them alone.
Does the Wayback Machine prove what my chatbot said?
Almost never. Web archives are genuinely independent and time-bound, and worth using. But a crawler fetches HTML — it does not click your chat launcher, wait for the panel and read the first message, which is exactly where the Article 50(1) disclosure lives. An archived page can show that a chat widget existed and tell you nothing about what it said. Coverage is also irregular, so you cannot count on a capture for the month you need.
What can a sealed evidence pack actually prove?
Two separable things. Integrity is independently provable: the manifest hash is a plain SHA-256 over a deterministic serialisation, so anyone can recompute it and see whether a byte changed, with no trust in us required. Authenticity is not independently provable in the current version: the seal is an HMAC under a secret key rather than a public-key signature, so only we can confirm a signature is ours. We state that limitation rather than implying more.
Does a scan prove my site was compliant?
No, and we never claim it. A record dated 4 November is evidence about 4 November and says nothing about 3 November. Findings are recorded as detected, not detected, or could not verify — never as a compliance verdict, because Article 50 turns on facts no crawler can see, such as whether a human held editorial responsibility for an article under the 50(4) carve-out.
How long should we keep disclosure evidence?
Longer than any single scan product retains it, which is why keeping your own copy matters. A purchased Evidence Pack is retained for 365 days from purchase, not indefinitely. Download the artifacts, store them off the vendor's platform, and write down the manifest hash — signature verification is stateless, so a genuine pack still verifies after its scan ages out of our retention.
Sources and further reading
Last updated September 2026. Informational only, not legal advice: this page describes what the text of the EU AI Act says and what an external check can observe, not whether any particular site complies. Corrections welcome at hello@disclosureproof.com.