Article 50 AI Act compliance for generative AI: a practical guide for CTOs and agency developers

In this guide the goal is narrow and practical: reduce the risk of avoidable Article 50 violations without turning compliance into a six-month architecture rewrite. When the founder asks “what do we need to do so we do not get fined for this AI feature,” you should be able to answer in one page, with evidence behind it.

The real problem

Most teams do not get into trouble because they ignore the law, they get into trouble because they ship something half-compliant: a chatbot with no clear AI disclosure, image outputs whose metadata vanishes in the delivery pipeline, audio generated for campaigns without any traceable marking, or public-facing AI content with no documented editorial responsibility behind it.

The right question is therefore not “what does Article 50 say,” because summaries of that are everywhere.

What Article 50 means in practice

Three obligations matter immediately for most generative AI teams.

First, direct interaction: if a person interacts with an AI system, the system must make that clear unless it is already obvious from context to a reasonably informed user. A customer-support chatbot on a retail site almost never qualifies as obvious; a chess engine on a gaming platform probably does. The disclosure belongs in the interaction itself — a banner, a first message, an audio notice — not in the terms of service.

Second, synthetic content marking: outputs that are generated or manipulated artificially should carry a marking mechanism that is machine-detectable and appropriate to the modality and the delivery path. The regulation does not mandate one specific technology. It mandates that the mechanism works and survives the transformations your output realistically goes through.

Third, traceability for sensitive outputs: deepfakes and AI-generated text on matters of public interest carry additional disclosure duties, usually on the deployer side, with an editorial-control alternative for text where a named human takes responsibility.

First question: which role are you actually in

Before any implementation decision, map your role in the table below, because Article 50 splits obligations between providers (who build and place AI systems on the market) and deployers (who use them under their own authority). The distinction decides what you control and what you owe.

Scenario	Your likely role	What that means
You built and operate the model or the branded AI feature yourself	Provider	Disclosure design and output marking are largely yours
You integrate a third-party AI API into your product	Usually deployer, sometimes both	You control disclosure to your users; marking may come from upstream — verify it
An agency builds an AI workflow for a client	Builder for a deployer, often in a gray zone	Document who is responsible for what before handoff
You fine-tune and re-release an open model under your own name	Provider	You inherit marking duties even if the base model came from elsewhere

The mistake to avoid is assuming that because you did not train the model, none of this applies to you. If the output reaches end users under your product or your client’s brand, someone in the chain carries the obligation, and contracts — not assumptions — should decide who.

The fast decision tree

Answer five operational questions before touching any code.

Question	If yes	Next action
Does a human interact directly with the AI?	Chatbot, copilot, support agent, voice system	Add first-contact disclosure in the UI or voice flow
Does the system generate text, images, or audio?	Any synthetic output returned to users or clients	Add a modality-appropriate marking mechanism
Can the output be redistributed or published?	Marketing, client delivery, social content	Strengthen marking and keep generation evidence
Does the output pass through CDNs, CMSs, or schedulers?	Delivery path may strip metadata	Test the real production path, not local files
Is the system built for clients, not only internal use?	Agency or software vendor scenario	Put provider/deployer responsibilities in writing

Three or more yes answers mean this is a shipping requirement, not a compliance backlog item.

What to do for text, image, and audio

Text

Text watermarking exists, but robustness against paraphrase, translation, and human editing is limited, and there is no single universally accepted standard yet. The most defensible posture for most teams combines three things: clear disclosure where the interaction happens, a response-level record stating that the output is AI-generated (model, timestamp, marking method), and — where you control the sampler — in-generation watermarking as an additional signal. Do not promise clients that a text watermark alone will survive heavy editing; it will not, and claiming otherwise creates its own liability.

Image

Assume metadata-only marking is fragile. CDNs, export tools, and optimization pipelines strip EXIF and XMP data without warning. The safer pattern is dual marking: an in-content invisible watermark plus a signed provenance layer, tested against the exact production delivery path — not against local files. If you deliver via URL responses, verify that the serving path preserves the manifest end to end, and add an automated check for it in CI.

