The Two Distinct Obligations: Article 50(2) vs 50(4)

When engineering teams build generative media pipelines under Regulation (EU) 2024/1689 (the EU AI Act), they frequently treat transparency as a single check-box requirement. In practice, Article 50 creates two distinct operational obligations that attach to different legal entities and demand completely different technical implementations. While Article 50(1) covers informing users when interacting directly with AI systems, and Article 50(3) regulates emotion recognition and biometric categorisation, the operational core for synthetic media sits squarely between Article 50(2) and Article 50(4).

Article 50(2) imposes an obligation on the provider of a generative AI system to ensure that synthetic audio, image, video, or text outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. In contrast, Article 50(4) places a disclosure duty on the deployer: an organisation using an AI system to produce deepfakes or publish synthetic text on matters of public interest must visibly disclose the artificial nature of that content to human viewers. Understanding this boundary is critical when mapping out deployer duties across your ingestion and egress stack.

  • Article 50(2) Machine-Readable Marking: Sits on the provider; mandates cryptographically verifiable or detectable signals (such as C2PA manifests) embedded directly into output files.
  • Article 50(4) Human-Perceptible Disclosure: Sits on the deployer; requires visible on-screen labels, watermarks, or audio disclosures upon first exposure for deepfake audio, image, or video assets.
  • Scope Boundary: A signed C2PA manifest does not discharge the human disclosure duty under 50(4), and a visual caption on a webpage does not satisfy the machine-readable requirement under 50(2).

Because these obligations operate on different layers of the delivery stack, relying on an upstream API provider to solve your compliance burden is an architectural error. A machine-readable payload embedded by an engine does nothing to inform a consumer viewing a rendered frame on a social platform, just as a UI badge does nothing for downstream programmatic verification.

Enforcement Dates and the December 2026 Grace Period

The enforcement schedule for Article 50 has created widespread confusion, largely due to conflation with the broader timeline for high-risk AI systems. Article 50 transparency obligations became enforceable on 2 August 2026. However, under Regulation (EU) 2026/1744, high-risk system obligations under Chapter III were deferred to 2 December 2027 for Annex III stand-alone systems and 2 August 2028 for Annex I product-embedded systems. Transparency rules apply right now, completely independent of the high-risk timetable.

For generative media systems, there is an essential transitional provision. A limited grace period applies specifically to the Article 50(2) machine-readable marking obligation for AI systems already placed on the market before 2 August 2026: providers of those systems have until 2 December 2026 to comply. That four-month transition comes from the EU Digital Omnibus amending the AI Act rather than from the original text of the Regulation, and it does not postpone any of the deployer-side duties. Content generated prior to 2 August 2026 carries no retroactive labelling requirement.

  1. 2 August 2026: Article 50 transparency obligations become fully enforceable across the EU; the Commission acquires Article 101 fining powers over GPAI providers.
  2. 2 December 2026: End of the grace period for pre-existing AI systems to implement Article 50(2) machine-readable marking.
  3. 2 December 2027: Deferred compliance deadline for Annex III stand-alone high-risk systems under Regulation (EU) 2026/1744.

If your production services deploy generative models today, you cannot defer implementation to the 2027 high-risk deadline. Systems in production must embed compliant technical marking now or operate under the shrinking December 2026 transitional window.

The Finalised Code of Practice on Transparency

To provide technical specificity for Article 50(2), (4), and (5), the Code of Practice on Transparency of AI-generated content has been assessed as adequate by both the European Commission and the AI Board. It has moved out of draft status, establishing a concrete compliance benchmark for engineering teams and infrastructure providers.

The Code functions as a voluntary practical tool rather than a legal finding of compliance. Providers and deployers who sign it can rely on its measures to demonstrate compliance with the marking and labelling rules, which gives them legal certainty, predictability and trust regardless of their place of establishment or competent supervisory authority. Those that decide not to adhere to the Code have to demonstrate compliance through alternative adequate means, and may be subject to more requests for information because there is less transparency on how they comply.

Under Article 99 of the AI Act, failures to meet Article 50 transparency obligations carry administrative fines of up to 15 million EUR or 3 percent of worldwide annual turnover, whichever is higher. Adopting the standard frameworks referenced in the Code of Practice is the most defensible engineering path to mitigate regulatory liability.

Evaluating C2PA, SynthID, Metadata, and Visible Labels

The Code of Practice evaluates marking mechanisms against four criteria mandated by Article 50(2): effectiveness, interoperability, robustness, and reliability. Different technical approaches offer vastly different trade-offs across these criteria, and understanding where each fails is essential before choosing an implementation.

MechanismMarking ScopeWho can verify itPrimary Failure ModeArticle 50 Target
C2PA Content CredentialsCryptographic JUMBF manifest bound to assetAny party implementing the published C2PA specification, whose trust model rests on a C2PA-managed list of X.509 certificate trust anchorsStripped by non-compliant editing tools or social media CDNsArticle 50(2)
SynthID / Neural WatermarkingImperceptible statistical perturbation in pixel/latent dataGoogle's own detection surfaces: asking Gemini about an uploaded file, or the SynthID Detector verification portalNo open verifier; third parties depend on the vendor's detectorArticle 50(2) (Supplementary)
Embedded EXIF / XMPPlaintext key-value metadata tags in file headerAny tool with a standard metadata parser, with no integrity guaranteeTrivially stripped, modified, or forged without cryptographic integrityInsufficient for 50(2)
Visible UI Badges / WatermarksPerceptible visual overlay or text captionHuman viewers only, with no programmatic pathProvides zero machine-readable detection dataArticle 50(4) Only

