The Article 50 operational pack

Why this pack exists

We make a compliance tool. We also ship AI features inside it, and we sell to companies in the EU. So when Article 50 of the EU AI Act became applicable on 2 August 2026, it was not an abstract regulation to us. It was a Sunday.

We read the regulation, the Commission's final guidelines, and the new Code of Practice on Transparency of AI-generated Content so you do not have to start from a blank page. And here is the surprise: Article 50 is one of the more reasonable parts of the AI Act. The obligations are narrow. The carve-outs are sensible. And almost all of it converts cleanly into the shape of work we like best: a control, a piece of evidence, and an owner.

That is what this pack is. Not a legal analysis (we are not lawyers, and you will be relieved to hear we know it). An operational translation: what actually applies to a typical small software company, what to do about it, and what to keep on file so you can show your work later.

The five-minute version

On 2 August 2026, Article 50 of the EU AI Act became applicable. If your product talks to users through AI, or generates text, images, audio, or video, and anyone in the EU uses it, some of this now applies to you. It does not matter where your company is based. If the output lands in front of people in the EU, you are in scope.

The whole article boils down to one idea: do not let people mistake AI for humans, or AI-made content for the real thing. Think of it as ingredient labelling for AI. Nobody is banning the product. They just want the label on the jar.

Six operational pieces, which are the six sections of this pack:

1. Interaction disclosures: tell people when they are talking to AI.
2. Marking and detection: generated content carries a machine-readable mark, and you test that it survives.
3. Labelling decisions: deepfakes and certain AI-written text get a visible label.
4. Human editorial review: the carve-out that lets your reviewed content skip the text label.
5. Code alignment or alternative means: pick your compliance route and write it down.
6. Change-triggered reassessment: re-check when something changes, not on a calendar ritual.

Here is the honest scope check most guides will not give you: for a typical B2B SaaS company, only items 1 and 2 usually apply in practice, with items 3 and 4 relevant if your marketing team publishes AI-drafted content. That is it. The scary-sounding parts (emotion recognition, biometric categorisation) are out of scope for nearly every software company we talk to.

Two dates to remember:

• 2 August 2026: Article 50 is live. Now.
• 2 December 2026: grace period ends for one specific obligation, the machine-readable marking of generated content, and only for systems that were already on the market before 2 August 2026. Content generated before 2 August does not need retroactive labels.

Penalties can reach 15 million euro or 3% of worldwide annual turnover, whichever is higher; for SMEs, the rule flips to whichever is lower. Enforcement sits with national market surveillance authorities. That is the one calm sentence about fines you will get from us. Fear is not a compliance strategy.

Step 0: does this even apply to you?

Before you do anything, figure out which hat you are wearing. Article 50 assigns duties to two roles, and mixing them up is the number one source of wasted work.

Provider. You built the AI system (or had it built) and you ship it under your own name or brand. Important nuance for SaaS founders: if you embed a third-party model (OpenAI, Anthropic, Google, whoever) inside your product behind your brand, you are almost certainly the provider of that AI system. "But the model is not mine" does not move the duty upstream. Your name on the door, your obligations.

Deployer. You use an AI system in your business. Your marketing team drafting posts with ChatGPT? Deployer. Your support team using an AI tool someone else built? Deployer.

Most small software companies are both at once: provider of the AI features in their product, deployer of the AI tools their team uses internally. That is normal. It just means you triage twice.

Now map the four obligations to the two hats:

• Article 50(1), interaction disclosure. Provider duty. Your product's chatbots, assistants, and voice interfaces must tell people they are AI.
• Article 50(2), machine-readable marking. Provider duty. Generative outputs (text, image, audio, video) must be marked so machines can detect they are synthetic.
• Article 50(3), emotion recognition and biometric categorisation. Deployer duty. If you run these systems on people, you must inform them. For nearly every SaaS company: not applicable. If it is applicable to you, close this PDF and call a lawyer. We mean it kindly.
• Article 50(4), visible labelling. Deployer duty. Deepfakes get a visible label. AI-generated text published to inform the public on matters of public interest gets a label too, unless a human editorially reviews it (section 4 of this pack).

The typical B2B SaaS triage, honestly done:

• Support or in-product AI chatbot: yes, 50(1) applies.
• Generative AI features in your product: yes, 50(2) applies.
• AI-drafted marketing and blog content: 50(4) maybe applies, and editorial review makes the question mostly moot.
• Emotion recognition or biometric categorisation: almost certainly no.

Write this triage down, with a date on it. A one-page memo. It is your first evidence artifact, and it is the document every later decision points back to.

Section 1: interaction disclosures

What the law says, in plain words

If a person could reasonably think they are talking to a human, you must tell them it is AI. The exception: when it is obvious anyway. But the bar for "obvious" is a reasonably well-informed, observant, and attentive person, judged in context. A robot avatar and a cute bot name might not clear that bar. A voice interface almost never does.

The disclosure must be clear, distinguishable, and delivered at the latest at the first interaction. Not paragraph 14 of your terms of service. At the moment the conversation starts.