Audio

Expect compression, clipping, and format conversion downstream: file headers alone are weak. Combine an inaudible watermark with response-level metadata and evidence logging, then test the output after the transformations it will actually face: mp3 re-encode, platform upload, video-editor export. If you ship through ad platforms or campaign tools, test through those too, because that is where marks die quietly.

If you are not the final publisher

This is the section most guides skip, and it is the one agency developers actually need. If you build the workflow but the client publishes the output, three things must happen before handoff.

First, document which parts of the workflow generate synthetic outputs and which marking mechanism each one uses. Second, put in writing who is responsible for preserving marks and disclosures after delivery — the client as deployer usually carries publication-side duties, but “usually” is not a legal strategy, the contract clause is. Third, give the client a one-page operational brief: what must stay enabled, what must not be removed, and what requires human review before publication.

This is self-protection more than bureaucracy. When the founder asks why a client published unmarked synthetic content six months later, the agency should be able to produce the workflow map, the marking evidence, and the signed responsibility split in minutes, not weeks.

The minimum safe architecture

Four components are enough for a defensible first layer:

1. A user-facing disclosure layer for any system that interacts directly with people.
2. A marking layer adapted per modality, placed where you actually control the output — for API-first teams, that is usually the serving layer.
3. An evidence register storing timestamps, model identifiers, tenant references, marking methods, and content hashes.
4. A verification step in QA or CI that checks whether common transformations break the mark.

This is not perfect compliance, It’s the difference between “we have no control” and “we run a deliberate, documented process,” which is the difference that matters in enterprise procurement, internal governance, and the first hours of any regulatory question.

The evidence you must keep, and what not to keep

Compliance teams over-focus on generation and under-focus on proof. Keep: generation timestamp, model identifier, output modality, marking method, marking-logic version, tenant or client reference, disclosure placement records, and a hash of the output.

Do not keep the raw output itself unless you have a specific reason — storing everything creates a second content database with its own GDPR exposure, breach surface, and retention problem.

This is where a privacy-first architecture pays off twice, a hash-based attestation register lets you verify any disputed artifact later — recompute the hash, compare it to the register — without ever having stored the content. Legal gets proof, the DPO gets data minimization, and the storage bill stays flat. If your infrastructure already runs zero-retention inference, this design falls out naturally; if it does not, building the register this way is still the cheapest defensible option.

---

Common mistakes that create liability

The first mistake is treating terms-of-service language as interaction disclosure. If a user could reasonably believe they are dealing with a human, the disclosure must happen in context, at first contact.

The second is metadata-only marking for images or audio without testing the production path. Many teams discover the stripping problem only when a downstream verification fails in front of a client.

The third is promising watermark robustness that the technology does not deliver, especially for text. Underclaim and over-document, never the reverse.

The fourth is undefined ownership: product assumes legal owns it, legal assumes engineering owns it, engineering assumes the client handles it. Nobody owns the risk, which means everybody does.

The fifth is assuming downstream users will preserve marks. Some will. Contracts, documentation, and technical defaults should be designed for the ones who will not.

---

FAQ

Is this mainly a legal issue or a technical one?

Both, but failures happen in product and infrastructure. The law defines the obligation; the stack determines whether the obligation survives contact with reality.

What should a small team do first?

Three actions: disclose AI interaction clearly at first contact, add a documented marking mechanism per modality, and stand up a lightweight evidence register. These reduce risk faster than policy writing.

Do agencies carry risk if the client publishes the final output?

Yes, through ambiguity. The agency should document the workflow, preserve generation evidence, and put the responsibility split in the contract before handoff.

Is one universal marking method enough for text, image, and audio?

No. Modalities break in different ways — expect a mixed strategy, and be especially careful with text, where watermark robustness is the weakest.

What is the fastest way to lower founder risk?

Inventory every AI output exposed to users or clients, add disclosure where interaction occurs, add marking where content is generated, and document the evidence path. Uncertainty is where bad decisions survive longest.

---