The EU AI Act transparency rules, and what agencies must do.
Enforcement began on 2 August 2026 and the rules reach further into ordinary agency work than the coverage suggested. What is in scope, and what is not.
On 2 August 2026 the European Commission began enforcing the AI Act’s transparency rules, and they reach further into ordinary agency work than most of the coverage suggested. If you have built a client chatbot, an automated reply, or a workflow that drafts customer-facing text with a model, this applies to something you have already shipped.
This is a practical summary for agencies, written on 6 September 2026. It is not legal advice, and anything with real exposure deserves a lawyer who knows the client’s jurisdiction.
What changed on 2 August.
The Commission’s announcement sets out three obligations in plain terms: chatbots and other interactive AI systems must tell users they are dealing with AI rather than a human, deepfakes must be labelled, and AI-generated or altered content must carry machine-readable marks so it can be detected.
These sit in Article 50, which covers four situations: direct interaction with people, synthetic content, emotion recognition and biometric categorisation, and deepfakes or AI-generated text on matters of public interest.
The disclosure standard is specific. Information has to reach the person at the latest at the time of the first interaction, and it must be clear and distinguishable. A line in the terms of service does not satisfy it.
Penalties run to €15 million or 3% of worldwide annual turnover, whichever is higher.
Provider or deployer, and why agencies are often both.
The Act splits obligations between two roles. A provider develops an AI system and places it on the market. A deployer uses one under their own authority. Different duties attach to each.
For agency work the line is genuinely blurry. If you assemble a chatbot from a model API and ship it under a client’s brand, you have arguably built and supplied a system while the client operates it. In practice the obligation tends to land on the client as deployer, and the ability to satisfy it sits entirely with whoever wrote the workflow.
That is the gap worth closing contractually rather than assuming. Whoever is formally responsible, the disclosure has to be implemented by the party holding the code.
Geography does not help either. The rules apply to anyone placing AI on the EU market or whose AI outputs are used within the EU, so a UK agency building for a client with European customers is in scope.
What it means for the things agencies actually build.
| What you built | Whether it is in scope | The practical step |
|---|---|---|
| A support or sales chatbot | Yes, direct interaction | State it is an AI assistant in the opening message |
| An auto-reply drafted by a model and sent unreviewed | Likely, as synthetic text | Disclose, or route through human review |
| A model drafting replies a person edits and sends | Generally not, where a human takes editorial responsibility | Keep the review step real, not nominal |
| Internal classification and routing | No, no person is interacting or receiving content | Nothing required here |
| Document extraction into a CRM | No, output is internal data | Nothing required here |
| AI-generated images or video for a client | Yes, synthetic content | Marking and labelling obligations apply |
The pattern is that back-office automation is largely untouched. Classification, extraction, routing and enrichment do not put a person in front of generated content. What is caught is anything a customer talks to or reads.
The human review exemption is the one to understand properly. AI-generated text on public interest matters does not require disclosure where it has undergone substantive human review and somebody holds editorial responsibility. A person clicking approve on forty drafts a minute is unlikely to meet that description.
The December date still ahead.
There is one deadline that has not passed. Generative AI systems already on the market before 2 August 2026 have until 2 December 2026 to comply with the machine-readable marking and detection obligation. Everything else in Article 50 has applied since August.
If a client is running something that generates synthetic content and predates August, that is a real date with roughly three months left on it at the time of writing.
What to do now.
Four things, none of which take long.
Inventory what you have shipped. List every client system where a model produces something a person sees or talks to. Most agencies find fewer than they expect, and find one they had forgotten.
Add the disclosure where it is missing. For a chatbot this is usually one sentence in the opening message, and it is a fifteen minute change.
Check whether your review steps are real. If a workflow drafts and a person approves, confirm the approval is a genuine editorial decision rather than a button somebody presses to clear a queue.
Raise it with clients rather than waiting. The obligation is theirs to carry and yours to enable, and a short email now reads very differently from the same conversation after a complaint.
If you have client automations with a model in them and want a straight answer on which are in scope and what would need to change, send us what they do. We will tell you which ones need disclosure and what implementing it would involve. Send us the details.
Sources: European Commission, EU Artificial Intelligence Act, Article 50, Cooley.
Related notes
How to handle GDPR when an automation moves client data.
Most agency automation work is data protection work, and it usually gets treated as though it is not. Controllers, processors and where the data actually goes.
Build an LLM step that returns structured JSON you can trust.
A model in the middle of a workflow returns whatever it decided to write. Build the step so the node after it always receives the shape it was expecting.
Build a document extraction pipeline with a confidence gate.
A pipeline that extracts fields at ninety percent accuracy and writes all of them has not saved anybody time. It has created a data problem for later.
