Does the six-month retention floor apply to all logs the AI system generates?

The retention floor applies to the automatically generated logs that Article 12 requires for high-risk AI systems. Operational logs the application keeps for its own debugging purposes are not the same records and are not subject to the same floor, though many deployers find it operationally simpler to apply the same retention to both. The records that have to survive the six-month minimum are the per-decision audit records that identify the period of use, the input data, the reference databases checked, and the identity of natural persons involved.

Can a deployer satisfy Article 19 with logs the AI provider produces on its own infrastructure?

The disclosure obligation under Article 19 sits with the deployer, not the provider. If a provider produces records on its own infrastructure under its own retention, the deployer is dependent on the provider for access during a competent authority review. The practical implementation has to give the deployer direct access to the records under the deployer's control, either by routing requests through the deployer's enforcement layer or by ingesting records the provider produces in a form the deployer retains independently. A provider-controlled record alone leaves the disclosure obligation unmet at the deployer level.

What field formats does the regulator expect for the natural-person identity?

The regulation does not prescribe a specific format. The competent authority will look for a value that uniquely identifies the natural person within the deployer's environment and that ties to a record the deployer can authenticate. In most enterprise deployments, this is the corporate identity provider's user identifier. For customer-facing deployments, it is the customer record identifier from the deployer's system of record. The field has to be propagated at the request layer, not reconstructed from session heuristics after the fact.

How does Article 19 interact with GDPR data minimization?

Article 19's content requirements explicitly include personal data because the regulation calls for identification of natural persons. The deployer has a parallel GDPR obligation to minimize personal data and limit retention to what is necessary. The two obligations align: the records are retained for the minimum the AI Act requires, the personal data fields are limited to what supports identification, and the retention can be extended where other law requires it. Deployers usually document the lawful basis under GDPR Article 6 as compliance with a legal obligation, since the records are required by the AI Act.

Will a deployer face penalties for missing the retention floor specifically?

Article 99 sets the penalty tier for high-risk non-compliance at 15 million EUR or 3% of global annual turnover, whichever is higher. Missing the Article 19 retention floor falls under the operational obligations of deployers and is in scope of the high-risk non-compliance tier. The penalty in practice depends on the seriousness of the gap, the deployer's overall posture, and the competent authority's discretion. A deployer that cannot produce records for a sampled period during a market surveillance action faces the disclosure gap directly, with the supervisory obligation presumed unmet.

EU AI Act Article 19: What the Six-Month Log Retention Rule Requires

Article 19 of the EU AI Act sets the retention floor for the automatically generated logs that Article 12 requires. Deployers of high-risk AI systems have to keep those logs for at least six months. The content of the logs has to include the period of use, the reference databases checked, the input data leading to a match, and the identity of the natural persons involved in verification of results. The August 2, 2026 deadline applies. Most application logging stacks today miss the identity and policy-state fields that Article 19 actually calls for.

The retention number is six months, written in the regulation. The implementation runs to identity propagation, data classification, tamper protection, and access control at the record level.

I want to walk through what Article 19 specifies, where it intersects with Article 12 and Article 26 deployer obligations, and what the architecture needs to produce so the records survive an audit.

What Article 19 actually requires

Article 19 sits inside the high-risk AI system obligations and applies to deployers, not to providers. The text directs deployers to keep the logs that the AI system automatically generates under Article 12 for at least six months. The retention floor is unconditional: if a deployer wipes the records before six months, the obligation has been missed regardless of intent or system state. Where other Union or national law requires longer retention, the longer period applies. Financial services deployers usually face record-keeping obligations measured in years, so the six-month floor is the minimum, not the operational target.

The article also covers access. The records have to be available on request to the national competent authority. The competent authority can demand the records during a market surveillance action or as part of a serious-incident review under Article 73. The records have to be readable, intelligible, and capable of supporting the authority's review.

The Article 12 content fields Article 19 inherits

Article 12 specifies that the recording is automatic, covers the lifetime of the system, and produces records detailed enough to identify risk situations and support post-market monitoring. Article 19 inherits those content requirements and adds the explicit minimum field list.

