Compliance by design

You spend three weeks writing the risk dossier. You hand it in. The next day you retrain the model — and your dossier already describes a system that no longer exists. That is the hole in post-hoc compliance: it is born obsolete. Compliance by design closes it by making every risk treatment a signed commit, not a note in a document that is already dead.

Concretely, 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.

---

Why this obligation exists — and why retrofitting fails

The AI Act is not paperwork for its own sake: it exists to prevent real harms — a discriminatory decision, an unsafe medical reading, a credit denial nobody could explain — risks that, left untreated before deployment, land on actual people. The cost of getting it wrong is not abstract either. Art. 99 sets fines of up to €35 M or 7% of worldwide annual turnover; and without the Annex IV technical file, the EU Declaration of Conformity and CE marking, a high-risk system simply cannot be placed on the EU market. That is the regulatory floor.

The pragmatic point follows from it. Rebuilding a compliance dossier at the end — by hand, on a system that retrains every sprint — is unworkable: the document is stale before the ink dries, and it collides head-on with the conformity-assessment and notified-body timeline, which needs evidence that matches the system actually being assessed. By-design is not the elegant choice; it is the only one that survives contact with a model that keeps changing.

When AI decides about peopleThe harms the obligation prevents, the cost of non-compliance, and what is at stake — in detail.

---

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 (.froga/bundle.json) is the risk treatment register. It is not a representation of it; it is the register itself. froga 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 froga.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 froga.yaml (intended_purpose) is the basis of regulatory triage.
Art. 9	Continuous risk management system	The froga run gate evaluates blocking controls on every execution; froga 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 team uses them to declare bias risks (§6.4.2; the future KAG will assist that identification).
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; froga approve adds management approvals as commits with a Froga-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 (froga status) resolves the first problem: it fails if the signed evidence does not describe the current system. The git replay (froga 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: froga conformance and froga 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: froga reconstruct, the living AssuranceProgram, and Annex IV provenance.

---

Works with your MLOps stack

The froga engine imports no MLOps tool. Pipeline reproducibility is delegated to the Reproducer seam, and the pipeline.tool field in your froga.yaml selects the adapter. Three tools are tested in CI today against the same scenario:

• DVC — git-native: the unit of change is a file versioned in git.
• MLflow — experiment → Model Registry: promotion to @champion is the treatment.
• Dagster — asset-based orchestration.

Integrate your workflow (DVC · MLflow · Dagster)How to connect your MLOps pipeline to the engine via the Reproducer seam, without froga importing any tool.