AI Logging for Compliance Teams: Audit Evidence Without Customer Data

Under the EU AI Act, high-risk AI systems must automatically generate traceable logs, and providers and deployers must retain the logs they control for at least six months. This applies across the system's operational lifetime, not just at deployment. Compliance teams that fail to build this capability into their architecture face gaps they cannot retroactively fill once an incident occurs.

TL;DR:

• Retaining logs for at least six months is a minimum requirement, but longer retention is often necessary for systems with extended decision-making periods.
• Logs must include unique prediction identifiers, model versions, input snapshots, output scores, and human interventions to support effective post-market monitoring.
• Responsibility for logging duties depends on whether the organization is a provider, deployer, or both, with control over the logs determining obligations.
• Proper architecture involves immutable, signed logs with chain-of-custody controls, ensuring logs are tamper-evident and linked to specific inference events for auditability.
• A metadata-only, tamper-evident evidence layer can help regulated firms produce audit-ready logs without exposing sensitive customer data or disrupting their existing infrastructure.

Table of Contents

• What the EU AI Act requires under Articles 12, 19, and 26
• Who is subject and how to confirm high-risk classification
• What to record: minimum log fields and events
• Retention, GDPR reconciliation, and setting a defensible period
• Allocating responsibility between providers and deployers
• Operationalizing logs: architecture, integrity, and join keys
• Audit-readiness checklist for compliance teams
• Practical example: generating tamper-evident evidence packs
• How compliance teams should prioritize logging work
• How an agentless governance layer can help
• Sources
• FAQ

What the EU AI Act requires under Articles 12, 19, and 26

Article 12 sets the technical baseline: high-risk AI systems must be designed with logging capabilities that automatically record events throughout the system's lifetime. This is not optional instrumentation added after the fact. It is a design requirement, meaning the capability has to exist before the system goes into production, capturing events that support traceability and post-market monitoring.

Article 19 translates that logging capability into a retention duty for providers. Providers of high-risk AI systems must keep the automatically generated logs under their control for a period appropriate to the intended purpose, of at least six months, according to the Article 19 text on the AI Act Service Desk. Article 26(6) extends a parallel obligation to deployers, requiring them to retain the logs generated by the high-risk AI system to the extent those logs are under their control, for the same minimum period.

The phrase "appropriate to the intended purpose" is doing real work in both articles. It signals that six months is a floor, not a target. A credit-scoring system with a multi-year loan term, or a medical-device system feeding long-running clinical decisions, will typically need retention well beyond six months to support meaningful post-market monitoring and incident reconstruction. Compliance teams should treat this clause as an instruction to document a retention rationale, not just a number.

Who is subject and how to confirm high-risk classification

The obligation ownership differs by role. A provider designs, develops, or places a high-risk system on the market and carries the Article 12 design duty plus Article 19 retention. A deployer uses the system under its own authority and inherits Article 26 retention obligations for the logs it controls. An organization can hold both roles simultaneously if it builds and operates its own system.

Whether a system counts as high-risk depends on Annex I (products already regulated under existing EU safety legislation, such as medical devices and machinery) and Annex III (defined use cases including credit scoring, recruitment, biometric identification, and critical infrastructure management). Timelines for these classifications are staggered, so a system that is not high-risk today may become one as Annex III categories take effect.

A quick three-step check works for most organizations:

• Match the use case against Annex III categories such as employment, essential services access, or law enforcement.
• Check for existing sectoral regulation that would place the system under Annex I instead.
• Confirm your role as provider, deployer, or both, since this determines which article's retention duty applies to you directly.

What to record: minimum log fields and events

Logs need enough structure to support a reconstruction of any single decision, months or years after it happened. The minimum event classes are inputs, outputs, timestamps, model or system version, and any human intervention that altered or overrode the automated output.

A defensible log schema includes:

• A unique prediction identifier (a UUID) attached to every inference event, which becomes the join key linking that event to its inputs, features, and model version.
• Model and version identifiers, so auditors know exactly which version of the system produced a given output.
• Input snapshot references, pointing to the data used at inference time rather than duplicating raw personal data wherever possible.
• Output and confidence scores, including any probability or ranking the system generated.
• Human review actions, recording overrides, approvals, or escalations tied to the same prediction identifier.
• Error and fallback events, capturing when the system failed to produce a valid output and what happened next.

