The EU AI Act (Regulation 2024/1689) is unusual among regulations in that it specifies technical obligations, not just process ones. Article 12 does not ask whether you have a logging policy; it requires automatic, traceable, tamper-evident logs. Article 14 does not ask whether oversight is described in your documentation; it requires that oversight be designed into the system. Article 15 does not ask for a robustness plan; it requires appropriate levels of accuracy and resilience to adversarial manipulation. Every one of these is an architectural property that either exists in your system or does not.
This reference is the lookup: for every obligation, what architectural property it demands, what typical stacks fail to provide, and how EVE AI Core's components map onto each one. The layout is intentionally dense. It is meant to be used the way an auditor uses a compliance matrix during conformity assessment — by Article number, left to right, without narrative detour.
How to Read This Reference
Each row in the tables below has five columns. The first three describe the obligation as the Act states it and the architectural property required to satisfy it. The fourth names the architecture pattern that typically fails. The fifth names the EVE AI Core component that provides the required property.
Column 1-2
Obligation
The Article number and the operative requirement, in plain language. Where the Article has multiple paragraphs, rows are split by paragraph so that each row maps to a single architectural property.
Column 3
Required architectural property
The technical design attribute the obligation demands — for example, tamper-evident logging, deterministic gating, fail-closed behaviour, signed verdicts. This is the part that either exists in your system or does not.
Column 4-5
What fails · What satisfies
Column 4 names the typical architecture pattern that fails the property. Column 5 names the EVE AI Core component that provides it. Component names match the modules in
core/governance/ and the product surfaces CoreGuard, EVE Proof, and the Sovereign SDK.Note. This reference covers the technical obligations. It does not replace legal advice on risk classification, conformity-assessment route, or notified-body selection. Risk classification in particular must be confirmed with counsel before relying on any of the mappings below.
Providers of High-Risk AI — Articles 8 to 17
Articles 8 through 17 define the substantive requirements a provider must satisfy before placing a high-risk AI system on the EU market or putting it into service. CE marking and conformity assessment depend on each of these being demonstrable.
| Article | Obligation | Required architectural property | Architecture that FAILS it | EVE AI Core component |
| Art. 8 | Compliance with the Chapter III Section 2 requirements, considered together with the system's intended purpose and the state of the art. | A demonstrable end-to-end compliance envelope: every downstream obligation is traceable to a component, and the component is testable. | Spread-across-microservices compliance with no single surface that shows the whole envelope. | Unified control-plane stack: CoreGuard gate, EVE Proof ledger, and Sovereign SDK provide one coherent compliance envelope exposable under one schema. |
| Art. 9(1-5) | Risk management system established, implemented, documented, and maintained. Identifies and analyses known and reasonably foreseeable risks across the lifecycle. | A living risk register that is machine-queryable, versioned, and linked to the enforcement rules that mitigate each identified risk. | Risk register as a Word document updated quarterly with no link to production controls. | Policy-as-Code Engine with versioned policy bundles; each rule is traceable to the risk it mitigates. Risk register exported from core/governance/ config. |
| Art. 9(6-9) | Testing of risk-management measures, including against reasonably foreseeable misuse. Testing performed at appropriate points throughout development. | Reproducible adversarial test harness with documented attack classes, executable on every build. | Ad-hoc red-team exercise run once before launch and never repeated. | Sovereign 1000 adversarial gauntlet: 1000 vectors, 13 pattern groups, versioned attack taxonomy, executable pre-deployment and in CI. |
| Art. 10(1-3) | Training, validation, and testing datasets subject to data-governance practices. Relevance, representativeness, freedom from errors, statistical properties appropriate to the intended purpose. | Dataset provenance records with source, collection method, representativeness assessment, and version-pinning. | Training data stored in S3 with no immutable manifest; model card written months after training. | Build Attestation (SLSA Level 2) records dataset hashes and source tree state per build. Ground Truth Validator anchors factual claims to a curated source set. |
| Art. 10(5) | Examination for possible biases that could affect health, safety, fundamental rights, or produce discriminatory outcomes. | Repeatable bias-examination protocol with stored baseline metrics and regression alerts. | One-off bias audit that becomes stale the day the next model update ships. | CRD Engine (Confidence-Reality Divergence) continuously scores calibration gaps; regression results persisted in data/governance/regression_results.json. |
| Art. 11 | Technical documentation drawn up before placing on the market, kept current, and containing the content set out in Annex IV. | Documentation that auto-generates from the running system so it cannot drift out of sync with deployed artefacts. | Static PDF that lags the codebase by months. | Build Attestation + SBOM (CycloneDX 1.4) produce Annex-IV-aligned artefacts per build. Decision certificates document model identity, policy version, and evidence chain. |
| Art. 12(1-2) | Automatic recording of events ("logs") over the lifecycle. Level of traceability appropriate to the intended purpose. | Logs that are automatic, immutable, and cryptographically verifiable without trusting the logger. | Application stdout piped to a mutable log store any engineer can edit. | EVE Proof Ledger: HMAC-SHA256 signed, hash-chained v1.1 governed-decision certificates. Independently verifiable via POST /api/tve/verify-attestation. |
| Art. 12(3) | Logs must allow identification of situations resulting in risk and enable post-market monitoring. | Structured event taxonomy with enough dimensions to reconstruct any decision after the fact. | Free-text log lines with no consistent schema. | Unified Audit Bus (JCS-canonicalized, RFC 8785). 16 event source types; Merkle-aggregated with signed root publication. |
| Art. 13(1-2) | Transparency sufficient to enable deployers to interpret output and use appropriately. Instructions for use include accuracy, robustness, cybersecurity characteristics. | Deployer-facing instructions that are machine-readable and match the deployed artefact exactly. | Marketing copy and README describing a capability that the model no longer has. | Decision Certificate Schema v1.1 documents capability envelope per tenant. Sovereign SDK exposes capability-query endpoint. |
| Art. 13(3) | Characteristics, capabilities, and limitations of performance, including intended purpose, accuracy, and known circumstances that may lead to risks. | Per-tenant capability envelope that restricts what the system may do, and an enumeration of known failure modes. | "Best effort" disclaimers in the terms of service. | Bounded Agency constraints per tenant; 127-pillar enforcement list serves as the enumerated failure-mode catalogue. |
| Art. 14(1-3) | Designed and developed so as to be effectively overseen by natural persons during the period in which the system is in use. | Built-in interception point before execution, with structured verdicts a human can act on. | Post-hoc content filter that sees the output only after it has left the model. | CoreGuard pre-execution gate: every decision intercepted before execution; structured ALLOW/MODIFY/BLOCK verdicts with full reasoning delivered to the operator console. |
| Art. 14(4) | Enable the natural person to understand capacities and limitations, remain aware of automation bias, correctly interpret output, decide not to use, and intervene or interrupt. | Real-time kill switch; approval workflow for high-risk actions; reasoning exposed in operator-legible form. | No human-in-the-loop surface; UI shows only the final output. | Operator Console: real-time kill switch, approval workflow, reason-annotated verdicts, decision replay against the certificate chain. |
| Art. 15(1) | Appropriate level of accuracy, robustness, and cybersecurity; performance consistent throughout the lifecycle. | Fail-closed defaults, deterministic enforcement independent of model non-determinism, continuous performance monitoring. | LLM-based moderation of an LLM: non-determinism stacked on non-determinism. | Failure-Mode Invariant module: Hard-Fail-Shut protocol, 175 compiled regex across 13 pattern groups, pure deterministic, zero I/O. |
| Art. 15(3) | Resilience against errors, faults, or inconsistencies; technical redundancy solutions such as backup or fail-safe plans. | Circuit-breaker on external dependencies; graceful degradation path; fail-closed default. | Single-vendor dependency with no failover and no degraded mode. | LLM Fallback Router with per-provider circuit breakers. Degradation levels none, reduced, fallback, browser, text. Fails closed on governance errors. |
| Art. 15(4) | Resilience against unauthorised third parties attempting to alter use or performance by exploiting system vulnerabilities. | Input normalisation before pattern match (NFKC, homoglyph collapse); novel-attack detection; hardened supply chain. | Simple string matching on user input; homoglyph and zero-width character bypasses succeed. | Failure-Mode Invariant Pillar 89 (NFKC + 35 homoglyph mappings). Novel-Attack Detector: 27 TF-IDF centroid classes for semantic attacks. |
| Art. 15(5) | Declared levels of accuracy and relevant accuracy metrics in the instructions for use. | Published, versioned metric set with calibration and reproducible measurement protocol. | Accuracy claim made once in a blog post and never re-measured. | Brier-score calibration in Claims Ledger; Research Mode protocol for reproducible measurement; metrics exported per policy version. |
| Art. 16 | Obligations of providers: QMS, technical documentation, automatic logs, conformity assessment, registration, CE mark, corrective actions, market surveillance cooperation. | Unified compliance surface that exposes every provider obligation through a single, auditable interface. | Obligations spread across ticketing systems, spreadsheets, and chat messages. | Sovereign SDK exposes the full provider compliance surface at /api/sovereign/ — one API-key-authenticated interface per org. |
| Art. 17 | Quality management system: compliance strategy, design-control, development-control, verification, post-market plan, resource management, accountability framework. | An audit-trail substrate the organisation's QMS can attach to; not a substitute for the QMS itself. | Custom QMS with no machine interface, manually reconciled against engineering artefacts. | Build Attestation + Unified Audit Bus + Decision Certificates provide the evidence substrate. QMS remains your responsibility; we make it verifiable. |
Deployers of High-Risk AI — Articles 26 and 27
Deployers are the organisations that put a high-risk AI system into use, distinct from the providers who built it. Deployer obligations are often the most underestimated part of the Act, because embedding a third-party model in a product that affects fundamental rights makes you the deployer — regardless of who trained the underlying model.
| Article | Obligation | Required architectural property | Architecture that FAILS it | EVE AI Core component |
| Art. 26(1) | Use the system in accordance with the instructions for use provided by the provider. | Policy engine that enforces the provider's envelope at runtime rather than relying on operators to remember it. | Instructions read by integration engineers at onboarding and never referenced again. | Policy-as-Code Engine: provider envelope compiled into enforcement rules; deviations produce BLOCK verdicts. |
| Art. 26(2-3) | Assign human oversight to natural persons who have the necessary competence, training, authority, and support. | Role-scoped operator console; approval-chain records; competence gating per action type. | Shared admin credentials used by whoever is on-call. | RBAC (5 roles, 9 granular permissions) with tenant isolation. Operator Audit Logger records actor, action, resource per operation. |
| Art. 26(4) | Ensure input data is relevant and sufficiently representative in view of the intended purpose. | Input-validation layer with per-tenant schemas, rejection of off-distribution input. | Unrestricted input handed straight to the model. | CoreGuard pre-execution gate validates input class; Contextual Harm Classifier rejects off-distribution prompts. |
| Art. 26(5) | Monitor operation based on instructions for use, inform provider of risks, suspend use where warranted. | Real-time monitoring surface with structured incident taxonomy; one-click suspension. | Ticketing-based escalation with hours of latency. | Operator Console live incident feed; Red Team Mode toggle for one-click tightening; emergency-stop endpoint. |
| Art. 26(6) | Keep the logs generated by the system for at least six months (or longer where required), unless otherwise provided. | Retention-policy engine with cryptographic retention proof; append-only storage. | Log retention governed by whichever engineer set up the log pipeline, with no verification. | Unified Audit Bus writes to append-only JSONL (data/audit/unified_audit.jsonl); retention policy enforced per tenant with Merkle-root-signed chain verification. |
| Art. 26(7) | Where workplace deployment, inform workers' representatives and affected workers before putting the system into use. | Deployment-notification template, audit log of notification, tie-in to HR systems. | Deployment proceeds without any notification trail. | Deployment audit events via Unified Audit Bus (source type deployment_notice); template generator in Sovereign SDK. |
| Art. 26(8) | Comply with obligation to inform natural persons subject to the use of a high-risk AI system that they are subject to it. | Structured disclosure surface tied to each session; user-facing explanation of the decision. | Disclosure hidden in an unread terms-of-service document. | Decision Certificate Retrieval (GET /api/tve/certificates/{id}) exposes decision reasoning to the affected person. |
| Art. 26(10) | Inform the provider and, where relevant, market-surveillance authorities of any serious incident. | Serious-incident reporting pipeline with defined timelines, signed artefacts. | Manual email reports assembled after the fact. | Incident reporting via data/governance/incident_log.jsonl; signed attestation per incident; webhook events route to provider and authority endpoints. |
| Art. 27 | Fundamental Rights Impact Assessment (FRIA) before first use, for public-body deployers and Annex III points 5(b) and 5(c) deployers. | Evidence collection substrate for the assessment; structured risk taxonomy; reviewable audit trail. | FRIA treated purely as a written document with no link to runtime evidence. | We provide the evidence substrate (audit bus, decision certificates, incident log). The assessment itself is your responsibility — see limitations section. |
Transparency Obligations — Article 50
Article 50 applies horizontally to several classes of AI system irrespective of risk tier. It governs chatbots, synthetic content, emotion recognition, biometric categorisation, and deepfakes. Obligations take effect on 2 August 2026.
| Article | Obligation | Required architectural property | Architecture that FAILS it | EVE AI Core component |
| Art. 50(1) | Providers of AI systems intended to interact directly with natural persons must design and develop them so the persons are informed they are interacting with an AI system. | Explicit AI-disclosure surface in the interaction channel; identifiable in session metadata. | Chatbot presented as a human agent with no disclosure. | Session metadata carries AI-identity assertion; disclosure enforced at the pre-execution gate; breach produces BLOCK verdict. |
| Art. 50(2) | Providers of AI systems that generate synthetic audio, image, video, or text content must mark outputs as artificially generated or manipulated (machine-readable). | Cryptographic watermark or C2PA-style content credentials bound to the generation event. | Visible watermark that can be cropped; no embedded metadata. | Decision Certificate binds synthetic output to generation event; certificate ID embedded in output metadata; C2PA-compatible export. |
| Art. 50(3) | Deployers of emotion-recognition or biometric-categorisation systems must inform affected natural persons of the operation and process personal data in line with GDPR and Regulations 2016/679 / 2018/1725. | Per-subject disclosure event recorded at time of categorisation; consent state tracked. | Blanket notice at a building entrance with no per-subject record. | Per-subject disclosure events emitted to the Unified Audit Bus; consent-state tracked in the PII stats store; tied to signed certificate. |
| Art. 50(4) | Deployers of AI systems generating or manipulating image, audio, or video content constituting deepfakes must disclose the content has been artificially generated or manipulated (artistic and satirical exceptions apply). | Deepfake detection, classification, and disclosure-enforcement layer tied to output pipeline. | Disclosure left to content creators and enforced by social pressure. | Deepfake class tagged at decision time; disclosure string injected into output metadata; BLOCK verdict when disclosure is stripped. |
General-Purpose AI — Articles 53 and 55
Articles 53 and 55 apply to providers of General-Purpose AI models. Article 53 sets baseline transparency and copyright obligations for all GPAI providers. Article 55 layers additional obligations on providers of GPAI models classified as having systemic risk (models exceeding 10^25 FLOPs of training compute, or designated by the AI Office).
| Article | Obligation | Required architectural property | Architecture that FAILS it | EVE AI Core component |
| Art. 53(1)(a) | Draw up and keep up-to-date technical documentation of the model (Annex XI content), including training and testing process and evaluation results. | Auto-generated technical documentation tied to the build; versioned alongside model weights. | Model card last updated before launch and never synced with the deployed model. | Build Attestation + Algorithm Agility policy tracker produce Annex-XI-aligned artefacts per build. |
| Art. 53(1)(b) | Draw up, keep up-to-date, and make available information and documentation to providers of AI systems integrating the model (Annex XII content). | Machine-readable downstream-provider information surface; capability/limitation enumeration. | Downstream integrators call support to find out what the model does. | Sovereign SDK capability-query endpoint; Decision Certificate Schema v1.1 exposed per tenant. |
| Art. 53(1)(c) | Put in place a policy to comply with Union law on copyright and related rights, including state-of-the-art technologies for reservation-of-rights respect. | Training-data rights policy encoded as enforceable rules; opt-out enumeration; per-source licensing status. | Training-data sourcing left undocumented. | Rights policy encoded in Policy-as-Code; per-source licensing status tracked in Ground Truth Validator source set. |
| Art. 53(1)(d) | Draw up and make publicly available a sufficiently detailed summary about the content used for training. | Public training-content summary generated from the same data-governance records that underpin Article 10. | Summary written manually and quickly out of date. | Training-content summary generator sources from Build Attestation dataset hashes; versioned and publishable. |
| Art. 55(1)(a) | Perform model evaluation in accordance with standardised protocols including adversarial testing, with a view to identifying and mitigating systemic risk. | Reproducible adversarial-evaluation harness; documented attack taxonomy; pre-deployment gate. | Evaluation limited to benchmark scores on standard leaderboards. | Sovereign 1000 adversarial gauntlet (1000 vectors, 13 groups); Falsification Framework for null-model and degradation testing. |
| Art. 55(1)(b) | Assess and mitigate possible systemic risks at Union level, including the sources that may give rise to them. | Structured systemic-risk taxonomy; mitigation registry; outcome tracking. | Risk discussion conducted only in internal memos. | Governance Introspection pipeline + Recursive Reasoner manage the risk taxonomy. Mitigations applied via Policy-as-Code. |
| Art. 55(1)(c) | Keep track of, document, and report without undue delay to the AI Office and national authorities relevant information about serious incidents and corrective measures. | Incident-pipeline with defined timelines, signed artefacts, structured format. | Incident response owned by the on-call engineer with no formalised reporting. | Signed incident records in data/governance/incident_log.jsonl; webhook delivery to authority endpoints; Merkle-aggregated for independent verification. |
| Art. 55(1)(d) | Ensure an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and for its physical infrastructure. | Supply-chain integrity; model-weight integrity verification; infrastructure hardening. | Model weights on a shared object store with no integrity verification. | Build Attestation (SLSA Level 2) covers supply chain; HSM Health Monitor for key material; Sovereign Enclave for sealed invariants. |
Governance and Post-Market — Articles 72 and 73
Articles 72 and 73 define post-market responsibilities: continuous monitoring after the system is placed on the market, and reporting of serious incidents to national competent authorities.
| Article | Obligation | Required architectural property | Architecture that FAILS it | EVE AI Core component |
| Art. 72(1-2) | Establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risks of the high-risk AI system. | Plan expressed as enforceable monitoring rules, not narrative. Measurable signals tied to alert thresholds. | Written plan with no corresponding monitoring implementation. | Post-market monitoring plan encoded as Policy-as-Code rules; metrics and thresholds live in core/monitoring/. |
| Art. 72(3) | Collect, document, and analyse data provided by deployers or other sources on performance throughout the system's lifetime. | Ingestion pipeline with structured event schema; aggregation; trend detection. | Deployer feedback arriving by email and stored in no particular location. | Unified Audit Bus as the canonical ingestion pipeline; Merkle aggregator for batched integrity; Forecasting API for trend analysis. |
| Art. 73(1-2) | Report any serious incident to the market-surveillance authority of the Member State where the incident occurred, with timelines as set out. | Incident pipeline with timeline enforcement; signed report artefacts; authority routing. | Incident reports assembled from Slack threads days after the event. | Incident log with timeline assertions; HMAC-signed attestation per report; webhook routing to authority endpoints; Federation Trust Exchange for cross-border. |
| Art. 73(6-7) | Providers must perform necessary investigations, take corrective action, cooperate with authorities' investigations, and preserve documentary evidence. | Evidence preservation by construction (append-only, hash-chained); investigation workbench; corrective-action tracking. | Corrective actions lost between incident reviews. | EVE Proof Ledger is append-only and hash-chained by design. Self-Modification Governance tracks corrective actions with approval chain. |
Cross-Reference: Component to Article
The reverse index. For each EVE AI Core component, the Articles it helps satisfy. Useful when you are writing conformity-assessment documentation and need to cite the component that underwrites each obligation.
| EVE AI Core component | Articles satisfied |
| CoreGuard pre-execution gate | Art. 14, 15(1), 15(3), 26(1), 26(4), 50(1) |
| EVE Proof signed certificates (v1.1) | Art. 12(1), 12(2), 26(6), 26(8), 72(3), 73(1) |
| Unified Audit Bus (JCS canonicalized) | Art. 12(2), 12(3), 26(6), 26(7), 50(3), 72(3) |
| Failure-Mode Invariant (127 pillars, NFKC, Hard-Fail-Shut) | Art. 15(1), 15(3), 15(4), 55(1)(a) |
| Novel-Attack Detector (27 TF-IDF centroids) | Art. 15(4), 55(1)(a) |
| Build Attestation (SLSA Level 2) + CycloneDX SBOM | Art. 10(1), 11, 15(1), 53(1)(a), 55(1)(d) |
| Sovereign SDK (tenant-isolated governance) | Art. 16, 26(1), 26(2), 26(3), 27 (evidence), 53(1)(b) |
| EVE Proof Ledger + Merkle aggregator | Art. 12(1), 12(2), 72(3), 73(6) |
| Ground Truth Validator | Art. 10(1), 13(2), 15(5), 53(1)(c) |
| Policy-as-Code Engine | Art. 9(1-5), 13(3), 26(1), 55(1)(b), 72(1) |
| Sovereign 1000 Adversarial Gauntlet | Art. 9(6-9), 15(4), 55(1)(a) |
| Operator Console + RBAC (5 roles) | Art. 14(4), 26(2), 26(3), 26(5) |
| Sovereign Enclave (sealed invariants) | Art. 15(4), 55(1)(d), 73(6) |
| CRD Engine (calibration monitoring) | Art. 10(5), 15(5) |
| Incident Log + HMAC attestation | Art. 26(10), 55(1)(c), 73(1), 73(2) |
What This Mapping Does Not Cover
This reference is honest about its boundaries. The Act imposes obligations that technical architecture alone cannot satisfy. The following are the ones you need to handle separately.
- Fundamental Rights Impact Assessment (Article 27). The FRIA is a documentation and consultation obligation. Our tools support the evidence-collection side (audit bus, decision certificates, incident log), but the assessment itself — scoping affected groups, consulting stakeholders, assessing impacts on specific rights — is your organisation's responsibility and typically requires legal, ethical, and domain expertise beyond what software can supply.
- Conformity assessment by a notified body. Under Articles 43 and 44, certain high-risk systems require third-party conformity assessment. EVE AI Core produces the evidence substrate (signed certificates, build attestations, Annex-IV-aligned documentation) that the notified body will audit, but it does not replace the notified body or the assessment process itself.
- Training-data curation (Article 10). Our governance substrate logs dataset hashes, records provenance, and monitors calibration. It does not curate the training data for you. The obligation to ensure relevance, representativeness, and freedom from bias in the dataset remains a data-engineering responsibility.
- Quality management system (Article 17). Article 17 is an organisational obligation. It requires a quality management system with documented procedures, roles, and accountability — not just an audit trail. We provide the audit-trail substrate that a QMS can attach to. We do not provide the QMS itself.
- Registration (Article 49) and CE marking (Article 48). Both are administrative obligations requiring EU database registration and marking procedures. They depend on the preceding conformity assessment, which depends on the evidence we help produce — but the administrative filings are separate.
- Workers' representative consultation (Article 26(7)). Where deployment is in a workplace context, the obligation to inform and consult workers' representatives is a labour-relations process. Our audit bus can log the notification event; the consultation itself is a human process.
- Classification confirmation. Whether your system is high-risk, limited-risk, or GPAI-with-systemic-risk is a legal determination. The mapping above assumes a correct classification. Get classification in writing from counsel before relying on the mapping.
The short version. This mapping covers the technical obligations the Act imposes on AI systems. It does not cover the organisational, legal, or administrative obligations it imposes on your organisation. Both sides of the wall matter, and we only supply one side.
Next Steps
The 2027 deadline for high-risk systems is sixteen months away. Conformity assessment for high-risk systems takes six to twelve months. Working backward from August 2, 2027 and leaving six months of buffer puts your start date at February 2027. If you have not begun, the time to begin is now.
Step 1
Risk Classification
Determine which tier applies to your system under Annex III. Classification drives everything else.
Step 2
Gap Analysis
Map your current architecture to the obligations above. The rows you cannot fill are your gaps.
Step 3
Compliance Roadmap
A timeline working backward from the August 2027 deadline, with conformity-assessment buffer built in.
See It Live
CoreGuard Demo
The Article 14 pre-execution gate and Article 15 adversarial resilience, in your browser, in real time.
Certificate Infrastructure
EVE Proof
The Article 12 signed-certificate substrate. Volume-priced. Independently verifiable.
Patent Portfolio
88 Filed Applications
The unified control-plane stack that underwrites this mapping: Serial Nos. 64/022,671, 64/022,677, 64/022,682 and six umbrella families.
If you want a deeper pass — mapping your specific deployment to the Articles above, scoping the conformity-assessment work, and identifying which EVE AI Core components fit your existing stack — schedule a compliance architecture review. The Act is in force. The fines are real. The technical obligations are specific. Knowing exactly which architectural component satisfies each one is how you turn a rolling liability into a property of your system.
End of Reference