What to actually do

1. Inventory every AI-to-human touchpoint. Support widget, in-product assistant, onboarding bot, voice interface, any email automation that converses rather than just notifies. Write the list down with a date.
2. Write the disclosure. One honest sentence beats a paragraph of legalese. "You're chatting with an AI assistant." Done. Resist the urge to soften it into meaninglessness.
3. Place it at first interaction. In the chat window itself, before or with the first message. Visible, not hover-hidden.
4. If you rely on the "it's obvious" exemption anywhere, write down why. A decision you cannot show your reasoning for is a decision you will end up re-arguing under pressure, probably at the worst possible time.

Section 2: marking and detection

What the law says, in plain words

If your system generates synthetic audio, images, video, or text, the outputs must carry a machine-readable mark, so that tools can detect the content is AI-generated or manipulated. This is different from a visible label. The mark can be invisible to humans; the point is that machines can find it. This is a provider duty.

The techniques in play: metadata standards (C2PA content credentials are the emerging default), watermarking, and fingerprinting. The law asks for solutions that are effective, interoperable, robust, and reliable as far as technically feasible, explicitly taking into account the type of content, the cost, and the state of the art. Translation: nobody expects unbreakable watermarks. They expect a serious, documented attempt.

Two useful exemptions: systems that only assist with standard editing (a grammar checker is not a deepfake factory, and the law knows it), and systems that do not substantially alter the input you gave them.

The question every founder asks

"I build on top of GPT, Claude, or Gemini. Doesn't the model provider handle this?"

Partly, sometimes, and you should not bet your compliance on it. If you ship the AI system under your brand, the duty sits with you. Upstream marks help (some image generation APIs already embed C2PA metadata), but only if they survive your pipeline. Your image resize step, your PDF export, your CDN optimization can silently strip metadata. The mark that mattered in the API response and died in your build step does not count.

So: test. Do not assume. This is the operational core of this section.

The marking and detection test, step by step

1. Inventory every generative output your product ships. Text the user exports, images, generated documents, PDFs, audio. All of it.
2. Identify the marking mechanism per output type. Upstream metadata passed through, your own watermark, both, or honestly "none yet."
3. Run each output through your real production pipeline and verify the mark survives. Download the file the way a user would. Check the metadata. Record what you find, with dates and sample files.
4. Where marking genuinely is not feasible for a content type yet, write a short memo: what you evaluated, why it is not feasible today, and when you will re-check. Documented limitation beats silent hoping, in front of an auditor and in front of a regulator alike.

Grace period reminder: if your system was on the market before 2 August 2026, this specific obligation applies from 2 December 2026. That is a runway, not an exemption. Four months disappears fast when the fix involves your export pipeline.

Section 3: labelling decisions

Marking vs labelling, untangled

People mix these up constantly, so let us fix it once. Marking (section 2) is machine-readable, can be invisible, and is the provider's job. Labelling (this section) is visible to humans, sits at the point of publication, and is the deployer's job. You can be responsible for both, for one, or for neither, depending on what you build and what you publish.

What the law says, in plain words

Two labelling duties:

• Deepfakes. AI-generated or manipulated images, audio, or video that depict real people, places, or events in a way that appears authentic must carry a visible disclosure that the content is AI-generated or manipulated. If the content is part of an evidently artistic, satirical, or fictional work, you still disclose, but you may do it in a way that does not spoil the work (credits, description, and so on).
• Public-interest text. AI-generated or manipulated text published with the purpose of informing the public on matters of public interest must disclose that it was AI-generated. Unless a human reviewed it and a person or company holds editorial responsibility for the publication. That carve-out gets its own section next, because it is the most practically useful sentence in the whole article.

The decision tree

For every piece of AI-assisted content you publish, ask in order:

1. Does it depict real people, places, or events in a way that looks authentic? Yes: visible label, at first exposure, not behind a click. "This image was generated with AI" is enough.
2. Is it text intended to inform the public on matters of public interest (news-like content, analysis, reporting)? Yes: label it, or run it through documented editorial review (next section).
3. Is it your marketing copy about your own product? "Matters of public interest" is a stretch for a feature announcement, but the line is genuinely fuzzy, and we would rather admit that than pretend it is crisp. Our pragmatic default: run the editorial review process anyway. It is cheap, it makes your content better, and it makes the fuzzy legal question mostly irrelevant.

What a label looks like

Plain, visible, present at first exposure. "This image was generated with AI." "Parts of this audio were AI-generated." No euphemisms ("digitally enhanced" is not a disclosure), no burying it below the fold.

Section 4: human editorial review

The most useful carve-out in Article 50

Here is the plain version: if a human reviews AI-drafted text before publication, and a person or company holds editorial responsibility for it, you do not need to put an "AI-generated" label on that text.

Why this matters: it is the difference between stamping every blog post "written by AI" and simply having an editor. Which, if we are honest, good content teams have anyway. The law is quietly rewarding a practice you should already want: a human who reads the thing, fixes the thing, and puts their name behind the thing.

