Technical evidence for Annex IV.
Caisson generates the logging, traceability, and data-governance artifacts an EU AI Act Annex IV technical-documentation file requires. The administrative and legal compliance determination stays yours.
-- RLS cross-tenant denial -- (Art. 10 data governance) > SELECT count(*) FROM ai_inference_log; -- no tenant context set ERROR: unrecognized config parameter "app.tenant_id" // kernel verifyChain (Art. 12 record-keeping) const result = await verifyChain(db, { table: "ai_inference_log" }); // { intact: true, rows: 7043, breaks: 0 }
What Caisson does
- Generates the technical evidence Annex IV §2–6 requests
- Ships the controls Art. 10 / 12 / 14 require at the code level
- Produces a dated, replayable, auditor-readable artifact bundle
- Wires the gates before your first deployment, not after your first assessment
What stays yours
- The conformity assessment and legal sign-off
- Risk classification (prohibited / high-risk / limited-risk)
- Organizational controls: HR, vendor management, incident response
- Registration in the EU AI Act database (Art. 49, where required)
Caisson ships technical controls. Whether your system satisfies every EU AI Act obligation depends on deployment context, risk category, and your conformity assessment: that determination belongs to your legal team.
Five requirements. Five controls. All testable.
Each requirement below maps to a Caisson primitive that produces a verifiable artifact. The output is code you can read, run, and hand to a notified body or an internal assessor.
Every inference hashes into an append-only chain.
Article 12 requires high-risk AI systems to log events at a level sufficient to trace decisions back through time. Caisson's audit chain writes each event with SHA-256 over the previous hash, so tamper, truncation, and reorder each break the chain and surface on verify. What you hand an auditor is that same chain, run live.
// kernel verifyChain — append-only SHA-256 audit chain
import { verifyChain } from "@caisson/kernel/node";
const result = await verifyChain(db, { table: "ai_inference_log" });
// { intact: true, rows: 7043, breaks: 0, root: "9c3a…f1" }
// A tampered row breaks every subsequent link — detectable and provable.
// The chain is tested in CI on every push (RLS cross-tenant test suite).Art. 12(1) · Annex IV §3 (logging of operation period)
Training and inference data isolated per tenant by construction.
Article 10 requires data-governance practices covering the datasets used to train and operate the system. Fail-closed Postgres RLS ensures no query crosses a tenant boundary without an explicit, policy-enforced grant. A query that never sets the tenant context returns nothing, enforced by the database's own privilege system rather than a checklist an engineer might skip.
-- RLS forces every query through the data-governance policy.
ALTER TABLE ai_training_records ENABLE ROW LEVEL SECURITY;
ALTER TABLE ai_training_records FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_data_scope ON ai_training_records
USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- Cross-tenant access attempt fails closed — no privileged path.
> SELECT count(*) FROM ai_training_records; -- no tenant context set
ERROR: unrecognized configuration parameter "app.tenant_id"Art. 10(2) · Annex IV §2(f) (data governance measures)
Sensitive training data encrypted per tenant at the column level.
Where Article 10 data-governance requirements apply to personally identifiable training data, Caisson encrypts sensitive columns with a key derived per tenant via HKDF-SHA256. A leaked key exposes one tenant's data, not the table. Root key rotation re-derives every tenant key without a re-encrypt scan.
// Per-tenant DEK scoped by tenant id — one leaked key, one tenant.
const dek = hkdf("sha256", rootKey, /* salt */ tenantId,
/* info */ "caisson/field-v1", 32);
const sealed = aesgcm.seal(dek, sensitiveTrainingField);
// Tenant A's DEK cannot open tenant B's ciphertext — structurally.
// Root rotation re-derives; ciphertext stays addressable.Art. 10(5) · Annex IV §2(f) (appropriate security measures for data)
Eval harness gates every pull request against a golden set.
Article 9 risk-management and Annex IV §5 require documented testing for accuracy, robustness, and cybersecurity. Caisson's standalone eval-harness module (ai-evals) ships a golden-file eval harness that gates pull requests on score regression past a declared tolerance, checked into the repo as caisson.ai.toml and enforced the same way on every push.
# caisson.ai.toml — eval gate configuration (ai-evals module) # Wires CI to fail the PR when accuracy drops past the declared tolerance. # The golden set, baseline, and report are repo artifacts an assessor can read. [evals] gate = "ci" # fail the PR on score drop tolerance = 0.02 # max allowed regression before block golden_set = "evals/annex-iv-accuracy.jsonl" report_dir = "reports/"
Art. 9(4)(b) · Annex IV §5 (testing procedures + performance metrics)
Circuit breaker and spend cap surface override control to operators.
Article 14 requires high-risk AI systems to allow natural persons to intervene and override automated outputs. Caisson's circuit breaker opens when a tenant's token spend exceeds a hard cap, returning HTTP 402 and surfacing the event: a structural pause that routes control back to the operator before the next call. Override and reset are explicit, logged operator actions inside the same audit chain the rest of the system writes to.
// billing primitives (base substrate) — hard spend cap per tenant
import { checkCredits, recordUsage } from "@caisson/billing";
const ok = await checkCredits(db, { tenantId, tokens: estimatedTokens });
if (!ok) {
// HTTP 402 surfaces the pause — override is an explicit operator action
return Response.json({ error: "token_cap_exceeded" }, { status: 402 });
}
// Override and resume are explicit actions, logged to the audit chain.
// No automatic resumption — the structural pause routes control back to the operator.Art. 14(1)(3) · Annex IV §4 (human oversight measures)
Auditor-readable output from live controls.
The Compliance bundle collects the RLS policies, audit-chain proof, and field-encryption config from the system that enforces them, maps each to an Annex IV section, and packages them as a dated, replayable bundle.
{
"framework": "eu-ai-act",
"generated": "2026-06-27",
"controls": [
{ "article": "Art. 12 · Annex IV §3", "control": "audit-chain", "status": "verified" },
{ "article": "Art. 10 · Annex IV §2f", "control": "rls-policy", "status": "active" },
{ "article": "Art. 10 · Annex IV §2f", "control": "field-crypto", "status": "active" },
{ "article": "Art. 14 · Annex IV §4", "control": "spend-cap", "status": "configured"}
],
"artifacts": [
"chain-proof.txt",
"rls-policies.sql",
"field-crypto-config.json",
"annex-iv-control-map.json"
]
}The EU AI Act-ready evidence bundle ships with the Compliance bundle, available to buyers anywhere.
Retrofitting a tamper-evident log and per-tenant data isolation into a live AI system costs months. Start with them.
Once inference data and audit events are commingled in production, isolating them for Annex IV becomes a migration. On day one, it is a default. The controls are structural, tested in CI before your first customer signs, well ahead of your first notified-body assessment.
Article 50 applies from August 2, 2026.
Article 50 generally applies from August 2, 2026. The duties are not limited to high-risk systems: providers must disclose covered direct AI interaction, while providers of covered generative systems must make synthetic outputs machine-readably marked and detectable, subject to the provision’s exceptions. The adopted Digital Omnibus text awaits Official Journal publication and entry into force. Once effective, it gives providers of generative AI systems placed on the market before August 2 until December 2, 2026 to conform with Article 50(2)’s marking and detection duty. The other Article 50 duties were not postponed.
The disclosure surface itself is your product’s UI. What Caisson supplies is the evidence discipline behind it: disclosure events logged to the tamper-evident audit chain, configuration versioned in your repo, and a dated evidence bundle that preserves evidence that a disclosure event was recorded. Whether the product surface satisfies Article 50 remains a separate legal determination.
Article 50(2) outputs and Article 50(4) deepfakes generated or manipulated before August 2, 2026 do not require retroactive marking or labelling. Public-interest text receives that treatment only when it was both generated or manipulated and published before August 2.
Primary sources reviewed 2026-07-27: Regulation (EU) 2024/1689 on EUR-Lex — Articles 50(1)–(2), 50(4), and 113; OJ pp. 82 and 123/144
European Commission final Article 50 guidelines — Paragraphs (69)–(74) and (153)–(154), pp. 24–25 and 49–50
Council adopted Digital Omnibus legislative text — Article 111(4), p. 90/102, and Article 4, p. 101/102: systems “placed on the market before 2 August 2026”; compliance with Article 50(2) by 2 December 2026; entry into force on the third day after Official Journal publication
Council final-approval and next-steps notice — Page header dated 29 June 2026; opening paragraph beginning “Today, the Council gave its final green light”; “Next steps” paragraph on Official Journal publication and entry into force
Ship with the evidence already in the repo.
The Compliance bundle ships the audit chain, RLS policies, and field-encryption wired and testable from day one, ready well before your first notified-body assessment.
bunx @caisson-sh/cli@latest