Regulation (EU) 2024/1689

What the AI Act requires in terms of records, and how much of that Logsiegel covers

The AI Act is the first regulation that explicitly prescribes logging for AI systems. It says that records must be kept and for how long, but not how you later prove that the record is unaltered. That is exactly where Logsiegel starts.

Who this applies to

Providers and deployers of high-risk AI systems under Annex III (employment selection, creditworthiness, critical infrastructure, education, law enforcement, migration, for example) and under Annex I (AI as a safety component of regulated products). The application dates for high-risk systems were adjusted in 2026 as part of the Digital Omnibus; what counts is the current state of the text. If you run an agent in one of these areas today, you are better off building the logging in now than shortly before a deadline.

What the regulation requires in terms of records

The duties are spread across three articles, plus human oversight, which can only be evidenced with records:

What Logsiegel contributes today

• Automatic recording at the interface. The LiteLLM adapter turns every model call into an event with time, model, token counts and hashes of input and output, without any change to application code. The event attributes follow the OpenTelemetry GenAI conventions, so that your existing observability understands them.
• Unaltered records, verifiable. Every entry is hash-linked to the one before it; at intervals a Merkle root is formed and signed with Ed25519 (a checkpoint). Any later edit, reorder or truncation makes logsiegel verify fail.
• Event types for Art. 12(2). Besides inference, the trail knows model changes, human interventions (human_override) and anomalies, that is, the events that have to be evidenced for traceability and human oversight (Art. 14).
• Retention you can prove. A signed checkpoint shows that at a given moment the trail had a certain length and a certain content. Anyone who truncates it later stands out against every checkpoint or receipt handed out earlier. That way the six-month duty from Art. 19 and Art. 26(6) is not only met, it is provably met.
• Single-entry receipts for third parties. logsiegel receipt builds a file for one single action, made of the entry, an inclusion proof and a signed checkpoint. An auditor, customer or court verifies it offline against your published key, without access to your systems and without seeing the rest of the trail.
• A readable dossier. logsiegel export writes the trail as a Markdown dossier for people who do not want to touch a command line. For requests from market surveillance, or from the provider to the deployer.
• Metadata only in the trail. What enters the chain is event metadata and salted hashes; inputs and outputs are kept separately, encrypted per entry. The content of an entry can be deleted by deleting its key (crypto-shredding), without breaking the chain. Art. 12 asks for events, not content; the trail contains no raw personal data by default.

What is in progress planned

• An event taxonomy for agents (tool calls, delegation, value flows, human intervention) mapped onto the emerging standards prEN 18229-1 and ISO/IEC 24970.
• MCP proxy that evidences tool calls by agents at the interface, the way the LiteLLM adapter evidences model calls.
• Retention policy: deletion once the period expires, with signed evidence that nothing was missing until then.
• Independent witness that counter-signs checkpoints, so that not even the deployer can keep two versions of history.

How to put it to work

1. Install it and create a trail

The SDK is Python, Apache 2.0, no server and no account. The origin (origin) names the system whose actions are being recorded.

pip install logsiegel
logsiegel init ./trail --origin "acme.example/support-agent"

2. Plug the adapter in at the point every action must pass

If your AI traffic runs through LiteLLM, every completion becomes a signable inference entry, and errors are recorded as an anomaly. Human interventions you record explicitly, as an event of their own.

import litellm
from logsiegel.integrations.litellm_logger import LogsiegelLogger

litellm.callbacks = [LogsiegelLogger("/var/lib/logsiegel/prod", store_payload=True)]

3. Record human interventions explicitly

Art. 14 requires that humans can intervene. Show that they did: every stop, every discarded output, every correction becomes an event of its own.

logsiegel log ./trail --event human_override \
  --attr actor="j.doe" --attr reason="Output discarded, customer advised manually"

4. Create checkpoints and hand them out

Create checkpoints regularly (via cron, for instance) and put them outside your own infrastructure: with the auditor, with the customer, in someone else's repository. Only a checkpoint you no longer control alone makes the trail hold up against yourself.

logsiegel checkpoint ./trail
logsiegel verify ./trail

5. Hand out the receipt when someone asks

Instead of database extracts you hand out a single receipt. The other side verifies it in the browser at logsiegel.com/verifier or on the command line, both offline.

logsiegel receipt ./trail --seq 1284 --out receipt.json
logsiegel verify-receipt receipt.json --pubkey logsiegel.pub

More regulations: GDPR DORA NIS2 / critical infrastructure ISO/IEC 27001 ISO/IEC 42001 GoBD eIDAS Overview

Legal status September 2026. This page is a technical assessment by the project, not legal advice and not a conformity statement. Please check the references against the current text of the law. Corrections welcome via GitHub issue.