The EU AI Act and your inference stack
The EU AI Act isn't a draft framework or an aspirational white paper. It is binding law enacted 1 August 2024, with enforcement for high-risk AI systems arriving within days. If your application runs LLM inference in a regulated context — healthcare, hiring, lending, insurance, critical infrastructure — the clock has nearly run out.
Compliance Lead
This is practical guidance, not legal advice. Consult your own counsel on how the EU AI Act applies to your use cases.
Who the Act covers — and what it requires
The Act classifies AI actors into three buckets. Providers develop a system or place it on the EU market. Deployers use an AI system in their professional operations. GPAI model providers train general-purpose AI models. Most enterprises running inference through a platform are deployers — you're using the model, not building it. But if you fine-tune or substantially modify a model, you may be reclassified as a provider, which carries a heavier set of obligations.
For deployers, the obligations that matter most: Article 9 — implement a risk-management system throughout the system's lifecycle; Article 12 — maintain logs for traceability of the system's functioning; and Article 50 — disclose to end users that they are interacting with an AI system. If your use case falls under Annex III (education, employment, essential services, law enforcement, migration, democratic processes), these are mandatory, not optional.
The enforcement timeline
The Act entered force on 1 August 2024. GPAI-model-provider obligations have applied since 2 August 2025. The next deadline — and the one that triggers the most preparation — is 2 August 2026, when high-risk obligations (Annex III), Article 50 transparency rules and GPAI penalties become enforceable. Annex I systems and legacy GPAI models follow on 2 August 2027. There is a proposed Omnibus simplification package that would delay certain deadlines, but as of this writing it has not been adopted — the dates above are current law.
How your infrastructure choice simplifies compliance
Picking the right inference infrastructure doesn't make the Act go away. But it turns several abstract requirements into concrete, demonstrable controls. If your LLM runs on dedicated GPUs inside your own VPC with zero data retention, four obligations become substantially easier to meet:
- Risk management (Art. 9). Your technical documentation can describe a known, auditable infrastructure stack — not a black-box API. That is a stronger control description when regulators ask.
- Logging (Art. 12). A private gateway generates request-level audit trails without exposing prompt content. You can prove the system operated as designed without logging what it processed.
- Transparency (Art. 50). When responses stream through your application layer, you control exactly when and how the AI disclosure is presented — no dependency on a third party.
- Data governance. Region-pinned inference in EU data centers keeps every byte inside the jurisdiction, satisfying both AI Act data-governance expectations and GDPR residency requirements.
ISO 42001 maps to much of the Act
An ISO 42001 AI management system aligns closely with the Act's high-risk governance provisions: documented AI policy, risk assessment, impact assessment, continuous monitoring and corrective action. Organizations that hold or pursue ISO 42001 certification have already addressed a large fraction of the technical documentation and quality-management requirements the Act demands.
A deployer's preparation checklist
- Classify your use case against Annex III — if you are in a high-risk category, start now, not in August.
- Document your risk-management process (Art. 9) and your data-governance controls.
- Confirm your inference provider can produce the audit trails and technical documentation an Art. 12 logging obligation demands.
- Prefer an open-weight model with a permissive license — it gives you full visibility into the system.
- Ask for a SOC 2 Type II report to satisfy the third-party assurance expectations regulators will expect.
The timeline is now
August 2026 isn't a distant deadline — it is the compliance posture you need to have in place before enforcement begins. Technical documentation, risk assessments, logging architecture and transparency mechanisms take time to implement and test. The teams that started early, running inference on infrastructure built for auditability and residency, are the ones with a clean story when the first questions arrive. Every compliance program looks different — a solutions engineer can map yours to the infrastructure controls that support it.
Related reading
- ComplianceGDPR & data residency for LLM inferenceGDPR compliance for LLM inference isn't just about a DPA. It's about controller-processor boundaries, cross-border transfer safeguards and region-pinned data residency — all working together.
- ComplianceISO 42001 for AI inference, explainedISO 42001 isn't just another certificate. It's a lifecycle AI governance framework that maps to the EU AI Act and is fast becoming the procurement standard for enterprise inference.
- ComplianceWhat SOC 2 Type II means for inferenceSOC 2 Type II audits a provider's controls over months, not a single day. Here's what the five Trust Services Criteria mean for inference, how to read a report, and what to ask for.
- ModelsChoosing an open model for regulated AIRegulated teams have more open-weight model choices than ever. Here's how to compare them on what matters: capability, license, context length, provenance, and where they run.
Run this privately, in your own environment
A solutions engineer will scope a zero-retention deployment for your models and volume.