How to Build a Logging Pipeline That Meets EU AI Act Article 12
A regulator asks how your AI reached a decision six months ago. Can your logs answer? How to build an Article 12-compliant logging pipeline that holds up under audit.
The Audit Question You Cannot Answer
A regulator asks how your AI system reached a specific decision six months ago. Your team trained the model, shipped the pipeline, and watched the dashboards. But when you try to reconstruct that one decision, the trail ends at an application log that rotated out weeks ago. Article 12 of the EU AI Act exists for exactly this moment: it requires AI systems to keep records complete enough to trace what happened, when it happened, and why. This guide walks through building a logging pipeline that satisfies that requirement under audit, not just on paper.
What Article 12 Actually Requires
Article 12 applies to high-risk AI systems listed in Annex III and requires that they technically allow for the automatic recording of events, called logs, over the lifetime of the system. The recording obligation is not "keep some logs." The standard is that a competent third party, given only your logs, must be able to reconstruct the operation of the system well enough to identify malfunctions, trace decisions back to inputs, and verify that the system operated within its intended purpose.
In practice that means logging five things for every consequential system event: what input the system received, which model and prompt version processed it, what output it produced, who or what triggered it, and when it happened to a verifiable timestamp. Missing any one of the five makes a decision non-reconstructable.
The Five-Question Reconstruction Test
Before designing anything, apply the test auditors effectively apply. Pick a random production decision from ninety days ago and ask whether your current logs can answer all five questions:
| Question | Required log fields | Common gap |
|---|---|---|
| What input did the system receive? | input_payload_hash, input_source, received_at | Inputs logged only on error, not on success |
| Which version processed it? | model_id, model_version, prompt_template_id, config_hash | Model version known but prompt version untracked |
| What did it output? | output_payload_hash, output_type, confidence | Output stored in a cache that expires |
| Who or what triggered it? | actor_id, actor_type, session_id, tenant_id | Service account shared across tenants |
| When, provably? | timestamp_utc, clock_source, sequence_number | Local timestamps without timezone or ordering |
If any row fails, the pipeline is not Article 12-ready regardless of how much data it stores. Volume is not the requirement; reconstructability is.
The Minimum Viable Log Event
Every consequential event should emit a single structured record. A schema that satisfies the five questions:
{
"event_id": "uuid-v4",
"timestamp_utc": "2026-08-14T15:22:08.412Z",
"sequence": 482913,
"actor": { "type": "user", "id": "u_8f31", "tenant_id": "t_acme" },
"input": { "source": "api/chat", "payload_hash": "sha256:9f2c..." },
"model": { "id": "gpt-4o", "version": "2024-11-20", "prompt_template_id": "risk-summary-v7" },
"output": { "type": "completion", "payload_hash": "sha256:41ab...", "confidence": null },
"decision": { "type": "risk_flag", "value": "elevated" },
"trace_id": "otel-trace-id",
"prev_event_hash": "sha256:77de..."
}Three fields do most of the compliance work. Payload hashes let you prove what was processed without retaining raw personal data. The model and prompt version fields pin the decision to a reproducible system state. The previous-event hash links records into a tamper-evident chain, which is covered in depth in implementing immutable audit trails.
Pipeline Architecture: Five Stages
EMIT TRANSPORT STORE PROTECT VERIFY
structured -> queue/topic -> append-only -> hash chain -> replay +
event in-app (Kafka/SQS) object store + WORM + sampling
(S3/BigQuery) retention audits1. Emit structured events, not log lines
Free-text log lines cannot answer the reconstruction test reliably. Emit the JSON event above at the application boundary, inside the request path, not as a side effect that can be skipped on error. Failed requests are often the events a regulator most wants to see.
2. Transport through a durable queue
Application logs and compliance events have different availability requirements. Send events to a queue (Kafka, SQS, Pub/Sub) with its own retention, so a logging-backend outage cannot create silent gaps. Missing-event detection is itself an audit requirement.
3. Store append-only
Write events to object storage or a warehouse configured for append-only access. In AWS terms that means S3 Object Lock in compliance mode or an equivalent WORM control; the point is that no credential, including admin credentials, can rewrite history inside the retention window.
4. Protect integrity and confidentiality separately
Integrity comes from hash chaining or a ledger database; confidentiality comes from encryption and access scoping. Teams frequently conflate the two and end up with encrypted logs that are still silently editable. Article 12 cares about both: the record must be provably unaltered and must not leak the personal data inside it.
5. Verify by replay, not by inspection
Quarterly, pick a sample of historical decisions and reconstruct them end to end from logs alone. If reconstruction requires asking the engineer who built the system, the pipeline fails the test. This replay drill is the difference between a logging pipeline and a logging archive.
Retention and the Three Failure Modes
Article 12 does not set a single retention number; the operational floor comes from adjacent obligations, commonly six months minimum and up to the system lifetime for high-risk deployments, reconciled against GDPR minimization. The three failure modes I see in practice:
| Failure mode | Symptom | Control |
|---|---|---|
| Silent rotation | Logs expire before anyone audits them | Retention alarms that fire before deletion, not after |
| Schema drift | Model v3 adds a field; old events become unparseable | Versioned schemas with backward-compatible readers |
| Orphaned context | Event exists but the prompt/config that produced it is gone | Pin prompt_template_id and config_hash at emit time |
Conclusion
An Article 12-compliant logging pipeline is not a bigger log store. It is a system that can answer the five reconstruction questions for any historical decision, prove the records were not altered, and survive a replay drill without the original engineers in the room. Build the event schema first, make transport durable, store append-only, and test by replay. For the tamper-evidence layer, see immutable audit trails for SOC 2, and for the broader operating model see how to secure and govern AI systems.
FAQs
What does EU AI Act Article 12 require?
Article 12 requires high-risk AI systems to automatically record logs throughout their lifetime, sufficient to trace system operation, identify malfunctions, and reconstruct how outputs were produced. It is a record-keeping obligation aimed at traceability, not a prescribed storage technology.
Which AI systems must comply with Article 12?
Article 12 applies to AI systems classified as high-risk under Annex III of the EU AI Act, such as systems used in employment decisions, credit scoring, critical infrastructure, and law enforcement contexts. General-purpose and minimal-risk systems are out of scope, though many organizations adopt the same logging standard voluntarily.
How long should AI logs be retained?
The AI Act does not mandate one fixed retention period for all logs; obligations interact with GDPR minimization and sector rules. A defensible baseline is six months minimum for operational logs and the system lifetime for decision-reconstruction events on high-risk systems, documented in a written retention policy.
What is the difference between application logs and compliance logs?
Application logs exist for debugging and observability and can be lossy, rotated, or unstructured. Compliance logs exist to reconstruct decisions for a third party, so they must be structured, complete for consequential events, append-only, and integrity-protected. A single event stream can feed both if the schema is designed for it.
Does Article 12 require storing raw personal data?
No. Hashing input and output payloads lets you prove what was processed while storing personal data separately under GDPR-appropriate controls. The reconstruction obligation is about traceability of system behavior, not indefinite retention of personal content.
Download the EU AI Act Logging Pipeline Checklist
Enter your email to download the implementation checklist (Markdown).
We will email you the checklist and occasionally send AI governance insights. Unsubscribe anytime.
Get new articles in your inbox
Occasional emails when I publish something worth reading. Unsubscribe anytime.
Subodh KC
Enterprise AI Advisor & AI Systems Architect. Former Sr. Program Manager, HP Inc. Founder of HAIEC - High Assurance In Every Consequence. Builds production AI systems from decision through operation.