EU AI Act Art.19 Automatically Generated Logs: Provider and Deployer Retention Obligations, 6-Month Minimum, Sector-Specific Extensions, and Art.12 × Art.19 × Art.72 Integration (2026)
Article 19 of the EU AI Act occupies a specific position in the compliance architecture that is often misread: it does not require high-risk AI systems to generate logs — that obligation is in Art.12(1) — but it requires both providers and deployers to retain those automatically generated logs for a defined minimum period. The distinction matters. Art.12 governs the technical logging capability of the AI system itself. Art.19 governs the organisational retention obligation that sits downstream of that capability.
Two obligations exist in Art.19, directed at different actors in the supply chain. Art.19(1) addresses providers. Art.19(2) addresses deployers. Both set a floor of 6 months, but both explicitly allow Union law or national legislation to require longer periods — and in regulated sectors, those longer requirements are the norm rather than the exception.
The cross-regulation complexity of Art.19 is significant. Financial entities operating AI systems under DORA will face DORA Art.12 log retention requirements that may substantially exceed the AI Act's 6-month floor. Healthcare AI providers subject to the MDR face similar obligations. Understanding Art.19 as a minimum baseline — a floor, not a ceiling — is the correct implementation posture.
The Legal Architecture of Art.19
Art.19 sits within Section 3 of Chapter III (Obligations for Providers and Deployers of High-Risk AI Systems), immediately following Art.18 (documentation keeping) and immediately before Art.20 (corrective actions). This placement is not incidental: Art.18 governs the technical documentation of the AI system, Art.19 governs the operational evidence generated during its use, and Art.20 governs what happens when that evidence reveals problems requiring correction.
Art.19(1) — Provider Obligation:
Providers of high-risk AI systems shall keep the automatically generated logs referred to in Art.12(1) to the extent such logs are under their control. They shall keep those logs for a period appropriate to the intended purpose of the high-risk AI system, of at least 6 months, unless a different period is provided for in applicable Union or national law, in particular under Union law applicable to financial services or Union law establishing obligations for operators of critical infrastructure.
Three elements require parsing.
"Automatically generated logs referred to in Art.12(1)" means logs that meet the Art.12(1) technical requirements: logs generated automatically by the AI system that record events occurring during the system's operation. These are not application-layer logs chosen by the provider for debugging purposes; they are the Art.12-compliant event logs the AI system generates as a requirement of its conformity with the high-risk AI system requirements.
"To the extent such logs are under their control" introduces a practical scoping limit. Where a provider deploys an AI system as a cloud service and the deployer operates the AI system in their own infrastructure, some operational logs will be under deployer control rather than provider control. The provider's Art.19(1) obligation applies only to the logs they can actually access and control. This interacts with contractual arrangements between providers and deployers: providers who want to fulfil Art.19(1) comprehensively must ensure they have contractual rights to access or receive copies of logs generated in deployer-controlled environments.
"Appropriate to the intended purpose, of at least 6 months" creates a two-level requirement. The baseline is 6 months, but the provider must also assess whether the intended purpose of the AI system requires a longer period. A high-risk AI system used for credit scoring decisions, where applicants have up to 24 months to challenge a decision under GDPR Art.22, may require retention periods longer than 6 months to enable the provider to reconstruct what the AI system did in a specific instance.
Art.19(2) — Deployer Obligation:
Deployers of high-risk AI systems that are subject to obligations regarding keeping of logs under Art.12(1) shall retain the logs automatically generated by the high-risk AI system to the extent they are under the control of the deployer. They shall keep those logs for a period of at least 6 months, unless a different period is provided for in applicable Union or national law, in particular under Union law applicable to financial services or Union law establishing obligations for operators of critical infrastructure.
The deployer obligation mirrors the provider obligation in structure but differs in two key ways. First, deployers retain the logs generated in their operational environment — their retention obligation is focused on the logs generated during actual deployment and use of the AI system, not the logs from the provider's development or testing phases. Second, the reference to critical infrastructure operators signals that deployers operating in regulated sectors — energy, water, transport, financial infrastructure — face sector-specific retention floors that will generally exceed the 6-month AI Act baseline.
Art.12 × Art.19 Integration: What Gets Logged and How Long It Must Be Kept
Art.12(1) specifies that high-risk AI systems shall be designed and developed with capabilities enabling the automatic recording of events (logs) relevant to identifying risks to health and safety, or risks related to fundamental rights, throughout the lifetime of the system. These are the logs that Art.19 requires to be retained.
The minimum log content under Art.12(1) is not exhaustively defined in the Act, but Recital 72 and the technical specifications developed under Art.40 provide guidance on the categories of events that must be logged:
| Log Category | Art.12 Requirement | Retention Relevance |
|---|---|---|
| Session start/end timestamps | Required | Establishes when AI system operated |
| Input data references | Required | Enables reconstruction of what data was processed |
| Automated decision outputs | Required | Enables audit of specific decisions |
| Human oversight interventions | Required | Documents where Art.14 oversight was exercised |
| Error and anomaly events | Required | Input for post-market monitoring under Art.72 |
| System state at decision time | Context-dependent | Relevant for reproducibility claims |
| User/operator identification | Context-dependent | Required for GDPR data subject requests |
The intersection between Art.12(1) log content requirements and Art.19 retention obligations creates a specific architectural requirement: logs must be retained in a form that preserves their evidential value. A log entry that records a decision output without the corresponding input data reference is not a compliant Art.12 log, and retaining non-compliant logs for 6 months does not satisfy Art.19.
Sector-Specific Retention Requirements: When 6 Months Is Not Enough
The explicit references to financial services and critical infrastructure in both Art.19(1) and Art.19(2) signal that the AI Act recognises the 6-month floor as insufficient in many deployment contexts. The interaction table below maps sector-specific requirements against the Art.19 baseline:
| Sector | Applicable Regulation | Log Retention Requirement | Exceeds Art.19 Floor? |
|---|---|---|---|
| Financial Services | DORA Art.12 | 5 years | Yes — substantially |
| Banking (AML) | AMLD6 Art.40 | 5 years after business relationship ends | Yes |
| Healthcare AI | MDR Annex IX | 15 years (implantable devices) / 10 years | Yes |
| Healthcare (patients) | GDPR + national health law | Variable, often 10+ years | Yes |
| Critical Infrastructure | NIS2 Art.23 | Varies by MS, typically 12-24 months | Often yes |
| Aviation AI | EASA CS/AMC | As required by type certificate | Often yes |
| Employment AI (credit scoring) | GDPR Art.22 | Duration of data subject rights window | Often yes |
| General high-risk AI | EU AI Act Art.19 | 6 months minimum | Baseline |
For providers and deployers operating in financial services, the most operationally significant interaction is with DORA. DORA Art.12 requires financial entities to keep logs related to ICT systems, including AI systems that constitute ICT services, for a minimum of 5 years. Where a high-risk AI system under the EU AI Act is also an ICT system under DORA, the DORA 5-year retention requirement applies — and the EU AI Act 6-month floor is irrelevant as the higher obligation governs.
The principle of lex specialis applies: where sector-specific Union law establishes a log retention requirement for AI systems in that sector, the sector-specific requirement takes precedence over the EU AI Act's baseline. The EU AI Act does not preempt these requirements — it establishes a floor that sector-specific law raises.
GDPR Art.5(1)(e) vs Art.19: The Storage Limitation Conflict
Automatically generated logs frequently contain personal data: decision outputs that identify individuals, user session data, input data references tied to specific persons. When logs contain personal data, GDPR Art.5(1)(e)'s storage limitation principle applies: personal data must be kept in a form permitting identification of data subjects for no longer than necessary for the purposes for which the data are processed.
The tension between GDPR's storage limitation and Art.19's minimum retention period is resolved by GDPR Art.6(1)(c): processing is lawful where it is necessary for compliance with a legal obligation to which the controller is subject. Art.19's mandatory retention period constitutes a legal obligation under Union law that provides the GDPR lawful basis for retaining logs containing personal data for the required period.
However, GDPR Art.6(1)(c) does not create a blanket exemption from data minimisation. The resolution requires three practical steps:
Step 1 — Minimise log personal data content at the point of generation. Logs should be designed to capture the minimum personal data necessary for Art.12 compliance. Where a log can record a decision output with a pseudonymised identifier rather than a direct identifier, that approach satisfies both Art.12 and GDPR Art.5(1)(c) data minimisation.
Step 2 — Segment log retention by data sensitivity. Not all log entries will contain personal data. Log architectures that separate personal data elements from operational event data enable differential retention — personal data elements retained for the legally required minimum period, operational event data retained longer where justified by intended purpose assessment.
Step 3 — Document the retention justification. Art.13/14 GDPR transparency obligations require data subjects to be informed of retention periods. The retention justification (EU AI Act Art.19 obligation, sector-specific regulation) must appear in privacy notices covering AI system operations.
Provider vs Deployer: Allocation of Retention Responsibilities
One of the operationally significant questions raised by Art.19's dual obligation structure is how providers and deployers allocate retention responsibilities in practice. Both Art.19(1) and Art.19(2) use the limiting phrase "to the extent under their control" — meaning the obligations are scoped to what each party can actually control, but also meaning both parties may have concurrent obligations over the same logs if they share control.
The practical allocation depends on the deployment model:
| Deployment Model | Provider-Controlled Logs | Deployer-Controlled Logs |
|---|---|---|
| SaaS model (AI as a service) | All operational logs (provider infrastructure) | None (or only client-side API call logs) |
| On-premises deployment | Development/test logs only | All operational logs |
| Hybrid (provider API + deployer processing) | API-layer logs | Application integration logs, user session logs |
| Fine-tuned model deployment | Training logs, base model logs | Inference logs, deployment-specific logs |
For providers deploying AI systems as SaaS, Art.19(1) requires retention of all operational logs since they are under provider control. The deployer's Art.19(2) obligation is limited to whatever logs they generate independently (API call logs, downstream processing logs).
For providers deploying on-premises or in deployer-controlled infrastructure, the provider's Art.19(1) obligation covers only the logs they can access — typically development logs, testing logs, and such operational logs as the deployer contractually agrees to share back. Providers who want complete Art.19 coverage must build contractual log-sharing or log-escrow arrangements with deployers into the supply chain.
The EU AI Act's Art.25 (responsibilities along the supply chain) supports this contractual approach: providers can rely on deployers to fulfil obligations under Art.19(2) for deployer-controlled logs, but must document this allocation in the QMS under Art.17(1)(d).
MSA Access Rights to Retained Logs
Market Surveillance Authorities have access rights to retained logs under Art.74(3), which grants MSAs the right to access the documentation and information necessary to perform their tasks. Automatically generated logs retained under Art.19 are within the scope of Art.74(3) access rights.
Three practical implications follow:
Log retrieval SLA. Logs must be retrievable in a timeframe compatible with MSA investigation requirements. There is no explicit response time in Art.19, but Art.74 investigation powers contemplate active access during investigations — logs stored in cold archive with multi-day retrieval times may not satisfy the "at the disposal of" standard implicitly required.
Log integrity. Retained logs must be producible in a form that demonstrates their authenticity. Hash-chain log architectures, write-once log storage, or cryptographic attestation of log integrity are implementation approaches that support this requirement. Logs that could have been modified after generation have reduced evidential value in MSA investigations.
Cross-border MSA access. Where a provider is established in one Member State and deploys an AI system in another, both Member States' MSAs may have access rights. Log retention infrastructure must be accessible to MSAs in all jurisdictions where the AI system is deployed, not only in the provider's home jurisdiction.
Python LogRetentionManager Implementation
The following implementation provides a compliant log retention management system that handles the Art.19 retention period logic, sector-specific extension detection, and log integrity verification:
import hashlib
import json
import logging
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from enum import Enum
from pathlib import Path
from typing import Any, Optional
logger = logging.getLogger(__name__)
class Sector(str, Enum):
GENERAL = "general"
FINANCIAL_SERVICES = "financial_services"
BANKING_AML = "banking_aml"
HEALTHCARE = "healthcare"
HEALTHCARE_IMPLANTABLE = "healthcare_implantable"
CRITICAL_INFRASTRUCTURE = "critical_infrastructure"
AVIATION = "aviation"
EMPLOYMENT_AI = "employment_ai"
# Art.19 minimum + sector-specific retention periods in days
RETENTION_PERIODS = {
Sector.GENERAL: 180, # Art.19 baseline: 6 months
Sector.FINANCIAL_SERVICES: 1825, # DORA Art.12: 5 years
Sector.BANKING_AML: 1825, # AMLD6 Art.40: 5 years
Sector.HEALTHCARE: 3650, # MDR: 10 years
Sector.HEALTHCARE_IMPLANTABLE: 5475, # MDR Annex IX: 15 years
Sector.CRITICAL_INFRASTRUCTURE: 365, # NIS2 indicative: 12 months
Sector.AVIATION: 3650, # EASA: 10 years (conservative)
Sector.EMPLOYMENT_AI: 730, # GDPR Art.22 challenge window: 2 years
}
@dataclass
class LogEntry:
"""A single Art.12-compliant log event."""
event_id: str
timestamp: datetime
event_type: str # session_start, decision, intervention, error, session_end
session_id: str
ai_system_id: str
input_ref: Optional[str] # pseudonymised reference to input data
output_summary: Optional[str] # decision output (not full personal data)
operator_id: Optional[str] # pseudonymised operator identifier
contains_personal_data: bool = False
metadata: dict[str, Any] = field(default_factory=dict)
integrity_hash: Optional[str] = None
def compute_hash(self) -> str:
payload = json.dumps({
"event_id": self.event_id,
"timestamp": self.timestamp.isoformat(),
"event_type": self.event_type,
"session_id": self.session_id,
"ai_system_id": self.ai_system_id,
"input_ref": self.input_ref,
"output_summary": self.output_summary,
}, sort_keys=True)
return hashlib.sha256(payload.encode()).hexdigest()
class LogRetentionManager:
"""
Art.19 EU AI Act log retention manager.
Manages retention periods for automatically generated logs from
high-risk AI systems. Implements both provider (Art.19(1)) and
deployer (Art.19(2)) retention obligations.
"""
def __init__(
self,
ai_system_id: str,
sector: Sector,
actor_type: str, # "provider" or "deployer"
log_store_path: Path,
):
self.ai_system_id = ai_system_id
self.sector = sector
self.actor_type = actor_type
self.log_store_path = log_store_path
self.retention_days = RETENTION_PERIODS[sector]
log_store_path.mkdir(parents=True, exist_ok=True)
def store_log_entry(self, entry: LogEntry) -> str:
"""Store log entry with integrity hash. Returns entry ID."""
entry.integrity_hash = entry.compute_hash()
log_file = self.log_store_path / f"{entry.event_id}.json"
with open(log_file, "w") as f:
json.dump({
"event_id": entry.event_id,
"timestamp": entry.timestamp.isoformat(),
"event_type": entry.event_type,
"session_id": entry.session_id,
"ai_system_id": entry.ai_system_id,
"input_ref": entry.input_ref,
"output_summary": entry.output_summary,
"operator_id": entry.operator_id,
"contains_personal_data": entry.contains_personal_data,
"metadata": entry.metadata,
"integrity_hash": entry.integrity_hash,
"stored_at": datetime.utcnow().isoformat(),
"retention_until": (
entry.timestamp + timedelta(days=self.retention_days)
).isoformat(),
"sector": self.sector.value,
"actor_type": self.actor_type,
}, f, indent=2)
return entry.event_id
def verify_log_integrity(self, event_id: str) -> dict[str, Any]:
"""Verify stored log has not been tampered with."""
log_file = self.log_store_path / f"{event_id}.json"
if not log_file.exists():
return {"event_id": event_id, "status": "not_found"}
with open(log_file) as f:
stored = json.load(f)
entry = LogEntry(
event_id=stored["event_id"],
timestamp=datetime.fromisoformat(stored["timestamp"]),
event_type=stored["event_type"],
session_id=stored["session_id"],
ai_system_id=stored["ai_system_id"],
input_ref=stored.get("input_ref"),
output_summary=stored.get("output_summary"),
operator_id=stored.get("operator_id"),
)
expected_hash = entry.compute_hash()
actual_hash = stored.get("integrity_hash")
return {
"event_id": event_id,
"status": "valid" if expected_hash == actual_hash else "tampered",
"expected_hash": expected_hash,
"stored_hash": actual_hash,
}
def get_retention_status(self) -> dict[str, Any]:
"""Return retention compliance status for all stored logs."""
now = datetime.utcnow()
all_logs = list(self.log_store_path.glob("*.json"))
compliant = []
expiring_soon = []
expired = []
for log_file in all_logs:
with open(log_file) as f:
entry = json.load(f)
retention_until = datetime.fromisoformat(entry["retention_until"])
days_remaining = (retention_until - now).days
if days_remaining < 0:
expired.append(entry["event_id"])
elif days_remaining < 30:
expiring_soon.append({
"event_id": entry["event_id"],
"days_remaining": days_remaining,
})
else:
compliant.append(entry["event_id"])
return {
"ai_system_id": self.ai_system_id,
"sector": self.sector.value,
"retention_days": self.retention_days,
"total_logs": len(all_logs),
"compliant": len(compliant),
"expiring_within_30_days": expiring_soon,
"expired_requiring_review": expired,
"retention_baseline": "EU AI Act Art.19",
"applicable_lex_specialis": self._get_lex_specialis(),
}
def generate_msa_retrieval_package(
self,
session_id: Optional[str] = None,
from_timestamp: Optional[datetime] = None,
to_timestamp: Optional[datetime] = None,
) -> list[dict]:
"""Generate MSA-accessible log package for Art.74(3) access requests."""
results = []
for log_file in self.log_store_path.glob("*.json"):
with open(log_file) as f:
entry = json.load(f)
if session_id and entry.get("session_id") != session_id:
continue
ts = datetime.fromisoformat(entry["timestamp"])
if from_timestamp and ts < from_timestamp:
continue
if to_timestamp and ts > to_timestamp:
continue
integrity = self.verify_log_integrity(entry["event_id"])
results.append({**entry, "integrity_status": integrity["status"]})
return sorted(results, key=lambda x: x["timestamp"])
def _get_lex_specialis(self) -> Optional[str]:
lex_map = {
Sector.FINANCIAL_SERVICES: "DORA Art.12 (5 years)",
Sector.BANKING_AML: "AMLD6 Art.40 (5 years)",
Sector.HEALTHCARE: "MDR Annex IX (10 years)",
Sector.HEALTHCARE_IMPLANTABLE: "MDR Annex IX (15 years)",
Sector.CRITICAL_INFRASTRUCTURE: "NIS2 Art.23 (sector-specific)",
}
return lex_map.get(self.sector)
Art.19 × Art.72 Integration: Logs as Post-Market Monitoring Input
Article 72 requires providers of high-risk AI systems to implement a post-market monitoring system that actively collects and reviews data on the performance of high-risk AI systems throughout their lifetime. Automatically generated logs retained under Art.19 are a primary data source for the Art.72 monitoring system.
The integration creates a retention-monitoring feedback loop:
- Art.12(1) logs are generated automatically during system operation
- Art.19(1)/(2) require those logs to be retained for at least 6 months (or sector-specific longer period)
- Art.72(1) requires the provider to collect and review data on system performance — the retained logs are this data
- Art.20 requires providers to take corrective actions when monitoring reveals risks — the trigger for corrective action derives from log analysis
- Art.18 requires retention of corrective action records (as QMS records under Art.17) for 10 years
This five-step loop means that an organisation's log retention infrastructure is not simply a compliance storage obligation — it is the operational backbone of the post-market monitoring system. Providers who retain logs but do not actively analyse them for Art.72 purposes are complying with the letter of Art.19 while potentially failing the spirit of Art.72.
The Art.19 × Art.11 Documentation Intersection
Art.11 technical documentation (retained under Art.18 for 10 years) must include a description of the monitoring, functioning, and control provisions. This description must reference the logging capabilities implemented under Art.12 and the retention arrangements under Art.19.
For Art.11 compliance, providers should document:
- The categories of events automatically logged by the AI system
- The log format and data schema
- The retention period applied and the legal basis (Art.19 baseline or sector-specific extension)
- The log storage architecture (on-premises, cloud, hybrid)
- The access control and integrity protection measures
- The retrieval procedures for MSA access under Art.74(3)
This documentation serves as evidence in conformity assessments that the Art.12 logging capability is real, that the Art.19 retention infrastructure exists, and that the Art.74 access rights can be exercised in practice.
20-Item Art.19 Implementation Checklist
Provider Obligations (Art.19(1))
- Confirm that the high-risk AI system generates Art.12(1)-compliant logs automatically during operation
- Map all log types generated to the Art.12 minimum content requirements (session events, inputs, outputs, interventions, errors)
- Assess which logs are under provider control vs deployer control in each deployment model
- Set default retention period: 6 months minimum from event generation timestamp
- Conduct sector-specific retention assessment: identify all Union/national laws requiring longer retention for the intended deployment sectors
- Apply the longer retention period where sector-specific law exceeds the Art.19 6-month floor (do not blend periods — apply the maximum to avoid compliance gaps)
- Implement log integrity protection (hash-chain, write-once storage, or cryptographic attestation)
- Document log storage architecture in Art.11 technical documentation (Annex IV)
- Establish log retrieval procedure for Art.74(3) MSA access requests
- Include log retention arrangements in QMS under Art.17(1)(d)
Deployer Obligations (Art.19(2))
- Identify all automatically generated logs under deployer control (operational logs, inference logs, user session logs)
- Confirm the AI system is subject to Art.12(1) logging requirements (high-risk classification confirmed)
- Apply 6-month minimum retention from log generation timestamp
- Assess applicable sector-specific retention requirements for the deployer's industry
- Separate personal-data-containing log elements from operational log data for differential retention management
- Document GDPR Art.6(1)(c) legal basis in privacy notices for log data containing personal data
- Establish internal access control: who can access retained logs and under what circumstances
- Test log retrieval capability against MSA access request simulation (retrieve specific session logs within defined timeframe)
- Negotiate contractual log-sharing obligations with provider (to ensure provider can satisfy Art.19(1) for deployer-controlled logs where relevant)
- Include Art.19(2) log retention obligations in deployer's AI governance policy and data retention schedule
Key Takeaways
Art.19 creates two parallel retention obligations — provider (Art.19(1)) and deployer (Art.19(2)) — both floored at 6 months but routinely extended by sector-specific Union law. The 6-month floor is not a ceiling: DORA's 5-year requirement for financial entities, the MDR's 10-15 year requirements for healthcare devices, and NIS2's sector-specific requirements all supersede the Art.19 baseline under lex specialis principles.
The Art.12 × Art.19 × Art.72 integration is the key architectural insight. Automatically generated logs are not just compliance artefacts — they are the operational input to the post-market monitoring system, the trigger mechanism for corrective actions under Art.20, and the evidence base for MSA investigations under Art.74. Providers who treat log retention as a storage problem rather than a monitoring capability will find themselves technically compliant with Art.19 while structurally unprepared for Art.72 and Art.74.
For GDPR, the Art.6(1)(c) lawful basis resolves the conflict with storage limitation for the minimum required retention period — but data minimisation obligations still apply at the point of log generation. Log architectures that pseudonymise direct identifiers at the source, and that segment personal data elements from operational event data, satisfy both the AI Act's retention requirements and GDPR's data minimisation obligations more cleanly than blanket retention of raw log data.
See Also: