For two years the EU AI Act was something a legal team read and a product team ignored. That gap has closed. By 2026 the regulation is no longer a future memo: its first obligations are in force, the high-risk provisions are arriving, and the penalties for the worst breaches reach into the tens of millions of euros or a percentage of global turnover. For any enterprise operating in Europe, or selling into it, AI compliance has moved from the legal department to the engineering roadmap.

GRAL builds AI for exactly the industries the Act scrutinises most: finance, healthcare, and the regulated mid-market. We have learned to treat the AI Act not as paperwork bolted on at the end, but as a set of architectural requirements that good private AI satisfies by design. This is our engineering playbook: where the Act stands, what it demands, and how the way you build determines whether compliance is a scramble or a property of the system. One caveat before we start: this is engineering guidance, not legal advice. Your counsel classifies your systems; we make sure the architecture can satisfy what the classification requires.

Where the Act stands in 2026

The EU AI Act entered into force in 2024 and applies in phases rather than all at once. Three milestones matter for planning in 2026.

  • Already binding. The bans on unacceptable-risk practices took effect in early 2025, alongside an obligation to ensure staff AI literacy. These are live today.
  • Already binding. Obligations on providers of general-purpose AI models, together with the governance and penalty framework, took effect in mid-2025.
  • Arriving. The core obligations for high-risk AI systems phase in across 2026 and 2027. This is the milestone most enterprises are unprepared for, because high-risk duties are the heaviest and the systems are often already in production.

The practical implication is that "we will deal with it when it is enforced" is no longer a strategy. The systems being deployed in 2026 are the systems that will be in scope when the high-risk obligations bite. Architecture decided now is compliance inherited later.

The four risk tiers

The Act does not regulate "AI" as one thing. It sorts systems into four tiers by the risk they pose, and the obligations scale with the tier. Knowing your tier is the first move, because it determines everything that follows.

  • Unacceptable risk: prohibited. Practices the Act bans outright, such as social scoring by public authorities and manipulative systems that exploit vulnerabilities. If your use case is here, there is no compliance path. You stop.
  • High risk: heavily regulated. Systems used in areas such as credit decisions, employment and recruitment, essential services, medical contexts, and critical infrastructure. Permitted, but subject to the full set of obligations.
  • Limited risk: transparency. Systems such as chatbots and generative tools, where the main duty is disclosure: people must know they are interacting with AI and that content is AI-generated.
  • Minimal risk: unrestricted. The large majority of AI uses, such as spam filters and recommendation features, carry no specific obligations under the Act.
The four EU AI Act risk tiers A pyramid of four tiers. From top to bottom: unacceptable risk which is prohibited, high risk which carries full obligations, limited risk which carries transparency duties, and minimal risk which is unrestricted. Obligation weight increases toward the top. FOUR RISK TIERS, OBLIGATIONS SCALE WITH RISK Prohibited Unacceptable risk: no compliance path High risk Full obligations: risk mgmt, data governance, logging, human oversight, conformity assessment Limited risk Transparency: disclose that it is AI Minimal risk No specific obligations more obligation less
Schema 01. The four risk tiers. Most AI sits harmlessly at the base. The obligations that demand real engineering, and the penalties that punish their absence, concentrate in the high-risk tier, where most serious enterprise AI lives.

What high-risk systems actually require

If your system lands in the high-risk tier, the Act sets out a substantial list of obligations. Stripped of the legal phrasing, they describe a well-engineered, well-governed AI system. The headline requirements are:

  • Risk management. A continuous process to identify, evaluate, and mitigate risks across the system's lifecycle, not a one-off sign-off.
  • Data governance. Training and operational data must be relevant, representative, and managed, with control over where it lives and how it is handled.
  • Technical documentation and record-keeping. Documentation sufficient to demonstrate conformity, plus automatic logging of events throughout operation.
  • Transparency. Deployers must be able to interpret the system's output and understand its limits.
  • Human oversight. The system must be designed so a person can understand, intervene in, and if necessary override its behaviour.
  • Accuracy, robustness, and cybersecurity. Appropriate levels of each, sustained over the lifecycle.

Read that list again with an architect's eye. None of it is satisfied by a disclaimer or a policy document. Logging, oversight, data governance, and interpretability are properties of how the system is built. Which is the whole point of this article.

Compliance is an architecture problem, not a paperwork problem

The expensive way to approach the AI Act is to build an AI system for capability alone, then ask the legal team to wrap it in documentation afterwards. That produces a system that cannot actually log what it did, cannot explain why, and cannot be overridden in flight, papered over with promises it cannot keep.

