What the AI Act, Directive (EU) 2024/2853, NIS2, and DORA concretely require you to produce when an AI agent acts on your production systems — and on what deadlines.
A maintenance agent holds a write role on a production database. At 02:14 it runs an ALTER TABLE ... DROP COLUMN against the billing schema, because a ticket asked it to "clean up obsolete columns." Three weeks later a request arrives: internal audit, a supervisory authority, or a customer's counsel. The question is the same every time. What exactly was executed, against which resource, under which policy version, authorized by whom — and how do you prove that this record has not been rewritten since?
The usual answer is an application log index: mutable, partial, scattered, rarely tied to a human decision. That used to be an inconvenience. It is becoming a deadline, because four European instruments turn the question into a dated obligation.
This article is not legal advice. It describes what the texts require, attributing each duty to its instrument. Qualifying your own use is a matter for your counsel.
Four instruments, four distinct requirements
AI Act: log, retain, oversee
Regulation (EU) 2024/1689 requires, in Article 12, that high-risk AI systems technically allow the automatic recording of events. The deployer's own duty sits elsewhere: Article 26(5) requires keeping the logs automatically generated by the system, to the extent they are under the deployer's control, for a period appropriate to the system's intended purpose and at least six months, unless Union or national law provides otherwise.
Two words carry weight. "Automatically": a log reconstructed after the fact from tickets does not satisfy the logic of the text. "Under its control": retention is not something you delegate to your model vendor.
Human oversight sits on top: Article 14 requires high-risk systems to be designed so they can be effectively overseen by natural persons, and Article 26 puts on the deployer the duty of assigning that oversight to competent and empowered people. Oversight that left no trace is, to an inspector, indistinguishable from oversight that never happened.
Product Liability Directive: 9 December 2026
Directive (EU) 2024/2853 replaces the 1985 regime and applies to products placed on the market from 9 December 2026. Software — AI systems included — falls explicitly within the notion of a product, and the regime remains strict liability: the claimant shows defectiveness, damage, and causation, not negligence.
The point that changes engineering requirements is the disclosure-of-evidence mechanism: a national court can order a defendant to disclose the relevant evidence at its disposal, and failure to do so can lead to a rebuttable presumption of defectiveness. Being unable to produce a file is therefore not neutral.
NIS2: 24 hours, 72 hours, one month
Directive (EU) 2022/2555 imposes risk-management measures on essential and important entities (Article 21) and incident reporting on a short clock (Article 23): early warning within roughly 24 hours, notification within roughly 72 hours, final report within roughly one month. Those windows leave no room for manually correlating heterogeneous logs: they assume an ordered, attributed, timestamped timeline already exists when the incident is detected.
DORA: the same logic, applied to financial services
Regulation (EU) 2022/2554 requires financial entities and their ICT providers to run an ICT risk-management framework, meet logging requirements, and report major ICT-related incidents — initial, intermediate, and final reports, on deadlines set by the technical standards. For a platform team the consequence is the same as under NIS2, plus third-party traceability: which resources, operated by whom, were touched.
What this concretely requires you to produce
| Instrument | Duty | What you must be able to produce |
|---|---|---|
| AI Act, Art. 12 and 26(5) | Automatic logging; deployer retention, at least six months | A complete, exportable log of agent operations over the requested period |
| AI Act, Art. 14 and 26 | Effective human oversight | The trace of the stop points: what was submitted for approval, approved by whom, when |
| Directive (EU) 2024/2853 | Disclosure of evidence; strict liability | An ordered, timestamped, third-party-verifiable file covering an incident window |
| NIS2, Art. 23 | 24 h warning, 72 h notification, 1 month final report | A timeline available in hours, not weeks of reconstruction |
| DORA | ICT logging and incident reporting | The same timeline, plus the scope of resources and providers involved |
| eIDAS, Art. 41 | Presumption attached to qualified timestamps | Evidence roots timestamped by a qualified trust service provider |
None of these lines asks for "more logs." They all ask for the same thing: a record whose integrity, ordering, timing, and origin can be demonstrated to someone who does not trust you.
The form of the evidence matters as much as its content
This is what conventional logging architectures handle badly: a searchable index proves what it contains today, not that it contained the same thing last week. Three properties make the difference.
Chaining and checkpoints. Each record carries the hash of the previous one, with a strictly monotonic sequence number: any insertion, deletion, or reordering becomes detectable. Signed checkpoints carry the Merkle root of recent records and are countersigned by the control plane, which makes unilateral history rewrites by a stolen key detectable.
Time anchoring. Roots are anchored with RFC 3161 timestamps, and the daily consolidated root receives a qualified electronic timestamp. Article 41 of the eIDAS Regulation attaches to it a presumption of the accuracy of the date and time and of the integrity of the bound data — the property that matters when facing a disclosure order.
Independent verification. A file is only worth something in an adversarial setting if the other side can verify it without depending on you. The sealr-verify verifier is published under Apache-2.0 and runs offline, with no call to any service:
sealr-verify evidence-2026-11.seal
RESULT: PASS WITH FINDINGS
Proven: 128394 records across 3 stream(s); 128102 attested by checkpoints; 128102 anchored.
Recorded span: 2026-11-01T00:00:04.118Z .. 2026-11-30T23:59:41.902Z
Earliest timestamp anchor: 2026-11-01T00:04:12Z
Findings (1):
WARN unattested_tail [stream 01JC…]: 292 record(s) not covered by any valid checkpoint
Standing limits:
- Tamper-evident, not tamper-proof: this report proves integrity, ordering,
timing, and origin of the recorded stream; it cannot prove that unrecorded
events did not happen.
- Coverage is a deployment property: only operations that passed through a
recorder are in this stream.
…
The verifier prints its own limits in every report and returns a distinct exit code per result (0, 10, 11), so it can run in CI.
Human oversight has to be a control point, not an intention
Technically, effective oversight is a deterministic stop point before execution, not an instruction in a prompt. A guard parses the operation itself — the real PostgreSQL grammar for SQL, plan JSON for Terraform, argv and refs for Git — and returns a local verdict in a few milliseconds. The policy decides:
schema: sealr/policy/v1
name: prod-databases
bindings:
- resources: ["db:prod-*"]
mode: enforce
critical: true
rules:
- id: block-unbounded-writes
match: { guard: sql, reason_any: [SQL_UNBOUNDED_WRITE, SQL_TAUTOLOGY_WHERE] }
decision: BLOCK
- id: approve-destructive-prod
match: { guard: sql, risk_at_least: HIGH }
decision: REQUIRE_APPROVAL
approval: { approvers_group: dba-oncall, min_approvers: 1, ttl: 1h, scope: operation }
- id: default
match: {}
decision: ALLOW
The verdict and the approval themselves become signed records — that is what makes oversight demonstrable rather than asserted:
{
"record_type": "operation",
"seq": 48211,
"ts_wall": "2026-11-12T02:14:07.418Z",
"subject": {
"agent_kind": "claude-code",
"human_principal": "[email protected]",
"attribution": "attributed"
},
"action": {
"integration": "postgres",
"operation": "query",
"verb_class": "destructive_ddl",
"target_resource": "db:prod-billing"
},
"verdict": {
"decision": "REQUIRE_APPROVAL",
"mode": "enforce",
"risk_class": "HIGH",
"policy_version": 12,
"reason_codes": ["SQL_DESTRUCTIVE_DDL"],
"guard": { "name": "sql", "version": "1.0.0" }
},
"approval_ref": { "approval_record_id": "01JC…" }
}
Note what is absent: no literal values. The metadata is structural — statement type, relation names, predicate skeleton with typed placeholders. The evidence stays verifiable without exporting personal data, the payload remaining on the customer side as a salted cryptographic commitment.
What this evidence does not prove
It has to be said plainly, because this is what the other side will raise. Evidence of this kind is tamper-evident, not tamper-proof: it makes any modification visible, it does not prevent one. It demonstrates the integrity, ordering, timing, and origin of the recorded stream — not that unrecorded events did not happen.
Coverage is a deployment property, not a cryptographic one. An agent that connects straight to the database without passing through the interception point will not appear in the stream. What you can do is make those blind spots visible: coverage-gap records written at recorder stops, reconciliation between events seen server-side and recorder-side, unattributed operations surfaced explicitly. A bounded, documented hole beats silence — it is not a guarantee of completeness, and nobody should sell you one.
Likewise, producing an evidence file makes no one compliant and settles no legal outcome. It answers one precise demand — "show what was executed" — with an artifact the other side can verify.
The questions to ask internally before December 2026
They are technical, not legal:
- If we are asked tomorrow for the agent operations against a production resource between two dates, how long does it take us to produce them, and in what form?
- Can that record be modified by an administrative access without it showing?
- How long do we retain it, and is that at least the period the applicable text imposes?
- Does a destructive operation on a critical system pass through a stop point attributable to a person, and is that approval recorded?
- Do we know what share of agent activity bypasses our interception point?
The fifth is the most uncomfortable, and it is the only one whose answer does not improve on its own.
The deadlines are set: December 2026 for product liability, a continuing ramp-up of the AI Act, incident clocks already running under NIS2 and DORA. Sealr's evidence format and its verifier are published under Apache-2.0, precisely so that what is claimed here stays checkable without taking our word for it. How it works end to end is described on the platform page.