AI transparency does not belong in the footer

When a product uses artificial intelligence, the usual response to a transparency requirement is to add a notice. A sentence says that AI may be involved, an icon appears beside the content and a legal page explains the rest.

That approach treats transparency as copy. The problem is that transparency is product behavior.

It has to appear when it can change a user's decision, travel with content beyond the interface where it was created and show who is accountable for what gets published. Unless those properties are part of the architecture, a notice merely describes an intention the system cannot reliably maintain.

New European guidance makes that distinction concrete. On July 20, 2026, the European Commission published guidelines for the AI Act's Article 50 transparency obligations, which apply from August 2. They address direct interactions with AI, machine-readable marking, deepfakes, emotion recognition, biometric categorization and certain text on matters of public interest.

The significance is larger than a new compliance list. The guidance exposes a durable product principle: information about AI's role must survive the entire path from generation and interaction to review and distribution.

A visible notice is only the surface

There are at least two distinct forms of transparency in an AI product.

The first guides an interaction. People need to understand who — or what — they are communicating with before deciding how much context to share, how much confidence to place in an answer or whether to ask for a human.

The second follows an output. Text, images, audio and video can be copied, exported, edited and republished far from the interface that created them. At that point, the information once visible on screen is no longer enough.

The European guidance reflects this separation. In direct interactions, notice should be given from the start of the first exchange in a clear, distinguishable and accessible way. For synthetic content covered by the rule, providers have machine-readable marking obligations. The Commission's official Article 50 FAQ, updated on July 24, also makes clear that a technical mark does not replace perceptible disclosure in every situation where people encounter the content.

One badge cannot solve both problems. Interface disclosure and provenance are different layers and should be designed accordingly.

Timing determines whether information is useful

Transparency delivered too late becomes documentation for a decision that has already been made.

A notice buried in terms of service may be legally close to the product while remaining functionally distant from the user. It does not help someone calibrate trust during a conversation, interpret a recommendation or recognize that a virtual person is not human.

The right moment depends on the risk the information changes. In a conversation, it may be before the first message. For an automated suggestion, it should sit near the recommendation. For synthetic content, it must accompany the first exposure. When a session transfers to a human, the change in responsibility should be explicit.

These are interface decisions, not just writing decisions. Teams have to define visual hierarchy, accessibility, persistence and behavior across channels. A notice that works in a web application can vanish in an email, exported file, notification or third-party integration.

The useful question is no longer “do we have a disclaimer?” It is “which decisions require the user to know that AI is participating?”

Providers and deployers see different parts of the system

AI products are rarely built by one organization. One company develops the model. Another provides infrastructure. A product team integrates the system. A business unit defines its use. An external channel distributes the result.

The European rules distinguish between obligations for providers and for those using a system under their authority. That legal split does not automatically match a product's org chart. A company can be a model customer at one layer and the provider of an AI experience at another.

The first operational task, then, is not writing a notice. It is mapping the chain of responsibility:

1. who controls the experience shown to the user;
2. who can add and preserve technical marks;
3. who determines the context in which an output will be used;
4. who reviews or approves content before publication;
5. who retains evidence that each control worked.

Without that map, every party assumes transparency belongs to someone else. The model vendor points to the integrator. The integrator points to the channel. The channel receives content without context and publishes what arrived.

Transparency fails at organizational interfaces before it fails in the visual interface.

Provenance should be a data contract

A machine-readable mark is not a minor metadata detail. It creates a requirement for the whole pipeline.

The product needs to know where origin information is created, how it is represented, which transformations preserve it and where it may be lost. Compression, format conversion, cropping, screenshots and republication create different technical boundaries. Not every limitation can be eliminated, but each one should be understood.

This makes provenance similar to other data contracts. An important field cannot exist only at ingestion and then disappear without observability. Teams need to validate it at system boundaries, record relevant transformations and define what happens when marking cannot be retained.

A resilient strategy combines layers. A technical mark helps systems detect origin. A perceptible label helps people interpret content. An operational record helps the organization explain how an output was generated and distributed.

No layer is perfect on its own. Together, they reduce dependence on one fragile signal.

Human review is not an approval click

One of the most useful parts of the new guidance concerns text on matters of public interest. The FAQ distinguishes substantive human review from purely formal checks. Spelling or grammar correction, for example, does not amount to editorial control over the substance.

That distinction matters far beyond the rule's specific scope. Many workflows include a step called “human review” without defining what the reviewer must assess, what authority they have or which decision they own.

Putting a person in the flow does not automatically introduce judgment. Sometimes it adds only latency and a misleading audit trail.

Meaningful review needs at least four things:

• enough context to evaluate the claim;
• explicit quality and risk criteria;
• authority to change or reject the output;
• identifiable accountability for the final decision.

If a person merely confirms that a field is not empty, the automation remains in control. If they can challenge sources, change the argument and stop publication, editorial control exists.

Transparency belongs in the delivery cycle

No single component can solve this problem. The work crosses product, engineering, content, security, legal and operations.

A practical approach starts with an inventory of experiences where AI interacts with people or produces material for distribution. Each flow should then record its role in the chain, disclosure moment, provenance method, applicable exceptions and owner of the final decision.

Those definitions need to become tests. Does the notice appear before the first interaction? Is it accessible? Is it still visible in the mobile app? Does export retain the expected signals? Does an integration strip metadata? Can human review stop publication? Can the log reconstruct which version and flow produced an output?

The objective is not to turn every release into a legal exercise. It is to keep an essential obligation from depending on someone's memory at the end of a project.

When transparency is part of acceptance criteria, it evolves with the product. When it lives only in a policy, it starts aging the day after publication.

The principle travels beyond Europe

The AI Act defines specific obligations, roles and exceptions that must be assessed in their proper context. A product essay is not a substitute for that analysis.

The engineering consequence, however, is broader. AI products create new information asymmetries: the system knows how an output was produced; the user often does not. The more natural the interaction and the more persuasive the content, the easier it is for that difference to go unnoticed.

Reducing the asymmetry improves more than compliance. It helps users choose when to trust, when to verify and when to request human intervention. It helps teams locate accountability. It helps operations investigate failures without reconstructing the process through guesswork.

In that sense, transparency is not an admission that the technology is imperfect. It is part of product quality.

A footer can explain a policy. Only architecture can keep that policy true while the system is running.