EU AI Act compliance mapped to engineering controls. Risk classification, audit logging, human oversight, and transparency requirements developers must build before August 2026.
Regulation (EU) 2024/1689 contains 80 control references, compared to 49 for NIST AI RMF and 41 for OWASP. That density tells you something important about the nature of the obligation. This is not a framework you satisfy with a risk register and a quarterly review. The EU AI Act is granular, operational, and deeply technical.
Most compliance guides treat it as a paperwork exercise: classify your system, fill out the forms, move on. But the hardest 2026 requirements are operational rather than paperwork-driven, with much of the burden falling on ongoing risk controls, traceable audit trails, human review, security safeguards, and the maintenance of technical records. For developers building AI applications, that means compliance is an engineering problem. The controls have to be built into the system, running in production, generating evidence continuously.
This checklist maps each major Article to the specific engineering work it demands, and identifies where an infrastructure layer can carry the load.
The AI Act is a first-of-its-kind legal framework intended to regulate the development and use of AI across Europe. It came into force in August 2024, with an implementation timeline running to mid-2027.
Two details that developers outside Europe tend to miss:
Not everything hits at once. The Act phases in by risk category:
| Date | What takes effect |
|---|---|
| August 2024 | Act enters into force |
| February 2, 2025 | Article 5 prohibited uses enforceable (social scoring, workplace emotion recognition) |
| August 2, 2025 | GPAI obligations apply (technical documentation, training data summaries, copyright compliance) |
| August 2, 2026 | Full obligations for high-risk AI systems |
August 2026 is the date that matters most for application developers. That is when the engineering-heavy requirements under Articles 9 through 15 become enforceable for high-risk systems.
The Act uses four risk tiers: unacceptable risk, high risk, limited risk, and minimal or no risk. Your classification determines every obligation that follows.
Getting this wrong is common. Enterprises most often fall short on incorrect high-risk classification, weak understanding of deployer responsibilities, and governance tooling that fails to produce continuous compliance evidence. If you classify a high-risk system as limited risk, every downstream engineering decision is built on a false premise.
Article 9 requires providers of high-risk AI systems to implement a risk management system that spans the entire AI lifecycle: design, development, deployment, and post-market monitoring. Providers must identify and analyze known and reasonably foreseeable risks to health, safety, and fundamental rights.
A gateway layer sitting between your application and model providers gives you the instrumentation point. Every request and response passes through it, which means risk-relevant signals (anomalous outputs, prompt patterns associated with misuse, latency spikes indicating degraded performance) can be captured without modifying application code.
Two requirements that live in different Articles but converge on the same infrastructure need:
Data governance (Article 10): You need documented training, validation, and testing dataset provenance. You must evaluate datasets for relevance, representativeness, and potential biases, particularly those that could result in prohibited discrimination.
Logging (Article 12): AI systems must generate tamper-evident audit trails of relevant events. Logging must be a built-in technical feature that captures inputs, outputs, and decisions in sufficient detail to allow traceability. Deployers must retain automatically generated audit trails for at least 6 months.
A gateway can provide useful request metadata and usage accounting, but content retention and immutability require an explicit records system. SHIM's durable request records exclude raw bodies, so it should not be presented as a complete Article 12 evidence archive.
Human oversight must be designed into the system from the start. Article 14 requires natural persons to monitor high-risk AI systems during operation and to have the ability to override or halt the system.
This is not a governance policy. It is a system architecture requirement. The override capability has to exist in the running system, accessible to a human operator, functional under load.
A gateway layer is the natural place for this. It already mediates every request. Adding conditional routing (flag a request for human review based on confidence score, content category, or policy rule) is a configuration change, not a new system. Guardrail enforcement at the proxy layer means high-risk outputs can be intercepted, held, and routed to a reviewer before reaching the end user.
Article 50 applies across risk tiers and contains three distinct requirements:
Providers must ensure that AI systems intended to interact directly with people are designed so that individuals are informed they are interacting with an AI system. This requirement does not apply where it is obvious to a reasonably well-informed person given the context.
Providers of AI systems generating synthetic audio, image, video, or text must mark outputs in a machine-readable format detectable as artificially generated or manipulated. The technical solution must be effective, interoperable, robust, and reliable.
Businesses using deepfakes in professional activity must disclose that the content has been artificially generated or manipulated.
High-risk transparency (Article 13). Providers of high-risk AI must design systems so deployers can understand how the AI system works, evaluate its functionality, and comprehend its strengths and limitations.
For developers building chatbots or content-generation tools, Article 50 compliance means injecting disclosure metadata into every response. A gateway layer can append AI-disclosure headers, inject watermarking metadata into generated content, and enforce disclosure rules without requiring each application team to implement them independently.
If you build applications on top of a general-purpose AI model (GPT-4, Claude, Gemini), the GPAI obligations affect your supply chain. Since August 2, 2025, GPAI providers must maintain technical documentation, publish training data summaries, implement copyright compliance policies, and share information with downstream deployers.
As an application developer, you inherit obligations based on what you do with the model. If you fine-tune a GPAI model and deploy it in a high-risk context, you may become a provider under the Act with full Article 9-15 obligations. If you use a GPAI model via API in a limited-risk application, your obligations are lighter but still real (Article 50 transparency, deployer-side logging).
The key engineering question: can you demonstrate which GPAI model served each request, what version it was, and what documentation the upstream provider supplied? A gateway that logs model routing decisions and version metadata gives you that traceability without building custom integration per provider.
The fines are structured to be painful at any company size:
| Violation tier | Maximum fine |
|---|---|
| Prohibited uses (Article 5) | €35 million or 7% of worldwide annual turnover, whichever is higher |
| Other violations (Tier 2) | €15 million or 3% of worldwide annual turnover, whichever is higher |
For a company with €10 billion in global revenue, a Tier 2 violation translates to €300 million in exposure. These are not theoretical ceilings. The enforcement apparatus is real and the prohibited-use provisions are already active.
Meanwhile, only 37% of organisations are currently conducting regular AI risk assessments. The gap between regulatory expectation and engineering reality is wide.
Map the Articles against a typical AI application stack, and a pattern emerges. The controls that the Act demands (logging, oversight, transparency, access control, PII handling) cluster at the same architectural point: the layer between your application and the model provider.
| EU AI Act requirement | Engineering control | Gateway-layer solution |
|---|---|---|
| Article 9: lifecycle risk management | Production telemetry, anomaly detection | Request/response monitoring with alerting |
| Article 10: dataset bias evaluation | Bias testing pipeline | Input/output analysis for discriminatory patterns |
| Article 12: tamper-evident audit trails | Immutable structured logging, 6-month retention | Built-in request logging with retention policies |
| Article 14: human oversight | Override routing, kill switch, escalation | Conditional routing to human review queues |
| Article 50: transparency | AI disclosure headers, content watermarking | Automated metadata injection on responses |
| GPAI traceability | Model version logging per request | Multi-provider routing with version tracking |
Shim provides a tenant-isolated policy and accounting boundary for native OpenAI, Anthropic, and Google routes, including PII placeholder processing and durable metadata that excludes raw bodies. Provider selection, failover, and any compliance evidence retention remain explicit application and records-system responsibilities.
The August 2026 deadline is 40 days away. The AI governance framework you need is not a policy document. It is running code that generates evidence on every request. Start with the engineering controls, and the paperwork follows.