Audit-first AI governance
← Insights
Readiness Brief

EU AI Act readiness: what "high-risk" obligations mean in practice

The Act reserves its heaviest obligations for systems it classifies as high-risk. Most of those obligations are unmet today — not because the policy is missing, but because nothing enforces it at the moment an action is taken. This brief translates the high-risk requirements into operational controls you can actually point to.

Reading the EU AI Act for the first time, most risk and compliance leaders have the same reaction: this is a lot, and most of it sounds like documentation. Risk management systems, technical files, data governance, logging, transparency, human oversight, accuracy and robustness — clause after clause that reads like a request for binders. That reading is a trap. The Act is not asking primarily for documents. It is asking for an operating model in which certain things are true at the moment a system acts, and provable afterward. The institutions that struggle will be the ones that produced the binders and left the moment of action ungoverned.

The tiered model, in plain terms

The Act sorts AI systems by the risk they pose and attaches obligations accordingly, in broadly four bands.

Prohibited. A small set of uses the Act treats as unacceptable and bans outright. Here the conversation is not about controls but about not doing the thing.

High-risk. Systems used in consequential contexts — the kind that affect people's access to credit, employment, and essential services. This is where the heavy, structural obligations live, and where almost all of the engineering and governance work concentrates.

Limited-risk (transparency). Systems that mainly carry an obligation to be honest about what they are — letting people know they are interacting with an AI system or that content was generated. The duty is disclosure, not the full high-risk apparatus.

Minimal-risk. Most everyday AI, largely unburdened by the Act's specific obligations.

The practical consequence is simple: high-risk is the line that matters. The first question for any system is not "how good is the model" but "which band is this in, and if it is high-risk, can we meet the structural obligations?" Classification is a legal and factual judgment about use and context — confirm it with counsel — but operationally, everything downstream depends on getting that answer right and then building for it.

The high-risk obligations, restated as controls

At the structural level, the high-risk obligations cluster into a recognizable set: a risk management system, data governance and quality, technical documentation, record-keeping and logging, transparency and information to users (Article 13 is the well-known transparency provision), human oversight, and accuracy, robustness, and cybersecurity. Read as a checklist, these invite a documentation exercise. Read as an operating model, each one names a control that has to be live where the system acts.

Record-keeping and logging → a signed decision record

The obligation is usually satisfied on paper with "we retain logs." But a log scraped together after an incident — timestamps from one system, model outputs from another, an analyst's recollection from a third — is a reconstruction, assembled by the party with an interest in the outcome after the outcome is known. The control that meets the intent is a decision record created at the moment of the decision: what was proposed, which checks ran, what evidence each relied on, the verdict, and a tamper-evident signature so later alteration is detectable.

Human oversight → an allow / block / escalate gate with a real person in the loop

Human oversight is one of the Act's core high-risk requirements, and the one most often reduced to a policy sentence: "a human reviews high-risk decisions." A sentence is not oversight. The control is a gate at the point of action that can allow, block, or escalate — and where it escalates, a named human reviews and approves before the action proceeds, with that approval captured in the record. Oversight that exists only as after-the-fact review of things that already happened is not the meaningful intervention the obligation contemplates. The capability to stop an action, exercised by a person with the authority to do so, is.

Transparency → being able to show why an action was taken

Article 13 transparency, operationally, is the ability to explain an output in terms a person can act on. For a consequential decision, "the model scored it below threshold" is not an explanation — it is the absence of one. The control is the ability to show, per decision, which policies and rules were checked, which passed, which failed, and on what evidence. That decomposition turns an opaque verdict into an account someone can scrutinize and, if necessary, challenge.

Risk management → controls at the point of action

A risk management system is meant to be continuous, not a one-time assessment filed away. The usual gap is that risk is identified in a document and then nothing enforces the mitigation when the system runs. The control is to put the mitigations where the action happens — bounded authority so a system cannot exceed what it is permitted to do, checks that run before the action rather than reports compiled after it, and an escalation path for the cases that fall outside the bounds. Risk management becomes real at the moment a risky action is permitted, blocked, or escalated. Everywhere else, it is intent.

Data governance, technical documentation, accuracy and robustness

These obligations are genuine and largely the institution's own to meet. Data quality and governance, the technical file, and demonstrated accuracy, robustness, and cybersecurity are program responsibilities that no control layer discharges for you. What an enforcement layer can do is supply contemporaneous evidence that feeds them: a signed trail of what the system did, under what authority, with what result.

Why these obligations go unmet — and where KAiM Helm fits

The pattern across almost every gap is the same. The policy usually exists. The oversight is written down. The logging is "in place." What is missing is enforcement at the moment of action — something that, when a system is about to do a consequential thing, checks it against the rules, decides allow or block or escalate, puts a human in the loop where one is required, and writes a signed record of the event. Without that, every obligation degrades into a document describing what should happen, and the moment that actually matters passes ungoverned.

This is the gap KAiM Helm is built to close. It runs six-axis checks at the point of action, returns an allow / block / escalate decision, enforces bounded authority so a system cannot exceed what it is permitted to do, routes escalations to human oversight, and produces a signed, reproducible record for every action it evaluates. Mapped against the high-risk obligations honestly: the contemporaneous signed record, the allow/block/escalate gate with human-in-the-loop escalation, per-decision transparency, and point-of-action risk controls are provided directly. Data governance, the technical file, and demonstrated model accuracy and robustness remain the institution's program to run; KAiM Helm supplies operational evidence into them rather than replacing them. It is at the design-partner and controlled-demonstration stage — the controls described here are real and demonstrable, and we make no customer-deployment or certification claims.

What KAiM Helm does not do is determine whether a given system is high-risk, or certify compliance with the Act. Classification and compliance conclusions are legal judgments. Anyone who tells you a product satisfies the EU AI Act on its own is overclaiming.

This brief is not legal advice. The Act's scope, classifications, specific article requirements, penalty levels, and phased timelines have precise legal meanings, and obligations phase in over time. Confirm how the Act applies to your systems — and on what schedule — with qualified counsel.

Key takeaways

The institutions that meet the Act's high-risk obligations cleanly will not be the ones with the thickest binders. They will be the ones that can show, for any consequential action, that it was checked against the rules, decided within bounded authority, escalated to a human where required, and recorded in a form built to be examined.

If you want to see how your high-risk systems would hold up — what is actually enforced at the moment of action today, and where the obligations are met only on paper — start with a Control Gap Assessment. It is a scoped read of your AI decisions against the high-risk controls above, with honest status for each one.