Article 50 Transparency as an Architecture Decision

Each EU AI Act Article 50 duty translated into a place in the stack, a log row, and an owner — chatbot disclosure in UI chrome, C2PA marking that survives the CDN, and an evidence pack that is not screenshots.

Article 50 gets read as a legal checklist — disclose, mark, label — and handed to legal to “own”. That framing fails at the first audit question, which is never did you intend to disclose? It is show me the disclosure for this session, on this surface, on this date. Only architecture answers that. Our working rule: every Article 50 duty gets three assignments — a place in the stack, a log row, and a named owner — and a duty missing any of the three is not implemented, whatever the policy document says.

Quick anatomy, because the four duties land on different roles and different layers. Art 50(1): providers of AI systems that interact with natural persons must ensure people are informed they are dealing with AI — unless it is obvious to a reasonably well-informed, observant and circumspect person. Art 50(2): providers of systems generating synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated — with the marking expected to be effective, interoperable, robust and reliable so far as technically feasible. Art 50(3): deployers of emotion-recognition or biometric-categorisation systems must inform the people exposed to them. Art 50(4): deployers must disclose deepfakes (softened, not waived, for artistic and satirical work) and AI-generated text published to inform the public on matters of public interest — unless the text passed human editorial review with someone taking responsibility. Across all of it, the delivery bar: clear, distinguishable, at the latest at the first interaction or exposure, and accessible.

Duty 1 — where the chatbot disclosure lives

Two candidate homes for the Art 50(1) disclosure, and teams keep picking the wrong one.

Option A: the first-turn system response. Instruct the model, via system prompt, to open with “I’m an AI assistant…”. Tempting because it ships in an afternoon. Wrong because it makes a legal obligation depend on a probabilistic system: the disclosure can be lost to prompt injection, dropped when the conversation resumes from history, mangled by a locale the prompt never anticipated, or silently eroded by the next prompt refactor. Worst of all, you cannot prove it fired for any given session without parsing generated text after the fact.

Option B: UI chrome. The disclosure is a deterministic element of the interface — a labelled header, a persistent badge, an interstitial on first use — rendered by the front end before the first token streams. It is versioned in the front-end repo, survives model swaps and prompt refactors, renders identically whether the model behaves or not, and maps exactly onto the statutory delivery bar: clear, distinguishable, at first interaction. Chrome wins. We keep a belt-and-braces line in the system prompt so the model also acknowledges being AI when asked directly — but that line is UX polish, not the compliance control.

The part most teams skip: disclosure as an event. Rendering the badge is necessary; being able to prove you rendered it is what survives an audit. Our front end emits a disclosure event per session with a fixed schema: hashed user ID (salted — the evidence log must not become its own privacy problem), surface (web, iOS, embedded widget, voice line), timestamp, disclosure version (pointing at the exact copy text and locale in the config repo), and session ID. One row per session, ~200 bytes, kept alongside the interaction logs. When someone asks “was this user informed on 14 March?”, the answer is a query, not an argument.

Duty 2 — marking that survives your own infrastructure

Synthetic-media marking has a natural home: the generation service, the one chokepoint every generated asset passes through. The clouds increasingly do the first step for you — Azure OpenAI image models attach C2PA Content Credentials to every generated image automatically: a cryptographically signed manifest recording that the content is AI-generated, which service produced it (the softwareAgent field), and when. Google marks Imagen output with SynthID invisible watermarking, and AWS provides watermarking for its own image models — check current docs for exact coverage on each, because modality support moves quarterly.

Then your own infrastructure destroys it. This is the trap that bites nearly everyone: C2PA manifests live in file metadata, and media pipelines strip metadata as a feature. The thumbnailer re-encodes the image and drops the manifest. The CDN’s image-optimisation layer converts to WebP and drops the manifest. The social-share crop drops the manifest. Six months in, you discover that every asset users actually see is an unmarked derivative of a marked original — the marking exists only in an S3 bucket nobody serves from. Marking is a pipeline property, not a generation property: every transform step either preserves the credential, re-signs the derived asset, or is a compliance bug.

Which is why the duty is really two duties. The metadata layer (C2PA) is rich and verifiable but fragile — it survives nothing that re-encodes. The watermark layer (signal embedded in the pixels or waveform) survives re-encoding and metadata stripping, but degrades under aggressive crops, filters, and adversarial attack — and vendors’ robustness claims deserve the same scepticism as any other vendor claim. The statute asks for effectiveness and robustness so far as technically feasible, not for miracles: our honest implementation is layered marking plus a written robustness statement — a tested table of what our marking survives (resize, WebP conversion, 80% JPEG re-encode) and what it does not (heavy crops, screenshots, deliberate laundering). Detectability you can also operate: detection APIs (Azure’s Content Provenance Detection API among them) let us verify our own published assets on a schedule, which turns “are we still marking?” from an assumption into a monitored metric.

Duties 3 and 4 — notices at the point of exposure, and the exception that is really a workflow

Emotion-recognition notices follow the chatbot-disclosure pattern with one twist: the people to inform are the exposed, not the users. In the classic case — call-centre voice analytics scoring caller frustration — the operator sees the dashboard but the caller is the exposed person, so the notice lives in the IVR flow (“this call is analysed by AI…”), and the architecture decision is a gate: the analytics pipeline does not start for a call whose notice event has not been logged. Same event schema as the disclosure log — hashed identifier, surface, timestamp, notice version. The GDPR/LED duties for the underlying biometric processing run in parallel; the Art 50(3) notice does not discharge them.

The deepfake duty inverts the flow: the label a viewer sees should be derived from provenance metadata, not typed in by an editor who remembered. If the asset carries a credential, the player renders the label; the label-render event joins to the asset ID in the logs. And the Art 50(4) text exception — no disclosure needed where AI-drafted public-interest text passed human editorial review with someone taking responsibility — is the most architectural clause in the article: claiming it requires a workflow system that records the AI-drafted flag, the named reviewer, and the approval timestamp. The exception is itself an evidence duty. A newsroom that cannot produce its review records cannot claim its exception.