Work / EU AI Assurance OS
EU AI Assurance OS
A release gate for teams shipping AI into the EU: it decides whether a model is allowed out, and proves why.
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
A deploy pipeline posts release v2.4 to the assurance gate. The gate classifies it as high risk and checks four obligations: technical documentation, data governance, and logging and traceability pass; human oversight evidence is missing. The gate returns blocked, and the release travels back to the team with the reason attached. Cited evidence is retrieved from a vector index over the tenant's own documents. The decision and its evidence are sealed into an evidence pack and appended to a hash-chained ledger.
How it works
- 01
Register the system
The AI system is described once and classified with guidance into a risk class, so the obligations that follow are explicit rather than assumed.
- 02
The gate runs in CI
A release calls the gate like any other pipeline check. Evaluations run on a durable queue and report back over signed callbacks.
- 03
Get a verdict with citations
The gate returns pass, review or blocked — and cites the specific evidence behind the decision, so a blocked release comes with the reason attached.
- 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
Guided risk classes — minimal, limited, high, prohibited — with a control catalog and per-system status tracking.
Evidence retrieval
all-MiniLM-L6-v2 embeddings over pgvector HNSW, returning citations rather than unsourced prose.
Release gating
PASS / REVIEW / BLOCKED contract callable from CI, with a durable worker queue and signed result callbacks.
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 3.3 API with Flyway V1–V16 and multi-tenant JPA behind JWT and API-key auth — 64 REST endpoints and 190 automated tests.
- 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
Assisted classification over automated judgement
instead of inferring the risk class from a description
Getting a risk class wrong has legal consequences. The product guides the decision and records who made it, rather than claiming an authority it does not have.
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
64
REST endpoints
190
automated tests
V16
schema migrations
3
sector packs