EU AI Act — regulatory framework

The EU AI Act (Regulation EU 2024/1689) establishes horizontal requirements for high-risk AI systems. This page describes the articles relevant to the scenarios the sei engine covers and how the engine addresses them. Pending gaps are listed in Status & gaps.

High-risk classification — Art. 6 + Annex III

An AI system is classified as high-risk when it falls within Annex III categories (including credit scoring, employment, education, essential services, or medical devices) or when it forms part of products regulated under Annex I.

How the sei engine addresses it: the intended purpose (intended_purpose in the system: block of sei.yaml), together with potential_misuses, forms the basis for regulatory triage. The engine does not make the classification decision — that responsibility lies with the operator — but it enforces that the intended purpose is declared before any evaluation can run.

Risk management system — Art. 9

Art. 9 requires a documented, iterative, and continuous process of risk identification, analysis, evaluation, and treatment throughout the system lifecycle. Risks must cover both intended use and reasonably foreseeable misuse.

How the sei engine addresses it: the engine implements the ISO 23894 §6 process as the Art. 9 compliance engine. Each sei run execution evaluates the blocking controls of the AssuranceProgram. sei status allows integrating this evaluation into a CI/CD pipeline without full recomputation. The AssuranceProgram grows during development: sei assess proposes undeclared risks; the human curates and commits them.

See ISO 23894 — AI risk management for the process implementation.

Data governance — Art. 10

Art. 10 requires that training, validation, and test datasets are relevant, representative, and free of errors to the extent possible, and that documented data governance practices are maintained. The provider must assess potential biases and their effects on protected groups.

How the sei engine addresses it: the Croissant descriptor (dataset.croissant in sei.yaml) declares the dataset provenance and its fairness attributes. The engine anchors the dataset digest in the signed evidence. The KAG uses Croissant metadata to propose bias risks (ISO 23894 §6.4.2). Fairness metrics (demographic_parity_diff, group_min_positive_rate, es_dice) are evaluated as AssuranceProgram controls.

Technical documentation — Art. 11 + Annex IV

Art. 11 requires the provider to draw up and maintain technical documentation before placing the system on the market. Annex IV specifies the minimum content: system description (§1), training data (§2), monitoring and operation (§3–§4), lifecycle description (§5–§6), human oversight (§7), accuracy and robustness (§8), post-market monitoring (§9).

How the sei engine addresses it: the engine only leaves the signed evidence (.sei/bundle.json); the cloud (control plane) assembles and renders the Annex IV from that signed bundle, with per-field provenance (declared in sei.yaml, derived from the bundle, or derived from the git history), and delivers it as a PDF. The documentation is not hand-authored: it is generated from the actual system state.

🟡 Partial — In the cloud-assembled Annex IV, §7 (standards) and §8 (DoC) are never pending; §2/§3/§4/§9 can be marked PENDING if their input is missing (data / misuse+residuals+Art.14 / control results / post-market measures). In the loan scenario, with data/controls/measures present, only §3 and §9 would appear pending. See Status & gaps.

Record-keeping — Art. 12

Art. 12 requires high-risk systems to generate and retain logs that allow identifying the period of operation and relevant events for supervisory purposes. Logs must be kept for a minimum period established by implementing act.

How the sei engine addresses it: the git log of the evidence bundle (.sei/bundle.json) is the risk treatment log: each commit is dated, attributed, and signed. sei approve --by adds management approvals as commits with a Sei-Approved-by: trailer. sei reconstruct converts that history into the formal per-risk cycle. The retention vault (Art. 18) is part of the cloud plane.

Transparency — Art. 13

Art. 13 requires high-risk systems to be sufficiently transparent that operators can interpret outputs and use them correctly. Usage documentation must include the system’s capabilities, limitations, and operating conditions.

How the sei engine addresses it: the cloud-assembled Annex IV includes system metrics (accuracy, fairness, power statistics) with confidence intervals. The risk profile and conformance assessment are accessible via sei conformance and sei soa. The system.intended_purpose and system.potential_misuses fields in sei.yaml document anticipated limitations.

Human oversight — Art. 14

Art. 14 requires high-risk systems to be designed so that natural persons can oversee, detect, and correct malfunctions, and can interrupt the system. Operators must be able to understand the system’s capabilities and limitations.

How the sei engine addresses it: the engine’s gates (sei run) are human decision points: a failing gate halts the flow until the human applies a treatment (code change, parameter adjustment, or explicit acceptance with sei approve). sei approve --by records the evaluator’s identity in the bundle.

Accuracy, robustness and cybersecurity — Art. 15

Art. 15 requires high-risk systems to achieve appropriate levels of accuracy and robustness, and to be resilient against errors, faults, and manipulation attempts. Levels must be documented in the technical documentation.

How the sei engine addresses it: accuracy metrics (e.g. accuracy, Dice/es_dice) are evaluated as AssuranceProgram controls with declared thresholds (the NSD boundary metric is a future line, see the Dice size-bias caveat). Power statistics (bootstrap with per-patient clustering) quantify whether samples are sufficient to defend the result before a regulator. Results and confidence intervals are included in the signed bundle.

Fundamental rights impact assessment — Art. 27

Art. 27 obliges operators (in certain cases) to carry out a fundamental rights impact assessment before deploying a high-risk AI system in covered categories.

🚧 Planned — The Fundamental Rights Impact Assessment (FRIA) is not explicitly covered in the v1 bundle. See Status & gaps.

Post-market monitoring — Art. 72

Art. 72 requires providers to establish and execute a post-market monitoring system proportionate to the nature of the system. Serious incidents and malfunctions must be reported.

🚧 Planned — The Art. 72 continuous monitoring model is not modelled in the v1 engine. See Status & gaps.

Summary table

Article	Obligation	`sei` engine coverage
Art. 6 + Annex III	High-risk classification	`intended_purpose` + `potential_misuses` — declared triage, decision by operator
Art. 9	Risk management system	ISO 23894 §6 engine; blocking gates; live AssuranceProgram
Art. 10	Data governance	Croissant descriptor; anchored digest; fairness metrics as controls
Art. 11 + Annex IV	Technical documentation	Assembled by the cloud from the signed bundle — partial (§2/§3/§4/§9 conditionally pending if their input is missing; §7/§8 never; in `loan` only §3/§9)
Art. 12	Record-keeping	`git log` + DSSE signing; `sei approve`; cloud vault
Art. 13	Transparency	Metrics with CI; `sei conformance`; `sei soa`
Art. 14	Human oversight	Gates as decision points; `sei approve --by` records evaluator
Art. 15	Accuracy and robustness	Controls with thresholds; bootstrap power-stats
Art. 27	FRIA	Planned
Art. 72	Post-market monitoring	Planned

Relevant harmonised standards

The EU AI Act delegates the technical requirements of Art. 9 to CEN/CENELEC harmonised standards:

prEN 18228 — AI risk management (Art. 9); gives presumption of conformity by clause. See prEN 18228.
ISO/IEC 23894 — AI risk management process; implemented in the engine. See ISO 23894.

The full crosswalk between articles and standard clauses is in Reference: Standards crosswalk.