AI Act Article 50: What It Means for the AI Features in Your App

Your app probably picked up an AI feature in 2025: a support assistant, a button that generates an image, a summary at the top of a long record. AI Act Article 50 is the part of the EU AI Act that decides what you owe the people using those features, and it has applied since August 2, 2026. If your app is used in the EU and its assistant never tells people it is an AI, that gap is three months old.

Article 50 is a transparency rule, not a ban. It asks for two things an engineer can build: tell people when they are dealing with an AI, and mark what the AI generates so it can be detected.

What AI Act Article 50 requires, paragraph by paragraph

Article 50 of Regulation (EU) 2024/1689 splits its duties between providers (who develop an AI system and offer it under their name) and deployers (who use one under their own authority). In plain terms, following the Commission's Service Desk text and guidelines:

• 50(1), providers: a system meant to interact directly with people must be designed so they are told they are dealing with an AI, unless that is obvious to a reasonably well-informed, observant and circumspect person.
• 50(2), providers: a system that generates synthetic audio, images, video or text must mark its output in a machine-readable format, detectable as artificially generated or manipulated. The marking must be effective, interoperable, robust and reliable as far as technically feasible. Assistive functions for standard editing, and output that does not substantially alter the input or its meaning, are exempt.
• 50(3), deployers: anyone using emotion recognition or biometric categorisation must inform the people exposed to it and comply with data protection law.
• 50(4), deployers: disclose deepfakes (with a lighter duty for evidently artistic, creative or satirical work), and disclose AI-generated or manipulated text published to inform the public on matters of public interest, unless a human reviewed it and someone holds editorial responsibility.
• 50(5): the information must be clear and distinguishable, and given at the latest at the first interaction or exposure.

Paragraph 7 covers codes of practice. The Code of Practice on Transparency of AI-Generated Content, published on June 10, 2026, is voluntary, but it is the clearest description of what "marked and detectable" means, so we lean on it below.

AI Act Service Desk: Article 50, transparency obligations

The dates after the Digital Omnibus

The Digital Omnibus, Regulation (EU) 2026/1744, was published in the Official Journal on July 24, 2026 and entered into force on July 27, 2026. For Article 50, very little moved:

• August 2, 2026: Article 50 applies to every system in scope, whenever it was placed on the market. Paragraphs 1, 3 and 4 have been due since that day, for new and existing apps alike.
• December 2, 2026: the one grace period. Providers of generative systems already on the market before August 2, 2026 have until this date for the marking and detection duty in 50(2), and for nothing else. A feature that both chats and generates gets the extra time for the marking only.
• No grace for new features: a generative feature first launched on or after August 2, 2026 must mark its output from launch.
• February 2, 2027: the Code's target for interoperable watermark detection, for its signatories.

Content generated or published before August 2, 2026 needs no retroactive marking or labelling. One exception: public-interest text generated earlier but published on or after that date must be labelled.

Provider or deployer: where an app that calls a model API sits

Most apps we build do not train models. They call a hosted model or Apple's on-device one. So is Article 50 the model vendor's problem?

The guidelines define a provider as whoever develops an AI system, or has it developed, and places it on the EU market or puts it into service under its own name or trademark, paid or free. Their own example is a company offering a chatbot, image generator or AI agent to consumers under its own name. That company is the provider for 50(1) and 50(2), wherever it is established.

The guidelines do not mention an app that calls a model API. Our inference, not a Commission statement: an app shipping an assistant under its own brand passes the own-name test and is the provider, even though someone else's model powers it. We also read an app on EU storefronts as placed on the Union market. No example in the guidelines settles either point.

EU storefronts also decide which of Apple's new EU terms apply to you.

Apple's new EU App Store terms: which distribution route fits your app

Two things soften this. First, you may rely on an upstream model provider's marking, provided it complies with 50(2); the Code says the same. Second, that reliance is "without prejudice" to your own responsibility to demonstrate compliance. The vendor's marking can be your implementation. It cannot be your excuse.

Deployer duties (50(3) and 50(4)) fall on whoever decides the purposes and manner of a system's use. In our reading an app can hold both roles: provider of its assistant, deployer when it publishes that assistant's output.

Nor can you assume the vendor has it covered. Article 50 does not bind general-purpose models directly; model providers are only encouraged to mark at model level. We could not confirm from vendor documentation what OpenAI, Anthropic or Apple mark in API output, so we make no claim about it. Ask each vendor in writing, and if you route between vendors, track the answer per provider.

Multi-provider AI architecture for apps: don't marry one model vendor

Feature by feature

A chatbot or assistant

This is 50(1): tell users they are talking to an AI, clearly, at the latest at first interaction. The "obvious" exception is read restrictively. The guidelines name helpdesk chatbots whose replies could pass as human as not exempt, along with companion products and human-like avatars.

Not enough: a line in the terms, a general "Services on this website use AI", or a machine-readable mark alone. One notice before the first interaction is likely enough in most cases, with reminders in risky contexts such as health, finance, minors and companions. The exempt examples are narrow: coding assistants for professional developers, internal staff assistants (relevant to internal business apps), and single-player game characters.

Generated images, audio and video

