The EU's AI transparency rules now apply. Here is what product and engineering teams need to change in interfaces, content pipelines, provenance, and operational evidence.
On 2 August 2026, a quiet but consequential boundary moved.
If a person in the European Union is interacting with an AI system, they may need to be told. If a system generates or manipulates content, its origin may need to be machine-readable. If an organisation publishes a deepfake or AI-written material on a matter of public interest, visible labelling may be required.
These are not abstract governance principles. They are behaviours the product must perform.
The timing has confused some teams because the July 2026 AI Omnibus extended the deadlines for many high-risk systems. The rules for stand-alone high-risk uses now begin in December 2027, while AI embedded in regulated products moves to August 2028. But the European Commission is explicit: the transparency obligations in Article 50 apply from 2 August 2026.
That distinction matters. A company can be outside the high-risk regime and still have transparency work to do today.
Article 50 separates obligations by role. The first useful question is therefore not “Do we use AI?” but “In this product, are we the provider, the deployer, or both?”
A provider develops an AI system and places it on the market or puts it into service under its name. Providers must design relevant systems so people are explicitly informed when they are interacting directly with AI. Providers of systems that generate or manipulate audio, images, video, or text must also support machine-readable detection of that content where the rules apply.
A deployer uses an AI system under its authority. Deployers have disclosure duties when people are exposed to emotion recognition or biometric categorisation, deepfakes, or certain AI-generated text about matters of public interest that has not received human review or editorial control.
One organisation may occupy both roles. A media company that builds its own writing system and publishes its output is an obvious example. A business using a third-party model inside a customer-facing assistant may be a deployer of the model while also acting as the provider of the finished application. The answer depends on the facts, contracts, branding, and degree of control—not on the API call alone.
This is where legal interpretation has to meet system design. Counsel can establish the obligation. Product and engineering must decide where, when, and how the system fulfils it.
The weakest implementation is a line in the terms of service saying that AI may be used somewhere in the product.
A useful disclosure appears at the point where it changes the user’s understanding. If the interface is conversational, the disclosure belongs at or before the start of the interaction. If content has been generated or materially manipulated, visible labelling and machine-readable provenance solve different problems: one informs the person looking at it; the other allows systems downstream to inspect its origin.
That creates several design questions:
The C2PA 2.4 specification, released in April 2026, added an AI disclosure assertion and expanded the technical vocabulary available for content credentials. C2PA is not a universal answer and using it is not, by itself, proof of legal compliance. It is useful because it treats provenance as structured data attached to an asset rather than a sentence pasted beside it.
That is the right engineering instinct: make transparency part of the content pipeline, not a manual task performed just before publication.
Start with an inventory of experiences, not models. A single foundation model might sit behind a support chat, an internal drafting tool, a public report generator, and an image workflow. Each surface has a different audience, purpose, and disclosure requirement.
For each experience, record:
Then build the controls into four layers.
Define the exact event that triggers a notice. Make the copy specific: “You are chatting with an AI assistant” is better than “This experience may use advanced technology.” Test the disclosure across web, mobile, voice, embedded widgets, and accessibility modes.
Mark generated assets as close to creation as possible. Store the generation event, model or system version, timestamp, responsible organisation, and transformation history. Decide what must survive when content leaves your platform.
“Human reviewed” cannot be an undefined escape hatch. Specify who reviews, what they check, what authority they have to change or reject the output, and what evidence the system retains. Clicking “approve” without examining the substance is an interface event, not editorial control.
Keep versioned records of the policy, disclosure copy, system behaviour, exceptions, and tests. If the implementation changes, the evidence should show when and why. Compliance that exists only in the current interface is difficult to defend after the interface has changed three times.
The July AI Omnibus gave organisations more time for high-risk requirements and simplified parts of the regulatory framework. It did not suspend the transparency rules.
There is a limited grace period until December 2026 for the machine-readable marking obligation on certain generative AI systems placed on the market before 2 August 2026. The Commission’s quick facts also note that deepfakes created before the application date do not require retroactive labelling, although labelling is encouraged. These are narrow transitional points, not permission to postpone the entire programme.
The same Commission guidance lists potential fines of up to €15 million or 3% of worldwide annual turnover, with proportional treatment for smaller organisations. The more immediate risk for many companies, however, is operational: discovering during procurement, launch review, or a customer audit that no one owns the disclosure and provenance layer.
A competent review can begin in a week. It does not require a six-month governance programme.
Bring product, engineering, design, legal, security, and the content owner into one working session. Map the live experiences. Assign the provider/deployer analysis. Inspect the actual interfaces and exported assets. Choose one evidence owner per control. Open tickets with acceptance criteria that can be tested.
The output should not be a slide titled “AI Act readiness.” It should be a small set of product changes, technical controls, operating decisions, and named owners.
The central lesson of Article 50 is simple: transparency is no longer copy added after the system is built. It is part of how the system identifies itself, how its outputs travel, and how the organisation proves what happened.
That makes it a product requirement.
This article is a product and engineering perspective, not legal advice. If you need to translate regulatory requirements into a working AI system, talk to our team.