AI Act compliance for a SaaS team splits into two lanes, and most product teams land in the smaller one without noticing. Article 50 of Regulation (EU) 2024/1689 sets out transparency duties that attach to how a feature presents itself to the person in front of it; Chapter III sets out the high-risk regime, which attaches to what a system decides about people (EUR-Lex). A support bot, a writing assistant and an image generator can all sit in the first lane and nowhere near the second. Which lane a feature occupies decides whether the next quarter is a notice-and-evidence project or something considerably heavier.
Most write-ups of AI Act compliance for SaaS teams open with the four risk tiers. That is the wrong end of the problem for a team that already ships. You do not classify a company; you classify a surface, one at a time, and then you keep the classification alive while the roadmap moves underneath it.
This is operational guidance for shipping teams, not legal advice. Role classification, territorial scope and whether an exception fits your case are fact-specific questions for qualified counsel. What follows is the part a product team can run itself.
Inventory surfaces, not systems
Ask engineering for an AI inventory and you get systems: the chatbot, the summariser, the recommender. Three rows, done by lunch. But the transparency questions in Article 50 turn on the moment output reaches a human, and one "system" can reach humans in a dozen places — several of which nobody on the call remembers.
Surfaces a system-level inventory routinely misses:
- the chat widget when it runs inside a customer's own site, Slack or Teams instead of your app
- draft replies inserted into a human agent's compose box
- email digests where the summary paragraph is model-written
- PDF and CSV exports carrying generated text
- per-account empty states, tooltips and onboarding copy
- voicemail transcription summaries and IVR flows
- alt text, avatars, thumbnails and other generated imagery
- pages your product publishes on a customer's behalf: help-centre articles, job posts, listings
- model output returned through your API and rendered in someone else's interface
- release notes and status-page copy drafted by a model
- anything reachable by a deep link that skips onboarding
The last item is a decision rule rather than an example. If a surface can be reached by a URL that bypasses your onboarding modal, treat it as its own surface with its own notice question. The API row is where the argument usually starts, because the person seeing that output is not your user, and the interface rendering it is not your code.
The four lanes, and which one a feature sits near
| Lane | What puts a feature near it | Whom Art. 50 addresses | Familiar SaaS example |
|---|---|---|---|
| 50(1) — AI-interaction notice | System intended to interact directly with people | Providers | Support chatbot, voice agent |
| 50(2) — marking of synthetic output | System generates synthetic audio, image, video or text | Providers | Image generator, writing assistant |
| 50(3) — emotion recognition, biometric categorisation | You operate a system in one of those categories | Deployers | Sentiment scoring on recorded calls |
| 50(4) — deepfakes, public-interest text | Published content that is generated or manipulated | Deployers | Marketing video, AI-drafted public post |
Three details in that table cause most of the misreadings. The lanes are not mutually exclusive — a voice agent can sit near 50(1) and 50(2) at once. Provider and deployer are readings of a role in relation to a specific system, so one company can hold both, on the same day, for the same product. And the carve-outs in the text are narrow and worded tightly: 50(1) turns on whether the AI interaction is obvious to a reasonably well-informed, observant and circumspect person in the circumstances of use, and 50(2) addresses systems performing an assistive function for standard editing that does not substantially alter the input data (EUR-Lex). That second carve-out is exactly why "is this grammar correction or generation?" is a live question for a writing assistant rather than a philosophical one.
Article 50(5) also addresses timing: information provided at the latest at the time of the first interaction or exposure, in a clear and distinguishable manner, meeting accessibility requirements. Timing is an engineering decision, which is why it belongs in the release checklist and not in a policy PDF.
Six feature archetypes against four lanes
The grid below is a triage aid for a planning session, not a classification. It tells you which conversation to have first; the verdict comes from the text and, where it is close, from counsel.
| Feature archetype | 50(1) | 50(2) | 50(3) | 50(4) | First question to settle |
|---|---|---|---|---|---|
| Support chatbot in-app | Likely near | Fact-specific | Out | Out | Who ships the notice when the bot is white-labelled? |
| In-app writing assistant | Unlikely | Likely near | Out | Fact-specific | Assistive editing, or generation that alters the input? |
| Image/video generation | Unlikely | Likely near | Out | Fact-specific | Does output depict identifiable real people? |
| Meeting transcription + summary | Unlikely | Fact-specific | Fact-specific | Out | Does any feature infer an emotional state? |
| Outbound voice agent | Likely near | Fact-specific | Out | Fact-specific | At what second of the call does the notice land? |
| Sentiment scoring in a CX dashboard | Out | Out | Likely near | Out | Emotion inference or keyword classification — and who is the deployer, you or your customer? |
Run this once per product, not once per company. If the same archetype appears in two products with different distribution models, it gets two rows. For the chatbot row specifically, the interaction-notice question has more depth than a grid cell allows — we unpack it in the chatbot disclosure requirement under Article 50.
Who owns which decision
| Decision | Sits with | Failure mode when it drifts |
|---|---|---|
| Which surfaces exist at all | Product | New surfaces ship with no lane assigned |
| Lane assignment and written reasoning | Product, reviewed by counsel | Reasoning lives in a doc nobody reopens |
| Where and when the notice renders | Engineering | Notice bound to the app shell, absent from embeds |
| Wording, contrast, screen-reader behaviour | Design | Notice technically present, practically invisible |
| Dated record that it went live | Whoever runs releases | Evidence is a screenshot in a Slack thread |
The pattern that breaks this is classification drift: one thorough exercise in month one, then eleven months of shipping. A prompt change turns a summariser into a drafter. A feature flag exposes an internal tool to end customers. Neither event files a ticket that says "reclassify."
The cheap fix is a trigger, not a review cadence. Any change to a model, a prompt, or a flag that changes what a surface emits reopens the lane question for that surface — put that line in the release template where engineers already look, and drop the quarterly governance meeting that nobody prepares for.
The 122-day window between the two 2026 dates
Article 50 applies from 2 August 2026 (EUR-Lex). A limited transition that may extend provider-side machine-readable marking to 2 December 2026 for eligible systems has been proposed by the European Commission (the November 2025 Digital Omnibus package) and is described in the Commission's Article 50 FAQ as envisaged — it is a proposal, not adopted law, so check its current status and its eligibility conditions against your own case rather than assuming either. Those dates are 122 calendar days apart.
If the transition is adopted, that window is the sequencing budget for the marking work specifically. It is not a general pause on the rest of Article 50, and treating it as one is how teams end up with a marking pipeline and no visible notice. A workable sequence inside 122 days, adjusted to your release cadence:
- Days 1–21: surface inventory with a named owner per surface. Nothing else. Notice copy written before the inventory is finished gets rewritten.
- Days 22–45: wording, placement and accessibility pass on the highest-traffic surfaces.
- Days 46–90: marking applied at generation time in the pipeline, with a verification check in CI.
- Days 91–122: evidence backfill and the re-check trigger wired into the release template.
What machine-readable marking is not
HTML attributes, JSON-LD blocks and response headers are advisory metadata. They travel with an artefact only as long as nothing touches it. Screenshot a generated image and the metadata is gone. Paste a marked paragraph into an email and the wrapper stays behind. Re-encode a video and most pipelines discard what they do not recognise.
Marking is therefore a claim about your generation pipeline, not a property of the artefact once it is loose in the world. It is not signed provenance, and it is not C2PA certification. Calling it proof of origin overstates the technique by a wide margin, and anyone reviewing your setup with a technical background will spot the gap in about a minute.
Practically: mark at generation, log the fact that you marked, and treat the human-visible disclosure as the part that survives contact with real users.
Three failures that show up in review
The notice that only exists in onboarding. Deep links, embedded widgets, restored sessions, mobile web, and customers who invite users straight into a shared object all skip the first-run flow. Build a test grid of entry points before you build the notice; the placement and resilience work is covered step by step in our guide to the Article 50 disclosure widget embed.
The white-label question nobody asked. If you put your name or trademark on a third-party system, or modify it substantially, the provider definition in Article 3(3) of Regulation (EU) 2024/1689 and — for high-risk systems — the value-chain provisions in Article 25 are the place to check what changes (EUR-Lex). This is not a call a product team should make alone, because it can change which set of duties the text points at you. It also runs in both directions: your reseller may be asking the same question about you.
Evidence that is a screenshot. A usable record holds the surface identifier, the assigned lane, the notice version, the deployed-at timestamp, the verification result and the person who signed off — appended, not edited. Screenshots go stale silently and cannot show when something stopped being true. If you are evaluating tooling for this, the criteria for an Article 50 compliance tool cover what to test before buying. No tool settles classification for you; what a tool can do is keep the record from depending on someone's memory.
A nine-question readiness score
Score each question 0 (no), 1 (partly true, or true but undocumented), or 2 (yes, with a dated record). Maximum 18.
1. Can you list every surface where model output reaches a person, each with a named owner? 2. Has each surface been assigned to a lane, with the reasoning written down and dated? 3. Is the provider/deployer reading recorded per product rather than per company? 4. Does the notice appear on deep-linked and embedded entry points, not only after onboarding? 5. Does the notice survive your smallest supported viewport and a screen reader? 6. Is marking applied at generation time in the pipeline rather than bolted on at render? 7. Do you have a dated record of when each notice went live, produced by something other than recollection? 8. Does a change to a model, prompt or feature flag trigger a re-check of that surface? 9. Is there a named person who signs off classification changes, and a defined route to counsel for the close calls?
0–7: the inventory is your bottleneck. Stop writing notice copy — you do not yet know where it goes.
8–13: coverage is probably fine and the evidence is not. Expect to re-derive answers under time pressure, from memory, in front of someone who wants dates.
14–18: this is now a maintenance problem. The remaining exposure is drift, so spend the effort on question 8 rather than on more documentation.
Three questions teams ask before the classification lands
We only call a third-party model API. Does that make us a provider? It depends on what you do with the system and how you put it on the market, which is precisely the kind of question the provider definition and the value-chain provisions address. Write down what you actually do — rebrand, fine-tune, modify, resell, or simply call — and take that description to counsel rather than reasoning from analogy with another company's blog post.
Our product is not high-risk. Does Article 50 still apply to us? The transparency lane and the high-risk regime are separate parts of the regulation with separate triggers (EUR-Lex). Concluding that a feature is outside Chapter III does not answer the Article 50 question, and the two assessments are worth keeping in separate documents so nobody conflates them later.
Do we need a separate notice for every feature? Article 50(5) addresses timing and clarity rather than counting notices. In practice, teams tend to converge on one reusable component with per-surface configuration, because a bespoke notice per feature is what decays first when the feature team changes.
What to verify rather than assume
Take these to counsel or to the official text and guidance — the European Commission's AI Act Service Desk publishes the current material, and the consolidated regulation is on EUR-Lex:
- whether the regulation reaches your company given where your users and outputs are
- whether a specific feature falls inside a definition in the text
- whether re-branding or modifying a third-party system changes your role reading
- whether an exception genuinely applies to your case, and what you would show to support that
- which national authority handles supervision in the markets you sell into
The hard part is not deciding which lane a feature sits in. It is noticing when a feature changes lanes — and that happens on a Tuesday, in a prompt change, without a ticket.