EU AI Act Article 50 Is Live: A Product Launch Matrix for AI App Founders
A practical way to map chatbot notices, machine-readable marks, deepfake labels, public-interest text, ownership, and launch evidence under Article 50.
Article 50 of the EU AI Act starts applying today, August 2, 2026. It covers four different transparency situations: direct interaction with an AI system, machine-readable marking of synthetic content, exposure to emotion recognition or biometric categorisation, and disclosure of certain deepfakes or public-interest text. The European Commission published final guidance shortly before the date and a voluntary Code of Practice for some marking and labelling duties.
This matters to an AI app founder even when the app uses someone else's model. A team can be a provider of the customer-facing AI system, a deployer of a third-party system, or both in different parts of the same workflow. Buying an API does not automatically transfer every product-level transparency decision to the model vendor.
The useful response is not to paste “Made with AI” everywhere. It is to inventory each user-facing surface, identify the legal role and content path, connect the applicable duty to a named owner, and test whether the notice or mark survives the way users actually encounter the output. This guide provides that launch matrix, a hypothetical product walkthrough, a reusable disclosure receipt, failure tests, and a 48-hour triage plan. It is product-operating guidance, not legal advice; material scope decisions should be reviewed by qualified EU counsel.
What changed today—and what did not
The European Commission's final Article 50 guidelines say the obligations apply from August 2, 2026. The underlying duties are not a new universal rule that every AI-assisted sentence or image must carry the same visible badge. They are four scoped duties with different responsible actors, exceptions, and delivery mechanisms.
There is one narrow timing qualification. Regulation (EU) 2026/1744, the Digital Omnibus on AI, gives providers of generative systems placed on the market before August 2, 2026 until December 2, 2026 to comply with Article 50(2), the machine-readable marking and detectability duty. It does not postpone all of Article 50. The Commission also says content generated and already made available before August 2 does not need retroactive labelling.
Three tempting interpretations are therefore wrong:
- “The whole AI Act was delayed.” The limited four-month transition concerns existing systems and Article 50(2), not every transparency duty.
- “Only foundation-model companies are responsible.” An app company can become the provider of its own named system and may also be a deployer when it uses AI professionally under its authority.
- “One watermark solves Article 50.” A machine-readable provider mark and a clear human-facing deployer disclosure perform different jobs.
Define provider, deployer, output, and exposure
In this context, a provider is the person or organisation that develops an AI system—or has one developed—and places it on the EU market or puts it into service under its own name or trademark. A company outside the EU can still be in scope when its system's output is used in the EU. The Commission's Article 50 questions and answers gives chatbots, AI agents, and avatars as examples of directly interactive systems.
A deployer uses an AI system under its authority for a professional purpose. Employees and contractors acting under a company's control do not each become separate deployers; the legal person remains the deployer. Purely personal, non-professional activity is excluded, while regular economic activity can make an individual a deployer.
An output is the synthetic or manipulated audio, image, video, or text produced by a system. Not every internal intermediate needs the same treatment. The Commission says source code, short sequences of symbols, exclusively machine-to-machine outputs, and non-final material in some closed development environments can fall outside the Article 50(2) marking duty. Standard editing that does not substantially change input or meaning also has an exception.
Exposure is when a natural person encounters the relevant interaction, system, or content. Article 50(5) says required information must be clear, distinguishable, accessible, and provided no later than first interaction or exposure. A disclosure hidden in terms accepted months earlier is not equivalent to a notice at the relevant moment.These are legal classifications, not UI labels. Record your factual assumptions and ask counsel to confirm borderline cases instead of having a product manager silently decide them in a design file.
Map the four obligations before designing a notice
The operative Article 50 text separates the duties. A founder-facing summary looks like this:
| Product situation | Primary duty holder | Product duty | Important boundary |
|---|---|---|---|
| AI system directly interacts with a person | Provider | Design the system so the person is informed they are interacting with AI | Exception where interaction is obvious, interpreted restrictively |
| System generates synthetic audio, image, video, or text | Provider | Add effective, interoperable, robust, reliable machine-readable marks and enable detectability where technically feasible | Standard editing and other scoped exclusions; limited transition for pre-August 2 systems |
| Emotion recognition or biometric categorisation exposes a person | Deployer | Inform exposed people that the system operates | Other data-protection and prohibited-practice rules may also apply |
| Deepfake, or certain AI-generated public-interest text, reaches people | Deployer | Make a clear human-perceivable disclosure | Creative-work treatment and human-review/editorial-responsibility exception are specific, not blanket |
“Primary duty holder” does not mean “only team that needs a control.” A downstream app builder may need vendor evidence to know whether a provider mark exists and survives transformation. A model provider cannot place the correct visible label in every customer's publishing context. The handoff between them is part of the product design.
The matrix also prevents category errors. A chatbot notice is not the same as synthetic-content metadata. A Content Credential is not automatically a visible deepfake disclosure. An editorial approval checkbox is not necessarily substantive human review.
Inventory surfaces, not just models
One model call can feed several legally and operationally distinct surfaces. Inventory each path from generation to first exposure and supported export. A useful row contains:
- product, feature, and surface;
- intended EU audience and professional context;
- system provider and deployer;
- whether a person directly interacts with the AI;
- output modalities;
- whether output depicts or resembles a real person, object, place, entity, or event;
- whether published text informs the public on a matter of public interest;
- human review, editorial control, and legal responsibility;
- provider marking capability and downstream transformations;
- notice or label location, timing, language, and accessibility;
- evidence owner, review date, and unresolved questions.
Treat each material path as its own launch unit. “We use Model X” is not an inventory.
Decide when an AI interaction is truly obvious
Article 50(1) does not require a separate notice where AI interaction is obvious to a reasonably well-informed, observant, and circumspect person in context. The Commission says the exception should be interpreted restrictively. Product teams should not translate “our brand name sounds futuristic” into “everyone knows.”
Test the first 30 seconds of every entry path with people who did not design the product:
- Can they tell whether the reply comes from a human, a scripted automation, or an AI system?
- Does the answer change on mobile, voice, embedded chat, messaging integration, or human handoff?
- If an agent uses a human avatar, name, or typing indicator, does the presentation weaken the obviousness claim?
- Does a returning user see the relevant information when the context has changed?
- Is the notice available before the person shares sensitive information or relies on advice?
The notice also needs to be accessible. Article 50(5) points to applicable accessibility requirements; WCAG 2.2 is a useful product test reference for perceivable text alternatives, contrast, keyboard access, focus order, and status communication, although the applicable legal accessibility regime depends on the product.
Separate machine-readable marking from visible disclosure
Article 50 deliberately creates two layers. Under paragraph 2, the provider of a generative system is responsible for machine-readable marking and detectability. Under paragraph 4, a deployer publishing an in-scope deepfake or public-interest text must disclose it clearly to people.
The Commission's Q&A explicitly says a deployer cannot rely only on the provider's embedded machine-readable mark to satisfy the human-facing deepfake disclosure. Conversely, a visible “AI-generated” pill does not establish that the provider met the marking duty for synthetic outputs.
For each content path, store evidence for both layers:
| Layer | Question | Evidence |
|---|---|---|
| Provider mark | Does the original output contain a machine-readable signal? | Vendor documentation, sample artifact, detector result, model/version |
| Transformation survival | Does resizing, transcoding, editing, screenshotting, or copy/paste preserve it? | Test corpus and transformation log |
| Visible disclosure | Can a person perceive and understand the disclosure at first exposure? | Screenshot/audio capture, locale, viewport, accessibility result |
| Export disclosure | Does supported sharing retain or recreate the notice? | Export fixtures for download, embed, email, social preview, API |
| Failure behavior | What happens if marking or labelling cannot be applied? | Block, hold, retry, alternate format, or explicit product limitation |
The C2PA technical specification offers one way to carry signed provenance assertions, and its UX guidance recommends a persistent indicator plus deeper inspection. C2PA is relevant engineering evidence, not a legal guarantee and not proof that the depicted claim is true.
Classify deepfakes by resemblance and context
Article 50 defines a deepfake more narrowly than “any AI image.” The content must be AI-generated or manipulated image, audio, or video; resemble existing persons, objects, places, entities, or events; and falsely appear authentic or truthful to a person.
The Commission's Q&A turns that into three cumulative questions: sufficient resemblance, an existing or plausibly existing subject, and a false appearance of authenticity or truthfulness. It says intended and foreseeable deployment contexts, audience expectations, and the content's message can matter.
That means a clearly fictional game character is not automatically treated like an invented video of a real executive announcing layoffs. Background effects in a movie are not automatically treated like a fake recording presented as security footage. But “creative” is not a magic word. When deepfake content is part of an evidently artistic, creative, satirical, fictional, or analogous work, Article 50 still calls for an appropriate disclosure that does not hamper enjoyment.
The EU has published optional AI-content icons. Its own user testing found performance improved when the basic icon was paired with a text label. That supports a broader product lesson: use words that explain what changed. “Voice generated with AI” is more actionable than an unfamiliar symbol alone.
Treat public-interest text review as an accountable process
Article 50(4) also covers AI-generated or manipulated text published to inform the public on matters of public interest. The Commission lists politics, public administration, justice, rights, public security, health, environmental protection, consumer safety, and economic, financial, scientific, or cultural developments that may be part of public debate.
There is an exception where the content underwent human review or editorial control and a natural or legal person holds editorial responsibility. The Commission says review must deliberately examine substance using relevant knowledge and professional judgment. Spell-checking, grammatical correction, or a procedural click is not enough. Editorial control means real authority to approve, alter, or reject the substance, including fact-checking and source trustworthiness; editorial responsibility means ultimate legal responsibility for publication.
If your app auto-publishes public-health explainers, market updates, election summaries, safety alerts, or scientific news, “a founder glances at the queue” is not a defensible operating description. Define:
- who is qualified to review each topic;
- what sources and claims they inspect;
- whether they can reject or rewrite the output;
- how the decision is recorded;
- who accepts legal responsibility for publication;
- what happens when no qualified reviewer is available.
Walk through one small-team scenario
Consider a hypothetical two-person startup called CivicBrief. It offers three features to EU municipalities: a resident chatbot, automatically narrated video updates, and draft public notices summarising council documents. The startup uses third-party language, voice, and video APIs under its own product name.
For the resident chatbot, CivicBrief may be the provider of the directly interactive product even though it did not train the underlying model. It places a clear AI notice at the first interaction, repeats state changes during human handoff, and tests the embedded and voice versions separately.
For a video in which an AI-generated mayor-like avatar describes a real road closure, the team flags a likely deepfake analysis because the content resembles a real person and event and could appear authentic. It keeps the provider's machine-readable marks, places a visible and spoken disclosure at first exposure, and repeats a concise label in exports. It does not claim that metadata alone satisfies the deployer duty.
For draft council summaries, nothing is published automatically. A communications officer with subject knowledge checks the source documents, corrections, omissions, and material claims; can reject the draft; and is the municipality's authorised editorial owner. CivicBrief records that workflow. Whether the exception applies is a legal conclusion for the specific arrangement, but the product now produces evidence that counsel can assess.
Finally, the team runs a crop-and-share test. The first mobile social preview removes the visible video label. That is a launch blocker for that export path. CivicBrief changes the renderer to burn in an accessible disclosure and refuses exports when the disclosure service fails. This is the difference between a policy page and an operating control.
Create an Article 50 disclosure receipt
Store a versioned receipt for each material surface. This is a product artifact, not an official EU template:
surface_id: civicbrief-public-update-video
reviewed_at: 2026-08-02
eu_audience: true
roles:
system_provider: CivicBrief
model_provider: third-party-video-api
deployer: municipality-customer
article_50_paths:
direct_interaction: false
synthetic_output: video_audio
emotion_or_biometric_exposure: false
potential_deepfake: true
public_interest_text: false
provider_marking:
method: vendor-documented-machine-readable-mark
version: pending-vendor-evidence
transformation_tests: [download, transcode, crop, social-preview]
human_disclosure:
first_exposure: visible-and-spoken
export: burned-in-visible-label
locales: [en, de, fr]
accessibility_test: pending
exceptions_relied_on: []
owners:
product: founder
engineering: contractor-name
legal_scope: external-eu-counsel
failure_mode: block-export
evidence_links: []
open_questions:
- detector performance after social-platform recompression
decision: hold
The receipt forces useful honesty. “Pending vendor evidence” is visible. A product cannot quietly turn an unknown mark into a passed control. The decision can move from hold to limited pilot or ship only when required evidence exists and the named reviewer accepts it.
Run six failure tests before release
First-interaction test
Open every supported entry point with a fresh account. Confirm the AI-interaction notice appears at the correct time and remains understandable without relying on terms or marketing knowledge.
Mark-preservation test
Generate a harmless corpus across every modality, then apply supported transformations: edit, resize, transcode, copy, export, and recompress. Record which machine-readable signals survive. Never claim universal detection from a small test.
First-exposure label test
Show the actual page, video, audio, or publication to unfamiliar testers. Ask what was generated or manipulated. Test every launch language and assistive-technology path in scope.
Context-loss test
Download, embed, screenshot, forward, and render a social preview. If the disclosure disappears on a supported path, recreate it or constrain that path. You cannot prevent every hostile crop; you can make the normal product path responsible.
Editorial-substance test
Seed a draft public-interest text with a harmless wrong date, unsupported causal claim, and omitted limitation. Confirm the reviewer finds them, has sources, and can stop publication. A grammar-only review should fail.
Control-failure test
Simulate an unavailable marking, labelling, or rendering service. The product should block, hold, retry safely, or use an approved fallback. Silent publication is not graceful degradation.
Avoid five common failure modes
Universal badge logic. Labelling everything identically confuses chatbot interaction, provider marking, deepfake disclosure, and editorial review. Map the duty first. Vendor checkbox logic. A vendor saying “supports watermarking” is not evidence about the exact model, version, format, transformation path, or detectable result in your product. Metadata-only disclosure. Machine-readable provenance may help tools, but paragraph 4 disclosure must be understandable and perceivable without special tools where it applies. Review theatre. A human click without subject knowledge, source checking, rejection authority, and accountable ownership should not be treated as substantive editorial review. Grace-period overreach. The December 2 transition is limited to Article 50(2) for systems placed on the market before August 2. It is not permission to postpone chatbot notices, deepfake disclosure, or every new product decision.The Commission's Code of Practice is voluntary but has been assessed as an adequate compliance tool for the marking and labelling obligations it covers. Teams that do not sign can use other adequate means, but should expect to demonstrate them. Signing is not a substitute for implementing and testing the commitments.
Choose ship, limit, hold, or remove
Use a decision matrix rather than a single compliance checkbox:
| Decision | Conditions |
|---|---|
| Ship | Role and scope are reviewed; required notices/marks/labels work across normal paths; owners and evidence are complete; failure mode is safe |
| Limited pilot | Core path works, but a nonessential export, locale, or vendor-evidence question remains; access and outputs are constrained accordingly |
| Hold | Required scope is unclear, provider evidence is missing, first-exposure disclosure fails, or editorial responsibility is nominal |
| Remove feature/path | A necessary disclosure cannot survive the product context, or the team cannot staff the required review and responsibility |
Not every AI app needs every row. A private code helper that produces source code has a different Article 50 analysis from a public avatar, emotion-recognition kiosk, or auto-published health newsletter. Article 50 also does not replace privacy, consumer protection, intellectual-property, sector safety, accessibility, employment, or high-risk-system obligations.
The regulation provides substantial penalties for certain non-compliance, while requiring proportionality and attention to SMEs and startups. Do not use a maximum fine as clickbait or as a substitute for scope analysis. Use it as one reason to assign qualified ownership and preserve evidence.
A 48-hour founder action plan
Hours 0–4: freeze assumptions. Name every EU-facing AI interaction, synthetic-output feature, emotion/biometric feature, deepfake-like output, and public-interest publishing path. Record what is unknown. Hours 4–12: assign roles. For each surface, identify system provider, model provider, deployer, product owner, engineering owner, and legal reviewer. Ask vendors for marking documentation, supported formats, versions, detector access, and transformation limitations. Hours 12–24: patch obvious gaps. Add clear first-interaction notices, remove misleading human presentation, stop unsupported auto-publishing, and block exports whose disclosure disappears. Do not wait for a perfect compliance programme to close a known product gap. Hours 24–36: run the six tests. Save screenshots, audio, generated fixtures, detector results, reviewer decisions, and failure logs. Test production-like paths, not a design mockup. Hours 36–48: decide and document. Have qualified counsel confirm material role, scope, and exception decisions. Mark each path ship, limited pilot, hold, or remove. Set a review date for model, vendor, format, workflow, and legal changes.The outcome is not a larger policy document. It is a smaller, inspectable product surface with a known owner, a visible user experience, a safe failure mode, and evidence that matches the claim.
What this framework cannot decide
This framework cannot determine whether your specific company is legally a provider or deployer, whether a particular output is a deepfake, whether text concerns a matter of public interest, whether review qualifies for an exception, or which accessibility and sector rules apply. Those answers depend on facts, contracts, audience, control, jurisdiction, and current law.
It also cannot prove that a mark is universally robust. Detection techniques have false positives, false negatives, format limitations, and transformation failure modes. Preserve provider documentation and your own bounded test results without turning either into a universal claim.
Finally, transparency is not truth. A correctly labelled synthetic video can still defame someone. A marked financial summary can still be wrong. A disclosed chatbot can still collect excessive data or give harmful advice. Article 50 creates a visibility layer; product safety, evidence quality, privacy, authorization, and human accountability still need their own controls.
The founder judgment
Article 50 is best treated as a product-routing problem. Every AI interaction or output needs to reach the correct transparency control based on role, modality, context, audience, review, and exposure—not a generic badge based only on the model used.
For a small team, the minimum credible operating system is straightforward: inventory surfaces, distinguish provider from deployer duties, preserve machine-readable marks, add human-facing disclosures where required, make editorial review substantive, test normal context loss, fail closed, and keep a versioned receipt. When the scope is uncertain, limit the feature and obtain qualified advice rather than converting ambiguity into an undocumented launch decision.
References
- Regulation (EU) 2024/1689, official AI Act text
- Regulation (EU) 2026/1744, Digital Omnibus on AI
- European Commission, final guidelines on Article 50 transparency obligations
- European Commission, Article 50 questions and answers
- AI Act Service Desk, Article 50 text and relevant recitals
- European Commission, Code of Practice on Transparency of AI-Generated Content
- European Commission, Quick Facts: Transparency rules for AI systems
- European Commission, EU icons for labelling AI-generated content
- C2PA Technical Specification 2.2
- C2PA User Experience Guidance 2.2
- W3C, Web Content Accessibility Guidelines 2.2