The GRAL thesis is the opposite. The architecture we already advocate for private enterprise AI, for reasons that have nothing to do with the regulation, happens to satisfy most of the high-risk obligations as a byproduct. Build it right and compliance is something you have, not something you bolt on.

The mapping is direct. Human oversight and record-keeping are exactly the glass box and cognitive telemetry we build into every agentic system: every action logged, attributable, reversible, with a human able to intervene. Data governance is what running AI inside your own perimeter delivers, where you control where data lives and it never trains a third party's model. Transparency and accuracy follow from grounding every answer in a knowledge fabric with provenance, so each output traces back to a cited source rather than an opaque guess. The requirements the Act imposes and the properties good private AI already has are very nearly the same list.

AI Act obligations mapped to GRAL architecture Four EU AI Act obligations on the left connect to four GRAL architectural primitives on the right: human oversight maps to the glass box and telemetry, data governance maps to private deployment in your perimeter, transparency and accuracy map to grounding in a knowledge fabric, and record-keeping maps to attributable reversible audit logs. AI ACT REQUIRES GRAL BUILDS IT IN Human oversight understand, intervene, override Glass box and telemetry in-flight visibility, kill-switch, escalation Data governance control where data lives Private deployment in your perimeter open models, no third-party training Transparency and accuracy interpretable, reliable output Grounding in a knowledge fabric cited sources, escalate if unknown Record-keeping automatic event logging Attributable, reversible audit logs replay any decision on demand
Schema 02. The obligations on the left are legal language. The primitives on the right are how GRAL builds private AI regardless. The overlap is why compliance-by-design is cheaper than compliance-by-retrofit.

The general-purpose model question

Most enterprises do not train their own foundation models. They build on a general-purpose model, and the Act treats that choice as significant. Providers of general-purpose models carry their own obligations around documentation and, for the most capable models, systemic-risk assessment. But the deployer who builds on top still owns the duties for the system they put into use.

This is a quiet argument for open models running inside your perimeter, rather than a closed API you call across the internet. With an open model you control, you can document what you run, pin the version, log every inference, and demonstrate exactly what produced a given output. With an opaque third-party endpoint, you are attesting to a system whose behaviour can change underneath you without notice. For a high-risk deployment, provenance you control is far easier to defend than provenance you borrow.

A practical playbook for deployers

For enterprise teams deploying AI in 2026, the operational steps are concrete:

  • Inventory and classify. List every AI system in use or planned, and have counsel assign each a risk tier. You cannot comply with obligations you have not mapped.
  • Assign accountability. Name a human owner for each high-risk system. Oversight is meaningless without someone whose job it is.
  • Build logging and oversight from day one. Retrofitting an audit trail into a system that was not designed to keep one is the most expensive path. Design for the glass box at the start.
  • Control your data and your model. Prefer architectures where data stays in your perimeter and the model version is yours to pin and document.
  • Keep a human in the loop on consequential decisions. Where an output materially affects a person, ensure a person can review and override before it takes effect.
  • Document as you build. Maintain the technical documentation continuously, so conformity is a report you can generate, not a project you have to launch.

How GRAL builds compliance-ready AI

Every system GRAL deploys through Fabrica starts from these primitives rather than adding them later. The Cognity knowledge fabric grounds outputs in cited, versioned sources. The agent layer logs every action with full attribution and supports human escalation by design. The whole system runs inside the client's perimeter on open models the client controls. The result is a system that is defensible because of how it is built, not because of what its documentation claims.

That is the difference between treating the AI Act as a tax and treating it as a specification. A tax is something you pay to keep doing what you were going to do anyway. A specification is something you build to, and building to it well produces a better system: one that is auditable, controllable, and grounded, whether or not a regulator ever asks. Compliance, done at the architectural level, is just good engineering with a legal name.

Conclusion: regulation as a design brief

The EU AI Act is the most serious attempt yet to make artificial intelligence accountable, and in 2026 it is no longer optional reading. Enterprises will divide into two groups: those who treated it as paperwork to survive, and those who treated it as a design brief and ended up with systems they can actually trust. The second group will find that the work the Act demands is the work that makes AI safe to deploy at all.

GRAL builds for the second group. Private by default, grounded in a sovereign knowledge fabric, governed end to end, and engineered so that the answer to "show me what it did and why" is always available. That is what the EU AI Act asks for, and it is what we would build regardless.

Talk to GRAL about building AI Act compliance into your stack