Directive (EU) 2022/2555, transposed in Germany in the BSI Act

What NIS2 and the critical infrastructure rules require as evidence, and what Logsiegel contributes

NIS2 requires far more organizations than before not just to take security measures but to evidence them to the supervisor, and to report incidents within hours. When an AI agent is part of an incident, the report needs facts nobody can question afterwards.

Who this applies to

Essential and important entities in the sectors of Annexes I and II: energy, transport, banking, health (hospitals, laboratories, manufacturers), water, digital infrastructure, public administration, postal services, waste, chemicals, food, manufacturing, digital services, research. In Germany through the BSI Act, and for operators of critical installations additionally through the sector-specific security standards (B3S), such as the B3S for hospitals. Through the supply chain duty, indirectly also the suppliers of these entities.

What the regulation requires in terms of records

The directive names minimum measures and reporting deadlines; how logging is done is spelled out in Germany by the IT-Grundschutz of the Federal Office for Information Security:

Reference	Requirement
Art. 21(1)	Appropriate and proportionate measures to manage risks; the entity must be able to demonstrate their effectiveness to the supervisor (Art. 32, 33: supervisory and enforcement measures, evidence duties).
Art. 21(2)(b)	Incident handling as a mandatory measure, which covers detection, analysis and documentation.
Art. 21(2)(d)	Supply chain security, including the relationships with direct suppliers and service providers. An AI provider is one of them.
Art. 21(2)(f)	Policies to assess the effectiveness of the risk management measures.
Art. 23	Reporting of significant incidents: early warning within 24 hours, incident notification within 72 hours, final report within one month covering root cause, impact and mitigation.
BSI IT-Grundschutz, module OPS.1.1.5	Logging: log data is to be collected centrally, protected against unauthorized alteration, given a reliable time, and retained for evaluation and as evidence.
B3S for hospitals	For clinics as critical installations: sector-specific requirements on logging, traceability and incident handling as evidence of the state of the art.

What Logsiegel contributes today

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. That is the protection against unauthorized alteration OPS.1.1.5 asks for, recomputable by any auditor.
Facts for the final report. The report under Art. 23 has to say within one month what happened. For the AI part, the trail supplies a record whose integrity since the incident can be shown, because earlier checkpoints exist.
Evidence for the supervisor. 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.
Supply chain. An AI provider regularly gives its client signed checkpoints; the client verifies that the provider's trail has only grown since then, with no view into the content. That is a concrete, verifiable building block for Art. 21(2)(d).
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.
A readable dossier. logsiegel export writes the trail as a Markdown dossier for people who do not want to touch a command line.
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. Important in the health sector: patient data never enters the trail.

What is in progress planned

Independent witness and qualified timestamps, so that the reliable time from OPS.1.1.5 no longer depends on the operator's clock alone.
MCP proxy for tool calls by agents in operational systems and line-of-business applications.

What Logsiegel does not do

Detection and alerting. Logsiegel is not a SIEM, not an intrusion detection system, and does not replace central log collection. It makes the AI part of the records provable.
The reporting process itself. Deadlines, forms and communication with the authority remain your process.
The other measures from Art. 21(2) (backup, cryptography policy, access control, training) are topics of their own.
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.
Time. Timestamps in the trail are a claim by the operator until they are counter-signed by a witness or by a qualified timestamping service.
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. 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

4. Mirror checkpoints into central logging

Put every signed checkpoint into your central log collection as well. That gives you an anchor outside the AI system, against which the trail is later verified.

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: EU AI Act GDPR DORA 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.