With the fast-approaching enforcement of the European Union’s landmark artificial intelligence regulation, developers and operators of high-risk AI models are facing strict technical requirements. Chief among these is EU AI Act Article 12 logging obligations, which mandate that high-risk AI systems automatically record event logs throughout their lifecycle. But what does this actually mean in practice, and how can teams design logs that meet the spirit of the law while navigating the tension between data logging and GDPR?
Disclaimer: This article is a technical explainer written from an engineering perspective. It does not constitute legal advice. The systems and architectures described here are designed to map onto regulatory duties, but do not guarantee certified compliance.
The Regulatory Mandates: Article 12 and Article 26
The EU AI Act classifies artificial intelligence systems based on their potential for harm. Systems classified as “high-risk” (such as those used in employment recruitment, credit scoring, critical infrastructure, or law enforcement) must meet rigorous transparency and governance standards before they can be deployed in the EU market.
Two specific articles govern how these systems must record their execution history:
1. Article 12: Traceability and Logging
Article 12 mandates that high-risk AI systems must be designed and developed with capabilities enabling the automatic recording of events (logs) while the systems are operating.
These logging capabilities are legally required to facilitate:
- The monitoring of the system’s operation to detect anomalies, malfunctions, or unexpected behaviour.
- The traceability of the system’s functioning throughout its lifetime, enabling post-market investigations of incidents.
- The evaluation of whether the system continues to perform as intended.
The regulation specifies that, at a minimum, the logs must capture the period of each use of the system, the start/end times, the input data against which the system searched or processed, and the system’s outputs.
2. Article 26: Deployer Obligations and Retention
While Article 12 places the burden of building logging capabilities on the system’s providers, Article 26 shifts the burden of maintenance to the deployers (the organisations actually running the systems).
Under Article 26, deployers must ensure that the logs automatically generated by the high-risk AI system are kept for a period appropriate to the risk and intended purpose of the system. This requirement is set to become active starting from 2 August 2026.
Additionally, across the Atlantic, the US is moving in a similar direction. In February 2026, the National Institute of Standards and Technology (NIST) officially launched its AI Agent Standards Initiative, signalising a global regulatory convergence around AI observability and traceability.
Why Mutable Logs Fail the Regulatory Test
If an auditor, regulator, or court asks to review your AI system’s execution logs following an incident (such as an algorithmic bias complaint or a critical system failure), they will not accept a standard text file exported from your server.
Why? Because traditional text files, databases, and application logs are mutable.
If a system administrator has the permission to log into a server and edit a line of text, or run an UPDATE query on a SQL database, the log has no evidentiary value. An organisation under investigation could easily alter the logged input data, delete the steps that led to the failure, or rewrite the model’s outputs to make the system appear compliant.
To meet the spirit of Article 12, an audit trail must be:
- Tamper-evident: Any modification, deletion, or backdating of a log entry must be mathematically detectable.
- Non-repudiable: The system must cryptographically sign its own logs at the time of execution, proving that the entry was generated by the authorized code, not fabricated later.
- Verifiable Offline: A third-party auditor must be able to verify the log’s integrity independently, without trusting the database server or the hosting provider.
The Privacy Paradox: Article 12 vs. GDPR Article 17
For engineers tasked with building Article 12-designed logs, a major structural conflict immediately emerges: The GDPR Tension.
- EU AI Act Article 12 demands that you log the exact input data processed by the AI system (which often includes personally identifiable information (PII) like names, email addresses, or financial data) to ensure traceability.
- GDPR Article 17 (The Right to Be Forgotten) demands that if a user requests the erasure of their personal data, you must delete all records of that data from your systems.
If your audit log is cryptographically chained (where each log entry contains the hash of the previous entry to prevent deletion), deleting a user’s record will break the cryptographic chain. The signatures will fail, and your audit trail will look like it has been tampered with.
Conversely, if you keep the user’s personal data in your log to preserve the cryptographic chain, you are violating GDPR.
This is the Privacy Paradox of AI logging.
The Solution: Salted Field-Level Merkle Commitments
To resolve this conflict, we must decouple the proof of what happened from the raw personal data itself. We can achieve this by using salted field-level Merkle commitments.
Instead of writing raw, sensitive user data directly into the immutable log, we write cryptographic commitments (hashes) of that data.
How it Works in Practice
- Schema Definition: When a transaction occurs, the system identifies which fields are sensitive (e.g.,
customer_email). - Salting the Field: The system generates a cryptographically secure random value (a salt) for each sensitive field.
- Calculating the Commitment: The system hashes the sensitive data combined with the salt: $$\text{Commitment} = \text{SHA-256}(\text{Raw Data} + \text{Salt})$$
- Signing the Receipt: The system includes the commitment hash in the execution receipt, signs it using its Ed25519 private key, and appends it to the immutable ledger.
- Storing the Key: The raw data and the corresponding salt are stored in a separate, mutable database (the “reveal ledger”).
Mutable Database (Reveal Ledger) Cryptographically Signed Log (AXR)
┌────────────────────────────────────────┐ ┌──────────────────────────────────┐
│ ID: 104 │ ──> │ ID: 104 │
│ Email: user@example.com │ │ Email Hash: SHA-256(Email+Salt) │
│ Salt: a8f9c2d1b7... │ │ Signature: Ed25519(...) │
└────────────────────────────────────────┘ └──────────────────────────────────┘Handling a GDPR Deletion Request
When a user submits a GDPR Article 17 erasure request:
- The server locates the user’s records in the mutable database.
- The server permanently deletes the raw email address and the salt value from the mutable database.
- The server does not touch the signed execution log.
Now, because the salt and raw email are gone, it is mathematically impossible for anyone to ever reverse-engineer the hash or reconstruct the user’s email. To any observer, the hash is indistinguishable from random noise.
Yet, the cryptographic signature on the execution log remains valid. The Merkle tree is unbroken, the sequence is preserved, and the system can still prove to an auditor that a transaction occurred at that exact second, without exposing a single byte of personal data.
Moving Deliberately Towards AI Assurance
As we move closer to the August 2026 enforcement of the EU AI Act’s deployer obligations, organisations that proactively design their logging infrastructure around cryptographically verifiable standards will hold a massive competitive advantage.
Adding a signed audit layer is no longer just a technical nice-to-have; it is a fundamental governance requirement. By moving away from mutable, self-reported text logs and adopting open-source protocols like AXR, teams can build systems that are designed to map onto regulatory duties from day one.
Deepen Your Understanding of AI Governance
- See how a live production system uses verifiable agent logs to catch silent execution failures in real-time.
- Explore the open-source AXR Cryptographic Specification to understand how our receipt verification primitive works.
- Read our step-by-step technical guide on integrating tamper-evident logging into n8n workflows.