EU AI Act transparency rules: product work starts now
The EU AI Act has acquired a familiar software-industry feature: several deadlines, a lively side market in confident summaries, and just enough delay elsewhere to persuade busy teams that the whole thing can wait.
It cannot. The European Commission's Article 50 transparency guidance confirms that the relevant obligations began applying on 2 August 2026. They cover particular AI interactions and content, including direct interaction with people, machine-readable marking of generated or manipulated outputs, deepfakes, and some AI-generated text on matters of public interest.
This is not a reason to attach a flashing "AI WAS HERE" sticker to every autocomplete suggestion. It is a reason to work out what your product does, which role your business performs, where a person encounters AI, and how the system can prove that the required disclosure or marking happened.
The deadline that did not politely disappear
Much recent discussion has focused on delayed dates for some high-risk AI rules. That is important, but it is a different part of the legislation. Article 50's transparency obligations moved ahead on 2 August.
The Commission describes duties for both providers and deployers. The distinction matters. A company building an AI system may be a provider. A business using somebody else's system inside its service may be a deployer. A single product chain can involve both, along with model vendors, content tools, agencies and customers. The organisational chart may say "we only use an API"; the product still has to produce the right user experience.
According to the Commission's Code of Practice on Transparency of AI-generated Content, providers of generative AI systems are expected to support machine-readable marking and detection of generated or manipulated audio, images, video and text, as far as technically feasible. Deployers have disclosure duties around deepfakes and certain AI-generated or manipulated text published to inform the public on matters of public interest.
There is an important qualification for that public-interest text: the disclosure duty does not apply where the material has undergone human review and a person or organisation carries editorial responsibility. That is a rather more useful standard than the fashionable workflow in which a human glances at the first paragraph, changes "utilize" to "use", and declares the machine supervised.
Transparency is a product behaviour
The tempting response is to ask legal for a sentence and design for a tooltip. Both may be needed. Neither is the system.
A functioning transparency implementation has to answer ordinary product questions:
- When must a person be told they are interacting with AI?
- Where will that information appear, and will it still be clear on a small screen?
- What happens when an AI feature is embedded in a support flow, onboarding journey or third-party widget?
- Which outputs require machine-readable provenance, and does the chosen file pipeline preserve it?
- Who reviews public-interest text, what counts as meaningful review, and where is editorial responsibility recorded?
- What evidence shows the correct version of the disclosure was live for a particular release?
If the answer to the last question is "we can probably find it in Slack", the product has a memory problem dressed as a compliance programme.
Five places unfinished products tend to wobble
1. The interface knows less than the model integration
The backend can identify that a response came from an AI service while the frontend treats it as ordinary application text. The disclosure is then added to one screen but missed in exports, notifications, voice interfaces or mobile layouts. Product teams should map every surface where people encounter the system, not only the cheerful demo path.
2. Generated assets lose their provenance
Image optimisation, format conversion, content delivery networks and social platforms can alter metadata. A team may add machine-readable information at generation and quietly remove it three services later. The marking requirement therefore belongs in end-to-end asset testing, with representative formats and delivery routes.
3. "Human reviewed" has no process behind it
Editorial review needs an owner, a decision point and an audit trail. It should be possible to show who reviewed the material, what they were responsible for, and which version was approved. A checkbox added after publication is not oversight. It is archaeology.
4. Third-party tools are assumed to carry the whole obligation
Vendor features matter, but so do contracts, configurations and the way your product uses the output. Teams should document which party supplies markings, which party presents disclosures, what evidence is available, and what happens when a vendor changes behaviour.
5. Nobody tests the awkward cases
Disclosure logic often fails at boundaries: cached sessions, fallback models, regenerated content, edited media, translated text, bulk imports and old content republished through a new workflow. These are not exotic scenarios. They are Tuesday afternoon with a release deadline.
A practical Article 50 product audit
Founders and product owners do not need to begin with a ceremonial binder. They need a short, testable map of the product.
- Inventory AI behaviours. List user-facing interactions, generated content, manipulated media, automated decisions and third-party components.
- Classify the business role. Record where the company acts as provider, deployer or part of a longer chain. Obtain specialist legal advice where the classification or scope is uncertain.
- Map transparency triggers. Connect each relevant behaviour to the disclosure, marking, review or information requirement it may create.
- Design the user experience. Make disclosures timely, clear and accessible. Test responsive layouts, assisted technologies, voice journeys and multilingual variants.
- Trace content provenance. Verify markings survive generation, storage, transformation, export and delivery.
- Define human review. Give reviewers real authority, version control, clear responsibility and enough context to challenge the output.
- Capture evidence. Keep release records, test results, configuration history, vendor documentation and exceptions. Evidence should be produced by the workflow, not reconstructed during a complaint.
- Plan for failure. Decide how to disable an AI feature, correct content, preserve records and notify the right people when transparency controls fail.
Do not turn disclosure into theatre
The point of transparency is not to make the interface look regulated. It is to help people understand when AI is involved and to make the product's behaviour accountable.
That means resisting two equally unhelpful extremes. One is the invisible AI feature whose presence is buried in terms nobody reads. The other is blanket labelling so broad and noisy that users stop noticing it. Good implementation is specific to the interaction, technically durable and tested against what the product actually does.
The Commission's code is voluntary, while the underlying Article 50 obligations are legal requirements. The code offers a recognised practical route for demonstrating compliance, but it does not replace the legislation or the Commission's guidance. Product teams should treat those primary materials as the starting point and obtain legal advice for their particular facts.
What launch-ready looks like now
A launch-ready AI product is no longer merely one that produces an impressive answer on demand. It also explains itself at the right moment, preserves provenance through the delivery chain, supports genuine review, records what happened and can be corrected without an emergency rebuild.
That is less glamorous than a model benchmark and more valuable than another animated sparkle beside the prompt box.
If your AI feature works in the demo but its disclosures, content trail or review controls are still held together by assumptions, show Venturist what you have built. A focused product audit can turn the requirements into a practical release plan before customers or regulators perform the testing for you.