A requirement-by-requirement map of the amended EU AI Act to Smartflow's enforcement plane and EU AI Act Conformity Console, with conservative verdicts and the gap to close. Companion to the IMDA mapping.
The Digital Omnibus is a simplification package, not a rollback. It lightens process and paperwork while leaving the substantive runtime obligations intact — and in two places it makes them stricter and more enforceable:
The Omnibus removes paperwork but doubles down on the two things Smartflow is: a deterministic runtime enforcement plane between the agent/model and the systems it touches, and a tamper-evident, machine-readable evidence layer a supervisor can inspect on demand.
"… reasonable and adequate technical safety measures … including runtime prompt guardrails, content classification and filtering mechanisms, usage restrictions, abuse detection mechanisms, and notice and action mechanisms." — Recital 12, p.12
"… order operators to provide access to … their AI systems … impose an obligation on an operator to retain all data and documents deemed to be necessary to assess … compliance." — Art 75a(6), p.77
Smartflow already ships the EU AI Act Conformity Console (src/conformity_api.rs, /api/conformity/* + /conformity dashboard) surfacing regulator-facing evidence for Articles 9, 10, 11/Annex IV, 12, 13, 14, 15, 17, 26 and 79 — the exact articles this Omnibus restructures.
Delta view: the substantive runtime obligations survive; the changes are scope-tightening, burden relief, two new prohibitions, and a much stronger central enforcement + evidence regime.
| Provision | Original AI Act (2024/1689) | Digital Omnibus change (PE-CONS 30/26) | Smartflow angle |
|---|---|---|---|
| Art 5 — Prohibited practices | Fixed list (manipulation, social scoring, untargeted scraping, etc.) | Adds (ba) non-consensual intimate material & (bb) CSAM; providers must hold "reasonable and adequate technical safety measures" where misuse is foreseeable (Art 5(1a)); Recital 12 names runtime guardrails, content filtering, usage limits, abuse detection | Directly our enforcement plane — see Block A |
| Art 4 — AI literacy | Binding duty to "ensure a sufficient level of AI literacy" | Softened to "take measures to support" AI-literacy development | Lower friction for customers; not a gateway feature |
| Art 4a (new) — Bias-detection data | Art 10(5): special-category processing limited to providers of high-risk systems | Extended to deployers & other AI/models, under strict access-control, documentation & deletion safeguards | Access logging + information barriers evidence the safeguards |
| Art 3(14), 6(1a–1c) — Safety component / high-risk scope | Broad "safety component" definition | Clarified & narrowed; non-safety functions (assistance, optimisation, convenience, QC) don't trigger high-risk | Fewer systems in scope, but those in scope still need runtime control |
| Art 2(13) (new) — Equivalence limitation | Art 9–15 / 17–25 apply in full | Commission may limit these where Section A product law gives equivalent protection (delegated acts by 2 Aug 2027) | Console maps to whichever set remains in force per product |
| Art 11 / 17 / 63 — Docs & QMS | Full Annex IV documentation & QMS | Simplified Annex IV & proportionate QMS for SMEs/SMCs; new SME/SMC definitions (Art 3(14a/14b)) | Auto-generated evidence lowers the bar further |
| Art 28 / 29 / 43 — Conformity assessment | Separate designations per legislation | Single application + unified assessment; new Annex XIV code taxonomy (AIP/AIB/AIH) | Process change; no gateway impact |
| Art 42(3) (new) — Cybersecurity presumption | Art 15 cybersecurity assessed independently | High-risk AI in scope of the Cyber Resilience Act (2024/2847) deemed to meet Art 15 cybersecurity | Complements our robustness/abuse controls |
| Annex I / Machinery | Machinery (2023/1230) in Section A | Moved to Section B (sectoral approach); delegated acts by 2 Aug 2028 | EASA & machinery now sector-routed |
| Art 50(7) — Synthetic-content marking | Codes of practice encouraged | Commission may set common rules if codes are inadequate (implementing act) | Marking is product/provider-side (watch item) |
| Art 72(3) — Post-market monitoring | Harmonised plan template mandated | Template empowerment removed; flexible plan, guidance by 2 Sep 2027 | Our monitoring/analytics feed the plan |
| Art 75 + 75a–75d (new) — Central enforcement | Mainly national market-surveillance authorities | AI Office exclusively competent for GPAI-based systems & VLOPs; direct investigation/inspection powers, order access & retention, fines + periodic penalties up to 5% daily turnover | Tamper-evident chain = the retained record on demand |
| Art 77 — Fundamental-rights access | Authorities may request information | Must be provided in machine-readable format by electronic means | Exactly the Conformity Console output |
| Entry into application | Staggered to 2 Aug 2027 | Omnibus enters into force urgently (3rd day after publication); key delegated acts 2 Aug 2027, machinery 2 Aug 2028 | Buyers need a compliance answer now |
| Omnibus requirement (page) | Smartflow capability / evidence | Verdict |
|---|---|---|
| Runtime prompt guardrails against prohibited generation (Recital 12, p.12; Art 5(1a)) | Maestro semantic policy corpus + request-side guardrail graph; Shield destructive-prompt rules — request-path enforcement | EXISTS |
| Content classification & filtering of inputs/outputs (Recital 12) | compliance_detector — PII / toxic / regulated-content classification at ingest and egress (MCP_COMPLIANCE_SCAN_ENABLED); perimeter classification on egress (src/perimeter.rs) | EXISTS |
| Usage restrictions & abuse detection (Recital 12) | Per-key/route allowlists, budgets, rate limiter + adaptive rate limiter; Retrospector multi-turn abuse passes | EXISTS |
| Notice-and-action on observed/reported misuse + corrective action on circumvention (Recital 12, p.12) | Blocked-action sealing into the VAS hash chain + alerting fan-out; Shield approval/override queue closes the loop | PARTIAL |
| Consent collection for lawful intimate-material generation; synthetic-content marking (Art 5(1a); Art 50) | Identity/consent attestation possible via ID.me step-up, but consent capture & C2PA-style content watermarking are product/provider-side | ABSENT |
| AI Act article (as amended) | Smartflow capability / evidence (Conformity Console) | Verdict |
|---|---|---|
| Art 9 — Risk-management system | Guardrail policy graph, Maestro corpus, Shield tiered destructive-op rules; GET /api/conformity/articles/art_9 | EXISTS |
| Art 10 + new Art 4a — Data governance & bias-detection safeguards | compliance_detector data-class scopes; information-barrier (LDAP-group × content-label); AIDA signed data-class scopes. Art 4a access-control/documentation/deletion safeguards partly covered by access logging | PARTIAL |
| Art 11 / Annex IV — Technical documentation (simplified for SMEs/SMCs) | Examination suite + AI inventory + signed AI-BOM; JSON export; GET /api/examinations, /api/ai_inventory | PARTIAL |
| Art 12 / Art 19 — Automatic record-keeping over lifecycle | VAS per-request log (input/output/model/identity/decisions) + audit_chain HMAC-SHA256 prev-hash chain; independently re-runnable audit-verifier; POST /api/admin/audit/verify_chain | EXISTS |
| Art 13 — Transparency / information to users | Maestro response banners; x-smartflow-group-banner, x-shield-warn headers for downstream UI | PARTIAL |
| Art 14 — Human oversight (effective oversight by natural persons) | Shield High-severity → human approval queue; live ID.me human-in-the-loop step-up (IAL2/AAL2 + liveness) holds high-risk LLM/MCP calls until a verified human approves; Phase-4 oversight analytics (override rate / approval latency / outlier reviewers) | EXISTS |
| Art 15 + new Art 42(3) — Accuracy, robustness, cybersecurity (CRA presumption) | AI analyzer (hallucination confidence), A/B regression detection, alerting; Shield blocks destructive prompts + tool calls; rate limiter / circuit breaker | PARTIAL |
| Art 17 / Art 63 — Quality-management system (proportionate for SMEs/SMCs) | Retrospector 5-pass async QMS program; examination framework reports; alerting pipelines; GET /api/retrospector/passes | PARTIAL |
| AI Act article (as amended) | Smartflow capability / evidence | Verdict |
|---|---|---|
| Art 26 — Deployer obligations (human oversight, monitor, keep logs) | ID.me-attested deployer natural-person identity; every request stamped with user_id/groups/department; tamper-evident logs of deployer actions; GET /api/audit/logs?event_type=verified_identity | EXISTS |
| Art 72 — Post-market monitoring (flexible plan) | VAS analytics + perimeter egress monitoring + Retrospector nightly org report; no formal post-market-monitoring-plan export yet | PARTIAL |
| Art 73 / 79 — Serious-incident reporting (incl. to AI Office, Art 75(1a)) | Critical shield/nipr audit events + severity≥High Retrospector findings + webhook fan-out; pre-formatted incident envelope at GET /api/conformity/incidents | EXISTS |
| Omnibus power (page) | Smartflow capability / evidence | Verdict |
|---|---|---|
| AI Office may order access to the AI system & retain all data/documents (Art 75a(6), p.77) | Conformity Console read-only API surfaces live evidence per article; tamper-evident audit chain provides the retained record on demand | EXISTS |
| Fundamental-rights bodies may demand evidence in machine-readable format (Art 77(1), p.84) | /api/conformity/* returns structured JSON evidence + honest gap list per article; dashboard at /conformity | EXISTS |
| Inspections / proof of tamper-free records over time | Independently rebuildable audit-verifier (regulator-runnable). Gap: WORM retention (S3 Object Lock / Azure immutable) + RFC 3161 trusted timestamps on roadmap (B5/B6) | PARTIAL |
| Ability to take a system offline / limit blast radius during enforcement | Gateway-wide emergency stop (off / read-only / halt) across proxy + MCP + A2A, audit-chained (src/emergency_stop.rs, POST /api/admin/emergency-stop) | EXISTS |
| # | Omnibus theme | Verdict | One-line position |
|---|---|---|---|
| 1 | Art 5 runtime safeguards (NCII/CSAM) | EXISTS | Guardrails, content filtering, usage limits, abuse detection on the request path; consent/marking is product-side |
| 2 | High-risk duties Art 9–17 | PARTIAL | Console evidences all of them; Art 9/12/14 fully on hot path, rest partial/opt-in |
| 3 | Human oversight Art 14/26 | EXISTS | Live ID.me human-in-the-loop step-up + oversight analytics — strongest row |
| 4 | Record-keeping Art 12/19 | EXISTS | Tamper-evident chain + regulator-runnable verifier; WORM/RFC-3161 on roadmap |
| 5 | Incidents Art 73/79 | EXISTS | Pre-formatted incident envelope; per-Member-State templates on roadmap |
| 6 | AI Office evidence-on-demand Art 75a/77 | EXISTS | Machine-readable Conformity Console is exactly what the new powers require |
| 7 | Burden relief (SME/SMC docs, unified CA) | N/A | Process simplification — reduces customer friction to adopt Smartflow, not a gateway feature |
The Digital Omnibus is net-positive for APERION. It strips out paperwork that never differentiated us, while sharpening the two demands only a runtime layer can satisfy: (1) Article 5 now explicitly expects "runtime prompt guardrails, content filtering, usage restrictions and abuse detection" — Smartflow's core — and (2) the AI Office's new powers to compel access, retention and machine-readable evidence map one-to-one onto our tamper-evident audit chain and the /api/conformity/* console. The headline runtime story — holding a high-risk action until a government-grade verified human (ID.me IAL2/AAL2) approves it, now live on cluster1 — is a direct, demonstrable answer to Article 14 human-oversight effectiveness. Honest gaps remain on the evidentiary hardening track (WORM retention, RFC 3161 timestamps) and on provider-side concerns the gateway does not own (training-data lineage, synthetic-content marking, consent capture). Closing the hardening track yields legal-grade, on-demand conformance evidence for an EU-published, freshly-simplified regime — a strong differentiator for regulated buyers and SMEs/SMCs the Omnibus is explicitly courting.