The Developer's Guide to
EU AI Act Compliance
The EU AI Act is the world's first comprehensive AI regulation. Transparency obligations apply from August 2026, with high-risk system requirements deferred to December 2027 under the Digital Omnibus. Here's what engineering teams need to know — and how to comply with runtime governance.
Updated July 2026
TL;DR
- 1.If you build or deploy AI in the EU, this law applies to you.
- 2.High-risk AI systems need logging, human oversight, and robustness measures.
- 3.Fines go up to €35M or 7% of global revenue — bigger than GDPR.
- 4.Transparency rules apply Aug 2026; high-risk obligations deferred to Dec 2027.
- 5.Runtime governance (not static policy docs) is how you prove compliance.
What is the EU AI Act?
The EU AI Act (Regulation 2024/1689) is a comprehensive legal framework governing the development, deployment, and use of artificial intelligence systems in the European Union. It categorizes AI systems by risk level and imposes requirements proportional to that risk.
For most engineering teams building LLM-powered products, the relevant category is high-risk AI systems — which includes AI used in employment, education, critical infrastructure, law enforcement, and any system that significantly affects natural persons.
Even if your system isn't classified as high-risk today, the regulation incentivizes voluntary compliance and many enterprise buyers are already requiring it in procurement.
Enforcement Timeline
August 1, 2024
EU AI Act entered into force
February 2, 2025
Prohibited AI practices ban takes effect
August 2, 2025
Rules for general-purpose AI models apply
August 2, 2026
Transparency obligations (Article 50) apply
December 2, 2027
High-risk system obligations (Articles 13-15) apply (deferred by Digital Omnibus)
Penalties
The EU AI Act penalties exceed GDPR fines. Non-compliance isn't a paperwork issue — it's an existential business risk.
Prohibited AI practices
Up to €35M or 7% of global annual revenue
High-risk system non-compliance
Up to €15M or 3% of global annual revenue
Incorrect information to authorities
Up to €7.5M or 1% of global annual revenue
Key Articles for Engineering Teams
Three articles define the core technical requirements. Here's what they mean in practice.
Article 13 — Transparency & Traceability
“High-risk AI systems must be designed to ensure their operation is sufficiently transparent and traceable. Providers must log system behavior in a way that allows for oversight.”
What this means:
- ✓Log every AI decision with full context (input, output, model, latency)
- ✓Maintain structured records that demonstrate system behavior over time
- ✓Enable third-party auditability of AI system operations
How Overrule helps:
Overrule automatically captures structured events for every governed LLM call — model, provider, policies applied, violations detected, input/output tokens, and latency. All queryable from the dashboard.
Article 14 — Human Oversight
“High-risk AI systems must be designed to allow effective oversight by natural persons. This includes the ability to understand, monitor, and intervene in system behavior.”
What this means:
- ✓Provide mechanisms for humans to monitor AI system decisions
- ✓Enable intervention when AI produces harmful or incorrect outputs
- ✓Allow operators to override or halt system operation
How Overrule helps:
Overrule's policy engine acts as a programmable intervention layer. Policies can BLOCK harmful outputs before they reach users. The dashboard provides real-time visibility into what the AI is doing and where it's being stopped.
Article 15 — Accuracy, Robustness & Cybersecurity
“High-risk AI systems must achieve appropriate levels of accuracy, robustness, and cybersecurity. They must be resilient to errors, faults, and attempts to exploit vulnerabilities.”
What this means:
- ✓Protect against adversarial inputs (prompt injection, jailbreaks)
- ✓Ensure system continues operating safely under failure conditions
- ✓Implement measures against unauthorized manipulation of outputs
How Overrule helps:
Overrule detects 8 prompt injection patterns and 5 SQL injection patterns at runtime. The fail-open architecture ensures governance never becomes an outage. Circuit breakers and bounded buffers protect production stability.
Why Policy Documents Aren't Enough
Most organizations approach AI compliance the same way they approached GDPR — with policy documents, risk assessments, and internal review boards. This doesn't work for AI because:
- ✗AI systems produce different outputs every time — you can't audit what you don't log
- ✗Policy documents prove intent, not enforcement — regulators want evidence of active controls
- ✗Manual review doesn't scale — production AI makes thousands of decisions per hour
- ✗Retroactive compliance is expensive — catching violations after the fact costs 10x more
Runtime governance solves this by making compliance a property of the system itself, not a document that sits alongside it.
Runtime Governance: The Technical Approach
Runtime governance means policy enforcement happens where AI decisions happen — in the request path, at production time, automatically.
from overrule import Guard
async with Guard() as guard:
# Every call is now governed
response = await guard.chat(
model="gpt-4o",
messages=messages,
policies=["pii-detection", "injection-detection", "toxicity-detection"],
)
# Violations blocked before reaching users
# Structured event logged to audit trail
# Full context captured for regulatorsWith one SDK call, you get:
- ✓Article 13 compliance — every decision logged with full context
- ✓Article 14 compliance — policies act as programmable human oversight
- ✓Article 15 compliance — injection detection + fail-open resilience
Start complying today
The SDK is open-source and free. Add runtime governance to your AI application in under 5 minutes.