Working draft, v0.1. Markovian Protocol Research. Not legal advice, not a compliance product, not an assertion that any system or operator is compliant with any regulation. This paper describes a method for producing independently verifiable evidence that a retained AI system log has not been altered or back-dated. It supports, but does not satisfy, the obligations of the EU AI Act.
A high-risk AI system logs its own operation. When a market surveillance authority, a notified body, a deployer's auditor, a claimant, or an insurer later asks to see those logs, they are handed records the operator generated, stored, and produced from systems the operator controls. At that boundary the outside party has no independent way to know that the logs are the ones that existed at the time of the event, and that they have not been altered, back-dated, or selectively reconstructed since.
This matters most at the exact moment logs matter most: after something went wrong. Article 12 logs exist to help identify when a system presented a risk, to feed post-market monitoring, and to reconstruct what a system did. Every one of those uses is adversarial or forensic, and in a forensic setting a record you cannot independently authenticate is a record the other side can doubt.
The EU AI Act (Regulation (EU) 2024/1689) requires, at Article 12(1), that high-risk AI systems
"technically allow for the automatic recording of events (logs) over the lifetime of the system."
Article 12(2) requires that this logging capability enable recording of events relevant for (a) identifying situations that may result in the system presenting a risk within the meaning of Article 79(1), or in a substantial modification; (b) facilitating post-market monitoring under Article 72; and (c) monitoring the operation of the system under Article 26(5). Article 12(3) sets minimum records for remote biometric identification systems (period of use, reference database, matched input, and the persons verifying the result).
The retention of those logs sits in adjacent articles. Under Article 19, the provider keeps the automatically generated logs under its control for a period appropriate to the intended purpose, and in any case at least six months, unless other Union or national law provides otherwise. Under Article 26(6), the deployer keeps the logs under its control on the same at-least-six-months basis, and under Article 26(5) the deployer monitors operation. Article 11 and Annex IV require the technical documentation around all of this.
Here is the seam. Article 12 is a capability requirement on the system: it says the system must be able to record events. It does not specify that the retained log be tamper-evident, cryptographically sealed, or independently time-anchored. The retention articles say keep the logs, not prove the kept logs are unaltered. So an operator can fully satisfy the letter of Article 12 and Article 19 or 26(6), and still hand an authority a log file whose integrity rests entirely on trusting the operator's storage. The regulation asks for the record to exist and be retained. It does not, by its own terms, give an outside party a way to verify the retained record was not changed. That unspecified property, integrity and independent verifiability, is the entire subject of this paper.
Markovian is positioned as an independent tamper-evidence and time layer that sits alongside the operator's log store, not as the logging system and not as the store. The AI system still generates the logs. The provider or deployer still retains them. Markovian makes the retained record something an authority can verify without trusting the operator.
The components, all production-real and live:
ots client), and, optionally, an RFC 3161 timestamp from an accredited PKI Time-Stamping Authority (a format European authorities already recognize from eIDAS practice). One gives sovereignty, the other gives familiar legibility.| # | AI Act obligation | Markovian capability | Honest boundary / who else must act |
|---|---|---|---|
| A1 | Art. 12(1): system technically allows automatic recording of events over its lifetime | None. This is a system-design duty. | Markovian does not record events and is not a logging capability. The system must generate the logs. Markovian acts only on logs already generated. |
| A2 | Art. 12(2)(a): logs help identify Art. 79(1) risk situations / substantial modification | When an authority reviews the logs around a risk event, the anchor proves the logs were not altered or back-dated after the event, raising their evidentiary weight. | Markovian does not detect the risk or classify the event. It secures the record that a human or system uses to do so. |
| A3 | Art. 12(2)(b): logs facilitate post-market monitoring (Art. 72) | Provides an integrity and time spine so the monitoring record is auditable and non-repudiable. | Markovian does not perform monitoring. |
| A4 | Art. 12(2)(c) / Art. 26(5): monitoring operation | Lets a deployer or auditor prove the retained operational logs are original and existed when claimed. | Markovian does not monitor. |
| A5 | Art. 12(3): biometric ID minimum records (period of use, reference DB, matched input, verifying persons) | Each mandated record can be committed and time-anchored so start/end times and match records cannot be silently rewritten. | Markovian does not create these records. |
| A6 | Art. 19 / Art. 26(6): retain logs for at least six months | Proofs are tiny and durable: retained rows, permanent Bitcoin anchors, standalone timestamp files, carried alongside the logs. | Central boundary: Markovian anchors the hash, not the log body. The provider or deployer must store and retain the actual logs for the period. Markovian is a layer alongside retention, never a replacement. |
| A7 | Art. 11 / Annex IV: technical documentation | Anchored, offline-verifiable proofs are a clean artifact to reference in the documentation of how log integrity is assured. | Documentation is the provider's duty; Markovian supplies one referenced control. |
| A8 | Confidentiality of logs containing personal data | Only the SHA-256 goes to the anchor; the log body stays with the operator. A one-way hash exposes nothing, which is consistent with data-protection duties. | A feature, not a boundary. Personal data in logs can be integrity-proven without disclosure. |
One-line framing. Markovian does not generate your logs, does not store them, and does not make you compliant. It gives a market surveillance authority, a notified body, an insurer, or a court a way to verify, without trusting you, that the Article 12 logs in your own store are the unaltered logs that existed at the time you say they did.
Record: a single high-risk AI system log event. The pattern is identical whether the operator is a provider retaining under Article 19 or a deployer retaining under Article 26(6).
{
"record_type": "ai_system_log_event",
"system_id": "HRS-2026-CREDIT-0007",
"event": "inference_decision",
"event_time": "2026-08-14T09:12:44.031Z",
"subject_ref": "pseudonymous-8831",
"model_version": "v4.2.1",
"input_digest": "sha256:6b1f...c0",
"output": "decline",
"risk_flag": false,
"human_oversight": "not_triggered",
"deployer": "DEP-AT-4471"
}
Commit. record_bytes = JCS(record); data_hash = sha256(record_bytes); commit the hash, receive merkle_root, timestamp; produce an OpenTimestamps proof over the root (upgraded to Bitcoin-confirmed after roughly one block); optionally an RFC 3161 token. A later correction or annotation is a new commitment carrying an in-band reference to the prior root, producing the tracked change trail.
Offline verification transcript (market surveillance authority, no trust in the operator):
[1] Binding-valid : PASS sha256(JCS(record)) == commitment.data_hash
[2] Inclusion-valid : PASS merkle inclusion proof resolves to merkle_root
[3] Temporal-valid : PASS ots verify -> Bitcoin block 961204 @ 2026-08-14T09:15Z
[3b] TSA-valid (opt): PASS RFC 3161 token verifies against the TSA root certificate
--- change-audit ---
[4] Tamper test : flip risk_flag false -> true => data_hash changes => [1] FAILS
[5] Lineage test : trace supersede -> original; both roots Bitcoin-anchored
RESULT: the log existed unaltered at a Bitcoin-attested time; any change is detectable and ordered.
The record existed, unaltered, at an independently attested time; a post-hoc flip of the risk flag is detectable; and the authority confirmed all of it offline, with stock tooling, trusting neither the operator nor Markovian.
A sidecar model, no log data leaves the operator. A commit hook on the log pipeline computes the canonical hash of each record or batch and commits it; the resulting evidence bundle is retained alongside the logs. Phase it: start with the highest-stakes event classes (risk-relevant events under 12(2)(a), and the biometric records under 12(3)), then widen. An on-premise verifier lets an authority or the operator's own auditor verify offline. Offer RFC 3161 alongside the Bitcoin anchor so the artifact is legible to European authorities accustomed to qualified timestamps.
Under Article 40, a high-risk system that conforms to a harmonised standard whose reference is published in the Official Journal enjoys a presumption of conformity with the corresponding requirement. The Commission issued standardisation request M/593 (extended by M/613) to CEN and CENELEC, executed by Joint Technical Committee CEN/CLC/JTC 21. Two drafts are directly on point for logging:
These drafts do not mandate a specific technology, and they contemplate integrity mechanisms such as cryptographic signatures, transparency-log inclusion proofs, or equivalent mechanisms. An independent time-anchor with tamper-evidence is exactly such an equivalent mechanism.
What we honestly can and cannot do here. There is no direct, membership-free path for a small, non-EU protocol project to place text into JTC 21. The committee is nation-mediated: contributions flow through national standards bodies (DIN, AFNOR, BSI, NEN, and the like) and their mirror committees, or through the ISO/IEC JTC 1/SC 42 international track under the Vienna and Frankfurt agreements, or through recognized liaison organizations. The realistic leverage for a project like this is not a seat at the table; it is to be the citable prior art: publish an open, interoperable reference (a Record Integrity Attestation profile, an OpenTimestamps-over-canonical-Merkle-root vector, an RFC 3161 profile) that a committee member can reference on the merits, and to route comment through a cooperating national body during a public Enquiry window. We frame our work as a standards-compatible mechanism offered for consideration, never as writing the standard.
Regulation creates the obligation; insurance can create the incentive to exceed it. As AI liability cover and the emerging market for high-risk-AI insurance develop, an insurer's core problem is that it cannot price a risk it cannot verify. Tamper-evident, independently time-anchored logs are a hard, checkable control.
The throughline: Article 12 requires the log to exist and be kept, but not to be provable; Markovian supplies the independent tamper-evidence and time that make a retained log provable to a party that does not trust the operator; and the AI-insurance market supplies the money reason to adopt it.
Every verbatim quotation of the Regulation in the final version is to be re-verified against the authoritative EUR-Lex text before circulation, and every prEN standard number and status re-verified against the live CEN-CENELEC work programme. This draft states its honest scope in the open by design: it evidences the integrity and existence-in-time of a retained log; it does not record logs, retain them, or make any operator compliant.