The EU AI Act's Transparency Rules: What Builders Actually Need to Check

September 3, 2026 / Arvid Andersson

Article 50 of the EU AI Act applied from 2 August 2026. It is the transparency article: who has to say that something was made by a machine, and in what form. This is a builder's read of which parts are yours to implement and which belong to whoever supplies your model. It is not legal advice. The links go to primary sources so you can check any of it yourself.

Start here: are you a provider or a deployer?

Almost every confusion about Article 50 comes from skipping this question. The article puts different duties on different parties. The one people panic about, machine-readable marking, lands on the provider.

A provider, per Article 3(3), develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. A deployer, per Article 3(4), uses an AI system under its own authority, except in a personal non-professional activity.

If you call an LLM API and ship a feature on top, you are usually a deployer of that model. If you fine-tune, package, and sell a system as your own product, you are closer to a provider. Plenty of teams are both, in different parts of the same codebase.

This matters because the machine-readable marking duty in Article 50(2) sits with the provider of the generative system. A deployer building on someone else's model does not discharge it by adding a tag in their own DOM, and often cannot: the mark is meant to be applied at generation.

The duties, in the order you will hit them

Article 50(1): tell people they are talking to an AI. Providers must design systems that interact directly with people so those people are informed they are dealing with an AI, unless that is obvious "from the point of view of a natural person who is reasonably well-informed, observant and circumspect". A chat widget labelled as a bot clears this easily.

Article 50(2): mark generated output in a machine-readable format. The provider duty. Outputs of systems generating synthetic audio, image, video or text must be marked and detectable as artificially generated. The regulation asks for solutions that are "effective, interoperable, robust and reliable", then adds the qualifier that does most of the work in practice: "as far as this is technically feasible". It does not apply where the system performs an assistive function for standard editing, or does not substantially alter the input data or its semantics.

Article 50(3): emotion recognition and biometric categorisation. A deployer duty. Anyone exposed to such a system has to be informed of its operation, with the personal data handled under GDPR. Narrow scope, and no technical-feasibility escape hatch.

Article 50(4): disclose deepfakes and public-interest text. A deployer duty, about human-visible disclosure rather than metadata. Two limbs: deepfake image, audio or video must be disclosed as artificially generated, and text published to inform the public on matters of public interest must be disclosed too. The second limb has an exception: it does not apply where the content underwent "human review or editorial control" and a natural or legal person "holds editorial responsibility for the publication". An AI-drafted article a named editor checked and stands behind is treated differently from an unreviewed feed.

Article 50(5): when and how you say it. The information has to reach people "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure", and has to meet applicable accessibility requirements. Disclosure buried in a settings page does not obviously satisfy "first interaction".

What "machine-readable" means for text

Text is where this gets awkward, and the guidance says so itself.

The Commission's Code of Practice on marking and labelling AI-generated content, published in final form on 10 June 2026, is voluntary. It is not the law; it is one documented way to show you are meeting it. Providers who skip it have to demonstrate compliance "through alternative equivalently adequate means".

Its baseline asks for two layers of machine-readable marking: digitally signed metadata, and an imperceptible watermark. Read which content that applies to. The Code requires the two-layer approach for "audio, images, video, and containerised text", and then says this about the rest:

given that free-form text cannot transport metadata, a single-layer of marking as described in Sub-measure 1.1.2 is considered sufficient to comply with the requirements of Article 50(2) AI Act for this specific type of content.

So free-form text needs the watermark, not the metadata. The watermark requirement has a floor of its own: the Code exempts "very short text", defined as text shorter than 200 tokens. Current techniques cannot watermark anything shorter with even a basic level of reliability. Above 200 tokens watermarking applies, with the Code conceding it "may have lower reliability".

That concession has a consequence. Because free-form text watermarks are less reliable, the Code lets providers restrict access to the detection tool rather than publishing it openly. The restriction is narrower than it sounds: market surveillance authorities, regulators, law enforcement, media, fact-checkers, trusted flaggers, researchers and civil society organisations all keep access.

The available techniques are immature:

• C2PA / Content Credentials is the most deployed provenance standard and is mostly used on files. Its specification does cover unstructured text: since version 2.3 it defines embedding a manifest using invisible Unicode variation selectors, plus external manifest repositories for assets that cannot carry one inline. The reference implementation, c2pa-rs, does not list plain text among its supported formats. Invisible codepoints also do not survive much: plain-text conversion and re-typing strip them.
• Token-distribution watermarking embeds a statistical signal in the model's word choices. It degrades on short passages, which is exactly why the Code sets a 200-token floor and permits restricted detection access for text.
• Screenshots break everything. A re-captured image of text carries no provenance at all.

That immaturity is a reason to be sceptical of any vendor selling a solved, robust text watermark today, not a reason to ignore the duty. CEN-CENELEC's JTC 21 is still working on the harmonised standards, which leaves no settled conformity route to point at yet.

The checklist

Ordered roughly by how often each one gets missed.

Two things circulating that are not right

"The rules changed, visible text is no longer enough." The machine-readable requirement in Article 50(2) has been in the adopted text since 2024. What changed in 2026 is that the obligation started applying, plus a Code of Practice and Commission guidelines arrived to say how to meet it. The visible-disclosure duty in 50(4) was never replaced. They are parallel obligations on different parties.

"Everyone building with AI needs to implement a machine-readable tag." Only if you are the provider of the generative system. Most teams building on a hosted model are deployers, whose 50(4) duties are about disclosure to humans.

The jurisdiction question that arrives with it

Infrabase does not track Article 50 conformance per product, and would be inventing it if it claimed to. What it does track, verified from each company's own legal pages, is jurisdiction: which company is behind a tool, where it is headquartered, and whether it publishes GDPR and SOC 2 positions.

That is the useful adjacent fact. The transparency question usually gets asked in the same conversation as data residency. The second one is answerable from published evidence in a way the first is not yet. EU-headquartered inference providers in the directory with a verified GDPR position, as of September 2026:

Full list with country, category and compliance filters on the European AI infrastructure page.

Frequently asked questions