EU AI Act
Article 12 of the EU AI Act requires high-risk AI systems to support automatic recording of events over their lifetime, with enough detail to identify situations that may present risk and to support post-market monitoring (Article 72). Logs only help if you can show they have not been altered.
Sarek addresses both halves: every AI call becomes a structured log entry, and every entry is signed and anchored so tampering is detectable by anyone, at any time, without trusting the operator of the system.
What one log entry gives you
For each call through a monitored client:
- A structured record of when the call happened, which model ran, why it stopped, token usage and latency.
- SHA3-256 hashes of the exact input and output. The raw prompt and completion never leave your process, which keeps the log itself free of personal data.
- An ECDSA P-256 signature binding the entry to a named agent and role.
- An anchored proof file that makes any later edit to the entry detectable.
Field mapping
| Log field | Requirement |
|---|---|
timestamp | Art. 12: period of each use, date and time |
provider, model | Art. 12: identification of the system that ran |
systemFingerprint | Art. 12 / Art. 72: exact model version where the provider exposes it |
predictionId | Art. 12: reference to the individual output |
finishReason | Art. 12(2)(a): why the generation ended |
inputHash, outputHash | Art. 12(2): verifiable record of input and output without storing content |
agentId, role, signature | Accountability: which agent produced the record |
inputTokens, outputTokens, totalTokens, latencyMs | Art. 72: operational monitoring data |
environment, sdkVersion | Reproducibility of the logging setup |
txHash, blockNumber | Independent timestamp and integrity anchor |
citations | Source URIs for search-augmented responses (Perplexity) |
Two levels of evidence
| Level | What it covers |
|---|---|
| Per decision | One proof file per AI call. Suited to auditing a single contested decision: produce the entry, the proof and the original data, and anyone can verify the chain end to end. |
| Per report | sarek get report (TypeScript CLI) renders the log to a PDF and anchors the PDF itself. Suited to periodic audits: the report as a whole is provably unaltered since generation. |
Answering an auditor
A typical audit question is “show us what the system decided for case X, and prove the record is original”. The workflow:
# Find the entry
sarek list --agent claims-triage
# Export a portable evidence package: log.json + proof file
sarek get log --logId 550e8400-e29b-41d4-a716-446655440000The exported package can be verified by the auditor without access to your infrastructure. See Verification for the checks and what each one proves.
What Sarek does not do
Sarek records and proves. It does not classify your system’s risk level, decide your retention periods, or generate your conformity documentation. Those remain legal and organizational decisions; Sarek gives them a trustworthy factual base.