The EU AI Act as engineering controls: Article 14 first

The problem with compliance libraries

For the governed agent platform I designed for Dutch local government, I built a compliance library: about fifty frameworks in eight categories. EU law, from the AI Act and GDPR to NIS2, the Cyber Resilience Act, the Data Act and eIDAS 2. Dutch administrative law, the open-government act, archiving law. The ISO and IEC management-system standards. The Dutch government assessment frameworks, the human-rights impact assessment used as the national form of the fundamental-rights assessment, the algorithm register. Sector law for social support, youth care, participation.

Each framework file has the same structure: summary, who is affected, what it asks of the platform, open items, sources. That is useful. It is also where most organisations stop, with a library that describes obligations and a platform that does not implement them.

The honest moment in my own library came when I declared its “what we already cover” sections invalid. They described a system that did not exist when they were written. What each framework asks remained valid as requirements. The coverage claims did not. If your compliance documentation has a coverage column, ask who verified it against running code.

So this piece is about the other half: turning an obligation into a control an engineer can build and a tester can fail.

Article 14, first

Primary source: Regulation (EU) 2024/1689, the AI Act, Article 14 on human oversight. What follows is my design reading of it, not legal advice; each deploying organisation’s data-protection officer rules for their own deployment.

Human oversight is the article most AI strategies get wrong, in one of two directions. Either every action gets a human approval, which does not scale and becomes a rubber stamp. Or “a human is in the loop” is written on a slide and nobody can say where.

My design reading, stated as a design reading and not a legal ruling, because each deploying municipality’s data-protection officer rules for their own deployment, is this:

Position one. Pre-approval in the loop where the stakes require it; supervision on the loop elsewhere; and proof that the override was reachable. Irreversible and high-stakes effect classes keep explicit approval before execution. Lower-stakes classes run with a human on the loop who can see, stop and correct. The record must show that the stop and the override were reachable at the moment they mattered, not merely logged afterwards. Article 14 asks for oversight proportionate to the remaining risk, not pre-approval of everything; which effect class sits on which side follows the autonomy grading. Authority scales with stakes; controls scale with capability.

Position two. A human gate counts as oversight only if it declares mandate, time and a sanctioned right to refuse. An approval outside the approver’s mandate is refused, with a record. A refusal is a first-class outcome, not an error. Each human step declares how much time per decision it is given, and an undeclared gate is reported as such. A gate without those three things is theatre.

Position three. A published override rate. The aggregated rate at which humans override or reject agent proposals, with its denominator, shown next to each deployment’s value and never per employee. A rate of zero is a finding, not a success: it means nobody is reviewing, or the gate is in the wrong place.

The strongest counter-argument, that human-in-the-loop does not scale, is right about per-action approval and wrong about oversight. Oversight is three different controls: approval before an irreversible act, supervision with a reachable stop, and accountability afterwards through a reconstructable record. Each has its own mechanism. Conflating them is how organisations end up with the rubber stamp.

A companion position: the control plane governs actions and authority at the tool boundary, not model outputs. Work that can be described in advance runs as a workflow, a rule set or a solver with no model in the path at all.

Kant asked us to treat people as ends, never merely as means. A human gate without mandate, time or the right to refuse treats a person as a means of producing a signature.

Twelve articles, twelve controls

Article numbers refer to Regulation (EU) 2024/1689. The pairing of article to control is my interpretation; the regulation prescribes outcomes, not mechanisms.

Stated generically, with the control pattern that answers each. “Control” here means something that can be built, tested and evidenced, not a paragraph.

• Article 12, record-keeping. Automatic, append-only, hash-chained evidence for every decision, approval and effect, packaged as an evidence artefact a third party can verify without trusting the actor. A log is what a system says about itself. An audit trail is what someone else can check.
• Article 14, human oversight. Fail-closed approval gates on high-stakes effect classes; a reachable stop and override on the loop; mandate, time and refusal declared per gate; the published override rate.
• Article 13, transparency to deployers. A declared-limitations block in every evaluation contract, naming the dimensions not covered and the oracles absent, plus deployer instructions. Evaluation is never presented as certification.
• Article 15, accuracy, robustness, security. Accuracy declared through that same limitations block; robustness and security evidenced by measured tests, not asserted.
• Article 9, risk management. A per-capability risk register, updated on every version and re-assessed on a schedule.
• Article 11 and Annex IV, technical documentation. Templates per capability archetype, pre-filled from the signed capability manifest, so documentation derives from what is deployed rather than the other way round.
• Article 49, registration. Algorithm-register entries and EU database fields generated from the manifest.
• Article 72, post-market monitoring. Drift detection on accuracy, bias and usage patterns, compared against what the impact assessment declared, with alerts to the capability owner.
• Article 73, serious incidents. An incident workflow with deadline tracking and a reporting template, wired to the same evidence record.
• Article 27, fundamental-rights impact assessment. The platform supplies structured input to the deployer’s assessment; it does not perform it.
• Article 50, transparency to people. Disclosure at first contact, with wording supplied by the deploying organisation, and a machine-readable provenance mark on AI-generated content.
• Article 5, prohibited practices. A named enforcement point, so that “we do not do that” is a check and not a sentence.

Log retention under the deployer obligations is a case where I deliberately stop short: the retention policy must meet the statutory minimum, and that is a policy statement until the retention engine exists. I would rather say that than list it as implemented.

Classification before design

Every capability is classified up front as limited or high risk, with a rule of thumb: a capability that affects a decision with direct legal or material consequences for a person falls under Annex III; a capability that only finds or summarises information is usually limited risk. The classification drives which controls above are mandatory and which assessments must exist before the capability is admitted. Doing this first is cheaper than doing it in a tender response.

What the other frameworks add

The threat register maps to the OWASP lists and the MITRE ATLAS matrix for traceability, and the mapping says so: mapped means traceable, not mitigated. The voluntary risk-management frameworks are crosswalk candidates, not requirements; a vendor claim that one of them “demands” something was checked against the primary text and did not survive. An in-process governance library from a major vendor is adopted only for layers the platform owns and never as an enforcement point, because its own documentation says it shares the process boundary with the agent. The rule that follows: an in-process governance library is a component, never a kernel; a library the governed code can decline to call is not a control.

What I cannot prove

Prototype grade. The controls above are designed; some have instruments, some do not, and the library’s own open-items list says which. There is no conformity assessment, no notified body, no certification, and I claim none. There is also an evidence gap I would rather name than hide: the Article 14 reading rests on the regulation and on international practice, and I have not yet found a Dutch institutional primary source that settles it. When one appears, the position may move.

If you take one thing

Take Article 14 and write down, for your highest-stakes AI use case, the three things: which actions require approval before execution, who holds the mandate and how much time they are given, and what your override rate was last month. If any of the three is blank, you do not yet have human oversight. You have a plan to have it, which is a fine place to start, as long as nobody is told otherwise.

References

The allusions and quotations in this piece, with their origin:

• Immanuel Kant, Groundwork of the Metaphysics of Morals (1785): the formula of humanity, treat persons as ends and never merely as means.
• The Office (BBC, 2001-2003): David Brent, Ricky Gervais’s manager at Wernham Hogg.