Work / EU AI Assurance OS
EU AI Assurance OS
A fail-closed release gate for AI shipped into the EU: a pinned legal corpus, a human proposal queue, and an Evgraph 0.1.2 scan that must match the evidence pack.
The problem
Under the AI Act, obligations depend on what a system does and who it affects. Teams discover this late — usually in a review meeting, with a launch date already promised and no record of what was checked.
Release gate
The system enters with its owner and purpose. Risk is classified against a pinned legal corpus. Control mappings stay in a queue until a person accepts them. Cited evidence, the eval score, an open contract breach, and a pinned Evgraph 0.1.2 scan then meet at one shared gap. In-force controls apply INFORMATIONAL, WARNING, APPROVAL_REQUIRED, or BLOCKING. The gate returns PASS, REVIEW, or BLOCKED. It does not certify the system.
How it works
- 01
Register the system
The AI system is described once. Risk is classified against a pinned legal corpus, so the obligations that follow are explicit rather than assumed.
- 02
The gate runs in CI
Control mappings are proposals. A person accepts them. They are not auto-applied. In-force controls then use INFORMATIONAL, WARNING, APPROVAL_REQUIRED, or BLOCKING.
- 03
Get a verdict with citations
The gate returns PASS, REVIEW, or BLOCKED. The evidence pack and a live evgraph-cli 0.1.2 scan report the same current gap. A missing approval timestamp stays inconclusive.
- 04
Seal the record
The decision, its evidence and its approvals are sealed into an evidence pack and appended to a tamper-evident ledger for whoever asks later.
What it covers
Registry and classification
Risk classes — minimal, limited, high, prohibited — classified against a pinned legal corpus. Control mappings stay proposals until a person accepts them.
Evidence retrieval
all-MiniLM-L6-v2 embeddings over pgvector HNSW, returning citations rather than unsourced prose.
Release gating
PASS / REVIEW / BLOCKED. In-force modes are INFORMATIONAL, WARNING, APPROVAL_REQUIRED, and BLOCKING. The pack and evgraph-cli 0.1.2 share the current gap.
Workflows and oversight
Multi-stage approvals with reviewer assignment, human-oversight evidence capture and notifications.
Drift and lineage
Data-contract drift monitoring with a lineage graph across registered systems.
Sector packs
Insurance, HR and finance overlays as SPI implementations — not live vendor connectors.
Engineering notes
- Spring Boot 4.1.1 API, Java 17, Tika 4.0.0, and Flyway through V20. Multi-tenant JPA behind JWT and API-key auth.
- Cited-evidence retrieval runs on DJL + ONNX Runtime with pgvector HNSW, so answers point back at source documents.
- Eval results return over HMAC-SHA-256 signed callbacks; the queue is durable, so a gate decision survives a worker restart.
- Append-only audit ledger is hash-chained with verify endpoints, and evidence packs export as JSON with a PDF rendering.
Trade-offs
A person accepts each mapping
instead of auto-applying a control from the corpus
Risk is classified against a pinned legal corpus, and the mapping stays a proposal until someone accepts it. The product does not certify, CE-mark, or issue a legal verdict.
Java-native embeddings via DJL + ONNX
instead of calling a hosted embedding API
Compliance evidence often cannot leave the tenant boundary. Running the model in-process keeps evidence local and removes a per-call dependency.
Hash-chained append-only ledger
instead of an ordinary audit table
An audit table an administrator can edit proves nothing. Chaining makes tampering detectable and gives verify endpoints something to check.
Evidence
V20
Flyway migrations, plus postgres V4
0.1.2
pinned evgraph-cli
4
control modes
3
sector packs