Does the six-month retention rule apply only to providers or also to deployers?

Article 19 applies to providers explicitly. Article 26 extends comparable record-keeping obligations to deployers. The deployer must keep the logs generated by the high-risk AI system for at least six months, subject to the same "unless longer" clause for sectoral rules. In practice, deployers running high-risk AI systems face the same retention obligation as providers.

How does the six-month floor interact with GDPR data minimization?

GDPR data minimization requires personal data to be retained only as long as necessary for the purpose. The purposes of the AI audit log under Article 19 are audit and post-market monitoring. The six-month retention is the minimum period the regulation considers necessary for those purposes. GDPR does not override the sectoral floor set by another EU regulation. The two rules stack.

Is object-lock in compliance mode required, or is governance mode sufficient?

S3 Object Lock supports two modes. Compliance mode locks the object for the retention period regardless of who has access. Governance mode allows a privileged account to override the lock. Article 19 does not specify which mode is required, but the reconstruction test the regulator applies assumes the log has not been rewritten. Compliance mode is the safer default because it removes the human override path that a regulator would flag on inspection.

What retention applies to logs from a system that fails classification review after deployment?

If a system that was deployed as non-high-risk is later reclassified as high-risk, the retention rule applies from the reclassification date forward. The regulator does not retroactively require six months of retention on records that predate the classification. The reclassification triggers the retention clock on the log stream from the classification date.

How does the retention rule interact with backup and disaster recovery?

Backup copies of the log records fall under the same retention rule. A backup that is deleted before the retention period expires does not satisfy the rule if the primary copy is also lost. The retention architecture must ensure that at least one accessible copy of the log record exists for the full retention window. Object-lock policies applied to the backup storage tier are the common pattern.

Does the retention rule apply to logs of the model training process?

No. Article 19 covers the logs generated automatically by the high-risk AI system in operation. Training logs are covered by Article 11 technical documentation requirements. The two obligations are separate. The retention rule for operational logs is six months minimum. The retention rule for technical documentation is the lifetime of the system plus ten years after the system is placed on the market.

AI Audit Log Retention Under the EU AI Act: What Six Months Actually Means at the Storage Layer

Article 19 of the EU AI Act sets a floor. Deployers of high-risk AI systems keep the automatically generated logs for at least six months, unless other Union or national law requires longer. The floor is the minimum a regulator accepts during an audit of a high-risk deployment. Six months is a starting point that most enterprise deployments will exceed once sectoral rules stack on top: GDPR Article 30 records, HIPAA record-retention for treatment activities, MiFID II for investment services, SOX for financial reporting, DORA for ICT third-party events.

The August 2, 2026 enforcement date for high-risk system requirements is 30 days out from this article. The retention decisions made now determine the shape of the audit trail the regulator sees for the next six months minimum.

I want to walk through what the six-month floor actually requires at the storage layer, how it interacts with sectoral retention rules, and the inspection-layer architecture that produces logs the retention rule can operate on.

Retention floor

Article 19 reads: "Providers of high-risk AI systems shall keep the logs automatically generated by their high-risk AI systems, to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months." The floor is six months. The ceiling is set by the sectoral rules that apply to the deployment.

For a bank running an AI credit-scoring model, the ceiling is the record-retention rules under the Consumer Credit Directive and the national implementations of MiFID II. For a hospital running an AI clinical-decision-support tool, the ceiling is the record-retention rules under national health-record laws, which routinely require decade-long retention. For a general enterprise deployment, the six-month floor is the effective retention target unless GDPR Article 30 or another rule extends it.

Sectoral stacking

Article 19 explicitly acknowledges the stacking pattern. The clause "unless other Union or national law requires longer" preserves every existing retention rule that applies to the underlying business activity. The retention rule does not replace sectoral rules. It sets the floor and lets the ceiling emerge from the sectoral overlay.

Financial services

A bank running a high-risk AI system under the EU AI Act is also subject to the record-retention rules under MiFID II Article 16 and DORA Article 28 for ICT third-party service providers. MiFID II requires five years of retention on client-related records. DORA requires the ICT third-party register to be maintained for the duration of the contractual relationship plus a defined post-termination period.

