Regulation (EU) 2016/679
Accountability, integrity and erasure: where the GDPR asks for records, and how Logsiegel does both at once
The GDPR does not explicitly require a log, but it does require that you can demonstrate what you did with data, and that you erase data on request. An append-only trail and a duty to erase look like a contradiction. Logsiegel is built so that they are not.
Who this applies to
Every controller and processor whose AI system processes personal data, which in practice means everyone running an agent that talks to customers. Particularly relevant where the system makes or prepares decisions that affect individuals.
What the regulation requires in terms of records
Four places where records are either required outright or without which the duty cannot be met:
| Reference | Requirement |
|---|---|
| Art. 5(2) | Accountability: the controller must not only comply with the principles but be able to demonstrate compliance. |
| Art. 5(1)(f), Art. 32(1)(b) | Integrity and confidentiality: data must be protected against unauthorized alteration; security of processing covers the integrity of systems and services. |
| Art. 32(1)(d) | A process for regularly testing and evaluating the effectiveness of the security measures. |
| Art. 17 | Right to erasure. Personal data must be erased on request, including from logs, unless an exemption applies. |
| Art. 22, Art. 15(1)(h) | For automated individual decisions: the right to contest the decision, to express one's point of view, and to information about the logic involved. Without a record of which decision was taken when and on what basis, none of that can be honored. |
| Art. 33(5) | Personal data breaches must be documented so that the supervisory authority can verify compliance. |
What Logsiegel contributes today
- 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. Whether a salted hash is still personal data after key deletion is for your data protection review to assess; the design gives it the best starting position an append-only trail can offer.
- Erasure without breaking the chain.
logsiegel shred --seq Ndeletes that entry's key. The content is gone, verification of the trail still runs through. The duty to erase and tamper-evidence stop being mutually exclusive. - PII masking before storage. A pluggable detector masks identifiers in stored inputs and outputs before they are written to disk encrypted.
- 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 verifyfail. That is the technical evidence for integrity under Art. 32. - A receipt for the data subject. Anyone contesting an automated decision gets the receipt for exactly that decision: time, model, hashes, signed checkpoint. Verifiable offline, without exposing any other data subject.
- A readable dossier.
logsiegel exportwrites the trail as a Markdown dossier for people who do not want to touch a command line. For requests from the supervisory authority.
What is in progress planned
- Retention policy with deadline-driven crypto-shredding, so that erasure periods are met automatically and provably.
- Mandate binding: receipts that show on whose behalf an agent acted, connected to verifiable credentials and eID ecosystems.
What Logsiegel does not do
- Records of processing activities, data protection impact assessments, processing agreements. Separate duties, separate tools.
- Legal basis and classification. Whether your processing is lawful and whether Art. 22 applies is not something a log can tell you.
- Assessing what the hash leaves behind. Whether a salted hash still counts as personal data after key deletion is for your review to decide, in the light of the current guidelines of the European Data Protection Board.
- Completeness. What is proven is that the recorded material is unaltered, never that everything was recorded. That is an integration question: the adapter has to sit at a point every action must pass (LiteLLM today, MCP proxy in progress).
- Protection against the operator itself. Whoever holds the signing key could rewrite the trail and sign it again. That comes to light precisely when somebody else holds an earlier checkpoint or receipt. So hand your checkpoints out; counter-signing by an independent witness is the next stage of the project.
- Legal assessment. Whether your system falls under the regulation, which duties apply in detail and whether a receipt is enough in a given case is decided by your legal or compliance review, not by this tool.
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. Store content only masked and encrypted
With store_payload=True, inputs and outputs are stored encrypted per entry next to the trail; the PII detector masks them beforehand. Without that option the trail holds only hashes. Example: python examples/pii_demo.py in the repository.
4. Shred the entry when an erasure request comes in
The entry's key is deleted, so the content is gone for good. verify still runs through, because the chain hangs on hashes, not on content.
logsiegel shred ./trail --seq 1284
logsiegel verify ./trail # still PASS5. 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.pubMore regulations: EU AI Act 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.