Article 50 applies on 2 August 2026, and your model vendor cannot carry it for you

I spent an evening reading all 51 pages of the Commission's new Article 50 guidelines, which is not how I planned to spend it 1. They were adopted on 20 July, thirteen days before the rules they explain started to apply 2. One paragraph in the middle settles an argument I have had with three different founders this year, and it does not settle it the way any of us wanted.

Here is the short version. If your product has an AI feature, the law treats you as the one who has to tell users about it, even though the model belongs to OpenAI or Anthropic or Mistral. You are allowed to use whatever those vendors build to help you comply. You are not allowed to point at them when a regulator asks whether you did.

What applies since 2 August 2026?

Five rules, all of them in Article 50 itself 6. The first two sit on providers, the companies that ship an AI system. The next two sit on deployers, the companies that use one. A SaaS company running its own AI feature wears both hats, and most are caught by two or three of the five.

• Tell users when they are talking to an AI. Chat, a support assistant, a voice agent, anything conversational. Article 50(1), a provider duty.
• Mark generated content so a machine can detect it. Synthetic text, images, audio, video. Article 50(2), also on the provider. This is the only one that needs engineering rather than copy.
• Tell people when you are reading emotions or sorting them by biometric traits. Article 50(3), a deployer duty. Rare in B2B SaaS, but if you score sentiment from faces or voices, it is you.
• Label AI-written text you publish on matters of public interest, and label deepfakes. Article 50(4), also a deployer duty.
• Deliver all of it clearly, at the first interaction. Not in a policy page someone opens three clicks later. Article 50(5).

There is an escape hatch in Article 50(1), and someone on your team will find it: the duty falls away when it is obvious to a reasonably well-informed person that they are dealing with an AI. The guidelines say that test "should be interpreted restrictively" 1. Six experiments with 4,600 participants by Jakesch, Hancock and Naaman found that people cannot reliably spot AI-generated text, and that the cues they trust misfire badly enough for machine text to read as more human than human. Do not build on it.

You may have read in June that the EU delayed the AI Act. That was real 4, and it was a different part of the law: the rules for high-risk uses such as hiring and credit scoring moved to December 2027. Article 50 was never a high-risk rule, so there was nothing in it to delay.

One narrow piece of timing relief exists, in Regulation (EU) 2026/1744. If your AI feature was already live before 2 August 2026, you have until 2 December 2026 for the content-marking rule, and only that one 3, 7. Anything that went live after 2 August gets no grace period. Old output is not dragged back in either, though labelling attaches at publication rather than generation, so text written in July and published in August still needs a label 1.

If we call someone else's model, whose marking is it?

Yours. I will show the work, because the opposite answer is so widely believed.

The reasoning I keep hearing goes: we call an API, the model is theirs, the generation runs on their hardware, so the marking is theirs. The definition does not work that way. Article 3(3) says a provider is whoever develops an AI system and puts it on the market "under its own name or trademark" 6. Your product ships under your name, which makes you the provider of your AI feature. Your vendor is the provider of the model underneath it. Different things, different duties. Nor does it matter where you sit: the guidelines catch a provider offering an AI feature on the Union market "regardless of whether the provider is established or located in the Union or in a third country" 1.

I want to be careful here, because the guidelines are thinner on this point than most write-ups pretend. Their worked example of becoming a provider by modifying someone else's system is retraining it on new data, and they never squarely address a product that wraps a vendor's API without touching the model 1. It is the Act itself that closes the gap. Article 3(68) defines a downstream provider as a company whose AI system integrates an AI model, and says it makes no difference whether that model is your own or supplied by another entity under contract 6. An API agreement is that contract. The guidelines use the same frame when they discuss general-purpose models, and speak of compliance "by downstream AI system providers with their obligations under Article 50(1) and (2) AI Act" 1. The duty sits with the company that built the feature, not the company that trained the model.

Then paragraph 74, which is the sentence this whole post is about. You may rely on marking your model vendor has implemented, "to the extent that the marking solution is compliant with Article 50(2)". The next sentence: "Such reliance is without prejudice to the responsibility of the provider of the AI system to demonstrate compliance with Article 50(2) AI Act." 1

So when a regulator asks how you comply, "our model vendor handles it" is not an answer, because proving it was never their job. You have to show that marking survives your product, end to end. A test that generates an image, runs it through your resizer and your PDF export, and checks the marker is still there is worth more than any assurance in a vendor's documentation. The assurance has a known ceiling anyway: Zhang and colleagues' "Watermarks in the Sand", presented at ICML 2024, proved that a watermark an attacker cannot strip without wrecking output quality is impossible under natural assumptions, and demonstrated it on three existing schemes.

Does a smaller team get a smaller obligation?

No, and the guidelines close that door explicitly. Paragraph 81: technical feasibility "is an objective notion that is not dependent on the specific resources and capabilities of individual providers." 1

You do not get a lighter duty for the same content type because you are eight people and your competitor is eight hundred. Harsh, and also the only version that works, because the alternative is a rule whose strength depends on the balance sheet of whoever generated the image. The one concession is that nobody can require you to use a technique that does not exist yet.

If you have no in-house view on watermarking, the Code of Practice on Transparency of AI-generated Content, published 10 June 2026, is the shortcut. The Commission has confirmed it as an adequate voluntary tool for demonstrating compliance 5, so signatories argue from a recognised baseline instead of from first principles. It is not a shield: recital 41 of Regulation (EU) 2026/1744 says these codes grant no presumption of conformity 7. For the questions the guidelines leave open, the Commission's AI Act Service Desk takes them directly, answered by a team working with the AI Office.

Is there a way out for an internal or B2B tool?

