What the EU AI Act actually requires, and what most organisations are missing.

A financial services firm deployed an AI agent to assist with credit decisions. Six months later, a regulator asked a straightforward question: who is accountable for the decisions this system makes? The firm's legal team pointed to the vendor contract. The technology team pointed to the model card. The compliance team pointed to the policy document. Nobody could name a human who had reviewed a specific decision and could defend it without re-running the model. That is an EU AI Act problem. It is also an AI governance problem. They are, in almost every material respect, the same thing.

The EU AI Act came into effect in August 2024. Enforcement of the highest-risk obligations begins in 2025 and 2026, with broader requirements phasing in across 2027. Most organisations are treating compliance as something their legal team is handling. That is a category error, and an expensive one.

The Act's practical requirements cannot be met through legal interpretation alone. They require operational change: new accountability structures, new audit trails, new human-gate checkpoints at the points where AI makes or influences decisions that affect real people. What most organisations are missing is not knowledge of the law. It is the governance infrastructure the law assumes they already have. The Act, read operationally, restates a single principle the rest of this site puts more plainly: the agent drives, the human navigates, and the navigator has to be named, present, and able to defend a specific decision.

The Act is a response to how AI is actually being used.

The EU AI Act is not a technology regulation. It is an impact regulation. The same model powering a smartphone's unlock feature and the model evaluating a loan application face completely different legal obligations, because their impact on human lives is completely different. The Act classifies AI systems by what they do and who they affect, not by how they are built.

This distinction matters because AI has fundamentally changed what it does. For the first ten years of commercial AI deployment, AI was primarily a tool, it helped humans do things faster. A human remained in the decision seat; AI was in the copilot seat. That model has changed.

AI agents now make recommendations that get acted on without meaningful human review. They generate code that ships to production without being read. They produce assessments that become the basis for decisions affecting employment, credit, medical triage, and legal outcomes. The Act is the regulatory response to that trajectory. It mandates that when AI has that kind of impact on individuals, a named human must remain accountable for it.

"The Act didn't create the accountability requirement. It made visible that most organisations were already failing it."

Impact determines obligation.

The Act's risk classification system is the most important thing organisations need to understand, and the most frequently misunderstood. Most organisations assume their AI systems are low-risk because they are not doing anything obviously dangerous. That assumption requires scrutiny.

The Act defines risk by use case and impact on people, not by technical sophistication. An AI system that influences employment decisions, credit assessments, insurance pricing, or law enforcement outcomes is classified as high-risk regardless of how accurate it is, how well it was built, or what the vendor's model card says. A general-purpose model used in a high-risk context is a high-risk system.

Most organisations deploying AI in 2026 have not mapped their AI systems against the Act's risk categories. They have a list of tools and vendors. They do not have a classification of AI systems by use case, impact, and obligation. That is the first gap the Act will expose when enforcement arrives.

It is a governance problem, not a legal problem.

Here is what the Act actually requires of high-risk AI systems, translated from legal text into operational language:

A named human is accountable for the system. Not a team, not a function, not a vendor, a named individual who can be questioned about specific decisions the system made.

Decisions are logged and traceable. When the system makes or influences a decision affecting an individual, there is a record: what input it received, what output it produced, what human reviewed that output, and whether it was approved or overridden.

Humans can override the system. The Act requires genuine human oversight, the ability to intervene, correct, and override AI outputs in real time. A human who sees an output but cannot meaningfully evaluate it is not exercising oversight under the Act's definition.

The system is monitored after deployment. Performance metrics, accuracy rates, failure patterns, monitored continuously, with defined thresholds that trigger review. Not a one-time evaluation at deployment.

Documentation exists for an auditor. An inspector from a national supervisory authority should be able to walk into your organisation and, within 48 hours, receive: what the system does, what risk class it was assigned, who is accountable for it, how it has been tested, and what the human oversight process looks like.

None of these requirements are legal in nature. They are operational. A legal team can identify whether the obligation applies. Only an engineering and governance function can build the infrastructure that meets it.

What "ready for the Act" actually looks like.

Readiness for the EU AI Act is not a legal certification. It is an operational posture. Six capabilities define it:

1. Classify by impact
   Map every AI system in use against the Act's risk categories, by what it does and who it affects, not by what the vendor says it is. Assign a risk class to each system. Document the classification and the reasoning.
2. Name accountability
   For every AI system above minimal risk, name a specific individual who is accountable for what it produces. Not a team. Not a role. A named person who can be questioned about a specific decision and defend it without re-running the model.
3. Build human oversight in
   Define the human checkpoints where review and approval are required before AI outputs are acted upon. These checkpoints must be real, a human who genuinely evaluates the output, not one who acknowledges receipt of it. Document who is reviewing, what they are reviewing against, and what the outcome was.
4. Design audit trails
   Log what each AI system receives, produces, and triggers, with timestamps, named reviewers, and approval records. The audit trail should be readable by a third party who was not present at the time. Design it that way from the start, not as a retrofit.
5. Monitor in production
   Define the metrics that indicate the system is performing within acceptable bounds. Set thresholds. Monitor continuously. Build a process for what happens when a threshold is breached, who is notified, what review occurs, when the system is paused or corrected. This is post-market surveillance under the Act.
6. Document and attest
   Maintain the documentation that demonstrates all of the above. Not as a policy document, as a living record of actual practice. An auditor reading it should be able to trace a specific decision to the human who reviewed and approved it, and to the evidence that the system was operating within its validated parameters at the time.

The Navigator Framework connection.

An organisation that has implemented the Navigator Framework's Controls Catalogue and reached Stage 2 or above is, in operational terms, largely ready for the EU AI Act's high-risk obligations. The correspondence is not accidental.

The Navigator Framework's five phase gates produce exactly the documentation the Act requires: named human approval at every material stage, attestation templates that create auditable records, risk classification per project against categories aligned to the Act, and the AI-Absent Drill that proves operational resilience independent of AI tool availability.

The framework was not designed to produce EU AI Act compliance. It was designed to close the human oversight gap in AI-native development. The Act, it turns out, is trying to close the same gap. The organisations that will find Act compliance straightforward are not the ones that have hired more legal counsel. They are the ones that built accountability structures into how they develop and deploy AI from the start.

The organisations that will find it most difficult are the ones that shipped AI fast and assumed governance could be retrofitted. For them, the Act is not primarily a legal problem. It is a governance debt notice, and the interest is compounding.