An EU AI Act compliance checklist that survives contact with a shipping product runs in two passes: an inventory pass that lists every AI surface a person can see or hear, and a mapping pass that scores each surface twice — once against the risk tiers, once against the transparency lanes in Article 50. The second mapping is the one teams skip, and it is the one that catches ordinary SaaS products.
Timing sharpens this. As of 19 August 2026, the general application date for the Article 50 transparency rules — 2 August 2026 — is 17 days behind us, and a limited transition that may extend provider-side machine-readable marking to 2 December 2026 for eligible systems — 105 calendar days from today — has been proposed by the European Commission (the November 2025 Digital Omnibus package) but is not yet adopted law. The August date comes from Regulation (EU) 2024/1689 as published on EUR-Lex; the December date is a proposal to verify, not a fact to plan around; and the European Commission's AI Act Service Desk compliance checker is the official place to test which rules the Act points at your system. Nothing below replaces reading the article text or asking counsel about your specific setup.
A "minimal risk" verdict is not a "nothing applies" verdict
Risk-tier checkers answer a classification question about a system. Article 50 sits in its own chapter of the Act and is written around two other variables: your role (provider or deployer) and what the surface does to a person — talks to them, generates synthetic content, reads their emotions or biometrics, or publishes manipulated media. Those variables move independently of the tier.
Risk tier and transparency lane are scored on different axes; clearing one tells you nothing about the other.
The failure mode is almost always the same shape. A team runs one classification for "our product", gets a low tier, files the PDF, and never notices that the product contains four separate surfaces with four different answers. The early tell is cheap to spot: open the checklist and count the rows. If a product with a chat assistant, an AI summariser, an image generator and an internal transcription tool has one row, the inventory pass never happened.
Pass one: inventory by surface, not by vendor
The most common intake mistake is listing vendors. A row that says "OpenAI API" cannot be mapped, because the mapping questions are about what a person sees and who put it in front of them. Three rules keep pass one usable:
- One row per user-visible surface. Two chat features running on the same model produce two rows, because their notice placement, audience and output paths differ.
- Include internal-facing tools. Whether an internal transcription tool sits inside a lane is a pass-two question. Someone doing inventory should not be pre-filtering on legal grounds.
- Stop at the surface boundary. Retrieval pipelines, embeddings and rerankers are implementation detail unless their output reaches a person unmediated.
Ten fields per row are enough to run pass two without going back to the team a second time.
| # | Field | Example answer | Who can answer it |
|---|---|---|---|
| 1 | Surface name | "Support chat widget" | Product |
| 2 | Where it renders | Logged-in dashboard, all plans | Product |
| 3 | Audience | Customers, EU and US | Product |
| 4 | What it produces | Free text replies | Product |
| 5 | Human in the loop before output | No | Product |
| 6 | Brand shown to the user | Ours | Product |
| 7 | Model source and who configured it | Third-party API, configured in-house | Engineering |
| 8 | Output path after generation | Rendered in-app, exported to PDF | Engineering |
| 9 | Marking capability today | None | Engineering |
| 10 | Log retention for this surface | 30 days, no export | Engineering |
Six of the ten come from whoever owns the roadmap. Four — model source, output path, marking capability, log retention — only engineering answers reliably, and those four are exactly the fields that decide whether pass two produces a real answer or a shrug. Collect them in the same session or the mapping stalls.
Pass two: the two mappings
Mapping A, the tier branch. Three questions route the row: does the use fall under the Act's prohibited practices; does it fall in the high-risk categories tied to Annex III or to product-safety legislation; is a general-purpose AI model involved. An article cannot settle that classification for you, and any checklist that claims to has overreached. Run the row through the Commission's checker, record the date you ran it, and route anything ambiguous to counsel rather than to a spreadsheet cell.
Mapping B, the transparency branch. Article 50 splits into four paragraphs, each addressed to a different actor. Read the paragraph text on EUR-Lex before you accept any summary, including this one.
| Lane | The text addresses | Typical surface | Artifact worth keeping |
|---|---|---|---|
| 50(1) direct interaction | Providers of systems intended to interact directly with people | Chatbot, voice agent, in-app assistant | Notice wording, screenshot, timestamp of first display |
| 50(2) synthetic output marking | Providers of systems generating synthetic audio, image, video or text | Image generator, AI writing feature | Marking spec, sample payload, date deployed |
| 50(3) emotion & biometric categorisation | Deployers of those systems | Camera or audio analysis, sentiment scoring | Informing notice, rollout date, affected sites |
| 50(4) deepfakes & public-interest text | Deployers publishing manipulated media or public-interest text | Marketing video, synthetic voiceover, published articles | Label placement, editorial sign-off, publication URL |
Two things about this table matter more than the table. First, lanes 1 and 2 sit with the provider role and lanes 3 and 4 with the deployer role, which means one company can be in different lanes for different products — and can be both at once for a single product it builds and also operates. Second, the text carries exceptions inside the paragraphs themselves, including an obviousness carve-out in 50(1) and narrower framing for artistic and satirical work in 50(4). Whether an exception fits your wording is a reading question with real consequences; it is a fair thing to put in front of a lawyer rather than resolve in a sprint planning session. Our walkthrough of the chatbot disclosure question under Article 50 goes through lane 1 in more depth.
Five checklist answers that look clean and are not
Every one of these has a follow-up question attached that the original answer does not survive.
| What the row said | The question it leaves open | Early tell |
|---|---|---|
| "We don't build AI, we just call an API." | Which role does the text point at for the surface your users actually see? | The row names a vendor, not a screen |
| "Minimal risk, nothing to do." | Was the transparency branch run at all, or only the tier branch? | One row for an entire product |
| "The widget header says 'AI Assistant'." | When does the notice appear relative to the user's first message, and does it survive a mobile viewport? | Nobody on the team can state the timing |
| "Our marketing images come from an agency." | Who publishes the output, and does the marketing site have a row in the inventory? | The inventory covers the app only |
| "It's covered in our terms of service." | Is a link in a footer the same thing as a notice at the point of interaction? | The evidence file contains a URL and no screenshot |
Pattern three is the most common in reviews we run internally, and the most fixable: teams write decent notice copy and never decide when it renders. Pattern four is the most expensive to unwind, because the marketing site usually sits outside whatever governance process the product team built.
What the ranking checklists give you, and what they leave out
We sampled the nine results ranking for this query on 13 August 2026. Three of them — IAPP, OneTrust and ComplyCloud — put the actual checklist behind a form or a membership wall at the time of our check (this can change), so you could not see the structure before trading an email address for it. One is the Commission's own compliance-checker landing page, roughly 200 words, which hands you to an interactive tool rather than a document. The rest organise their steps by risk tier.
A tier-first spine ages badly for a checklist you rerun every release: the tier rarely changes, and the surfaces change every sprint. That is the argument for putting inventory first and treating classification as the second question rather than the first. If you are comparing tooling rather than building the list by hand, our criteria for evaluating an Article 50 compliance tool covers what to test before you commit.
Evidence: what to keep after each pass
The output of a checklist is not a verdict, it is a dated record that a specific person asked a specific question against a specific source. Seven fields per decision are enough for that record to mean something a year later:
1. Date and time of the decision 2. Surface identifier from pass one 3. The decision itself, in one sentence 4. Who made it, by name and role 5. Source consulted, with the version or retrieval date 6. The artifact — screenshot, DOM snippet, payload sample, hash 7. Next review date
Append-only beats editable here, because an overwritten row destroys the one thing the log was for. A transparency statement template covers the narrative document that sits on top of this log.
One boundary worth stating plainly: machine-readable marking implemented through HTML attributes, JSON-LD blocks or response headers is advisory metadata. It travels with your output only as long as nothing strips it, and it is not signed provenance, not cryptographic attestation and not a certification of anything. Treat it as a signal you deliberately attached and can demonstrate you attached — not as proof that any downstream copy still carries it.
DiscloseKit does the mechanical parts of this loop: a deterministic rules engine that maps intake answers to the four lanes, a disclosure widget, a verification step that checks the notice is live on the page, and the append-only evidence log described above. It does not decide your classification, and no tool can hand you a legal conclusion about your product.
The 2 December 2026 date, and what to verify before leaning on it
The transition for provider-side machine-readable marking is limited, conditional and — at the time of writing — proposed rather than adopted. Adoption status and eligibility both turn on facts outside your control, not on a self-assessment you write yourself, so the practical move is to confirm the position with counsel or through the Commission's Service Desk rather than assume the later date applies to you.
The calendar rule we use: put the internal review on 2 November 2026, not on 2 December. Thirty days is roughly the distance between "we need marking on the image generator" and a shipped, verified, logged implementation — and if the transition is not adopted or turns out not to apply to your system, you would rather learn that in early November than in the last week.
What a checklist does not decide
Three questions come up in nearly every review and none of them belong in a spreadsheet cell:
- Role under a white-label arrangement. When you build the feature and a partner puts their brand on it, who the text treats as provider is a reading of the arrangement, not a checkbox.
- Whether an exception fits. Obviousness under 50(1) and the creative-work framing in 50(4) are both judgement calls about your specific wording and context.
- Exposure across member states. National implementation and supervisory practice differ, and this article does not state what any authority will do.
This is educational and operational guidance about how to organise the work. It is not legal advice, and where the answer changes your product or your risk position, get it from a qualified lawyer.
Questions people ask alongside this one
Does the EU AI Act apply to companies outside the EU? The scope provisions are keyed to where systems are placed on the EU market and where output is used, not to where a company is incorporated. A US company with EU users is not automatically outside the frame, and a European company is not automatically inside it for every product. Article 2 is the text to read, and the Commission's checker is the place to test a specific system.
What are the key points of the EU AI Act? Structurally: prohibited practices, a high-risk regime with conformity and documentation duties, transparency duties in Article 50, separate rules for general-purpose AI models, and a phased timeline. A checklist for a SaaS team usually touches the transparency chapter and the scope article far more often than the high-risk chapter.
What is a compliance checklist actually supposed to produce? Two things: a decision trail with dates and named owners, and a rerun cadence. A checklist that produces a one-time PDF and no cadence has answered a question about the product as it existed on the day it was filled in.
Rerun pass one the next time you ship anything that writes, speaks or renders to a user. If the surface count went up and the checklist did not, the checklist is already out of date.