Chenna, M.Essays

Essay · The evidence layer

Article 26 Is a To-Do List

The EU AI Act's deployer obligations read like law but decompose like a backlog. Monitor, log, suspend, inform: four duties, each an engineering task, and the quiet assumption under all of them is that you know what your system is.

scroll to read

Essay · The evidence layer

Article 26 Is a To-Do List

The EU AI Act's deployer obligations read like law but decompose like a backlog. Monitor, log, suspend, inform: four duties, each an engineering task, and the quiet assumption under all of them is that you know what your system is.

Chenna, M. · Founder, Sanctity · Amsterdam · August 25, 2026

Most coverage of the EU AI Act aims at providers, the companies building the models. But the Act has a second addressee that gets far less attention and holds far less power: the deployer, the company that takes someone else's AI system and points it at the world. If that is you, Article 26 is your article, and I want to read it the way an engineer reads it, because underneath the legal language it is not a philosophy. It is a to-do list, and one of its items is quietly impossible with the tooling most deployers have today.

The duties, as tickets

Strip Article 26 to its verbs and you get a backlog. Use the system in accordance with its instructions for use. Assign oversight to people with competence and authority, which is the human-in-command problem wearing legal clothes. Monitor the operation of the system. Keep the logs it generates. If you have reason to think it presents a risk, suspend use and inform the provider and the authorities. Every one of those converts to work: a runbook, a staffing decision, a retention pipeline, an escalation path. Treat them as tickets and most are simply effort. Except one.

The impossible ticket

Monitor the operation of the system. Simple words, and every deployer believes they are doing it, because they have dashboards. But monitoring means comparing what the system does against what it is supposed to do, and here is the assumption hiding under the whole article: that the system you are monitoring today is the system that was assessed yesterday. When your AI runs on a third-party model behind an API, that assumption is unverified every single day. The provider can change the model without your knowledge, and your monitoring, built on your own traffic and your own logs, is structurally unable to notice cleanly. I wrote the full argument in Your AI Changed Last Night, Prove It. In Article 26 terms: you cannot monitor the operation of a system whose identity you cannot establish.

Logs of what, exactly

The log-keeping duty has the same trapdoor. Your logs record what your system did: inputs, outputs, timestamps. They do not record what your system was. If the model beneath you changed mid-quarter, your logs describe the behavior of two different systems under one name, and nothing in them marks the seam. When an incident review or an authority asks what the system was doing in a given week, a log without identity is an answer without a subject. The record that completes it has to come from outside your telemetry: an independent, continuous measurement of the model itself, which is precisely the record a deployer cannot generate alone and the provider will not volunteer.

Suspend on what evidence

The sharpest duty is the conditional one: if you have reason to consider the system presents a risk, suspend and inform. Reason built on what? A feeling that answers got worse is not a document you take to a provider or a regulator. The suspend duty silently requires an evidence threshold, and an evidence threshold requires a baseline, and a baseline requires someone to have been measuring before the bad week started. This is the pattern across the whole article: every duty is straightforward until you ask what evidence would discharge it, and then every road leads to a record nobody in the transaction is neutral enough to keep.

The file that survives a hostile read

So here is Article 26 as a completed checklist rather than an aspiration. Instructions: on file, matched to a verified model identity, not just a name on an invoice, which is its own problem I covered in The Model on the Invoice. Oversight: named humans, with the four conditions of command evidenced. Monitoring: your telemetry for your side, an independent behavioral record for the model's side, so drift is detected and dated rather than felt. Logs: yours, plus the identity record that gives them a subject. Suspension: a defined threshold against a measured baseline. That file survives a hostile read. The default file, dashboards and good intentions, does not. The gap between the two is not legal sophistication. It is one missing layer of evidence, and it is buildable now.

And a closing note on posture. Deployers tend to read the Act defensively, as risk to be minimized. Read it instead as a free specification for a system you should want anyway: monitored, evidenced, suspendable, answerable. Companies that build the checklist because it makes their product defensible will find compliance arriving as a side effect, which is the cheapest way compliance ever arrives.

Read on

The drift argument: Your AI Changed Last Night. Prove It. The identity argument: The Model on the Invoice. The instrument: modelometer.com.