The EU AI Act in the Runtime: A Practitioner's Reading

We should say plainly what this piece is and isn't. We are not lawyers, we are not offering legal advice, and nothing here should be treated as a compliance determination for any specific system — that's a conversation for counsel who knows your risk classification and your member-state context. What follows is a practitioner's reading of what the EU AI Act asks for at the level we actually work: the runtime, the logs, the interfaces a human uses to oversee a system. And from that vantage point, the most common failure mode we see isn't misunderstanding the law. It's building the compliance artifact — a binder, a risk memo, a conformity assessment — as a document that describes the system, rather than as a set of properties the running system actually has.

Where the obligations actually live

Strip away the legal scaffolding and the high-risk-system obligations that matter to us as builders cluster around a few concrete, engineerable properties, not a compliance narrative.

Logging that supports reconstruction, not just monitoring. The Act's record-keeping expectations for high-risk systems are oriented around being able to reconstruct how the system behaved and why — which is a materially different requirement from "we have application logs." Application logs tell you what happened at the service level. Reconstruction requires the evidence a specific decision was based on, the model or ruleset version active at the time, and enough context to answer a specific challenged outcome months later. We've written about instrumenting decisions as their own spans elsewhere; the point that matters here is that this kind of logging is an architectural decision made before launch, not something you can retrofit by turning up a log level after a regulator asks a question.

Human oversight that's a real interface, not a checkbox in a policy document. "A human can review the system's outputs" is easy to write in a governance document and genuinely hard to build well, because the oversight has to be meaningful — the reviewer needs enough context, at the right moment, to actually catch something wrong, not just a button that says "approve" next to a pre-filled recommendation they'll learn to click without reading. We cover the interface design side of this at length elsewhere; the compliance-relevant point is narrower: an oversight mechanism that exists on paper but produces rubber-stamping in practice is not the control the Act is asking for, even if it technically satisfies a checklist.

Risk classification that changes what the runtime actually enforces, not just what the paperwork claims. A system classified as high-risk carries specific runtime obligations — around logging, oversight, robustness — that a classification memo alone doesn't satisfy. We've seen classification exercises completed thoroughly and accurately, and then never connected to an actual change in what the running system logs, exposes to reviewers, or refuses to do autonomously. The classification becomes correct on paper and irrelevant in production, which is worse than being wrong, because it creates the appearance of compliance work having been done.

The paperwork exercise, and how to tell you're in one

The honest tell is directional: if your compliance work flows from the system to the document — an engineer describes what the system does, and a compliance team writes that description into the required artifacts — you're doing real compliance work, even if it's incomplete. If the work flows the other way — a compliance team defines the artifact structure, and engineering is asked to make the system's behavior match a pre-written description — you're in a paperwork exercise, and it tends to produce systems where the documentation and the running code diverge within a few release cycles, because nothing in the process re-verifies the match.

A second tell: ask whether the logging, oversight interface, and risk controls the Act asks for would survive the compliance team being reorganized out of existence next quarter. If those properties are enforced in the runtime — the logging happens because the code emits it, the oversight interface exists because it's the interface reviewers actually use, the risk controls fire because they're in the decision path — they survive. If they exist because a policy document says they should and a person is manually checking that reality matches the document, they don't, and that fragility is itself informative about how real the compliance posture currently is.

What we'd actually prioritize, engineering-first

If we were sequencing this work for a system likely to fall under high-risk obligations, we'd build the decision-level logging first, before the oversight interface and before the formal risk documentation — not because logging is more legally central, but because it's the dependency everything else needs. You can't build a meaningful human oversight interface without decision-level evidence to show the reviewer, and you can't accurately classify or document a system's actual risk profile without the logs to tell you what it's actually doing in production versus what the design doc says it does. Start there, and the paperwork gets easier to write honestly, because it's describing a system that already has the properties being claimed — which, again, is an engineering judgment about sequencing, not a legal one about sufficiency, and the actual compliance determination still belongs to counsel who can see the whole picture.