Control-level compliance: the EU AI Act as an instrumented system

There are two ways to comply with the EU AI Act, and they look almost identical on paper. The first is to write a policy for each obligation: an AI governance policy, a human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry → protocol, a data governance policy, an incident response procedure. The binder is thick, every article has a corresponding document, and an organisation can point to it and say it is compliant. The second is to build the obligations into the system itself, as controls that operate automatically, produce evidence, and can be demonstrated on request. The binder is thinner, because most of the compliance lives in the system rather than on paper.

The difference between the two does not show up in a procurement review. It shows up when a supervisory authority asks not "do you have a policy on this" but "show me that it worked". A policy describes what should happen. A control is what happens, and the log is the proof that it happened. The EU AI Act's technical articles are written, increasingly, to be satisfied by the second kind of compliance. They describe controls, not aspirations, and reading them at the control level reveals what an instrumented compliance system looks like.

What the articles ask for, read as controls

The technical obligations of the EU AI Act translate, almost one for one, into system controls. Read this way, the regulation stops being a list of things to write about and becomes a specification for things to build.

Immutable audit logs (Art. 12 and Art. 19). The system must automatically generate logs that are tamper-resistant, retained for at least six months, and detailed enough to reconstruct its operation. The control-level reading is precise: database logs that an administrator can edit do not qualify, because a record that can be changed is not evidence. The control is automatic generation plus immutability plus retention, and the proof is the log itself.

Human oversight with a kill switchkill switchThe designed-in, rehearsed ability to suspend or deactivate an AI system quickly when containment requires it.Open full entry → (Art. 14(4)(e)). The system must let a human bring it to a safe state in a single action, and the act of intervening must itself be logged. This is not a policy stating that humans are in control. It is a mechanism that makes the control real and a record that proves it was available and, when used, used.

Real-time data protection (Art. 10). Sensitive data is masked or redacted at the input level, before it reaches the model. The control operates at the prompt, not in a retrospective review, because the point is to prevent the exposure rather than to document it afterward.

Configurable block policies (Art. 26 and the prohibitions of Art. 5). Certain categories of use are blocked entirely, enforced by the system rather than discouraged by a guideline. This is policy as code, not policy as PDF: the rule is executed automatically, every time, rather than relying on a person to remember and apply it.

Risk scoring and incident reporting (Art. 9 and Art. 73). Risks are scored continuously through the risk management system, and serious incidents are reported to the competent authority within the deadline. The control is the instrumented pipeline that detects, scores, and escalates, with the reporting timeline built in rather than left to someone to remember.

Workspace isolation and role-based access (Art. 14 and Art. 26). Different data classifications require different surfaces, enforced by isolation and access control. A user sees and can act on only what their role permits, and the boundary is structural rather than procedural.

Read together, these are not six policies. They are six controls, each engineered into the system, each producing evidence, each demonstrable. That is what compliance looks like at the control level: not a policy document, but an instrumented system.

Why the control level is the level that matters

The case for control-level compliance is not aesthetic. It rests on three properties that policy-level compliance lacks.

The first is provability. A policy asserts that something should happen; a control, with its log, proves that it did. When a supervisory authority investigates, the question is always evidential. An organisation that can produce the immutable log, the record of the stop mechanism being available, the timestamp of the incident report, answers the question. An organisation that can only produce the policy describing these things has described its intentions, not its conduct.

The second is reliability. A policy depends on people remembering and applying it, every time, under pressure. A control executes automatically, every time, regardless of who is on shift or how busy they are. The block policy enforced as code blocks the prohibited category on the worst day as reliably as the best. The policy as PDF is only as reliable as the least careful person who was supposed to follow it.

The third is scale. A growing organisation cannot police every AI interaction by hand. Controls scale because they are part of the system; policies do not, because they depend on human attention that does not multiply. The organisation that instruments its compliance can grow its AI use without growing its compliance risk in proportion. The organisation that relies on policies finds that each new system, each new user, each new use case widens the gap between what the policy says and what happens.

The relationship to the GovCompass-7

Control-level compliance is the operational expression of the same idea that underlies the GovCompass-7 framework: responsible AI is a control problem, not a statement of values. Where the GovCompass-7 organises the controls around seven elements of responsible AI, the control-level reading of the EU AI Act organises them around the specific articles. They are two views of the same system. An immutable audit log serves the accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress — never the system itself.Open full entry → element and satisfies Art. 12; a kill switch serves the human oversight element and satisfies Art. 14(4)(e); data masking serves the privacy element and satisfies Art. 10. The framework and the regulation converge on the same controls, which is the strongest possible sign that those controls are the right ones.

What this means in practice

For an organisation deciding how to approach the EU AI Act, the choice between the two kinds of compliance is really a choice about where the work lives. Policy-level compliance front-loads the writing and back-loads the risk: the binder is produced quickly, and the gap between the binder and reality is discovered later, usually by an incident or an audit. Control-level compliance front-loads the engineering and back-loads the confidence: the controls take longer to build, but once built they operate, prove themselves, and scale.

This is not an argument that policies are worthless. The EU AI Act requires documentation, and policies have a role in setting direction and allocating responsibility. The argument is about where the centre of gravity sits. In a compliance programme built on policies, the documents are the compliance and the system is an afterthought. In a programme built on controls, the system is the compliance and the documents describe it. The first looks complete and fails quietly. The second looks modest and holds up.

That is what compliance looks like at the control level. Not a policy document. An instrumented system.