Compliance by design

Compliance by design describes an approach in which regulatory requirements are incorporated as constraints of the development process — not as a documentation layer added at the end. For high-risk AI systems under the EU AI Act, the alternative (documenting after the fact) is not viable: Art. 9 requires a risk management system that is continuous and kept up to date, not a point-in-time report.

---

The core thesis

The risk treatment (ISO 23894 §6.5) is a versioned change: to code, to a parameter, to a dataset. When that change is committed to git, it is timestamped, attributed to an author, and anchored to the triple (code, model, dataset) via an ECDSA-P256+DSSE+in-toto signature.

git closes the ISO 23894 treatment loop.

This statement has a direct consequence: the git log of the evidence bundle (.sei/bundle.json) is the risk treatment register. It is not a representation of it; it is the register itself. sei reconstruct converts it into the formal ISO 23894 cycle per risk, without manual intervention.

As a corollary, the Annex IV (EU AI Act Art. 11) is assembled by construction from the signed bundle, but in the cloud (control plane), not in the engine: the provenance of each field is declared (in sei.yaml), derived from the bundle, or derived from the git history. It is not written by hand.

Partial completeness

The mechanism is built and demonstrated. Annex IV completeness is partial: §7 and §8 are never pending; §2/§3/§4/§9 can be pending if their input is missing. In scenarios with data, controls and measures present, only §3 and §9 would appear pending. See Status & gaps.

---

Normative frame — EU AI Act

Venturalítica operates on the following EU AI Act requirements for high-risk systems:

Article	Requirement	How Venturalítica covers it
Art. 6 + Annex III	Classification as a high-risk system	The intended purpose declared in sei.yaml (intended_purpose) is the basis of regulatory triage.
Art. 9	Continuous risk management system	The sei run gate evaluates blocking controls on every execution; sei status can be integrated into CI/CD as a necessary condition without recomputation cost.
Art. 10	Data governance	The Croissant descriptor (dataset.croissant) declares provenance and fairness attributes; the KAG uses them to propose bias risks (§6.4.2).
Art. 11 + Annex IV	Technical documentation	The cloud assembles Annex IV from the engine’s signed bundle (partial; see above).
Art. 12	Record-keeping	The git log of the bundle is the treatment register; sei approve adds management approvals as commits with a Sei-Approved-by: trailer.

---

Why post-hoc auditing is not sufficient

A high-risk AI system changes during its lifecycle: the model is retrained, parameters are adjusted, the dataset evolves. Each change may alter the risk profile and the compliance status.

Post-hoc auditing — collecting evidence once and writing documentation — produces two practical problems:

1. Immediate obsolescence. The documentation describes the system at the time of the audit, not the system in production.
2. Absence of treatment traceability. ISO 23894 §6.5 requires demonstrating that applied treatments have reduced risk. Without a versioned history, that demonstration is narrative, not empirical.

The freshness gate (sei status) resolves the first problem: it fails if the signed evidence does not describe the current system. The git replay (sei reconstruct) resolves the second: the empirical arc FAIL→PASS by commit is the demonstration.

---

Compliance by design does not equal full compliance

Incorporating conformity into the process does not eliminate regulatory gaps. Some requirements — the overall residual risk (prEN 18228 cl. 10), the explicit hazard→harm chain, post-market surveillance (Art. 72) — are not fully covered in v1 of the engine.

The difference from the traditional approach is that gaps are declared as code: sei conformance and sei soa emit them per clause and per control from the signed bundle. There is no compliance documentation that conceals gaps; there is a report that lists them.

See Status & gaps for the full inventory.

---

The how

The mechanisms that implement this approach are described in the methodology pages:

• What is Risk-Driven Development — the conceptual frame: how the risk treatment loop drives development.
• git closes the ISO 23894 treatment loop — the core thesis developed: sei reconstruct, the living AssuranceProgram, and Annex IV provenance.