Healthcare

A hospital running a high-risk AI clinical-decision-support tool is also subject to national health-record retention rules. Germany's Sozialgesetzbuch Book V sets ten-year retention for patient records. France's Code de la santé publique sets twenty years. The AI audit log for a clinical decision covers the same event, and the retention rule that applies to the record of care extends to the AI decision log that fed the record.

GDPR overlay

GDPR Article 30 requires records of processing activities. The records must include the categories of data, the purposes, and the retention periods. The AI audit log under Article 19 is a processing activity under GDPR. The record of processing must reference the AI audit log's retention period, and the retention period must be justified against the purposes specified in the record of processing.

Compliance gap

Most AI deployments today have no retention architecture that satisfies either the six-month floor or the sectoral ceiling. The gaps are structural.

Application logs get rotated by default

Standard application logging pipelines rotate logs at intervals set by the operations team. Common defaults are 30, 60, or 90 days. The retention rule in Article 19 requires six months minimum. Application logs configured with a 30-day rotation fail the retention test on day 31 of an audit.

The event that matters is not preserved separately

An application log that records "request processed" for an AI decision does not preserve the decision inputs, the identity of the natural person involved, or the policy state at the moment of decision. The retention window covers the wrong record. Six months of application-log retention that lacks the required content fails the reconstruction test just as certainly as six months of retention that never existed.

Retention is not tamper-resistant

Article 19 does not use the word "tamper-resistant" but the reconstruction test the regulator applies during an audit assumes the log has not been rewritten. Application logs that live on the same host as the AI application are rewriteable by the same operator who has access to the AI application. The retention rule presumes the log is preserved in a form that survives the operator.

Retention architecture

The retention rule operates on the log stream that comes out of the AI request layer. The architecture that produces a compliant retention pattern has four properties.

Per-decision log at the request layer

The log is produced at the moment of the AI decision, not after the fact. Each AI request generates a log record that contains the identity of the natural person, the input prompt (or a policy-defined redaction), the model called, the policy state applied, the decision (pass or block), and the timestamp. The record is complete at the moment of decision. Retention starts from that moment.

Write-once storage

The log is written to a storage backend that enforces immutability at the storage-layer contract, not the application-layer discipline. Object storage with an object-lock policy configured for the retention window is the common pattern. S3 Object Lock in compliance mode, Azure Blob Storage immutability policies, and GCS bucket-lock all satisfy the write-once requirement.

Retention set at ingestion, not modification time

The retention clock starts when the log record is written, not when it is last modified. Object-lock policies that key off modification time can be reset by a rewrite operation. The clock keys off ingestion time and the policy holds regardless of what happens to the storage after.

Independent access path for the auditor

The auditor's read path is separate from the AI application's write path. The AI application writes logs. The auditor reads logs. Separation of the two paths means the AI application cannot modify what the auditor sees, and the auditor cannot influence what the AI application writes. The Article 12 record-keeping mandate makes this separation explicit at the policy level. The architecture makes it explicit at the storage level.

Penalties

Article 99 sets the penalty tier for high-risk non-compliance at €15 million or 3% of global annual turnover, whichever is higher. A retention failure that leaves a regulator unable to reconstruct a high-risk AI decision falls into the tier. The €15 million exposure is per finding, and a retention failure surfaces on the first audit that requests logs older than the rotation window.

The supplying-misleading-information tier sits at €7.5 million or 1%. A retention failure that produces logs that appear complete but lack the required fields falls into that tier when the field omissions become visible to the regulator.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request and response, it produces a per-decision log record that contains the identity of the natural person, the input prompt, the model called, the policy state applied, and the decision. The log record is written to an immutable storage backend at the moment of decision and retained under a policy that satisfies the six-month floor and any sectoral ceiling that applies.

The retention architecture is separate from the AI application. The AI application does not write the compliance log. DeepInspect writes it. The separation of the write path from the read path removes the failure modes that come with application-controlled logging.

If you are facing the August deadline, let's talk.