C2PA Content Credentials represent the primary standard that an engineering team can adopt unilaterally. A C2PA claim is a digitally signed, tamper-evident data structure bound to the asset through a content binding, and trust rests on the C2PA-managed list of X.509 certificate trust anchors that issue certificates to signers permitted to sign claims, so embedding the resulting manifest into image or video files gives independent verifiers something they can parse and validate. Proprietary watermarking schemes like SynthID embed a digital watermark directly into AI-generated images, audio, text or video, imperceptible to humans but detectable by SynthID's own technology, and detection runs through Google's own surfaces, asking Gemini about an uploaded file or the SynthID Detector verification portal, rather than through an open verifier, which is what makes them a poor fit for the interoperability criterion.

We strongly advise teams to verify what their upstream API endpoints actually return today. Generate a test asset, inspect the binary headers, and run it through a C2PA validator. In almost all cases, raw model outputs from serverless inference endpoints contain zero embedded provenance metadata, meaning the responsibility to inject C2PA manifests rests entirely on your own application backend.

Why Marking is a Pipeline Design Decision

Relying on an external model provider to inject cryptographic provenance into your outputs is an unworkable assumption. Upstream inference platforms focus on throughput, latency, and GPU kernel execution, not on managing your organisation's cryptographic signing keys or tracking prompt origins. Provenance marking must be designed directly into your application's post-processing worker layer.

This architectural reality is reinforced by data privacy boundaries. A zero data retention architecture processes requests strictly within volatile GPU memory without writing prompts or generated assets to persistent disk. That posture is self-asserted by inference platforms rather than third-party attested, and it has a direct consequence here: no upstream historical copy of the asset exists to reconstruct provenance from after the HTTP request terminates. If your application does not sign the file as it leaves your ingestion worker, that asset has no origin trail.

  1. Generation Step: Call the inference endpoint to receive the raw bitmap, PNG, or MP4 buffer into memory.
  2. Manifest Assembly: Build the C2PA claim containing model assertions, timestamp, and deployer identity in your post-processing worker.
  3. Cryptographic Signing: Sign the manifest using your private HSM or signing certificate, binding the hash of the raw pixels.
  4. Egress and Storage: Embed the JUMBF container into the final media container before uploading to your public object storage or CDN.

By positioning the C2PA injection step in your private pipeline immediately after generation, you maintain full control over certificate management, avoid exposing private keys to third-party endpoints, and ensure every published asset meets Article 50(2) standards regardless of the underlying compute engine.

Generation Cost is Not the Constraint

A common concern among infrastructure leads is that adding compliance overhead and running open-weight media models at scale will create unsustainable unit economics. In reality, raw generation costs on modern sovereign cloud infrastructure are negligible compared to the engineering effort of pipeline integration.

  • FLUX.1 Dev: $0.005 per image, catalogued in June 2026 as high-quality generation and hosted in eu-north1.
  • FLUX.2 Klein: $0.0001 per image, catalogued in June 2026 as compact and fast and hosted in eu-north1.
  • Image Ultra: $0.005 per image, catalogued in June 2026 as the fastest text-to-image with results in under one second, hosted in eu-north1.
  • Wan Image: $0.005 per image, catalogued in June 2026 as fast, efficient text-to-image and hosted in eu-north1.
  • Video Replace: $0.03/s for 720p and $0.06/s for 1080p, catalogued for video, face-swap and subject-replace and hosted in eu-north1.

Note that Video Replace is not a text-to-video model: it substitutes a face or a subject inside an existing video clip using a reference image. Because Video Replace directly modifies existing footage, assets produced by this endpoint represent classic deepfakes under Article 3(60) of the AI Act, triggering the strict Article 50(4) human-perceptible disclosure requirement whenever displayed publicly. At $0.03 to $0.06 per second of output, compute costs are low enough that teams should dedicate their budget and architecture toward robust post-processing compliance rather than attempting to cut corners on generation.

Deploying Compliant Media on Serverless Inference

To build a reliable, compliant media architecture, developers need direct access to open models on European infrastructure without the operational burden of managing cold starts, driver versions, or idle cluster costs. Serverless Inference provides pre-hosted generative media models behind an OpenAI-compatible API, so engineering teams can route generation calls by changing the base URL and the model string in existing client code.

Your application interacts with the media endpoints using standard HTTPS calls, receiving the raw generated buffers directly into your backend service: POST https://api.lyceum.technology/api/v2/external/images/generations for image models, and the parallel /api/v2/external/videos/generations path on the same host for video workloads. Once your worker receives the response, it executes your local C2PA signing routine before serving the asset downstream.

  • Serverless Architecture: Pay strictly per image generated or per second of video rendered, with zero baseline infrastructure fees.
  • European Data Residency: Media generation runs across European data centres in Paris and Finland under EU data residency standards.
  • Operational Availability: Serverless Inference carries no SLA, availability tier, or uptime target; live platform status is published on the public status page, which is an availability pointer and never a compliance answer.

By combining Lyceum Serverless Inference for raw compute with an internal post-processing worker for C2PA injection, engineering teams achieve a robust, cost-effective pipeline that fully satisfies the dual transparency requirements of Article 50.