Responsible-AI metrics deserve explicit attention here because they are widely under-logged. Research on machine learning logging practices found that privacy-related telemetry appeared in 89.3% of logged cases, while fairness-related metrics appeared in only 2.1% of logged information. That gap matters for Article 12 compliance, since post-market monitoring under the AI Act expects evidence of ongoing performance across protected groups, not just system uptime.

On privacy, store references to personal data rather than the raw data itself wherever the join key allows it, and document the lawful basis for whatever personal data does appear in the log itself.

Pro Tip: Log the model version alongside every prediction, even when the model has not changed recently. Version drift is the detail auditors ask about first.

Retention, GDPR reconciliation, and setting a defensible period

Six months is the statutory floor set by Article 19 and Article 26(6), not a safe default. Practical guidance on the six-month rule notes that both providers and deployers carry this duty over the logs they control, and that financial institutions in particular may need to follow longer, sector-specific retention regimes that already exceed six months under existing financial services record-keeping rules.

This creates a reconciliation problem with GDPR's storage limitation principle, which normally pushes organizations toward shorter retention. The AI Act's retention floor and GDPR's minimization principle are not actually in conflict: GDPR allows longer retention when a specific legal obligation requires it, and Article 19 or 26(6) is exactly that obligation. The retention period becomes the longer of the two applicable rules, documented with its legal basis.

To set and defend a retention period:

• Identify every applicable retention rule, including sectoral rules for financial services, healthcare, or employment records.
• Take the longest applicable period as your working retention floor, rather than defaulting to six months.
• Document the rationale in a written policy that references the specific article or sectoral rule driving the period.
• Review the policy whenever the system's intended purpose or use case expands.

Allocating responsibility between providers and deployers

The phrase "to the extent logs are under their control" in Article 26(6) is where most compliance ambiguity lives. A deployer running a vendor's system entirely within the vendor's cloud may control very little of the raw logging infrastructure, while a deployer running the same system on-premises controls all of it.

To close that gap contractually:

1. Specify log access and export rights in the vendor contract, including format, frequency, and retention period on the vendor's side.
2. Require notice of any change to the vendor's logging retention or deletion schedule.
3. Obtain evidence of the vendor's own Article 19 compliance, since a deployer's Article 26 duty depends on logs the provider actually generates.
4. Retain copies of exported logs independently, rather than relying solely on the provider's retention window.

Auditors will ask for the contract clause itself, not just a description of it, so keep the relevant SLA language on file alongside the evidence pack.

Operationalizing logs: architecture, integrity, and join keys

Turning a legal requirement into working infrastructure means treating logging as a security-critical system in its own right. CISA's Logging Reference Architecture frames logging this way: as an enterprise capability requiring dedicated architecture, governance, and integrity controls, built into the same lifecycle that governs the system it monitors.

A workable pattern uses streaming ingestion from the inference service into immutable, append-only storage. Append-only design matters because it prevents silent edits to historical records, which is exactly what an auditor is checking for when they ask about chain of custody.

Integrity controls should include:

• Signed manifests for each batch or evidence pack, so any later modification is detectable.
• HMAC-signed exports, giving auditors a cryptographic way to verify a file has not changed since it was generated.
• Chain-of-custody documentation showing who accessed, exported, or transformed the logs at each step.

The prediction_id UUID remains the backbone of all of this. Practitioner guidance on production machine learning systems identifies the absence of a unique prediction identifier as the most common practical failure that prevents joining inference events with the feature snapshots and model versions needed for a forensic audit. Without that join key, an auditor cannot reliably connect a disputed decision back to the exact inputs and model version that produced it.

CISA's architecture guidance also draws a distinction worth building into your schema from day one: source records versus derived or enriched fields. AI or ML enrichment, such as automated triage flags or anomaly scores, can help investigators prioritize which logs to review first, but it should never replace or overwrite the authoritative source record. Store enrichments as separate, clearly labeled records that reference the original log by its prediction_id, so the source data itself stays immutable and defensible.

Pro Tip: Never let an AI-assisted triage tool write back into your primary log store. Keep enrichment output in a linked, clearly labeled table instead.

Audit-readiness checklist for compliance teams

Reaching genuine Article 12, 19, and 26 readiness is a sequencing exercise more than a technology purchase. A practical order of operations:

1. Classify every AI system against Annex I and Annex III to confirm which ones are high-risk and in scope.
2. Verify automatic logging is actually enabled in production, not just designed into the specification.
3. Assign a control owner for each log source, distinguishing what your organization controls from what a vendor controls.
4. Confirm every inference event carries a prediction_id, since this is the field auditors will ask for first.
5. Lock down storage and retention settings to match your documented retention rationale, not the platform default.
6. Document the lawful basis for any personal data retained inside the logs themselves.