There is, and it is narrower than it sounds. Paragraph 87 exempts some industrial and business-to-business tools from marking 1, but all three of these have to be true at once:

1. The output is strictly technical: engineering designs, production workflows, technical instructions, predictive maintenance output, internal documentation before it is finalised.
2. Only a limited, pre-defined group of people read it, acting professionally, inside your company and your customer's.
3. It is not meant to leave the company at all, and you have controls that stop it.

If your tool drafts something an account manager later pastes into a customer email, condition three is gone and so is the exemption. The guidelines do call this a carve-out for "business to business applications" 1, so a B2B product whose output genuinely stays inside those walls can qualify. In practice condition three decides it, and for most SaaS products the whole point of the output is that it travels.

What does an AI agent have to disclose?

Two things: its artificial nature, and the person on whose behalf it is acting. The second half is missing from most implementations I have looked at. An agent that books, negotiates, buys or manages correspondence has to say whose authority it is carrying.

Paragraph 31 handles the case that makes this hard to build. You often cannot know in advance whether an agent will meet a human, so the disclosure belongs in the architecture rather than at each call site, and it fires whenever a human interaction is reasonably likely 1. Agents should also identify themselves to the people instructing them, at authorisation, validation and reporting. Not once at onboarding.

What happens if you get it wrong?

Transparency breaches sit in the middle penalty tier: up to EUR 15 000 000 or 3% of worldwide annual turnover, whichever is higher, under Article 99(4). The write-ups I have read stop there. Article 99(6) then inverts the test for SMEs and startups, who face whichever of the two is lower 6. The simplification package touched Article 99 around the edges but left both the transparency tier and the SME rule standing 7. If you are a twenty-person company, the headline number is not your number. Either way it is a statutory ceiling, not a forecast of what an authority would do to a company that made a serious attempt.

What do you actually have to do now?

The deadline has passed, so if anything on this list is still open it is not preparation any more, it is catch-up. The work itself is the same, and it depends on the shape of your product.

You ship a chat or assistant surface. Put the disclosure in the surface itself, at the first interaction, before the user types anything. Then check it actually renders in every place that surface appears: the widget, the mobile view, the version embedded in a customer's app, the email your bot replies from. That last one is where I keep finding it missing.

Your product generates content a user can export. The one with real work in it. Take a generated file, run it through every transform you own, and check the marker survives: resize, re-encode, thumbnail, PDF export, CDN. The guidelines define robustness as accuracy "under varying conditions, covering both common alterations and adversarial attacks" 1. They never name a screenshot, and I would treat one as a common alteration anyway. Then make it a test that runs in CI, because a passing test is what you can hand a regulator.

You publish AI-drafted text on your own site. The labelling duty in Article 50(4) is narrower than most checklists admit: it covers text published to inform the public on matters of public interest, which the guidelines read as topics that concern society at large, such as public health, consumer safety or public administration 1. A changelog, a release note or a status page update will rarely meet that bar. Where a piece of text does cross it, a security advisory that a lot of people depend on might, you have two options and you have to pick one per content type: a named person who reads it and takes editorial responsibility, or a label saying it was AI-written. An approval nobody owns is the version that fails.

You ship an agent that acts for a user. Two disclosures rather than one, both at every new interaction: that it is artificial, and whose authority it carries.

If your AI is internal tooling and nothing else, work through paragraph 87's three conditions before you decide you are out. And if you only have room for one of these, do the export one. It is the only one that needs code rather than copy.

What are we changing at Lawcel?

Lawcel is a compliance platform that watches a company's product changes and flags the ones that contradict its published legal documents. That makes us a SaaS company with AI features, so all of the above lands on us. Here is our list.

Our drafting produces text that customers publish. Lawcel writes legal documents from a company's legal profile, the set of factual claims about the company that those documents are generated from, and the documents get published on the customer's own site and embedded in their product. Synthetic text from a system we provide, so the marking duty is ours, and it has to hold through our export and embed paths rather than only at generation. The internal-tooling exemption is no help, because the point of the output is that it goes public.

Our case analyses are machine-written. When Lawcel opens a case it writes a summary of what changed and which documents it affects. Strictly, Article 50 may not force a label here: the analysis is read by a small professional group inside our customer's organisation, which is close to the shape of paragraph 87's carve-out 1. We will label it anyway. A compliance product that is coy about its own AI provenance would be a strange thing to sell.

The second item is the one Lawcel exists for. Our legal documents describe our product, and our product changes every week, so every pull request in our repo gets analysed against those documents. When a change contradicts something we have published, it opens a case naming the document to fix. That is the loop I would want for Article 50 anyway, and it is what we run for other people's documents too.

In fact (and this counts as disclosure) this post was drafted by a model and reviewed by me. Whether a blog post about EU law even clears Article 50(4)'s public-interest bar is debatable, but the editorial route it describes is the right shape regardless: a named person who reads the text and is accountable for it. My name is on it because I went through it line by line.

What still matters after 2 August?

You probably read this article because you were concerned about the deadline, but the deadline is in fact the least interesting thing about this.

Article 50 turns a set of claims about your product into claims you have to keep true while the product keeps changing. The disclosure in your chat UI, the sentence in your privacy policy about how AI features work, the allocation in your vendor contract, and the marking in your pipeline all describe the same system. They were written at different times by different people, and nothing in your stack tells you when they stop agreeing. It is the same drift that leaves a privacy policy on version one while the product deploys on every merge.

So the failure I expect is not a team that ignored this. It is a team that does the list above properly before the deadline, then swaps model vendors in the spring, adds an endpoint that writes customer-facing copy, moves the assistant somewhere and forgets to render the disclosure. None of this would have been a compliance event in the past, but it is now.