This is 50(2). Output must carry machine-readable marking that detection tools can find. The guidelines accept watermarks, metadata, cryptographic provenance, logging or fingerprints, alone or combined. Marking with no way to detect it does not suffice.

Code signatories use at least two layers: digitally signed, time-stamped metadata plus an imperceptible watermark. Editing features count too: object removal or insertion, face replacement and realistic voice cloning need marking, while minor crops and colour edits do not. If your app then publishes a realistic deepfake, 50(4) adds a visible disclosure on top.

Generated text and AI summaries

Text is where the duties split most, and where "label your AI content" goes wrong:

• Marking under 50(2): the guidelines list AI-generated summaries as needing marking, because a summary changes meaning. So does rewriting that changes style, structure or meaning. Grammar and spelling correction, minor polish and AI translation are assistive editing and exempt.
• Out of scope for marking: very short output (single words, captions, alt text, UI labels), source code, and extraction or ranking without summarising.
• In the Code, text carries a watermark only (it cannot hold metadata), and text under 200 tokens is excepted. Our reading: the watermark is embedded at generation, so for a hosted model it depends on the vendor.
• Visible labelling under 50(4) applies only to text published to inform the public on matters of public interest. An AI summary shown only to the user who asked for it is not covered. An AI summary of a town-council story on a newspaper site is, unless a human reviewed it (fact-checking at minimum) and someone holds editorial responsibility.

Voice and emotion features

A voice assistant interacts with people, so 50(1) applies. On a voice-only surface, in our reading, the disclosure has to be spoken. Generated or cloned speech is synthetic audio under 50(2), and realistic voice cloning is named as needing marking. If a feature infers emotion from a voice or a face, or categorises people biometrically, 50(3) requires telling the people exposed and complying with data protection law. That is a deployer duty with no grace period.

What it means in your app's code and UI

None of this needs a new architecture. It needs three things you can plan into a sprint:

1. A visible disclosure where the conversation starts ("You're chatting with an AI assistant"), not in settings. Record that it was shown, per user and app version.
2. A provenance record per output: human, AI-edited or AI-generated, and by which model. Without it you cannot decide what needs marking or labelling.
3. A marking pipeline you can evidence. For images and audio, check upstream marking survives your processing (re-encoding can drop metadata), or add your own. For text, keep the vendor's watermark documentation on file.

The provenance record is the piece most apps lack. Here is our own illustrative starting point, not an SDK API, with a rule deliberately simpler than the guidelines:

// Illustrative only: our own type, not an SDK.
enum OutputProvenance: Codable, Sendable {
    case human
    case assistiveEdit   // spelling, translation
    case generatedText(model: String, tokens: Int)
    case generatedMedia(model: String)
}

extension OutputProvenance {
    /// Simplified: ignores UI labels, code, etc.
    var needsMachineMarking: Bool {
        switch self {
        case .human, .assistiveEdit:
            return false
        case .generatedText(_, let tokens):
            return tokens >= 200
        case .generatedMedia:
            return true
        }
    }
}

The real rules have more branches (captions, source code, public-interest publication), but a type like this makes each one a switch you can test. Disclosure logs and provenance records belong in the same security review as the rest of your app's data.

The security of iOS apps for businesses

Penalties

Breaches of Article 50 fall under Article 99(4): fines up to €15,000,000 or 3% of total worldwide annual turnover for the preceding year, whichever is higher. For SMEs and start-ups it is whichever is lower. The guidelines confirm both the amounts and the SME rule.

Enforcement sits with national market surveillance authorities, on their own initiative or after anyone's complaint, and with the AI Office where a system is built on the same provider's general-purpose model. We found no fine under Article 50 to point to, and we could not confirm which authority each member state has designated.

What is still unclear

• Whether a thin wrapper is its own AI system. The provider reading above is our inference from the own-name test; no example in the guidelines settles it.
• What the vendors mark, and whether a regulator would accept an app relying on it. For Apple's on-device Foundation Models we found nothing at all.
• Whether a text watermark survives what happens next in an app (copying, editing, trimming). Nothing we could source addresses mobile clients.
• The exact wording. EUR-Lex could not be fetched during our research, so our paraphrase follows the Commission's pages. Read the regulation before relying on a phrase.

European Commission: Guidelines on the transparency obligations of providers and deployers of AI systems

A checklist for Article 50

1. List every AI feature and tag each: interacts with people, generates content, reads emotion or biometrics, publishes text publicly.
2. For every interactive feature, check there is a visible AI disclosure at or before first interaction. If there is not, ship one now: it has been due since August 2, 2026.
3. For every generative feature, note when it launched. Before August 2, 2026: marking is due by December 2, 2026. On or after: it is due already.
4. Ask each model vendor, in writing, what they mark, in which outputs and through which API, and how it can be detected. File the answer, and check your own pipeline does not strip it.
5. Decide which text is published to the public on matters of public interest. Private summaries are not; a news-style summary on a public page is, unless a named person reviews it.
6. Add a provenance record per output and a log of the disclosures shown.
7. Write down which role you believe you hold for each feature, and why, and have counsel read it.

For most apps, Article 50 comes down to one sentence of interface copy and one pipeline question. The sentence was due in August. The pipeline question is due December 2, 2026 for generative features already live, and at launch for anything new. Relying on upstream marking is allowed, but the responsibility stays with you.