The disclosure rule, and what it means for code

Enforcement of the EU AI Act began on 2 August 2026. Among the obligations that arrived is a transparency requirement: AI systems have to disclose themselves to the people interacting with them, and generated content has to be marked.

Every engineering leader I have spoken to since has asked a version of the same question, and it is the right question. Does that mean my code?

The honest answer is: almost certainly not in the direct way people fear, and it does not matter, because you are going to be asked anyway. My position is that the disclosure question for source code will be settled in commercial contracts long before it is settled by any regulator, and the organisations that get caught out will be the ones who waited for a rule that named them.

What the obligation actually says, and where code sits

Be precise here, because the vagueness is where bad decisions get made.

The transparency obligations are about two things. First, an AI system that interacts with a person should make it apparent that it is an AI system. Second, generated content should be marked as generated. The concern is a person being deceived about what they are dealing with.

Your internal repository does not obviously fit either limb. Nobody is being deceived about whether the payments module is a chatbot. If your product embeds an AI system that users interact with, the obligation lands on that system, not on how the surrounding code was written.

So the narrow reading is defensible: writing code with an agent is not, on its face, a transparency-obligated act.

I am not a lawyer and this is not legal advice, and I would say that even if I were, because the general reading is not the thing that will affect your quarter.

Where the disclosure obligation clearly bites

• A system a person converses with, which must say what it is
• Generated media presented to people, which must be marked
• Deceptive presentation of synthetic output as human

Where the question reaches your source tree

• A customer's supplier questionnaire
• Your own auditor asking what changed and on whose instruction
• A contractual warranty about IP provenance
• An incident where the answer to "who wrote this" matters

The gap that everybody in this field has noticed

Here is the part of the landscape worth staring at.

For generated images, native provenance attribution exists. There are established ways of carrying, in the artefact itself, a record of how it was produced, and an ecosystem that reads them.

For generated code, there is no documented equivalent. No standard field, no accepted convention, no tooling everyone agrees on. The industry that is most fluent in metadata, version control and structured records has no agreed way to say “this function was machine-authored, on this instruction, checked against this criterion.”

That gap is not going to persist. Where a marking norm exists for one class of generated artefact and the underlying policy concern is the same, the norm travels. It usually travels through the commercial channel first: a large customer adds a clause, then a second one copies the clause, then it appears in a standard questionnaire, and within two years it is simply what everybody asks.

The record you need is the one you already generate

The useful thing is that answering the disclosure question does not require a standard to exist yet.

Every machine-authored change in your organisation passes through a moment where all the relevant facts are simultaneously available: the change itself, the instruction that produced it, the criterion it was meant to satisfy, whether anything checked it, and which human accepted it. That moment is the merge.

If that record is captured then, you can answer any future phrasing of the question. If it is not captured then, you are reconstructing from git blame and chat history six months later, which produces an answer you would not want to sign.

Which changeThe commit or merge, immutably identified. You already have this.

Under what instructionThe ticket, criterion or prompt the work was produced against. Usually recoverable at merge time and almost never afterwards.

Authored by whatHuman, agent, or agent-drafted-and-edited. The distinction that no current convention expresses.

Checked against whatWhich criteria were evaluated, by what, and with what result.

Accepted by whomThe human who took responsibility, distinct from whoever clicked approve.

Note what this is not. It is not a compliance product, and no tool makes an organisation compliant with the AI Act or anything else. Compliance is a legal determination about your organisation, made by people qualified to make it. What a record does is let you answer questions truthfully and quickly. That is all it does, and it is worth a great deal.

Article 12 already points in this direction for high-risk systems: automatic logging of events relevant to risk and traceability, tamper-evident, retained six months, and twenty-four for biometric and law-enforcement uses. The instinct behind it, that the record has to be generated by the system rather than assembled by a person afterwards, is the same instinct you want for authorship.

Where this breaks down

Marking code may be a category error, and the strongest version of that objection is good. An image is a fixed artefact with a single moment of creation. A function is edited by four people over two years, refactored by a tool, and moved between files. What does an authorship marker even mean after the third rewrite? A per-change record survives this fine, but a per-line marking scheme is genuinely incoherent, and much of the “provenance for code” conversation is arguing for the incoherent version.

“It will arrive through contracts” is a prediction, not a fact. I believe it based on how questionnaire clauses have propagated in adjacent areas, and I could be wrong about the timing or about it happening at all. If it does not, the work I am recommending is still useful for incident response and audit, but the urgency I am attaching to it would be overstated.

Recording authorship creates a new problem you did not have. A field marking code as machine-authored is a field that can be used against you: in litigation, in an IP dispute, or by a customer who decides retrospectively that they did not want it. Some legal teams will read this article and conclude the safest record is no record. That is a coherent position, I disagree with it, and anyone advocating disclosure should be honest that it is not free.

Declare the interest. We sell tooling that produces exactly this kind of merge-time record, so an article concluding that you need one is self-serving. Discount it. The specific point that costs us nothing to make: most of what I have described can be built from your existing repository, tracker and CI without buying anything, and if you have the platform capacity, do that.

The narrow reading might just hold. Regulators have finite attention and code provenance is not obviously where public harm concentrates. It is entirely possible that nothing lands on source code for years and the organisations that invested early simply spent money early. I think the record pays for itself in incident response regardless, but that is a weaker argument than the regulatory one and I would rather say so than lean on urgency I cannot support.

The takeaway

The disclosure obligation that started applying in August is not, on any reasonable reading, a rule about your source tree. That is a bad reason to relax. The provenance question for code has a conspicuous hole where a standard should be, the equivalent norm already exists for other generated artefacts, and the commercial channel moves faster than the regulatory one.

You do not need to guess the eventual format. You need to be able to answer, for any change, what produced it, on what instruction, checked against what, and who accepted it.

If you take one thing into next week: pick a change merged six months ago and try to answer those four questions from your existing systems, with a timer running. Whatever you cannot answer is the thing to start capturing at merge time.