Period of use means start and end timestamps for the system's operation, including for each request the AI system handled. Reference databases checked means any external data source the system consulted to produce its decision. Input data leading to a match means the prompt or input that triggered the model's output. Identity of natural persons involved means the verified identity of the human or agent whose decision was affected by the AI system, and the verified identity of any person involved in checking the result before it took effect.

Most application logging today captures the first item and partial versions of the third. The reference databases checked and the identity of natural persons involved are commonly missing because the application calls the model with a static service credential and writes its logs against that credential rather than against the natural person.

Where current logging architectures fall short

The standard application logging stack has three failure modes against Article 19. The shared-credential model means the log records the application identity rather than the natural person. The application-controlled record means the same code path that ran the decision also wrote the log, and the log can be modified, suppressed, or lost on crash. The fragmented retention means the records live in whichever log store the application uses, with retention set by the storage tier rather than by the regulatory obligation.

The shared-credential model is the deepest failure. Article 19 expects the records to identify the natural person whose decision the AI affected. An AI system calling an LLM provider with a static API key issued to the application produces a log that identifies the application. The natural-person field has to come from the request context the application supplies, and most application code does not propagate it. The audit record is built from data the application chose to attach.

The application-controlled record fails the independence test. If the application can modify its own log, the log is not a system of record for an auditor. The competent authority reviewing the record under an Article 73 incident investigation will ask whether the application could have selectively logged the request. If the answer is yes, the record's evidentiary weight drops.

The fragmented retention fails the audit window. The six-month retention has to be enforced as a property of the record store, not as a hope that the operations team did not rotate the bucket. The deployer running the AI system has to be able to produce, six months after the request, the exact record the system wrote at the time.

What the architecture has to produce

For Article 19 to be satisfied operationally, the system has to produce records with the following properties.

Each record identifies the natural person whose decision the AI affected. The identity is established by the system that initiates the request, propagated to the AI request layer, and recorded in the log alongside the model decision. Each record names the reference databases consulted, which in modern LLM deployments includes any retrieval augmentation, any external context the prompt embeds, and any vector store query. Each record captures the input data that produced the decision, at the granularity the regulator will ask about: the full prompt for a single-shot AI call, the prompt and the retrieved context for a RAG call, the prompt and the action target for an agent.

The record is independent of the application that initiated the request. The application cannot modify the record after it is written. The record is committed before the model decision returns to the application, so a crashed or compromised application cannot suppress it. The record is retained for at least six months, with longer retention configurable per the deployer's other regulatory obligations.

The access layer supports retrieval by the deployer's compliance team and by the national competent authority on request. Records are queryable by user identity, by time range, by AI system, and by data classification. The query path produces the record in a form that satisfies the authority's review without reconstruction.

How this connects to Article 26 deployer obligations

Article 26 sets the operational responsibilities of deployers of high-risk AI systems. Among those is the obligation to monitor the system's operation, log incidents, and report serious incidents to the competent authority. The Article 19 logs are the substrate for the Article 26 monitoring obligation. Without the records, the deployer cannot demonstrate the monitoring was performed. With sparse or unreliable records, the deployer cannot reconstruct what the system did during the period under review.

The same records also support the Article 73 serious-incident reporting obligation. When a high-risk AI system causes harm or comes close to causing harm, the deployer has to report the incident and produce the records of the system's operation around the event. Without per-decision records under deployer control, the report depends on whatever the application or the vendor agrees to provide.

DeepInspect

This is the architecture Article 19 expects. DeepInspect sits at the AI request boundary as a stateless proxy between the application and the LLM provider. Every request that passes through it produces a per-decision audit record containing the verified identity of the natural person initiating the request, the role and authorization context, the data classification of the prompt, the policy version in effect, the decision outcome, the timestamp, and a cryptographic signature.

The record is committed before the model response returns to the application, so the application cannot suppress it. The record is stored independently of the application's own logs, so the application cannot modify it. The record retention is configured at the proxy layer, so the deployer can meet the six-month Article 19 floor and any longer obligations that apply.

For Article 19, the records are the deployer's evidence layer. For Article 26, the records are the substrate for ongoing monitoring. For Article 73, the records are what the deployer produces to the competent authority during a serious-incident review. If you are running AI in a regulated environment and your Article 19 readiness rests on application logs that the application controls, the readiness is incomplete. Book a demo today.