Most regulations are annoying to read but structurally simple: one set of rules, one deadline, done. The EU AI Act (Regulation 2024/1689) is a different kind of problem. It doesn't impose one obligation — it imposes four parallel sets of obligations, each gated by a different risk tier, each with its own deadline, and each aimed at a different actor in the chain (the provider who builds the system vs. the deployer who runs it).
I spent some time recently turning that structure into a plain, static reference site (reglementation-ia.fr) for AI Act compliance, and the interesting part wasn't the legal research — it was deciding how to model the regulation so the content didn't collapse into a wall of text.
Four tiers, not one checklist
The Act splits AI systems into:
- Prohibited practices (Article 5) — a short, closed list, immediate effect.
- High-risk systems (Annexes I & III) — the heavy one: eight core obligations for providers (risk management, data governance, technical documentation under Annex IV, automated logging, clear instructions for deployers, human oversight, accuracy/robustness testing, a quality management system, plus CE marking and EU database registration), and a separate, shorter list for deployers (use the system as instructed, maintain competent human oversight, validate input data, monitor operation, retain logs for six months, run a rights impact assessment if you're a public body or essential-service operator, and notify affected individuals).
- Limited-risk systems (Article 50) — mostly transparency: tell the user they're talking to a chatbot, that content is AI-generated, or that emotion-recognition/biometric categorization is in use.
- General-purpose AI models — a track of their own: documentation, copyright compliance, training-data transparency, and for models flagged as "systemic risk," adversarial testing and incident reporting.
Each tier also moves on its own clock. High-risk obligations split again depending on which Annex applies (Annex III systems land on one date, Annex I-embedded systems land later). GPAI systemic-risk obligations were already live well before either of those.
Why that breaks a normal content model
A typical "guide" page structure — one article per topic — actively hides this. If you write "Obligations for AI Providers" as a single page, you either flatten the risk tiers (inaccurate) or bury four different deadlines in one wall of prose (unreadable, and in a compliance context, genuinely risky — someone will read the wrong paragraph and assume the wrong deadline applies to them).
What worked better was treating (tier × actor) as the actual content unit, not "topic." Each combination — high-risk/provider, high-risk/deployer, limited-risk/user-facing, GPAI/model-provider — gets its own obligations list, its own applicable date, and its own one-line "who this is" test at the top, so a reader can rule themselves out in one sentence instead of reading the whole page to find out it doesn't apply to them.
The practical build is unglamorous: plain PHP, no framework, obligations stored as structured per-tier arrays rather than free text, so the same data can render both a "by risk tier" page and a "by deadline" calendar view without maintaining the facts twice. That duplication — the same obligation text copy-pasted into two different narrative pages — is exactly the kind of drift that makes a compliance reference untrustworthy six months after a clarification.
The boring lesson
None of this required clever engineering. It required resisting the urge to write the regulation as an essay, and instead modeling it as the thing it actually is: a small matrix of (who you are) × (what tier you're in) × (what date applies to you). The full breakdown, with the eight provider obligations and the shorter deployer list, is up at reglementation-ia.fr/obligations-par-risque if you're trying to figure out which column of that matrix you're actually in.
If you're building anything that has to represent tiered regulation — AI Act, but also things like CSRD or the EU Data Act — I'd genuinely recommend modeling by (actor × tier) from day one. Retrofitting it after the content is already written as prose is much more painful than it looks.
Top comments (0)