Somebody asks for proof. A client running a supplier questionnaire, a platform reviewing your account after a complaint, a lawyer building a case file, or a licensing partner checking a piece before using it. The request usually shows up loosely worded, "can you show us this content is AI-compliant," and that looseness hides two separate questions inside one sentence.
Two questions hiding inside one request
The first question is whether the content was labelled correctly at the time it was published. Under Article 50 of the EU AI Act, Regulation (EU) 2024/1689, which became applicable on 2 August 2026, a deployer, meaning whoever publishes AI-generated or AI-manipulated content, has to disclose that where a person encounters it. The full breakdown of what Article 50 asks for covers who is bound and what falls in scope.
The second question is whether you can back that disclosure up after the fact. A label states what you claim happened. On its own it does not show what happened, who was involved, or when any of it took place. That is a record, and a record is a different kind of object from a label: built at a different moment, stored differently, and verified by someone other than you. It is also the part that actually gets asked for, once a request moves past "did you label this" into "prove it."
Why the label runs out on its own
A label lives on your own page, inside your own CMS, editable by your own team at any time. That is exactly right for its purpose, which is telling a reader, at the moment they meet the content, that it was generated or modified with AI. It stops being enough the moment somebody treats it as evidence, because the party being asked to trust the label is the same party who wrote it.
Procurement questionnaires, contract disputes, and platform reviews arrive in different language but land on the same underlying question: can somebody outside your organisation confirm this without taking your word for it and without needing access to your systems. A screenshot of your CMS does not answer that. Neither does an email thread explaining your process, and neither does a file's "last modified" timestamp, which changes every time the file is opened, let alone edited.
What actually needs to exist before the question is asked
An evidence pack that holds up under a second look has four parts. None of them replace the Article 50 disclosure; they sit underneath it and give it something to stand on.
The declaration itself. Which of the four states applies: AI generated, AI modified, AI assisted, or human authored. Getting this wrong is worse than leaving it vague, because the obligation is about accuracy rather than caution. Most working content ends up AI assisted, a model helped somewhere in the process and a person wrote the final version, and saying that plainly is the accurate answer, not the weaker one.
A qualified timestamp on the exact file. A timestamp built to the RFC 3161 standard, issued through a qualified trust service under ZertES or eIDAS, proves that a specific file, down to the byte, existed in that exact form at a specific moment. Change a single character afterward and the timestamp no longer matches the file. That closes the "last modified" problem: the date is bound mathematically to the content itself, not to a filesystem field that anyone with edit access can alter or that resets the moment the file is opened.
A qualified signature tying the file to a verified party. A timestamp proves a file existed at a point in time. It does not say who put it there. A qualified electronic signature carries that identity through a verification step rather than an email address anyone could have typed in, so the two together answer "what" and "who," which covers most of what a questionnaire is actually asking, even when the question is phrased as "prove this is compliant."
A content hash registered publicly, without handing over the file. An ISCC hash of the content itself goes into a public, searchable database. It does not expose the underlying file, only a fingerprint derived from it. That gives the content, not just your custody of a particular copy, something a licensing body, a platform, or a party checking whether a piece of text or image turned up somewhere it should not have can match against later, without contacting you first. This is the piece a timestamp and signature alone do not cover: traceability of the content itself, independent of who happens to be holding the original file.
What you actually send, in practice
When the request lands, the answer is one link. A verification page that anyone can open without an account, without a login, and without emailing you first, showing the sealed record, the timestamp, the signing identity, and the declaration in one place. Sealing and declaring a file takes about five minutes at the point of publication, and the step that actually matters is the last one, where somebody outside your organisation checks the record cold, with no help from you and no benefit of the doubt.
Compare that against the usual answer to a compliance request: a PDF export of a Slack conversation, a screenshot of a Google Doc's version history, or a paragraph in an email explaining that the team "always discloses AI use." Every one of those stays internal, stays editable, and depends entirely on the recipient trusting your systems and your good faith. A verification link does none of that, which is the whole reason to build the record at the point of publication rather than trying to assemble one after the request arrives.
Who actually asks, and when
It is rarely a regulator knocking first. More often it is a client's procurement team running a routine vendor check, a counterparty in a contract dispute pulling records, a platform responding to a complaint, or a licensing partner deciding whether to use a piece of content and needing to know its provenance before they do. None of those situations come with much warning, and none of them wait while you go looking for the original file or the person who wrote it eight months ago.
How much of this you actually need
Not every piece of content needs the full evidence pack behind it. A social caption that disappears from feed algorithms within a day carries little practical risk if nobody ever challenges it. The pack matters most for anything that could plausibly land in front of a client's legal team, a regulator, or a court: paid deliverables, anything published into a market with an active disclosure obligation, and anything that makes a claim somebody could dispute months later.
Building the record at the point of publication is also simply cheaper than reconstructing one afterward. Once a request has already arrived, there is no way to manufacture a timestamp for a file that already went out unsealed; the best you can do at that point is explain your process and hope it is believed. Treat sealing as part of the publishing step itself, not as a separate task that happens later if there is time, and the evidence pack question stops being urgent because it was already answered before anyone asked it.
A short version to keep
Someone asking you to prove content is compliant is really asking four smaller questions: what was published, who published it, when, and can I check that myself without contacting you. A disclosure label answers the first question, and only if the person reading it already trusts you. A qualified timestamp answers when. A qualified signature answers who. A registered content hash answers what, in a form that survives even if the original file is never shared with anyone. Send the record that answers all four. A restatement of the label is not a fifth answer, it is the same one again.
