Regulatory

Article 12, clause by clause.

Article 12 has applied to high-risk AI systems since 2 August 2026 — automatic event logging, retained at least six months, sufficient to trace what the system did and why. Penalties reach €15,000,000 or 3% of worldwide annual turnover.

automatic event logging every model and tool call
traceable — what, and why the context, re-runnable
article 12 · in force since 2 August 2026
5supplied
2partial
1your obligation
Art. 12(1)Supplied

High-risk systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

The SDK records every model call, tool call, and agent step from inside your process — automatic, not manual documentation. Capture is a single import, or OpenTelemetry if you already emit spans.

npx @runback/verify <your-export>.json
Art. 12(2)(a)Supplied

Logs shall enable identification of situations that may result in the system presenting a risk, or a substantial modification.

Policy rules evaluate on every gated tool call and record the decision — allowed or blocked — as part of the run. A blocked action carries the rule that blocked it, so a risk situation is a queryable event rather than something inferred from prose.

GET /api/compliance/report?from=…&to=…
Art. 12(2)(b)Supplied

Logs shall facilitate post-market monitoring (Art. 72).

Runs aggregate into a period report — volumes, error rates, policy evaluations and blocks, redaction counts — computed from the database, not sampled, so the report's numbers are the data's numbers.

GET /api/compliance/report
Art. 12(2)(c)Supplied

Logs shall enable monitoring of operation by deployers (Art. 26(5)).

Per-agent coverage reconciles the agents you declared against the ones actually reporting: declared but never instrumented, reporting then gone silent, or running while absent from your register.

GET /api/app/coverage
Art. 12(3)Partial

Logs shall include the period of each use, the reference database checked against, the input data, and the identity of the persons verifying results.

Start/end timestamps, exact inputs, retrieved context, and tool results are captured per run. Human verification is captured where an approval gate is used. If your process has a reviewer step outside Runback, that identity isn't in our record — record it yourself.

Art. 19 / 26(6)Partial

Logs shall be kept for a period appropriate to the intended purpose, at least six months.

Retention is per plan, enforced by a scheduled sweep: Enterprise unlimited, Pro 90 days, Scale and Growth 60, Starter 30, Community 7, with regulated verticals raising the floor (healthcare 180 days). Meeting the six-month obligation therefore means Enterprise, a vertical floor that covers it, or self-hosting with your own retention. Legal hold suspends deletion for runs under a preservation obligation, and if the holds table cannot be read the sweep is skipped — the failure favours keeping data.

Art. 12 — impliedSupplied

Logs must be reliable as evidence. The Act does not use the word 'tamper-proof', but a record that can be edited without anyone noticing is not evidence of anything.

Every run is hash-chained and signed; each org's runs are sealed into an append-only ledger with signed checkpoints. Checkpoints are additionally time-stamped by independent RFC 3161 authorities and published to a public append-only log — so the record is not merely signed by us, it is anchored outside our control.

openssl ts -reply -in <checkpoint>.tsr -token_in -text
Art. 9, 11, 17Your obligation

Risk management system, technical documentation, quality management system.

Runback supplies evidence that feeds these; it does not produce them. A conformity assessment is an organisational process. Any vendor claiming to deliver Article 9 or 17 compliance as a product feature is overselling.

Verify it yourself

No account. No Runback software beyond one npx command.

A compliance claim you cannot check is a marketing claim. Every statement above resolves to something you can run:

bash
# 1. Verify a record's integrity and origin — no account required
npx @runback/verify audit-export.json
#    exit 0 = intact AND signed by our published key
#    exit 2 = intact, but origin unproven
#    exit 1 = a check failed

# 2. Check our published signing key out of band
curl https://runback.dev/.well-known/runback-audit-key.pem

# 3. Confirm a checkpoint was time-stamped by an authority we do not control
openssl ts -reply -in runback-checkpoint-4-freetsa.org.tsr -token_in -text

# 4. Read the public transparency log and archive it
curl https://runback.dev/api/transparency

Steps 2–4 use no Runback software at all. That is deliberate: an auditor should not have to run our verifier to check our tamper-evidence.

Honest limits — what this page does not claim →
  • No regulator certifies a file format. Whether your deployment satisfies Article 12 is a determination for your assessor. What we supply is the evidence that argument needs.
  • The harmonised standards are not final. ISO/IEC 24970 (AI system logging) is at FDIS and prEN 18229-1 is at DIS ballot. Nobody can claim conformance to an unpublished standard, including us. We track both and will publish a clause map when they land.
  • Runback is not certified. No SOC 2 report, no ISO 42001, no third-party penetration test yet. The security page states exactly what is shipped and what is not.
  • Article 12 is one clause. Articles 9, 11 and 17 are organisational processes. Evidence helps; it is not the same thing.

Read the record format, or verify one now.