Most companies deploying AI in Europe have read the headlines about the EU AI Act and concluded two things: it is coming, and someone else will handle it. Both conclusions are wrong. The Act (Regulation 2024/1689) entered into force on 1 August 2024. The prohibitions on unacceptable-risk AI became enforceable on 2 February 2025 — eleven weeks ago. General-Purpose AI obligations land on 2 August 2026. High-risk system obligations land on 2 August 2027. The fines for non-compliance reach €35 million or 7% of global annual turnover, whichever is higher.
That last number is not a typo. It is higher than GDPR's 4%. It applies globally. And unlike GDPR, the Act specifies technical obligations — not just process obligations — that your AI system must architecturally satisfy. You cannot paper over them with policies. You have to prove them.
This post breaks down what the Act actually requires, which companies it covers, and how EVE AI Core's deterministic governance infrastructure maps directly onto the technical obligations so that compliance becomes an architectural property rather than a documentation exercise.
The Four Risk Tiers
The Act classifies every AI system into one of four risk tiers. Your obligations depend entirely on which tier you fall into, and the classification is not optional.
| Tier | Examples | Status |
| Unacceptable | Social scoring, emotion recognition in workplaces/schools, real-time biometric ID in public spaces, manipulative subliminal techniques | BANNED (Feb 2, 2025) |
| High-Risk | Credit scoring, hiring, medical devices, critical infrastructure, law enforcement, education admissions, migration/border control | Compliant by Aug 2, 2027 |
| Limited-Risk | Chatbots, deepfakes, emotion recognition in other contexts, AI-generated content | Transparency obligations in force |
| Minimal-Risk | Spam filters, recommendation systems, video game AI | No specific obligations |
A separate category covers General-Purpose AI models — the foundation models underneath ChatGPT, Claude, Gemini, and their peers. GPAI providers have their own obligations, landing August 2, 2026, and an enhanced tier for models exceeding 10^25 FLOPs of training compute.
The trap most companies fall into: assuming they are "limited-risk" when they are actually "high-risk." If your AI makes or materially influences decisions about creditworthiness, insurance eligibility, hiring, promotion, termination, educational placement, or access to public services — you are high-risk. If you embed a third-party model in a product that does any of those things, you are a high-risk deployer even if the model provider is somewhere else.
What High-Risk Actually Requires
The Act devotes ten articles (8 through 17) and several annexes to what high-risk AI providers must do. Strip away the legal scaffolding and four obligations matter most operationally:
Article 12 — Record-Keeping. Automatic logs of every operation. Logs must be retained, traceable, and tamper-evident. Auditors must be able to reconstruct any decision after the fact.
Article 14 — Human Oversight. Natural persons must be able to understand system output, detect anomalies, and override or halt operation. The system must be designed to make this possible — not leave it as an afterthought.
Article 15 — Accuracy, Robustness, Cybersecurity. Appropriate levels of accuracy, robustness against errors and inconsistencies, and resilience to adversarial attempts at manipulation. Technical fail-safe measures where feasible.
Articles 26 & 27 — Post-Market Monitoring & Fundamental Rights Impact. Deployers must monitor operation, maintain logs, report serious incidents, and — for most high-risk systems — conduct a Fundamental Rights Impact Assessment before first use.
Every high-risk system must also have a CE mark, be registered in the EU database, and pass conformity assessment. Providers need a quality management system. Importers and distributors have their own obligations under Articles 23-25. If any link in the chain fails, the whole deployment is non-compliant.
The Act does not ask "do you have a policy?" It asks "can you prove, for any given decision, that your system met the technical obligation at the moment it decided?"
Where Most AI Stacks Break Down
Typical LLM-based systems fail three of the four obligations above, and most teams do not realize it until an auditor asks the right question.
Article 12 (record-keeping) is usually handled as application-level logs written to whatever observability stack the team has. These logs are rarely tamper-evident. An engineer with database access can edit them. An attacker with the same access can delete them. Under the Act, "automatically generated" logs that are mutable do not satisfy the traceability requirement.
Article 14 (human oversight) breaks down because most LLM pipelines cannot be interrupted mid-generation, and the outputs are non-deterministic — re-running the same input produces different results. "Understanding the output" is hard when you cannot reproduce it. "Overriding operation" is hard when the only point of intervention is before or after the model runs, not during.
Article 15 (robustness) is where prompt-injection resistance, hallucination rates, and adversarial testing all live. The Act requires "appropriate" levels, which sounds vague — until you read the harmonized standards being developed under Article 40, which will specify concrete technical benchmarks. Systems that cannot resist the documented attack classes will fail conformity assessment.
How EVE AI Core Maps to the Act
EVE AI Core is deterministic governance infrastructure for AI. Every decision passes through a pre-execution gate that runs in under a millisecond, produces a pattern-matched verdict, and emits a cryptographically signed certificate. The gate does not use the LLM to decide whether the LLM should run. It uses 175 compiled regex patterns across 13 pattern groups and 127 enforcement pillars, all rooted in a pure deterministic module that has zero I/O and zero state.
That architecture happens to satisfy every technical obligation the Act imposes on high-risk AI. Not by coincidence — by design.
| EU AI Act Obligation | EVE AI Core Component | How It Satisfies the Article |
| Article 12 Record-Keeping |
Proof Ledger + EVE Proof SDK | Every decision produces a v1.1 governed-decision certificate with HMAC-SHA256 signature and hash-chain linkage to prior decisions. Tamper-evident by construction. Independently verifiable without EVE involvement. |
| Article 14 Human Oversight |
CoreGuard Pre-Execution Gate + Operator Console | Every decision is intercepted before execution. Human operators receive structured ALLOW/BLOCK/MODIFY verdicts with full reasoning. Approval workflows for high-risk actions. Real-time kill switch. No decision reaches downstream without a governance verdict. |
| Article 15(1) Accuracy & Robustness |
Failure-Mode Invariant + Novel-Attack Detector | Hard-Fail-Shut protocol: any enforcement error defaults to veto, never fall-through. 27 TF-IDF novel-attack centroid classes catch semantic attacks that regex misses. Tested against the Sovereign-1000 adversarial gauntlet. |
| Article 15(4) Resilience Against Manipulation |
Unicode Normalization + 127 Enforcement Pillars | NFKC canonicalization and homoglyph collapse before any pattern match. 127 pillars covering prompt injection, role-swap, mechanistic steering, infrastructure depravity, semantic erosion, and spatial reconstruction attack classes. |
| Article 26 Post-Market Monitoring |
Unified Audit Bus + Merkle Aggregator | JCS-canonicalized, HMAC-signed, hash-chained audit events aggregated into Merkle trees with signed root publication. Real-time incident detection with structured event taxonomy. |
| Annex IV Technical Documentation |
Build Attestation + SBOM | SLSA Level 2 build provenance records (git state, dependency hashes, source tree hash, Docker digest). CycloneDX 1.4 SBOM for every deployment. Supply-chain verifiable. |
| Article 50 Transparency |
Ground Truth Validator + Decision Lineage | Every AI output can be traced to its decision certificate, the policy version that governed it, and the evidence chain that supported it. User-facing disclosure of AI involvement is structured and verifiable. |
The Compliance Pattern That Actually Works
The Act's Recital 27 makes the underlying philosophy explicit: high-risk AI systems should be "designed in a way to enable natural persons to exercise effective oversight." The word designed is carrying a lot of weight there. It is a design obligation, not a policy obligation. You cannot satisfy it by writing a Responsible AI document and training your team on it.
Design obligations require architectural guarantees. An architectural guarantee is a property of the system that holds regardless of who operates it, what configuration they choose, or whether they are paying attention that day. Deterministic pre-execution governance is an architectural guarantee. Application-level logging is not. Post-hoc content filtering is not. "We prompt the model to be safe" is emphatically not.
The compliance pattern that actually works has three properties:
- Decisions pass through a deterministic gate before execution. The gate is pure pattern matching with no LLM involvement — otherwise the governance layer inherits the same non-determinism and adversarial brittleness that created the problem in the first place.
- Every decision emits a signed certificate. HMAC-SHA256 over a canonicalized payload. Hash-chained to prior decisions. Independently verifiable. Auditors can request any decision's certificate and prove, cryptographically, that it was issued at the time claimed with the claimed inputs and outputs.
- The system fails closed, not open. Component errors default to veto. Unknown attack patterns default to veto. Ambiguous inputs default to veto. Under the Act, permissive defaults under uncertainty are non-compliant by construction.
What To Do Now
The GPAI deadline is August 2, 2026. That is three and a half months away. The high-risk deadline is August 2, 2027 — sixteen months away. Both look far, but conformity assessment for high-risk systems takes six to twelve months depending on the conformity body's queue. Organizations that start in January 2027 will not finish in time.
If your AI deployment in Europe touches any high-risk category in Annex III — credit, insurance, hiring, medical, education, law enforcement, migration, critical infrastructure — the work to do in the next 90 days is:
- Confirm your risk classification. Get this in writing from counsel.
- Map every Article 8-17 obligation to a specific technical control in your stack. The ones you cannot map are gaps.
- Evaluate whether your logging is tamper-evident. If engineers can edit logs, it isn't.
- Evaluate whether your governance layer is deterministic. If it uses an LLM to decide whether an LLM should run, you have stacked non-determinism on non-determinism.
- Plan your conformity assessment timeline backward from August 2, 2027. Leave six months of buffer.
EVE AI Core was built for exactly this class of obligation. CoreGuard is the pre-execution gate. EVE Proof is the signed-certificate infrastructure. Our Sovereign SDK gives you tenant-isolated governance-as-a-service so that every one of your customers can have their own charter rules while sharing our enforcement substrate. All three map onto Articles 12, 14, 15, 26, and 27 without you having to build anything. The underlying architecture is protected by an 88-application patent portfolio spanning the unified control-plane stack (Serial Nos. 64/022,671, 64/022,677, 64/022,682) and six umbrella families.
The Act is not a hypothetical. It is in force. The fines are not symbolic. The technical obligations are specific. Deterministic governance is how you turn compliance from a rolling liability into a property of your architecture — and sleep at night.
If you want to see what Article 15 robustness actually looks like when it is enforced deterministically, try the live CoreGuard demo. Submit an adversarial prompt. Watch the gate fire in under a millisecond. Get the signed certificate. That is what compliance is supposed to feel like. When you are ready for a deeper assessment, schedule a compliance architecture review.
Four resources we built for our own customers. Use them for yours.
A self-assessment checklist, a technical mapping of every obligation, a four-obligation gap analysis scorecard, and a phase-by-phase 15-month roadmap to reach compliance before the August 2027 deadline.