Auditors expect an evidence pack, not a narrative. That pack should include signed manifests, deterministic provenance records tying each decision to its inputs and model version, export scripts that reproduce the same evidence on demand, a redaction workflow for personal data, and at least one rehearsed incident reconstruction exercise showing the team can actually pull a decision's full history within a defined time window. Running that reconstruction test before an auditor asks for one is the single best predictor of a smooth audit.

Practical example: generating tamper-evident evidence packs

Regulated financial services firms increasingly need to show oversight of automated decisions without exposing the underlying customer data those decisions were based on. There are SaaS products offering a read-only, non-invasive AI-agent governance and evidence layer built for this environment, connecting through metadata only.

Certain products generate tamper-evident, cryptographically signed evidence packs that firms can provide to auditors, regulators, or internal risk functions without granting access to production customer data. In practice, that means a signed manifest, a provenance graph linking each decision back through its prediction_id, and an export format built for offline verification, mapping directly onto what Article 12, 19, and 26 evidence packs are expected to contain. Because the connection is metadata-only, firms can obtain audit-ready evidence without inserting a new system into the production path that generates the original decisions.

How compliance teams should prioritize logging work

Start with classification, then verify automatic logging is live, then map who controls which logs, then add the minimal integrity layer (signed manifests, a consistent prediction_id), then run a reconstruction test. That order surfaces the biggest gaps first.

When budget is tight, present retention decisions to legal and privacy teams as a risk trade-off: the cost of storage against the cost of an unreconstructable decision during an audit. Low-effort starting points include adding a prediction_id to existing logs and writing down your retention rationale before buying new tooling.

— Eleye

How an agentless governance layer can help

Building the full logging and evidence stack described above takes real engineering time, and most compliance teams are trying to do it alongside a growing backlog of other regulatory work. Some governance layers are built with hooks into relevant frameworks for this problem, including the Data (Use and Access) Act, EU AI Act Article 26, FCA Consumer Duty and SYSC requirements, and the ICO's developing code of practice on AI and automated decision-making.

For a regulated firm that needs to show oversight of its AI systems without giving a new vendor access to production customer data, that combination solves a specific problem: audit-ready evidence, produced without an invasive integration.

• Explore the platform on the Free, Pro, or Enterprise plans.
• Request an Article 26 readiness audit or review the Design Partner and Production tiers.

Visit Aetherpulse to see what a metadata-only evidence layer looks like for your systems.

Sources

• Logging Reference Architecture (LRA)
• Article 19: Automatically generated logs | AI Act Service Desk
• EU AI Act Log Retention: The 6-Month Rule (In Practice)
• Collect production data guidance (prediction_id best practice) — Microsoft Docs

FAQ

What counts as logging in an AI system?

Logging in an AI system means automatically recording the events tied to each decision: inputs, outputs, timestamps, model version, and any human override. Under the EU AI Act, Article 19 requires this capability to exist by design in high-risk systems, not as an optional add-on.

How long must AI logs be retained?

Providers and deployers must retain the logs they control for a period appropriate to the intended purpose, with a floor of at least six months under Article 19. Sector rules, such as those covering financial services, can require a longer retention period than the six-month floor.

What is the difference between provider and deployer logging duties?

Providers design and place the high-risk system on the market and carry the Article 19 retention duty over the logs they generate and control. Deployers use the system under their own authority and carry a parallel duty under Article 26(6), limited to the logs actually under their control.

Why does the prediction_id matter for compliance?

The prediction_id is a unique identifier attached to each inference event that lets auditors join that event back to its inputs, feature snapshot, and model version. Practitioner guidance identifies its absence as the most common failure that prevents a defensible forensic reconstruction of a disputed AI decision.

What happens if a firm fails to meet AI logging obligations?

Failure to meet Article 12, 19, or 26 obligations exposes a firm to regulatory enforcement action once supervisory authorities begin auditing high-risk systems, since the firm cannot produce the evidence trail the law requires. It also leaves the firm unable to reconstruct or defend a contested automated decision, which carries its own operational and reputational risk beyond the direct penalty.

Recommended

• AI Incident Response Compliance Workflow for Financial Services
• AI Governance Evidence vs Audit Trail: What's the Difference and Why It Matters
• 4 Mechanisms for Defensible Immutable Audit Trails for Compliance Teams
• AI Audit Evidence Chain of Custody: 2026 Compliance Guide