Does Article 19 apply to vendor-embedded AI usage?

The deployer obligation under Article 19 applies regardless of where the model runs. If your environment uses a SaaS tool that embeds an LLM under the hood, you are the deployer of the high-risk system if the use case falls under Annex III. The vendor is responsible for producing the records under Article 12. You are responsible for retaining them and producing them on demand under Article 19. Procurement contracts with AI-using vendors must explicitly include log access and retention provisions. Without those provisions, the obligation lands on you with no operational ability to satisfy it.

What happens if a log file is corrupted or partially missing?

Article 19 expects records sufficient to enable regulatory inquiry. Partial logs, corrupted log files, or gaps in the retention period are treated as compliance failures. The penalty falls under Article 99's €15 million or 3% tier. The regulator's posture is that missing records prove absence of compliance, not the other way around. An architecture that produces records inline, signs them at write time, and stores them in a tier with documented integrity properties is the operational answer to the corruption question.

Are anonymized logs acceptable under Article 19?

No. Article 19 explicitly requires identification of natural persons involved in human verification. Anonymized logs fail the requirement. The text intersects with GDPR's data minimization principle, which is sometimes invoked to argue for anonymization. The two regulations need to be implemented together. The Article 19 records contain identity. They are stored with access controls that satisfy GDPR's confidentiality requirements. Anonymization is not a substitute for either obligation.

What is the relationship between Article 19 and Article 12?

Article 12 is the provider's design-time obligation: the system must technically allow for automatic recording of events over its lifetime. Article 19 is the deployer's operational obligation: keep the records, produce them on demand. The two operate together. A provider that designs the system to produce logs and a deployer that fails to retain them produces a compliance gap. A deployer that retains logs the provider never produced produces a different compliance gap. The audit-survivable posture requires both halves.

How long should we retain Article 19 logs in practice?

Six months is the floor. The operational target is the longer of six months and the sector-specific retention obligation that applies to the deployer. Financial institutions in most EU jurisdictions retain five to seven years. Healthcare deployers retain ten years or longer in some Member States. Government deployers face national-law retention that frequently exceeds five years. The practical answer is to design retention to support seven years as a reasonable upper bound, with the option to extend per deployer.

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

Article 19 of the EU AI Act sets the retention floor and content specification for the automatically generated logs that Article 12 requires from high-risk AI systems. The mandate takes effect on August 2, 2026. Deployers must keep the logs for at least six months, unless other Union or national law requires longer. Financial institutions, healthcare deployers, and government deployers face longer retention obligations under existing sector law that stack on top of Article 19. The penalty for non-compliance reaches €15 million or 3% of global annual turnover under Article 99.

I want to walk through what Article 19 specifies, where the structural gaps sit, and what an architecture that survives a regulator inquiry actually looks like.

Mandate

Article 19 attaches the operational obligation to the deployer. The provider designs the system to produce automatically generated logs under Article 12. The deployer keeps those logs and produces them on demand.

The text specifies a six-month retention floor as the minimum. The records that must be kept include the period of use (start and end timestamps), the reference databases against which inputs were checked, the input data leading to a match or output, and the identity of the natural persons involved in any human verification of results. Financial institutions covered by sector-specific record-keeping rules under Union financial services law are explicitly subject to those longer retention periods.

The combination of Article 12 and Article 19 produces a structural requirement that few application-controlled logging systems satisfy.

Six months is the floor, not the operational target

Most regulated organizations face retention obligations that stack on top of Article 19. A bank under MiFID II keeps transaction records for five years. A healthcare deployer under HIPAA-aligned EU data protection law often keeps records for ten years or longer. A government deployer of a high-risk AI system in migration or border control faces retention rules that are governed by national law and frequently exceed five years.

The six-month figure is the minimum operational exposure, not the target architecture. Designs that assume six-month retention will hit the regulator-floor and miss the sector-specific obligations that apply in parallel.

What "automatically generated" rules out

The recording must be automatic at the system level. A configuration that can be disabled by an operator fails the test. An optional logging extension that is turned off in production fails the test. A logging mode that depends on the application correctly calling the log function during every code path fails the test, because application code can be modified, disabled, or bypassed. The recording must be structural to the system's design.

Identification of natural persons

Article 19 calls out identification of natural persons explicitly. The deployer must be able to produce, for every output of the high-risk system, the identity of the human who verified or acted on the output. Most AI deployments running on shared service credentials cannot produce that identity at the request layer. The credential identifies the calling application. It carries no information about the human or agent on whose behalf the application acted.

Compliance gap

Most high-risk AI deployments today have no Article 19-compliant retention architecture. Three structural gaps recur across the deployments I look at.

The application owns the write path

When the application that produces the AI output also writes the audit log, the audit record fails three failure modes. Selective logging: the application logs successes and omits edge-case failures. Suppression: the application can wipe or modify the log after the fact. Loss on crash: the application crashes after the model responds but before the log commits, and the action survives while the evidence does not. Article 19 expects records that are reliable enough to be admissible in a regulatory inquiry. A log that the application controls fails the reliability test by design.

Retention infrastructure is not in place

Six months sounds short. In practice, most AI deployment logs are routed to application observability platforms that rotate aggressively, often within thirty to ninety days. The records that the regulation expects to survive a six-month inquiry have been overwritten before the deployer realizes the obligation applied. A specific retention tier for Article 19 logs, separate from operational telemetry, is the architectural requirement.

Vendor-embedded AI is invisible

A material share of AI usage in enterprises flows through vendor SaaS tools that embed model calls under the hood. The CRM platform uses an LLM to summarize records. The customer-service tool uses a model to draft responses. The deployer's environment never sees the prompt or the response. The Article 19 obligation applies to the deployer regardless of whether the model ran in the deployer's environment. Procurement contracts that do not explicitly require vendor-side log access leave the deployer exposed.

What the architecture must produce

An architecture that satisfies Article 19 produces, for every output of the high-risk system, a record containing the input timestamp, the output timestamp, the identity of the natural person involved, the reference data or databases checked, the policy version in effect, and the outcome.

That record is independent of the application. It is signed or otherwise integrity-protected so post-hoc modification is detectable. It is retained for at least the longer of six months and any other applicable retention period under Union or national law. It is searchable by request, by user, by time range, and by policy version.

The record is produced inline, not asynchronously. An asynchronous logging pipeline that batches writes and acknowledges them later loses records on the crash conditions Article 19 cares about. Inline, write-before-response is the only architectural posture that survives the audit.

DeepInspect

This is the infrastructure Article 19 requires above the application's own observability stack. DeepInspect sits as a stateless proxy between the application and the LLM. Every request that passes through produces a per-decision audit record containing the identity of the natural person, the policy version, the data classification, the outcome, and timestamps. The record is committed before the response returns to the application, which means the application has no opportunity to suppress or modify it.

For Article 19, that record is the structural compliance artifact. Retention is configured per deployer to match the longer of the six-month floor and the sector-specific obligation. The records are signed and tamper-evident. The records are searchable in the same query interface across deployments, models, and policies.

If you are running AI in a high-risk category and your Article 19 readiness depends on the application's observability stack, that readiness is incomplete.

Book a demo today.