EU AI Act Compliance: What the Regulation Requires from Enterprise AI Architecture

The EU AI Act entered force on August 1, 2024, and its obligations land in stages. The prohibited-practices ban under Article 5 took effect February 2, 2025. The general-purpose AI model obligations under Chapter V took effect August 2, 2025. The high-risk system obligations under Articles 8 through 27 take effect August 2, 2026. The full set of post-market monitoring and conformity assessment rules under Article 72 and the surrounding chapters complete the rollout by August 2, 2027. Article 99 sets penalty tiers up to €35 million or 7% of global annual turnover, depending on the violation category.

The August 2, 2026 date is the one most enterprises are running toward right now. High-risk systems already in scope, in production, with EU users, must satisfy the full obligations on that date. Most deployments will not.

I want to walk through the structure of the Act, what the high-risk obligations actually require, and the architecture pattern that satisfies them without forcing a rewrite of every AI application.

What the EU AI Act covers

The Act regulates AI systems sold, deployed, or used inside the EU market regardless of where the developer is headquartered. The territorial scope under Article 2 is broad. Providers and deployers outside the EU are in scope if the output of the system is used in the EU. A US-headquartered SaaS company with EU customers whose employees use the embedded AI feature falls under the Act on the deployer obligations side, and the SaaS company falls under the provider obligations side.

The Act uses a risk-tiered classification. Prohibited practices under Article 5 are banned outright. High-risk systems under Article 6 and Annex III carry the most extensive obligations. General-purpose AI models under Chapter V carry their own set of obligations, with systemic-risk models facing additional rules. Limited-risk systems under Article 50 face transparency obligations. Minimal-risk systems are largely outside the regulatory scope.

High-risk classification triggers most obligations

Annex III lists eight categories of high-risk use. Biometric identification, critical infrastructure management, education and vocational training admission, employment and worker management, access to essential services including credit scoring and insurance pricing, law enforcement, migration, and administration of justice and democratic processes.

Most enterprise AI deployments end up touching at least one Annex III category. A credit-scoring feature triggers the essential services category. An HR screening tool triggers the employment category. A clinical decision support tool can trigger the essential services category depending on use. The European Commission's May 2026 guidelines on GPAI providers tightened the classification criteria further.

General-purpose AI models carry separate obligations

Foundation model providers face Chapter V obligations including the AI Act Code of Practice for systemic-risk models. The deployer of a GPAI-powered feature inherits responsibility for how the model is used in the deployment context. A SaaS deployer building on OpenAI or Anthropic does not become exempt because the model was trained elsewhere.

What the high-risk obligations actually require

Articles 8 through 27 lay out the obligations for high-risk systems. Several of them require structural changes to enterprise AI architecture that application-level retrofits cannot satisfy on their own.

Article 9: Risk management system

The provider establishes, implements, documents, and maintains a risk management system that runs across the lifecycle of the high-risk system. The deployer inherits a corresponding obligation to monitor the system in operation and report serious incidents.

Article 10: Data and data governance

Training, validation, and testing data must satisfy quality criteria including relevance, representativeness, freedom from errors, and statistical properties appropriate to the intended purpose. The deployer obligation translates into validating that the upstream training data context is acceptable for the deployer's use.

Article 11: Technical documentation

Providers maintain technical documentation that demonstrates the high-risk system's compliance with Section 2 of Chapter III. The documentation must allow national competent authorities and notified bodies to assess compliance.

Article 12: Record-keeping

Article 12 mandates automatic logging over the lifetime of the system. The logs must enable identification of risk-creating situations, facilitate post-market monitoring, and enable monitoring of system operation. This is the obligation most application-level architectures miss.

Article 13: Transparency and information to deployers

Providers must provide instructions for use that enable deployers to interpret outputs and use the system appropriately. The deployer relies on these instructions to satisfy its own obligations.

Article 14: Human oversight

The system is designed to allow effective oversight by natural persons during use. Deployers assign oversight responsibility to qualified persons.

Article 15: Accuracy, resilience, and cybersecurity

Providers design the system to achieve appropriate accuracy, resilience against errors and attacks, and cybersecurity. Performance metrics are declared in the instructions for use.

Article 19: Automatically generated logs

Article 19 is the deployer-side companion to Article 12. Deployers retain the automatically generated logs for at least six months, longer where sector law applies. The logs must include the period of use (start and end timestamps), reference databases checked, input data leading to a match, and identity of natural persons involved in result verification.

Article 26: Deployer obligations

