The EU AI Act now has three application dates, not one. After the AI Omnibus (political agreement 7 May 2026, adopted 19 November 2025), the timeline that actually applies to SaaS is this:
- 2 August 2026. Article 50 transparency, GPAI provider obligations, governance framework.
- 2 December 2027. Annex III high-risk obligations (moved from the original 2 August 2026).
- 2 August 2028. Annex I embedded-product high-risk obligations. AI as safety component under Machinery, MDR, IVDR, lifts, toys, RED, motor vehicles (moved from the original 2 August 2027).
Most SaaS teams I talk to are in "we'll deal with it later" mode. Partly denial. Mostly that the official text is 458 pages of lawyer-prose with the implementation details buried, and now there's a second 200-page Omnibus amending it.
So we wrote an engineer-readable version and open-sourced it:
Repo: github.com/GatisOzols/eu-ai-act-checklist (MIT, no signup)
The repo was updated in June 2026 to reflect the AI Omnibus dates across the README, checklist, penalty-bands.json, and annex-iii-categories.json. This post walks through what's in it, why we built it, and the four article references most teams underestimate.
What’s in the repo
11 files, ~24KB total. One afternoon to run through start to finish for a single-product SaaS.
README.md
checklist.md — 7-step self-audit, plain English
annex-iii-categories.json — 8 high-risk areas, machine-readable
classify.py — Decision-tree classifier for risk tier
penalty-bands.json — Article 99 penalty tiers as JSON
chatbot.html — Article 50(1) disclosure template
generated-content.md — Article 50(2) synthetic content template
deepfake.md — Article 50(4) deepfake template
emotion-recognition.md — Article 50(3) emotion / biometric template
translations.json — Disclosure labels in 6 EU languages
LICENSE — MIT
The classifier
The most interesting file is classify.py. It walks you through five questions about each AI feature in your product and returns the risk tier under the regulation.
It’s intentionally tiny: no dependencies, no framework, runs anywhere Python runs. Output is plain text you can paste into your audit record.
Example output for an AI resume-scoring feature:
HIGH-RISK under Annex III §4. Article 6 obligations apply (risk management, technical documentation, record-keeping, human oversight, accuracy/robustness, conformity assessment, CE marking, EU database registration).
What teams underestimate
Most “EU AI Act readiness” content I read online stops at “disclose your chatbot.” Article 50(1) is the obvious one. Four others matter more for engineers.
Article 12 — record-keeping isn’t “we log stuff”
Article 12 requires automatic event logging across the AI system’s lifecycle. The specific fields are in Annex IV section 9:
Period of each use (start, stop)
Reference database checked, where applicable
Input data when the search led to a match
Identification of natural persons involved in result verification, where Article 14(5) applies
Minimum retention is 6 months under Article 12(2), but most teams should plan for 12-24 months because Member State authorities can extend.
The word “tamper-proof” isn’t in the statute, but it’s the practical bar. The auditor will ask “can you prove these logs weren’t edited.” So design for it from day one: hashed lines, append-only storage, signed batches, whatever your stack supports. Retrofitting this after launch is painful.
Article 14 — human oversight is process plus UI, not just policy
Article 14(4) lists what the supervising person must be able to do:
Understand the system’s capacities and limitations enough to monitor operation (4a)
Stay aware of automation bias (4b)
Interpret output correctly (4c)
Decide not to use the output or override it (4d)
Intervene on operation or interrupt through a “stop” button or similar procedure (4e)
That last requirement is concrete and often skipped. If your agent runs in a long-running loop, the supervising operator needs a kill switch that is visible, accessible, and produces a safe state. Most internal tools we’ve looked at don’t have this and need to retrofit.
For documentation: write down who the oversight person is, the SLA between alert and intervention, what the stop procedure actually does, and how oversight personnel are trained.
Article 50 — four sub-paragraphs, four different triggers
Article 50 transparency obligations are not one rule, they’re four:
50(1) — AI interacting with humans (chatbots, voice assistants): disclose at the start of interaction, clear and distinguishable
50(2) — Synthetic content generation (text, image, audio, video): mark output machine-readable, plus visible label on publication
50(3) — Emotion recognition or biometric categorisation: inform users they’re being subjected to it
50(4) — Deepfakes (real persons depicted): disclose as artificially generated
Each has a different practical implementation. The repo has separate templates per sub-paragraph. Don’t reuse a chatbot disclosure for a deepfake feature, the requirements are different.
Article 86 — explainability for end users
This is the GDPR Article 22 analog. End users (not deployers, end users) have the right to a “clear and meaningful explanation of the role of the AI system in the decision-making procedure and the main elements of the decision taken” when the decision is based on high-risk AI output AND produces legal or similarly significant effects.
Most teams treat this as a customer-support overhead. It isn't. Article 86 is enforceable in step with the Annex III high-risk wave it depends on (deployers of Annex III high-risk systems owe affected persons the explanation), so plan it for 2 December 2027 post-Omnibus.
The minimum-viable explanation per the recitals: which features contributed, what the alternative outcomes would have been, what the user can do to change the outcome. Counterfactuals satisfy this. Pure feature-importance plots usually don’t.
Penalty bands
Penalty bands
Article 99 sets three tiers. Each tier triggers on a different date.
| Violation | Maximum fine | Triggers |
|---|---|---|
| Prohibited AI (Article 5) | €35M or 7% of global annual turnover | Already in force since 2 February 2025 |
| Article 50 transparency | €15M or 3% | 2 August 2026 |
| Annex III high-risk obligations | €15M or 3% | 2 December 2027 (Omnibus) |
| Annex I embedded high-risk obligations | €15M or 3% | 2 August 2028 (Omnibus) |
| Misleading info to authorities | €7.5M or 1% | In step with the substantive obligation breached |
SME proportionality applies under Article 99(6), but the upper bound still binds.
Why we built it
We run a productized €997 EU AI Act audit at disclos.eu — a 5-business-day deliverable for SaaS founders who want someone else to do the legwork. While building the audit methodology, we kept seeing the same gap: there was no engineer-readable starting point that wasn’t a paid platform or a €15k law firm engagement.
The 80% of EU SaaS that’s under €1M ARR has nothing to work with. So we open-sourced our internal checklist. The audit service stays paid, the repo stays free under MIT, and the licensing means anyone (including competitors) can fork it.
Contributing
If you want to help, the highest-leverage contributions are:
Translations of the Article 50 disclosure labels for the remaining 18 EU languages.
Annex III mapping refinements, particularly edge cases around agentic systems that touch §4 (employment) and §5 (essential services).
Real-world classification examples (anonymized) of how teams classified ambiguous features.
Open an issue first for anything substantial so we can discuss scope.
Free tools alongside the repo
For non-developer team members who don’t want to run Python, we also publish three browser-based tools (no signup):
EU AI Act penalty calculator
Annex III high-risk triage
Article 50 disclosure generator (24 EU languages)
Repo link, one more time
github.com/GatisOzols/eu-ai-act-checklist
MIT. ~24KB. No signup. The Article 50 deadline is 54 days out. The Annex III deadline is 18 months out. The Annex I deadline is 26 months out.
If your team is in “we’ll deal with it later” mode, this is the lightest possible way to stop kicking the can.
About
I'm Gatis Ozols, building Disclos from Riga. Disclos is a productized €997 EU AI Act compliance audit for SaaS companies. 5 business days, refund-guaranteed.
Not a lawyer. We work with EU counsel for the formal interpretation. The checklist in this post is the engineer-readable starter we wished existed when we first started talking to SaaS founders about the Act.
Free tools (no signup):
- EU AI Act penalty calculator: https://www.disclos.eu/tools/penalty-calculator
- Annex III high-risk triage: https://www.disclos.eu/tools/annex-iii-triage
- Article 50 disclosure generator: https://www.disclos.eu/tools/article-50-disclosure-generator
Contact: gatis@disclos.eu
Top comments (7)
Harjot's point about designed-in vs bolted-on is the right frame. One thing worth adding for teams thinking about the "prove these logs weren't edited" auditor question:
Hash chaining detects modification but doesn't prevent chain reconstruction. An operator with storage access can regenerate a valid chain over modified content, every hash checks out and the modification is invisible to a verifier.
The structural fix is separating the sealing authority from the agent operator into different trust boundaries. If the entity that signs the final log doesn't control the agent process, chain reconstruction requires compromising both independently. This maps to what an auditor actually needs when the operator is a party to a dispute, not just "operator-attested" but "independently attested."
Your Article 12 framing is correct. The depth people underestimate is usually this layer, not the logging itself.
Yeah, this is the bit that separates people who have actually sat across from an auditor from people who just read the article. You nailed it.
Hash chaining only proves the chain agrees with itself, and guess who can rebuild it. If I hold the storage and the signing key I can rewrite history and every link still checks out, the verifier sees nothing. So "operator attested" is basically worthless the second the operator is a party to the dispute, which is the only time anyone bothers pulling the logs anyway.
The split you describe is the actual fix, and it does not have to be heavy. Anchor the batch digests to something the operator does not control, an external timestamping authority or a public transparency log, and now faking the chain means breaking into two places instead of one. That is the whole jump from "trust me" to "go check yourself".
Good comment. This is where the next version of the checklist has to go deeper.
Anchoring it to an external TSA is exactly where Sasana's evidence model already points. SESSION_START now anchors to Freetsa before any agent events exist; the SHA-256 hash gets submitted, and the returned RFC 3161 token is embedded directly in the chain. Strip the token and the hash changes, breaking the next event's chain link immediately.
The current in process verifier checks hash chain integrity and MessageImprint match, it doesn't walk the full PKI chain against Freetsa's root cert yet. With that final check
(openssl ts -verify), rewriting history means either breaking the hash chain or forging an independent TSA signature, not just compromising the operator.Without it, a sophisticated attacker could still construct a syntactically valid token with the correct MessageImprint, since the TSA's actual signature isn't verified in-process. Documented as a known v1.0 limitation, the full guarantee exists today, just split between Sasana's verifier and one
opensslcall rather than fully automated yet.Code's here if useful: github.com/sahiee-dev/Sasana . Curious whether you've seen teams ask for transparency-log anchoring (CT-style) instead of TSA, seems like the next layer up from what we're both describing.
Open-sourcing a compliance checklist is a real public service - this stuff is dense, and most teams either ignore it or over-react. Article 12 (record-keeping/logging for high-risk AI) is exactly the one people misread because it sounds like a paperwork formality, when it's actually a technical requirement: you need automatic, tamper-evident logs of the system's operation, designed in from the start, not bolted on before an audit. The misread is treating "logging" as ops hygiene rather than a first-class system feature you must build.
The practical implication that follows: if Article 12-style traceability might apply to you, the cheap time to add it is now - structured event logs of what the AI did, what inputs it saw, what a human reviewed - because retrofitting an audit trail onto a system that wasn't designed to produce one is brutal. That logged-by-design stance is something I bake into Moonshift (a multi-agent pipeline that ships a prompt to a deployed SaaS) - every step emits a traceable event, partly because "prove what happened" is going from nice-to-have to legal requirement. Great resource to open-source. What's the most common Article 12 misread you saw - people thinking it doesn't apply to them, or underestimating the logging depth required?
Honestly both, but if I had to pick one, it's the "doesn't apply to me" misread. Teams classify themselves as limited-risk when their feature actually sits in Annex III, so Article 12 never gets on the roadmap. By the time someone catches it (usually procurement at a big customer), they're 6 months from the deadline and need to retrofit logging onto a system that was never built to produce an audit trail. Painful exactly like you said.
Underestimating the depth comes second. People think "we already log errors" covers it. The Act wants inputs, outputs, model version, who reviewed, retention horizon. Smaller gap to close than the first one but it still bites.
First of all: thank you! Every effort to simplify or make digestible any law that affects all of as is welcome.
I would suggest you, to say who you are, who are "we" and things like that, in order to get more credibility ;-)
Fair, you're right. I'm Gatis, running this from Riga. The "we" is me plus a couple of people on the audit side. Should probably say that somewhere in the post.
Not a lawyer. We work with EU counsel for the formal interpretation. The checklist is the engineer readable version we wished existed, sitting in between the €15k law firm memos and the vague summaries that don't say anything useful.
Thanks for reading.