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

There are two ways to comply with the EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry →, 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. It is meaningful only when the human has authority, information and time to act. One of the seven pillars of responsible AI, and under the EU AI Act a requirement for high-risk AI systems: Article 14 requires that those systems are designed so natural persons can effectively oversee them. Oversight that exists on paper but amounts to confirming in practice does not meet that bar. See override rate, automation bias, high-risk AI system, fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, responsible AI. In the IAPP AIGP body of knowledge, this principle appears as human-centricity, with human oversight as one of its elements.Open full entry → protocol, a data governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → policy, an incident response procedure. The binder is thick, every article has a corresponding document, and an organization can point to it and say it is compliant. The second is to build the obligations into the system itself, as controlscontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → that operate automatically, produce evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry →, 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.

Automatic audit logs (Art. 12 and Art. 19). Art. 12(1) requires the system to generate logs automatically over its lifetime, and Art. 19(1) with Art. 26(6) requires them to be kept for at least six months. Tamper-resistance and immutability are not stated in Art. 12 or 19; they are a sound control choice you add, because a record that can be silently edited is weaker evidence. The statutory control is automatic generation plus retention; making the logs tamper-evident is your design decision on top.

Human oversight with a stop function (Art. 14(4)(e)). Art. 14(4)(e) requires the ability to intervene or interrupt the system through a stop button or a comparable procedure that brings it to a halt in a safe state. It does not mandate a single-action control, and it does not itself require the intervention to be logged. A single, easy stop and a log of overrides are sound control design; anchor the logging to your oversight log rather than to Art. 14(4)(e).

Runtime input masking (GDPRGDPRRegulation (EU) 2016/679, the General Data Protection Regulation, the EU's law on the processing of personal data. It applies to AI wherever personal data enters training, inputs, outputs, or logs, and it operates alongside the EU AI Act rather than being replaced by it. See controller, processor, lawful basis, DPIA.Open full entry → minimisation and Art. 26(4)). Sensitive data is masked or redacted at the input level, before it reaches the model. This is a GDPR data-minimisation control and, for deployersdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →, relates to Art. 26(4) (relevance of input data under the deployer's control), not Art. 10, which governs the training, validation and test datasets used to build the system, a design-time providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → duty. The control is sound; the legal anchor is the GDPR and Art. 26(4).

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.

RiskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → scoring and incident reporting (Art. 9 and Art. 73). Risks are scored continuously through the risk management system, and serious incidentsserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure. It triggers regulatory reporting duties for high-risk systems.Open full entry → 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 organization that can produce the immutable log, the record of the stop mechanism being available, the timestamp of the incident report, answers the question. An organization 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 organization 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 organization that instruments its compliance can grow its AI use without growing its compliance risk in proportion. The organization 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 seven pillars of responsible AI

Control-level compliance is the operational expression of the same idea that underlies the seven-pillarpillarA responsible-AI principle as something an organization actively holds rather than merely endorses: one of the seven pillars of responsible AI, one per principle. A pillar is held, not implemented, by naming the harms that would breach the principle, assessing their risk, and placing controls that reduce it. Distinct from agentic AI, which is not one of the seven but a condition that changes how all of them are governed. See principle, harm, risk, agentic AI.Open full entry → framework: responsible AIresponsible AIThe set of principles an AI system should live up to: fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, and human oversight. Widely shared and sitting under the EU AI Act and the major frameworks. On their own the principles are statements of intent; the law turns them into duties that cannot be met unless they are carried inside the organization's governance, which is how responsible AI lands in governance rather than beside it. The seven principles are organized into seven pillars, one pillar per principle. See principle, pillar, governance. The seventh principle carries two names in practice: human oversight in the seven-pillar model, and human-centricity in the IAPP AIGP body of knowledge; the substance overlaps.Open full entry → is a control problem, not a statement of values. Where the seven pillars of responsible AI organize the controls, the control-level reading of the EU AI Act organizes 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. The EU AI Act attaches obligations to the role rather than the technology, with provider duties in Article 16 and deployer duties in Article 26, supported by technical documentation (Article 11) and record-keeping (Article 12). See provider, deployer, record-keeping, responsible AI.Open full entry → pillar and satisfies Art. 12; a kill switchkill switchThe designed-in, rehearsed ability to suspend or deactivate an AI system quickly when containment requires it.Open full entry → serves the human oversight pillar and satisfies Art. 14(4)(e); data masking serves the privacyprivacyThe principle that personal data used by or produced through an AI system stays within the purpose and the legal basis it was collected for. Three routes cause most of the trouble: personal data in training material that was never intended for it, model output that reproduces what the model retained, and purpose creep, where a system built for one use drifts into another the original basis never covered. The GDPR governs this in full, and the EU AI Act adds data governance duties for high-risk systems (Article 10). See DPIA, purpose limitation, responsible AI.Open full entry → pillar 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 organization 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 center of gravity sits. In a compliance program built on policies, the documents are the compliance and the system is an afterthought. In a program 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.