Article 26 lays out the operational obligations for deployers. Use the system according to the provider's instructions. Assign human oversight. Monitor the operation. Suspend use and inform the provider on incident. Maintain Article 19 logs. Conduct fundamental rights impact assessments where applicable.

Compliance gap

Most enterprise AI deployments running today do not satisfy the Article 12 logging mandate, the Article 19 retention floor, or the Article 26 oversight expectations. The gaps are structural, not configurational.

Application-controlled logs fail the self-attestation test

When the application that consumes the AI response also writes the compliance log, the audit record has three failure modes. Selective logging: the application logs successes and skips edge-case failures. Suppression: logs can be wiped or modified by the same system that failed. Loss on crash: the application crashes after the model responded but before the log committed, so the action was taken but the evidence is gone.

Regulators expect audit independence in every other regulated activity. The CFO does not sign the audit of the financial statements they prepared. Article 12 codifies the same principle for AI systems.

Identity context is missing at the request layer

Article 19 requires the log to identify the natural persons involved in verification. Most enterprise AI deployments call model APIs using static service credentials. The credential identifies the application, not the human or agent acting through it. Without identity context attached at the request layer, the log fails the Article 19 specificity requirement.

Retention is fragmented across application silos

A six-month retention floor sounds modest. The operational difficulty is that an application's log retention is configured at the application layer, varies by application, often lives on the application's host, and is subject to the same redeploy and crash conditions that the application is. Centralized retention requires a centralized log writer, which requires a centralized enforcement point that the application does not control.

Most deployments lack a policy decision point

Article 14's human oversight requirement and Article 26's monitoring obligation both assume a place where policy is evaluated. Most enterprise AI deployments evaluate policy implicitly in application code, scattered across micro-services. There is no single policy decision point that the deployer can point to during an audit.

What the architecture must do

Satisfying the Act at scale requires four structural properties at the AI request boundary.

Inline policy enforcement

Every AI request and response passes through a policy decision point that evaluates identity, role, data classification, and policy version before the model sees the request or the user sees the response. The enforcement is in line because asynchronous enforcement cannot prevent damage at machine speed. Mandiant's M-Trends 2026 report found a 22-second median attacker handoff time. Detect-then-block at that tempo is structurally too slow.

Identity context attached at the request layer

The request carries the verified identity of the calling user or agent. The service credential identifies the application; the identity context identifies the principal. Article 19 records the identity of natural persons involved. The enforcement layer needs that context to produce the record.

Per-decision audit records bound to identity, classification, policy, and outcome

The audit record is written by the enforcement layer, not by the application that consumed the response. The record is signed, tamper-evident, and retrievable on demand. Article 12 requires logs that can be used to reconstruct what happened; the audit record format must allow that reconstruction.

Fail-closed posture on policy ambiguity

On ambiguity, the enforcement layer defaults to deny rather than allow. The cost of an over-permissive decision under high-risk operation is regulatory exposure and consumer harm. The cost of a deny on a legitimate request is a retry. The math favors fail-closed.

Beyond the EU AI Act

The same architecture satisfies other regulatory regimes that target AI systems. NIST's AI agent identity and authorization framework splits AI agent security into three pillars: agent identity, delegated authority, action lineage. Pillar 1 is owned by the application; Pillars 2 and 3 are owned by the enforcement layer. The same enforcement layer that produces Article 12 logs produces Pillar 3 action lineage.

Fannie Mae Lender Letter LL-2026-04 requires inventory, governance, and disclosure on demand for AI used in mortgage origination and servicing. The same enforcement records that satisfy EU Article 12 satisfy Fannie Mae's disclosure-on-demand obligation.

DORA's ICT third-party risk regime, NIS2's incident reporting, HIPAA's audit trail expectations, and SOC 2's CC7 logging controls all benefit from a single AI request boundary architecture that produces identity-bound, signed, retention-controlled audit records.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect is a stateless proxy that sits between authenticated users or agents and LLMs, enforces identity-bound policy on HTTP AI traffic, and produces per-decision audit records that satisfy Article 12 record-keeping, Article 19 content and retention requirements, and the Article 14 oversight expectation. Enforcement happens inline at under 50 ms of added latency. The audit record is signed and tamper-evident. Identity context attaches at the request layer.

Teams running production AI workloads in EU scope can deploy DeepInspect in front of any HTTP-based LLM endpoint without changing the model, the model vendor, or the upstream application architecture. The audit obligation moves from the application to the enforcement layer where the regulator expects it to sit.

If you are facing the August 2 deadline, let's talk.