The EU AI Act (Regulation 2024/1689) gives you two public dates and a lot of silence in between. Program management turns those two dates into seven. This document is the roadmap from today to CE mark, working backward from August 2, 2027, with the conformity-assessment queue treated as the critical path. It is a status document, not legal advice. Conformity decisions must be validated with counsel and, where required, a notified body.
1. Executive Summary
- Two statutory deadlines drive every date in this document. GPAI obligations (Articles 51–55) become enforceable on August 2, 2026 — roughly 3.5 months from today. High-risk obligations (Articles 8–17, 26, 27) become enforceable on August 2, 2027 — roughly 15.5 months from today.
- Conformity assessment is the critical path. For Annex I high-risk systems, a notified body engagement runs 6–12 months depending on queue depth. An organization that starts the engagement in February 2027 or later will almost certainly miss the deadline. The last reasonable start date for conformity assessment is February 2, 2027.
- This roadmap works backward from that six-month conformity buffer. If you want the notified body to begin in February 2027, you need your Annex IV technical documentation package complete by November 2, 2026. Which means your controls must be operational by August 2, 2026. Which means your architecture design must be complete and your build underway by May 2, 2026 — about two weeks from today.
- Total effort for a single Annex III high-risk AI system, from scratch, is approximately 55–75 person-weeks for a 3-engineer team, plus 12–25 person-weeks of compliance and legal work, plus conformity assessment fees (EUR 30k–150k+ for notified bodies, or internal-assessment cost for non-biometric Annex III). The bill of materials is in §6.
- Three architectural invariants must hold end-to-end. If any one of them is missing, the conformity dossier will not survive scrutiny: (1) a deterministic pre-execution gate, (2) a cryptographically-signed, hash-chained audit ledger, (3) fail-closed defaults across every governance component. Each is detailed in §3.
- The "acceleration path" with EVE AI Core compresses the 66-week build-and-certify timeline to 18–24 weeks of integration. §8 shows the phase-by-phase math.
2. Deadline Cascade
The Act gives you two public dates. Program management gives you seven. Reading the cascade: if you are at "T-15 months" today and have not yet started Phase 2 control design, you are one week late. Phase 1 classification work should already be complete.
DATE (ISO) T-minus Milestone Type --------------------------------------------------------------------------------------------- 2025-08-02 T-24mo Risk management system designed (Article 9 scoping) (past) 2026-02-02 T-18mo Classification + scoping decisions locked (past) 2026-04-16 T-15.5mo ▶▶▶ YOU ARE HERE ▶▶▶ (now) 2026-05-02 T-15mo Architecture design complete; build started CRITICAL 2026-08-02 T-12mo GPAI obligations LIVE (Articles 51-55); controls operational STATUTORY 2026-11-02 T-9mo Technical documentation package complete (Annex IV) CRITICAL 2027-02-02 T-6mo Conformity assessment underway (notified body engaged) CRITICAL 2027-05-02 T-3mo Conformity assessment substantially complete CRITICAL 2027-08-02 T-0 HIGH-RISK OBLIGATIONS LIVE (Articles 8-17, 26, 27) STATUTORY 2027-08-02+ ongoing Post-market monitoring (Article 72) begins CONTINUOUS
The path below assumes a team starting Phase 1 on the publication date of this document and is aggressive but achievable. A team that waits until Q3 2026 to begin will not finish in time without buying pre-built components — which is one of the two sustainable paths out of this problem.
GPAI-only organizations. Foundation-model providers who do not place a high-risk system on the market have a shorter, more urgent runway: the full four phases of Phase 2/3 must be collapsed into ~12 weeks ending by August 1, 2026. The August 2, 2026 deadline has no buffer for GPAI providers.
3. The Three Architectural Invariants
Before we describe phases, establish what must be true of the end-state. These three are non-negotiable. A compliance dossier that lacks any of them will fail a notified body review or a market surveillance audit.
Invariant 1. Deterministic Pre-Execution Gate
Every AI decision must be intercepted before it executes by a governance layer that is not itself an LLM. This has two concrete implications.
Ordering. The gate runs before the model output is delivered to the downstream system, not after. A post-hoc filter is not equivalent — Article 15 (accuracy, robustness, cybersecurity) and Article 14 (human oversight) assume the control point is in the causal path of the decision, not downstream of it.
Determinism. The gate must be a pure, side-effect-free decision function whose outputs are reproducible given identical inputs. An LLM governing an LLM is not deterministic; it cannot be explained, audited, or bounded. Notified bodies will reject it.
EVE reference implementation: core/governance/failure_mode_invariant.py (127 pillars, Hard-Fail-Shut protocol, ~175 compiled regex patterns, zero I/O, zero imports outside stdlib). core/governance/veto_core.py provides the pure pre-execution checks (check_charter, check_cognitive_locks, check_drift_budget) that are formally composable and can be firmware-compiled.
Invariant 2. Cryptographically-Signed, Hash-Chained Audit Ledger
Every decision must emit a tamper-evident record that can be independently verified by a third party (auditor, regulator, insurer) without EVE's or the vendor's participation. This requires:
- JCS canonicalization (RFC 8785) on the record before signing — so that semantically identical records produce byte-identical signed payloads.
- HMAC-SHA256 or equivalent signatures keyed to a rotation-managed secret.
- Hash chaining — each record contains the hash of the prior record, so tampering with any record invalidates all subsequent ones.
- Merkle aggregation at configurable batch intervals, with signed root publication, so that a third party can verify inclusion proofs without downloading the entire log.
EVE reference implementation: core/governance/unified_audit_bus.py + core/governance/jcs_canonicalize.py + core/governance/merkle_aggregator.py. See core/memory/deletion_proof.py for GDPR-grade deletion receipts (adjacent control, not an AI-Act control, but notified bodies look for them).
Invariant 3. Fail-Closed Defaults
When a governance component errors, when an input is unrecognized, when a state transition is ambiguous — the default action is veto, never pass-through. The engineering principle: "an uncertain system is not a safe system."
Concrete rules:
- Every try/except around an enforcement call returns
BLOCK, not the prior decision. - Unknown input encodings are normalized or blocked — never passed through unnormalized (this is the NFKC + homoglyph collapse rule in the EVE
failure_mode_invariant.pymodule, Pillar 89). - A component that cannot reach its audit bus pauses the decision pipeline, rather than processing silently.
These three invariants together anchor the entire technical argument you will make to a notified body. Make them load-bearing in your architecture; do not retrofit them.
4. Phase-by-Phase Technical Roadmap
Five phases. Durations assume a dedicated team of 3 engineers + 1 compliance lead + 0.5 legal counsel working through the schedule. Larger teams can compress Phases 2 and 3; Phases 1, 4, and 5 do not parallelize well.
Phase 1 — Classification + Scoping (Weeks 1–4)
| # | Activity | Owner | Output |
| 1 | Enumerate every AI system in scope (including upstream GPAI providers you integrate) | Engineering + Product | AI system inventory |
| 2 | Classify each: Annex I, Annex III (and which of 8 use cases), GPAI, or out-of-scope | Compliance + Legal | Classification memo per system |
| 3 | For each high-risk system, identify role: provider, deployer, distributor, importer | Legal | Role memo |
| 4 | Data-flow map — where training data comes from, where inference data goes, where logs go, retention | Engineering | Data lineage diagram |
| 5 | Identify all intended purposes and reasonably-foreseeable misuses | Product + Compliance | Intended-use statement |
| 6 | Stand up the Risk Management System (RMS) — the living process that owns all controls (Article 9) | Compliance | RMS charter |
core/coreguard/policies/ reference policy packs (e.g., lending_v1.py) serve as templates for how to structure control-domain scoping.
Phase 2 — Control Design (Weeks 5–12)
| # | Activity | Owner | Output |
| 1 | Design the deterministic pre-execution gate — decision schema, intercept points, latency budget | Engineering (Architect) | ADR-001: Pre-Execution Gate |
| 2 | Design the signed audit architecture — JCS layer, HMAC key management, hash chain, Merkle roots | Engineering (Security) | ADR-002: Audit Ledger |
| 3 | Design fail-closed error handling across every component | Engineering | ADR-003: Fail-Closed Defaults |
| 4 | Design Article 14 human-oversight UX — stop/override, explanation surface, escalation workflow | Engineering + UX | UX prototype, HITL workflow |
| 5 | Design Article 15 accuracy/robustness/cybersecurity regime — eval harness, adversarial testing | Engineering (ML) | Eval harness spec |
| 6 | Design Article 12 record-keeping — exactly what each log entry contains | Engineering + Compliance | Log schema |
| 7 | Design incident response workflow (Article 73 serious incidents, 15-day reporting clock) | Compliance + Engineering | Incident playbook |
| 8 | Threat model the governance layer itself (what breaks the invariants?) | Engineering (Security) | Threat model doc |
core/governance/failure_mode_invariant.py is already a validated pre-execution gate design — 127 pillars, 1000-vector adversarial gauntlet, zero false positives in the published test set. core/governance/unified_audit_bus.py + core/governance/jcs_canonicalize.py is already a reference audit architecture. Adopting these drops Phase 2 from 8 weeks to 2 weeks of integration-planning work.
Phase 3 — Build + Integration (Weeks 13–32)
| # | Activity | Owner | Output |
| 1 | Implement (or integrate) Article 12 record-keeping — hash-chained ledger, signed certificates, Merkle aggregation | Engineering | Ledger in staging |
| 2 | Implement (or integrate) Article 14 human-oversight — stop button, override UX, escalation routing | Engineering | HITL in staging |
| 3 | Implement (or integrate) Article 15 accuracy/robustness — eval harness, adversarial test suite, post-market monitoring hooks | Engineering (ML) | Eval pipeline green |
| 4 | Implement (or integrate) Article 26/27 deployer controls — FRIA workflow, monitoring dashboards, affected-persons notification | Engineering + Compliance | Deployer tooling |
| 5 | Wire the pre-execution gate into every inference path (no bypass) | Engineering | All endpoints gated |
| 6 | Build the technical-documentation generator (auto-produces Annex IV sections 1–9 from runtime state) | Engineering | TechDoc generator |
| 7 | Internal red-team / penetration test targeting the governance layer | Security team or external | Pen-test report |
| 8 | Load testing — prove the gate's latency budget holds under production traffic | Engineering | Load test report |
core/coreguard/ + the /v1/decisions/evaluate endpoint covers items 1, 5, and 6 directly. EVE Proof SDK (sdks/proof/) covers independent verification for item 1. core/governance/novel_attack_detector.py (27 TF-IDF classes) covers adversarial testing at item 3. This drops Phase 3 from 20 weeks to 8–10 weeks when the team uses EVE modules and spends the saved time on UX and integration rather than primitives.
Phase 4 — Technical Documentation + Dossier (Weeks 33–44)
| # | Activity | Owner | Output |
| 1 | Assemble Annex IV sections 1–9 (system description, data, algorithms, metrics, HITL, changes) | Compliance + Engineering | Annex IV dossier |
| 2 | Write the Instructions for Use (Article 13) — accuracy claims, limitations, HITL expectations | Compliance + Product | IFU document |
| 3 | Assemble the QMS artifacts — policies, procedures, records, roles and responsibilities (Article 17) | Compliance | QMS manual |
| 4 | Draft the EU Declaration of Conformity (Article 47) | Legal | DoC draft |
| 5 | Complete FRIA if you are a deployer in scope of Article 27 (public service, migration, law enforcement) | Compliance + Legal | FRIA document |
| 6 | Build the runtime conformity evidence package — signed audit samples, eval reports, incident logs | Engineering + Compliance | Evidence binder |
| 7 | Internal conformity pre-audit — run the dossier against Annex IV line-by-line | Compliance | Gap report |
| 8 | Remediate gaps from pre-audit | All | Remediations |
core/governance/build_attestation.py module auto-generates supply-chain provenance (SLSA Level 2: git state, dependency hashes, source tree hash, Docker digest), which satisfies several Annex IV sub-requirements directly. core/resilience/trunk_certificate.py provides the signed resilience attestation that notified bodies have begun asking for as evidence of continuous control-plane health. Reduces Phase 4 from 12 weeks to 6–8 weeks.
Phase 5 — Conformity Assessment + CE Marking (Weeks 45–66)
| # | Activity | Owner | Output |
| 1 | Select path: notified body (Annex I, biometrics) or internal assessment (most Annex III) | Legal + Compliance | Path decision |
| 2 | If notified body: RFP, engagement, contract | Legal + Procurement | NB engaged |
| 3 | Submit dossier to notified body; respond to document requests | Compliance | Dossier under review |
| 4 | Onsite or virtual audit (typical: 3–5 days); remediate findings | All | Audit findings closed |
| 5 | If internal: formally execute Module A internal assessment per Annex VI | Compliance | Internal assessment |
| 6 | Receive certification or positive internal assessment outcome | — | Certificate |
| 7 | Apply CE mark; file DoC; register in EU database of high-risk AI systems (Article 71) | Legal + Compliance | Registration |
| 8 | Stand up post-market monitoring (Article 72): telemetry, review cadence, incident reporting (Article 73) | Engineering + Compliance | PMM live |
/coreguard and /proof products substantially reduce document-request round-trip time during NB review because every question about "how does your system actually demonstrate X" has a pre-built signed-evidence answer. Typical observed reduction: NB review compresses from 22 to 14–16 weeks.
After T-0: Post-Market Monitoring (ongoing)
Article 72 requires a documented post-market monitoring system: systematic collection of operational data, periodic review, incident reporting (Article 73: 15 days for serious incidents, 2 days for widespread infringement or critical-infrastructure disruption). This is not a phase — it is a permanent operating mode that begins the day you place the system on the market or put it into service. See §9 for how to operationalize post-market monitoring with unified audit bus, Merkle aggregator, and the resilience score engine.
5. Build vs. Buy Decision Matrix
For each of the four technical obligation controls, the realistic options are: build from scratch, buy a point solution (limited vendor market in early 2026), hybrid (build the last-mile, buy the primitive), or adopt EVE AI Core. Effort in person-weeks assumes a 3-engineer team with no prior governance-infrastructure experience.
| Obligation | Build (PW) | Buy | Hybrid | EVE Option | EVE Integration (PW) |
| Art. 12 — Record-keeping Hash-chained ledger, JCS canonicalization, signed certificates, Merkle aggregation, root publication |
20–30 | Not available as a turnkey product in April 2026. Adjacent SIEMs do not provide JCS + Merkle + inclusion proofs. | Build the audit schema; adopt a crypto-primitives library (HMAC/Merkle). Saves ~5 PW. | unified_audit_bus.py + merkle_aggregator.py + jcs_canonicalize.py |
2 |
| Art. 14 — Human oversight Stop/override UX, explanation surface, escalation routing, audit of oversight events |
15–20 | Partial: several vendors offer "human-in-the-loop" annotation UX, but none integrate cleanly with a pre-execution gate. | Build the UX; use EVE for the decision-ledger integration. | EVE Proof SDK + action_registry.py (3-phase propose/approve/execute workflow) |
4 |
| Art. 15 — Accuracy, robustness, cybersecurity Eval harness, adversarial test suite, continuous monitoring, ingress/egress filters |
25–40 | Limited: Red-teaming vendors exist but most do not produce persistent signed evidence suitable for a conformity dossier. | Buy red-teaming as a service; build the persistent evidence pipeline. | failure_mode_invariant.py (127 pillars) + novel_attack_detector.py (27 TF-IDF classes) + resilience_score.py |
4 |
| Art. 26/27 — Deployer controls + FRIA Monitoring dashboards, affected-persons notification, FRIA workflow, data-subject rights tooling |
12–18 | Some GRC platforms offer FRIA templates. None wire to a live gate. | Buy templates; build the runtime integration. | core/coreguard/ endpoint + deletion_proof.py (data subject erasure) |
3 |
| Totals | 72–108 PW build | — | — | — | 13 PW integration |
The build-from-scratch path for a 3-engineer team is approximately 24–36 calendar weeks of engineering alone. The EVE integration path is approximately 4–5 calendar weeks. The ~20-week difference is the dominant determinant of whether an organization starting today hits the August 2, 2027 deadline.
6. Cost Model (Micro / Mid / Enterprise)
The numbers below are internal-cost estimates. Actual cost varies significantly by jurisdiction, engineer seniority, and existing tooling. Figures in USD; conformity assessment fees are in EUR as quoted.
Scenario A — Micro (1 AI product, solo founder + 1–2 contractors)
Annex I (NB): ~$352k–$390k
Annex I (NB): ~$154k–$213k
Savings of approximately $174k–$198k on the Annex III internal-route. The dominant saver is engineering: 55 PW of governance-primitive building collapses to 8 PW of integration when you do not have to invent JCS, Merkle, Hard-Fail-Shut, and a 127-pillar enforcement list from first principles.
At a solo-founder cost structure, the EVE path also shortens calendar time enough to matter for runway.
Scenario B — Mid-Market (5–50 engineers, 2–4 AI products, 1 regulated)
Savings of approximately $400k–$700k, and — more importantly — a faster path through the notified body queue. In Q1 2027 the marginal calendar week is worth more than the marginal dollar.
The compliance and legal headcount does not collapse, because those teams still have to run FRIA, Instructions for Use, QMS, and the incident-response program. What collapses is the build effort.
Scenario C — Enterprise (50+ engineers, regulated industry, 5+ AI products)
Savings of approximately $1.5M–$2.0M on a base spend of five to seven million, plus the reduction in execution risk that comes from not building governance primitives while also shipping product.
At enterprise scale the audit-evidence substrate is reused across every product line, so the licensing cost amortizes quickly.
Notified body rates are rising. Market signal as of Q1 2026: EUR 30k–60k for a single Annex III conformity with a small product; EUR 80k–150k for Annex I or biometric systems; EUR 150k–400k+ for complex multi-model dossiers. Availability tightens significantly through 2026 as demand ramps. Engage a notified body now if you intend to use one.
7. Risk Flags That Kill Schedules
These are the failure modes that most commonly cause a compliance program to slip past August 2, 2027. Every one of them has been observed in adjacent regulatory programs (GDPR, DORA, HIPAA).
core/governance/unified_audit_bus.py if time-constrained.8. The Acceleration Path — If You Have EVE AI Core
The base roadmap totals approximately 66 weeks (Phases 1–5, weeks 1–66). Integrating EVE AI Core modules compresses the phases as follows:
| Phase | Base (weeks) | With EVE (weeks) | Delta |
| 1. Classification + Scoping | 4 | 4 | −0 |
| 2. Control Design | 8 | 2 | −6 |
| 3. Build + Integration | 20 | 8 | −12 |
| 4. Technical Documentation | 12 | 7 | −5 |
| 5. Conformity Assessment | 22 | 16 | −6 |
| Total | 66 | 37 | −29 |
The 37-week path begins today (week 0 = April 16, 2026) and lands at week 37 = January 1, 2027 — which leaves a 31-week buffer before the high-risk deadline. In practice that buffer is absorbed by notified body queue and by remediation cycles that are not fully predictable.
The 37-week path assumes:
- EVE modules are adopted as-is for the pre-execution gate and audit ledger — no custom forks.
- Your integration team has at least one senior engineer experienced with signed-attestation systems.
- Your compliance lead has direct reading access to the EVE audit stream (via
/v1/decisions/evaluateand EVE Proof verification). - You do not have unusual upstream GPAI supplier dependencies that require independent re-certification.
Where the savings come from:
- Phase 2 −6 weeks: The three architectural invariants are already designed, tested, and validated against a 1000-vector adversarial gauntlet. Your design work shrinks to "how do I integrate" rather than "how do I invent."
- Phase 3 −12 weeks: The four obligation controls have EVE reference implementations. The integration work is wiring, not inventing.
- Phase 4 −5 weeks: Build attestations, resilience certificates, and signed audit samples are auto-generated.
- Phase 5 −6 weeks: Notified body review is faster when every evidence request has a signed artifact behind it.
9. Monitoring After Compliance
Article 72 post-market monitoring is permanent. It is the operating mode, not a phase. The compliance program does not end on August 2, 2027; it becomes steady-state.
Four obligations persist:
- Operational telemetry collection. Accuracy, robustness, drift, and incident data must be continuously collected against a documented monitoring plan. EVE support:
core/resilience/resilience_score.pyprovides a composite 0–100 score across governance, identity, behavioral, and governance sub-layers;core/resilience/trunk_certificate.pyprovides signed snapshots suitable for auditor verification. - Periodic review. The RMS must be reviewed at minimum annually (more often if the system changes materially). Every review produces a signed record. EVE support: the unified audit bus + Merkle aggregator produces a quarterly signed Merkle root that summarizes all decisions for the quarter; regulators can verify inclusion of any single decision without downloading the full log.
- Incident reporting (Article 73). Serious incidents: 15 days from awareness. Widespread infringement or critical-infrastructure disruption: 2 days. Reporting is to the competent authorities of the member states affected. EVE support: the audit bus emits
severity=seriousevents that can be wired to an incident reporting workflow. - Substantial modification review. Material changes to the system trigger re-assessment. Whether a change is "substantial" is a judgment call that needs a documented policy. EVE support: the
core/governance/build_attestation.pymodule detects git-level and dependency-level changes automatically and can trigger substantial-modification review.
Continuous compliance is cheaper than periodic compliance if the audit evidence is continuously signed and continuously verifiable. The upfront investment in the three architectural invariants pays off across every audit cycle for the life of the system.
10. Close — What to Do This Week
You have roughly 15.5 months to the high-risk deadline. The notified body queue compresses that to 9 months of useful time. This roadmap's base path is 66 weeks; the EVE-accelerated path is 37 weeks. Both are feasible from today. Neither is feasible from Q4 2026.
This week.
- Lock Phase 1 classification decisions. If you haven't done them, do them.
- Make the build-vs-EVE decision at the architecture level. The decision gates every downstream timeline.
- Engage a notified body in an exploratory RFP if you're on the Annex I path. Queue position in early 2027 is a strategic asset.
Where to engage EVE AI Core
POST /v1/decisions/evaluate endpoint suitable for integration as the Invariant 1 pre-execution gate.The document count for this compliance series ends here. The deadline clock does not. If you want a deeper pass — mapping your specific deployment to the Articles, scoping the conformity-assessment work, and sequencing the phases against your release calendar — schedule a compliance architecture review. August 2, 2027 is fifteen and a half months away. Phase 1 was supposed to be done two weeks ago. There is no runway left for delay.
Legal notice. This document is informational and does not constitute legal advice. Compliance strategy must be validated by qualified counsel and, where applicable, a notified body. EVE AI Core references describe the reference architecture as of the publication date; specific module behavior may evolve. For the authoritative source on EVE modules, see the repository at core/governance/, core/resilience/, core/coreguard/, and sdks/proof/.