The catch, and it is the same catch as everywhere in compliance: a review that leaves no trace is a review you cannot prove happened.

Make it real in four steps

1. Name the editorially responsible person, in writing. In a small company this is one sentence in a one-page policy. "Editorial responsibility for published content rests with [name/role]."
2. Define what review means. Read fully, verify factual claims, edit meaningfully, approve. Skimming while the coffee brews does not count, and you know it does not.
3. Log it. Date, content identifier, reviewer, sign-off. A spreadsheet genuinely works. A timestamped acknowledgment in whatever system you use works better.
4. Keep the drafts, or at least the diff. Being able to show that a human changed things is quietly powerful evidence that review actually happened.

What this carve-out does not do

It does not remove the provider-side machine-readable marking duty (section 2 stays with whoever provides the generating system). It does not cover images, audio, or video. It covers the visible label on text. Scope it correctly and it will serve you well; overextend it and it will not.

Section 5: code alignment or alternative means

Two roads, one written decision

The Commission has published final guidelines on Article 50, and a Code of Practice on Transparency of AI-generated Content, drawn up by independent experts, is now final. That gives you two roads for the marking and labelling obligations:

Road A: align with the Code. The practices are spelled out for you, regulators recognize the route, and your evidence burden becomes "we follow the Code, here is the mapping." For a small team, this is usually less total work, because someone else already did the thinking about what good looks like.

Road B: your own means. Entirely allowed. But you carry the burden of showing your approach achieves the same outcome: documentation of what you do, and reasoning for why it is equivalent.

There is no shame in either road. There is considerable shame (operationally speaking) in choosing neither, which in practice means choosing Road B accidentally, with no documentation.

The deliverable

A one-page memo. Which road, why, who decided, and when. If Road A: a short mapping of your actual practices to the Code's commitments. If Road B: your equivalence reasoning. Add a review date, because both the guidelines and the Code will evolve.

While you are at it, actually read the Commission guidelines. They are the closest thing to the regulator telling you how they will interpret the fuzzy parts, and they are free.

Section 6: change-triggered reassessment

State is noise, change is the signal

Compliance snapshots rot. The triage you did in August 2026 is accurate right up until the Tuesday someone ships a new AI feature without telling you. This is true of every framework we have ever worked with, and Article 50 is no exception.

Our strong opinion, after living in compliance-land for years: do not build a giant annual re-review ritual. Build a short trigger list instead. When a trigger fires, re-run the thirty-minute triage from Step 0. That is the whole process.

The trigger list

• You ship a new AI feature or a new conversational surface.
• You swap or add a model or AI vendor.
• Your upstream provider changes how it marks generated content.
• Marketing adopts a new generative AI tool.
• You enter a new market, language, or content channel.
• Your content or delivery pipeline changes (new export format, new CDN, new image processing: re-run the marking survival tests).
• The Commission updates the guidelines or the Code of Practice.
• One trigger you can schedule right now: 2 December 2026, the day the marking grace period ends for systems that predate 2 August 2026.

The process, all of it

Trigger fires. Owner runs the triage and the relevant checklist section. Owner logs the date, the outcome, and any actions. Done. Thirty minutes, honestly, once the first full pass exists.

The one-page checklist

Print this. Pin this. Work through it top to bottom.

From PDF to practice

Everything above is deliberately tool-agnostic. A folder and a spreadsheet will genuinely get you through Article 50. What matters is the shape of the work: a control statement, evidence attached to it, an owner, a re-check cadence, and a history you can show someone later.

If you already run SOC 2 or ISO 27001, resist the urge to build a separate "AI compliance" silo. Article 50 slots into the machinery you have: add the controls, attach the evidence, assign the owners, schedule the reviews. One system, one habit, less rot.

And if that machinery is currently a spreadsheet that is starting to creak: that is the exact problem we built AuditBadger for. Custom controls, evidence with versioned history, document workflows with review reminders, timestamped acknowledgments. We used it to get ourselves SOC 2 Type II certified, zero consultants, and we run our own Article 50 evidence in it too, because we would feel silly not to. $250/month flat, no per-user fees. If your compliance work is landing in the same overloaded spreadsheet as everything else, come have a look: auditbadger.com

Honest limits, and where to read more

We are founders and engineers, not lawyers. This pack is an operational translation of Article 50, not legal advice, and it deliberately covers the common case: a small software company shipping and using AI in ordinary ways. If you run emotion recognition or biometric categorisation, operate anywhere near law enforcement use cases, or genuinely cannot tell whether your content "informs the public on matters of public interest," spend the money on counsel. It is cheaper than being wrong.

Worth your time, all free:

• Article 50, full text (EU AI Act Service Desk)
• Commission guidelines on transparency obligations for providers and deployers of AI systems (final)
• Code of Practice on Transparency of AI-generated Content
• Commission FAQ on Article 50 transparency obligations

AuditBadger is a compliance platform for small teams doing SOC 2 and ISO 27001 without a compliance department. We certified ourselves with it: SOC 2 Type II, zero consultants. $250/month flat. auditbadger.com