On a published page they look identical. A line saying content was produced with AI assistance, and a record showing what was produced, by whom, and when. Same sentence, same placement, same font. The difference only appears when somebody has a reason to question it, and by then it is too late to create the second one.
Two things that look the same
A label is a statement. You are describing your own content, in your own words, on a surface you control. Under Article 50 of the EU AI Act that statement is exactly what is asked for, and getting it right matters.
A record is different in kind, not degree. It is an artefact created at a specific moment, bound to a specific file, held in a way that neither you nor the person reading it can quietly revise. It does not describe what you did. It shows it.
Every compliance conversation that goes badly goes badly at the point where somebody assumed the first thing was the second thing.
What a self-declaration is worth
It is worth something, and dismissing it is a mistake in the opposite direction. A clear, accurate, consistently applied disclosure is what the rule asks for. It signals a functioning process. It is what a reasonable client wants to see first. If you have not done it, do it before you worry about anything else on this page.
What it is not is evidence of itself. A self-declaration is a claim, and a claim supports itself only for as long as nobody has an interest in testing it. That is usually a long time, which is precisely why the gap goes unnoticed until the day it matters.
The three questions a label cannot answer
Put any disclosure statement next to these and the shape of the gap becomes obvious.
What was made? Not what is on the page today. The exact artefact that went out. Pages get edited. A statement written today about a version that has since been revised twice describes something that no longer exists in that form.
By whom, and by what? Which parts were generated, which were edited by a model, which were written by a person. A single line at the bottom of a page compresses all of that into one word, and the word is chosen by the party who benefits from choosing it.
When was that true? This is the one that quietly destroys most internal answers. A statement made in August about work done in March is a memory. The date on it is the date you wrote the statement, not the date of the thing it describes.
Where teams think their evidence lives
Ask a marketing or content team to substantiate a declaration and four things come out, in roughly this order. Each is useful. None of them holds when it is being contested rather than consulted.
File modified dates. The most common answer and the weakest. A modification date is metadata inside a system you administer. It changes when a file is copied, synced, exported or opened by the wrong application, and it can be set deliberately. It is a working note about your own files, not a statement anybody else has reason to accept.
Email threads. Better, because a second party is involved and holds a copy. Still weak for this purpose. An email shows that something was discussed on a date. It rarely attaches to the specific file version, headers can be constructed, and a thread that reads as conclusive to the people who lived it usually reads as ambiguous to somebody who did not.
Project management history. Ticket transitions, comments, attachments, an audit log. This feels strong because it is detailed and timestamped. The problem is administrative: workspace administrators can edit or delete entries, retention policies quietly prune old items, and the whole store belongs to the party making the claim. Detail is not the same as independence.
Cloud version history. The strongest of the four and still inside the same trap. Version history shows a sequence of states in a document. It is held by a provider you contract with, under terms you can change, in an account you control, and it typically expires. It answers what changed. It does not independently answer when, to a person who has decided not to take your word for it.
The common thread is not that these systems are unreliable. It is that all four are held by the party whose claim is in question. That is a structural problem, and no amount of extra internal logging fixes it.
What changes when the record is sealed
Sealing moves one specific thing outside your control: the date.
A cryptographic hash is computed from the file itself, so the record is bound to one exact version rather than to a document that keeps moving. The declaration of how the work was produced is attached to that hash. A Qualified Trust Service Provider then issues a qualified electronic timestamp over both.
Under eIDAS, Regulation (EU) No 910/2014, a qualified electronic timestamp carries a legal presumption as to the date and time it indicates and the integrity of the data it is bound to. In Switzerland, ZertES governs certification services for electronic signatures, while handwritten equivalence comes from Art. 14 para. 2bis of the Swiss Code of Obligations. Those are two separate instruments and it is worth citing them as two.
What that buys you in practice is narrow and valuable. It does not make your declaration true. It makes the date of your declaration something you cannot have changed afterwards, which is the single property every one of the four internal records above is missing. A hash on a public ledger gets you a related but weaker result, for reasons worth reading in full on the comparison with blockchain timestamping.
A worked example
An agency delivers a campaign in February. Landing page, six ads, a launch video. Some of the copy was drafted with a model, all of it was edited by a person, one illustration was generated. The delivery includes a disclosure line, which is more than most agencies did that month.
In August the client is acquired. The acquirer's legal team runs a content audit and sends one question: for each asset, what was AI-generated, what was AI-assisted, and what evidence supports the answer. The deadline is two weeks and the tone is procedural rather than hostile.
The agency now has to reconstruct February. The designer who generated the illustration has left. The document has been edited eleven times since delivery, most recently by the client. The project management workspace was migrated in May and comments older than ninety days were not carried over. What remains is an email thread saying the campaign is ready for review, and a disclosure line whose date is unknown.
Nothing here involves bad faith. Everyone did their job. The agency simply cannot answer a question it had no reason to prepare for, and the acquirer is not being unreasonable in asking. The cost is a fortnight of senior time, a strained relationship, and an answer that ends in "to the best of our recollection".
The version of this where the agency sealed each deliverable at handover takes about ten minutes. They forward four certificates. The acquirer verifies them without contacting anybody. The conversation ends.
The practical point
Label your content. That is the obligation and it is not optional. Then ask a separate question, which the rule does not ask but your clients eventually will: if somebody who has no reason to trust us asks us to back this up in six months, what do we hand them?
If the answer is a folder of screenshots and a memory, the gap is worth closing while it is still cheap. Our Article 50 page sets out what the obligation covers and where a sealed declaration fits.
