The two posts I wrote in February about building AI platforms under European law, compliance-as-code and fine-tuning, stop at the architecture. They say where the compliance layer sits and not much about what goes in it. The AI Act is written in clauses, and each clause ends up as something specific in the code: a field in a log, a state in the UI, a test in CI. Most of what I read about the Act is written for lawyers or for the board, and very little of it gets as far as a pull request.
So from today, Fridays on this blog are for AI law. Each week I take one article of the EU AI Act, or one of the UK's rules on automated decisions, put the text up verbatim, and annotate every clause for the engineers who have to build to it. The first is Article 50, on 20 November.
The Digital Omnibus came into force on 27 July and moved the high-risk obligations for Annex III systems (recruitment, credit scoring, education, essential services) to 2 December 2027. Most teams now know the date and have not started building, which makes this a good year to read the text properly.
What a page looks like
Each post is one whole article, with the text front and centre. Click a clause, or tap it on a phone, and a panel opens with the clause quoted with its pinpoint, a plain reading of what it means, and the notes. Notes come in five kinds, each with its own colour, and you can filter by kind: software, contested, guidance, elsewhere in the law, and dates.
This is one clause from the Article 50 page, as the panel shows it.
Article 50(2), the standard editing exception
"This obligation shall not apply to the extent the AI systems perform an assistive function for standard editing"
What it means. Tools that only help prepare existing content for publication (grammar, spelling, formatting, compression, red-eye removal) need not mark their output as AI-generated. Once the change affects meaning, style or intent, it is no longer standard editing.
Software. One system can be exempt for some outputs and not others. "Fix grammar" is standard editing, while "Rewrite in a formal tone" changes style and must be marked, and the Commission's guidelines confirm the exception applies to the altered content rather than to the system as a whole. So the code that applies the mark needs to know which feature produced each output. A single marked: true at the API gateway either over-marks the spellchecker or under-marks the rewriter. (Guidelines ¶92)
Contested. The guidelines' own list of standard editing includes "AI-generated translations of text", next to spellchecking. A translation can change meaning, and the same guidelines say editing stops being standard when it does. A translation that localises tone and idiom for a market is rather close to the rewriting they say must be marked. (Guidelines ¶90, ¶92)
The Article 50 page has 33 clauses and 38 notes like that. Every clause and note has its own link, which is handy when you want to send someone the exact sentence you are arguing about.
Notes keep arriving after a post goes out
Publishing a post doesn't freeze the page. When new guidance comes out, or someone tells me I have read a clause wrong, I add a note with the date it went in, and the log at the foot of the page lists every change by date. A few lawyers I know are reading the drafts, and when they correct me the correction goes in as a dated note with their name on it.
The first three
- 20 November. Article 50, the transparency duties: telling people they're talking to an AI, and marking generated content. It has applied since 2 August, and the grace period for marking output from systems already on the market ends on 2 December.
- 27 November. Article 6, which decides whether your system is high-risk, with its four exceptions at the centre.
- 4 December. Article 26, the duties of deployers, the companies that use a high-risk system rather than build it.
I am an engineer, not a lawyer, so treat all of this as an engineer's reading and not as legal advice.
Top comments (0)