Disclosure Is Not Documentation

In the weeks around the August transparency deadline, a lot of firms added a line to their deliverables saying that AI assisted with the work. That is a reasonable response to a transparency obligation, and for many teams it is the first visible sign that anything changed. It also creates a gap that is easy to miss, because telling someone that AI was involved and being able to show what happened are two entirely different capabilities, and only one of them survives a follow-up question.

The distinction runs through the Act itself. Transparency duties sit in Article 50 and are outward facing: they govern what you tell the person receiving the output. Record-keeping sits in Article 12 and is inward facing: it governs whether events can be reconstructed afterward. The first is a statement, the second is evidence, and a firm can be scrupulous about the first while having nothing at all behind it.

The follow-up question is where it breaks

Disclosure invites exactly one predictable response, and it is not gratitude. A client who reads that AI assisted with their analysis will eventually ask what that means: which parts, what it was working from, whether anyone checked the numbers, and who that person was. These are not hostile questions. They are the obvious ones, and a disclosure line is what prompts them.

At that point the firm either has answers or it has a recollection. Recollection works fine for a week and poorly for a year, particularly when the person who did the work has moved on and the reasoning lived in a chat window nobody kept. The uncomfortable part is that disclosing without a record can leave you worse off than staying quiet, because you have made a written claim about your process to a client and cannot substantiate it.

What a usable record actually contains

A record that answers real questions has four elements, and most improvised setups have one or two. It shows the evidence the output was grounded in, meaning which documents and which passages rather than a general assertion that files were consulted. It shows what the analysis produced, including where confidence was weaker. It shows what a human did with that, not merely that someone opened it. And it shows who took responsibility, by name, at a point in time.

The reason all four matter together is that any one of them alone is easy to produce and easy to dismiss. A list of source files proves nothing about whether they were used well. A sign-off with no visible object proves only that a button was pressed. What makes a record credible is that the pieces connect: this evidence produced this answer, which this named person reviewed and approved on this date, and each link is checkable rather than asserted.

Why after the fact is too late

Documentation assembled retrospectively has a recognizable quality, and everyone who has read a reconstructed file knows it. The dates are round, the reasoning is tidier than any real process, and the gaps have been smoothed over by people reasonably confident about what must have happened. It is not dishonest so much as unfalsifiable, and unfalsifiable records carry very little weight precisely when weight is needed.

A record that is generated as the work happens has the opposite character. It contains the awkward parts: the answer that was sent back for revision, the source that turned out to be stale, the claim two models disagreed about. Those imperfections are what make the rest believable, which is the argument for building the trail into the workflow rather than around it. The audit trail that convinces is the one nobody had to write.

Adding the second half

If your firm added a disclosure line in August, the sensible follow-on is not more wording. It is picking the workflow that line appears on most often and making sure that for any given deliverable, someone could reconstruct within a few minutes what the analysis was based on and who approved it. If that is currently a research project, the disclosure is running ahead of the substance and the gap will close under pressure rather than at leisure.

Qonera is the AI governance platform for professional teams, built around a structured review and approval workflow in which the record is a by-product rather than a task: sources are audited before analysis, claims carry citations back to the passage supporting them, reviewers approve or send back by name, and the whole sequence is written to a tamper evident audit trail that exports for client assurance or internal review. The article-by-article mapping is published on the EU AI Act page. Disclosure tells a client that AI was involved, and it is the documentation underneath that determines whether that sentence reassures them or starts a conversation you cannot finish.

This article is for general information only and does not provide legal advice. Organisations should consult qualified legal counsel about how Article 12 and the EU AI Act apply to their specific systems, workflows, and obligations.