AI Transparency Obligations: What Providers and Deployers Actually Have to Disclose

Somewhere in your organisation, a chatbot is answering customers without telling them it is a machine. A marketing team is generating product imagery that was never photographed. A screening tool is ranking job applicants, and the hiring manager reading the shortlist assumes a colleague compiled it. None of these are exotic AI deployments. All three are now disclosure questions, and in most cases the disclosure has to reach the affected person at the moment of contact — not buried in a privacy notice nobody opens.

Transparency is the part of AI regulation that lands earliest and most awkwardly on ordinary operations, because it cannot be satisfied by a policy alone. It changes what a user interface says, what metadata leaves your systems, what a supplier contract has to guarantee, and what an employee is told before a tool starts assessing their work. The EU AI Act's transparency provisions in Article 50 sit in the phase of the Regulation that became applicable in August 2026. For UK organisations without EU exposure, there is no equivalent statute — but there are already transparency duties under UK GDPR that bite on exactly the same systems, and they have been enforceable for years.

Three different duties are all called "transparency"

Most confusion in this area comes from collapsing three separate obligations into one word. Separating them is the fastest way to work out who in your organisation owns what.

Documentation transparency (upstream)

For high-risk systems, the Act requires providers to supply deployers with instructions for use that cover the system's capabilities, limitations, expected accuracy, known risks, human oversight measures and the conditions under which performance degrades. This duty runs supplier-to-customer. If you are buying, it is a procurement artefact you should be demanding; if you are building, it is a document you have to write.

Interaction transparency (Article 50)

This is the duty owed to the person in front of the system: knowing they are talking to an AI, knowing content was synthetically generated, knowing they are being categorised or having emotion inferred. It applies to a much wider set of systems than the high-risk category, including many everyday tools.

Decision transparency (downstream)

Separately, where a high-risk system in the Act's listed categories produces a decision with legal or similarly significant effects on someone, the Act gives that person a right to a clear and meaningful explanation of the role the system played. This overlaps heavily with UK and EU GDPR rights around automated decision-making, but it is not the same duty and should not be tracked in the same register entry.

Who is a provider and who is a deployer

The Act splits duties by role, not by company size, and the label decides your workload. A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trade mark. A deployer uses an AI system under its own authority in a professional context.

The trap is that these are not permanent labels. An organisation that buys a general-purpose model and puts its own brand on the resulting assistant, or that substantially modifies a system or repurposes it for a use the original supplier did not intend, can find itself carrying provider duties it never budgeted for. In practice most mid-size organisations are deployers for the majority of their estate and providers for one or two internally built or heavily rebranded tools. Getting that split wrong is the single most common structural error in an AI inventory, because it points the entire obligation set at the wrong team.

What Article 50 asks for, by situation

Situation	Role that carries it	What "done" looks like
System interacts directly with people	Provider (designed in)	The person is informed they are dealing with an AI system, unless that is obvious to a reasonably observant person in the context
System generates synthetic audio, image, video or text	Provider	Outputs marked in a machine-readable format and detectable as artificially generated or manipulated, using solutions that are effective and interoperable as far as technically feasible
Emotion recognition or biometric categorisation	Deployer	Exposed individuals informed of the system's operation, with the personal data handled under data protection law
Deep fake image, audio or video	Deployer	Disclosure that the content is artificially generated or manipulated
AI-generated text published to inform the public on matters of public interest	Deployer	Disclosure, unless the content went through human review and a person or organisation holds editorial responsibility

The exceptions matter as much as the rules. Obviousness excuses interaction disclosure in some contexts. Assistive editing that does not substantially alter input data is treated differently from generation. Artistic, satirical and fictional works get a lighter form of disclosure that does not spoil the work. Certain law enforcement uses are carved out with their own safeguards. Disclosure itself has to be clear, distinguishable, accessible, and given no later than the first interaction or exposure — a footnote three clicks away does not meet that description.

Machine-readable marking is an engineering commitment

The marking duty is the one most likely to be missed, because it cannot be discharged by copywriting. Machine-readable means the marking survives outside your interface: embedded provenance metadata, cryptographically signed content credentials, watermarking, or a combination. Open provenance specifications exist and are being adopted across creative tooling, and the Act explicitly contemplates codes of practice at Union level to help standardise detection and labelling.

Two practical realities to plan around. First, marking degrades — screenshots, re-encoding, format conversion and some content delivery pipelines strip metadata, so a test that only checks the file at the point of generation proves very little. Second, if you generate through a third-party API, whether marking is applied is a supplier capability, not a choice you make afterwards. That belongs in the contract and in supplier assurance questions, not in a design ticket.

The UK position

The UK has no AI Act. Its approach places responsibility with existing regulators applying cross-sectoral principles, of which appropriate transparency and explainability is one. That does not mean transparency is optional. UK GDPR already requires that individuals be told about processing of their personal data, including meaningful information about the logic involved in solely automated decision-making with legal or similarly significant effects, and gives rights to contest such decisions. The ICO has published detailed guidance on explaining decisions made with AI. Where synthetic content misleads consumers, unfair commercial practice rules can also apply, quite independently of any AI-specific regime.

The practical consequence for UK organisations with EU customers, EU staff, or EU-facing output is that the two regimes stack. Meeting UK GDPR transparency does not discharge Article 50; meeting Article 50 does not discharge your Article 13 and 14 information duties.

A transparency readiness checklist

• Inventory by role, not by vendor. Every AI system in use, tagged provider or deployer, with a named accountable owner in the business — not in IT by default.
• Flag the four triggers. Direct human interaction, synthetic content generation, emotion or biometric inference, and public-interest text publication. These are the systems Article 50 reaches.
• Capture the actual disclosure wording and where it appears in the journey. Screenshot it. Wording that exists only in a design document is not a control.
• Test marking end to end, including after export, resize, re-encode and download, rather than only at generation.
• Check supplier terms for marking, provenance, model change notification and the documentation you would need to answer a regulator or a data subject.
• Record the exceptions you are relying on — obviousness, assistive editing, editorial review, creative works — with the reasoning, dated and signed off. An unrecorded exemption is indistinguishable from an oversight.
• Align workplace notification. Where AI assesses or affects workers, employee and representative notification duties apply alongside customer-facing ones.
• Keep evidence of staff AI literacy measures. The Act requires providers and deployers to take measures to ensure staff have a sufficient level of AI literacy.

Where this guide stops

This covers transparency duties in general terms. It does not determine whether a specific system is high-risk under the Act, which is a separate classification exercise with substantially heavier obligations attached, and it does not address prohibited practices — the most serious category, carrying penalties of up to 7% of global turnover, against up to 3% for most other obligations under the Act and 4% under UK and EU GDPR. Sector rules in financial services, healthcare, employment and law enforcement add requirements that sit on top of everything described here, and the guidance and codes of practice supporting the marking duty continue to develop.

Take specialist legal advice where the provider or deployer classification is genuinely contested, where you have modified or rebranded a third-party system, where AI output influences decisions with legal effects on individuals, or where an exception is doing significant work in your compliance position. Those are the points where a defensible written analysis is worth considerably more than a completed checklist.