The Commission adopted its Article 50 guidelines on July 20: who discloses, who marks, and what you have to be able to prove
The European Commission adopted its final guidelines on the Article 50 transparency obligations on July 20, 2026, thirteen days before those obligations start to apply on August 2. The guidelines set out scope, definitions, and exceptions, and they split the duties actor by actor: providers carry the interaction notice and the machine-readable marking of synthetic content, deployers carry emotion-recognition notice and deepfake disclosure. Generative systems already on the market get until December 2, 2026 for machine-readable marking. This walks the split obligation by obligation and separates the parts an AI policy gateway produces evidence for from the parts it never touches.
On July 20, 2026 the European Commission adopted its final guidelines on the transparency obligations for providers and deployers of AI systems under Article 50 of the AI Act. Thirteen days later, on August 2, those obligations start to apply. The guidelines work through scope, definitions, and exceptions, and they sort the duties actor by actor, with some landing on providers and others on deployers.
I want to walk that split obligation by obligation, then be specific about which parts of it an AI policy gateway produces evidence for and which parts it never touches.
The actor-by-obligation split
Article 50 reads as one transparency regime, and the guidelines treat it as four separate duties attached to two different actors. Getting the actor wrong is the fastest way to build the wrong control. A deployer that buys a chatbot from a vendor carries duties under 50(4) and possibly 50(3), while the vendor carries 50(1) and 50(2). Both parties frequently assume the other one has it covered.
Article 50(1): providers of systems that interact with people
A provider of an AI system intended to interact directly with natural persons has to design and develop it so the person is informed they are dealing with an AI. Chatbots, virtual assistants, and automated phone lines all sit here. The duty attaches at design time, which means it belongs to whoever builds the system rather than whoever switches it on.
The exception is written from the reader's point of view: the notice is unnecessary where AI involvement is obvious to a natural person who is reasonably well-informed, observant and circumspect. A second carve-out covers systems authorised by law to detect, prevent, investigate or prosecute criminal offences, unless those systems are available to the public for crime reporting.
Article 50(2): providers marking synthetic content
A provider of a generative system that produces synthetic audio, image, video or text has to ensure the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. This is a signal written into the artefact itself, at the point of generation.
The exception here is narrower than teams tend to assume. Systems performing an assistive editing function that leaves the input data or its semantics substantially unaltered fall outside the marking duty, which is how grammar correction and similar tooling escape. A rewrite that changes the meaning does not qualify as assistive editing.
Article 50(3): deployers of emotion recognition and biometric categorisation
A deployer running an emotion recognition system or a biometric categorisation system has to inform the natural persons exposed to it. The duty sits with the operator, not the vendor, because the operator is the one pointing the system at people. Systems permitted by law to detect or investigate criminal offences are exempt.
Article 50(4): deployers publishing deepfakes and public-interest text
Two duties live in this paragraph. A deployer generating or manipulating image, audio or video content that constitutes a deep fake has to disclose that the content is artificially generated or manipulated. Where the work is evidently artistic, creative, satirical or fictional, the duty reduces to disclosing the generated content in an appropriate manner that does not spoil the display of the work.
The second duty covers AI-generated or manipulated text published with the purpose of informing the public on matters of public interest. Publication requires disclosure, unless the content went through human review or editorial control and a natural or legal person holds editorial responsibility for it.
The exceptions carry more weight than the obligations
Read the four paragraphs above and the obligations look expansive. Read the exceptions and the real scope narrows considerably: obvious AI involvement, assistive editing, editorial responsibility, law-enforcement authorisation. Each one is a judgment call that a compliance owner has to make in advance and then defend later.
That is my honest read of this package: the guidelines are less a set of new requirements than a set of boundaries around exceptions that firms were already claiming informally. The value of adopting them on July 20 is that a firm claiming the editorial-responsibility carve-out for its newsroom AI now has a Commission document to point at when a national authority asks who signed off.
Two dates, not one
August 2, 2026 is the general application date for Article 50, and the Digital Omnibus deferral of the high-risk deadline to December 2027 left it untouched. One carve-out moves: generative AI systems placed on the market before August 2026 have until December 2, 2026 to meet the machine-readable marking requirement under Article 50(2).
Sitting underneath the guidelines is the Code of Practice on marking and labelling of AI-generated content, published on June 10, 2026 after a multi-stakeholder process that drew more than 187 participants from industry, academia, civil society, rightsholders and member states. The Code covers Article 50(2) and 50(4) and gives signatories a recognised way to demonstrate compliance with those two paragraphs. It sits alongside the guidelines rather than replacing them.
The four-month grace period on marking is the weakest part of the package, and I would have cut it. It hands an advantage to whoever shipped a generative feature fastest before August, and the firms that held back to build marking properly get to watch their competitors run unmarked until December.
What a policy gateway has nothing to do with
Three of the controls Article 50 asks for are produced somewhere other than the network boundary, and pretending otherwise wastes a reader's time.
The interaction notice under 50(1) is rendered by the application. It is the grey line of text above the chat box that says you are talking to an assistant, and it is written into the interface by whoever builds the interface. An HTTP proxy sitting between that application and the model sees the request after the user has already read the banner, or after they have not.
The machine-readable mark under 50(2) is written where the content is created, inside the model or the generation service that wraps it. Watermarking schemes for audio, image, and video embed a signal in the artefact during generation. A gateway that forwards a completed response has no position from which to embed anything.
Deepfake detection is a separate discipline with its own research literature and its own failure modes. DeepInspect performs none of these three functions, and any vendor telling a compliance owner that a proxy layer discharges Article 50(2) is selling them a problem for later.
The evidence layer a competent authority can inspect
The in-boundary slice is narrow and it is real. When a national market surveillance authority opens a file, the first question is rarely about watermarks. It is about scope: which AI interactions occurred, under whose identity, against which model, over what period. That is an inventory question, and inventory is what a per-decision audit record at the AI request boundary produces without anyone assembling it after the fact.
A policy gateway sits inline between authenticated users or agents and the LLM endpoints they call. Every call is authenticated, evaluated against policy, and written to a record before the response returns. The record names the actor rather than the API key, which is the difference between an answer and a shrug when an authority asks who was interacting with the system on a given Tuesday.
The second in-boundary control is response-side policy on governed AI egress. A policy that requires an AI disclosure to be attached to responses on a given route can be evaluated at the boundary, and the outcome of that evaluation gets recorded per request. The application still renders the disclosure. The gateway checks that the policy was in force at the moment of the call and produces the record proving it, which is the same architecture Article 12 record-keeping already requires for high-risk systems. One log satisfies both readings.
This also solves the self-attestation problem that application logs create. When the system making the AI call also writes the compliance record, the system under audit is generating its own evidence. A decoupled proxy commits the record independently, before the response reaches the application.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as a stateless, identity-aware enforcement layer. Every request is evaluated against who is asking, what role they hold, which model they are calling, and what organisational policy applies. Enforcement happens inline and fails closed.
For an Article 50 file, the artefact that matters is the per-decision audit record: identity-bound, tamper-evident, and written independently of the application that made the call. It gives a compliance owner the interaction inventory a market surveillance authority asks for, and it records whether the transparency policy was in force on every governed call. The disclosure itself and the content marking stay with the application and the model, where they belong.
If you are facing the August 2 deadline, let's talk.
Frequently asked questions
- Do the July 20 guidelines change what Article 50 requires?
The guidelines interpret rather than amend. Article 50's four obligations were fixed when the AI Act entered into force, and the July 20 document sets out how the Commission reads scope, definitions, and exceptions across them. The practical change is evidentiary. A firm relying on the assistive-editing exception under 50(2), or the editorial-responsibility exception under 50(4), now has an adopted Commission text to reason against instead of a draft. For anyone writing an internal position on why a given system falls outside a paragraph, that document is the reference the position should cite.
- Which Article 50 duties fall on us as a deployer rather than a provider?
Deployers carry Article 50(3) and Article 50(4). Under 50(3), a deployer running emotion recognition or biometric categorisation informs the people exposed to the system. Under 50(4), a deployer generating deep fake image, audio or video content discloses that the content is artificially generated, and a deployer publishing AI-generated text on matters of public interest discloses that too. The interaction notice under 50(1) and the machine-readable marking under 50(2) attach to providers, which means the vendor building the system rather than the enterprise switching it on. Buying a chatbot does not transfer 50(1) to you, and it does not relieve you of 50(4) when you use it to publish.
- Does the December 2, 2026 date apply to our new deployment?
Only to generative AI systems placed on the market before August 2026. Those systems have until December 2, 2026 to meet the machine-readable marking requirement in Article 50(2). A system placed on the market on or after August 2, 2026 complies from that date. The distinction matters when a vendor tells you their marking roadmap lands in Q4: the answer depends on when their product was placed on the market, and that is a question worth putting in writing during procurement rather than discovering in December.
- Can an AI gateway satisfy the machine-readable marking obligation?
No. Marking under Article 50(2) is embedded in the generated artefact at the point of generation, inside the model or the service producing the output. A proxy forwarding a completed response occupies the wrong position in the flow to embed a watermark. The gateway contribution to an Article 50 file is the per-decision record of which identity called which model under which policy, plus response-side evaluation of whether a required disclosure policy was in force. Treat the marking obligation as a provider engineering task and the evidence obligation as a boundary task.
- What should we have ready before August 2?
An inventory of every AI system in scope, mapped to the paragraph that captures it and the actor role you hold for it. A written position on any exception you rely on, citing the July 20 guidelines. A record of the disclosure decisions your systems make, produced by something other than the application making them. Confirmation from each vendor about marking status and market-placement date. The August 2 readiness work that most teams scoped in spring covers the first two items; the third is where deployments usually turn out to have nothing.
- How does this relate to the Code of Practice on AI-generated content?
The Code, published June 10, 2026, covers Article 50(2) marking and detection and Article 50(4) labelling. Signing it gives a provider or deployer an EU-recognised route to demonstrate compliance with those two paragraphs. The guidelines cover all four paragraphs and set out the Commission's reading of scope and exceptions. Signature is voluntary and the underlying obligation applies either way, so the Code is best understood as a demonstration mechanism layered on top of the duties the guidelines describe.