AI System Document Retention: GDPR and EU AI Act Requirements

GDPR's core principle is clear: minimize data, delete what you don't need, don't keep it longer than necessary. The EU AI Act's message is equally clear: document everything, maintain comprehensive records, keep them available for regulators.

For companies operating AI systems under both regulations, these competing demands create a genuine tension, and they sit on top of the broader friction described in GDPR vs the EU AI Act. This article provides practical strategies for balancing GDPR data minimization with EU AI Act documentation requirements.

The Tension

GDPR Says:

• Data minimization (Art. 5(1)(c)): Process only data that is adequate, relevant, and limited to what is necessary
• Storage limitation (Art. 5(1)(e)): Keep personal data only for as long as necessary for the processing purpose
• Right to erasure (Art. 17): Delete personal data upon request (with exceptions)
• Purpose limitation (Art. 5(1)(b)): Don't repurpose data beyond the original collection purpose

EU AI Act Says:

• Technical documentation (Art. 11): Maintain comprehensive documentation throughout the AI system's lifecycle
• Record keeping (Art. 12): Automatic logging of AI system operations for traceability
• Data governance (Art. 10): Document training data characteristics, collection methods, and quality measures
• Post-market monitoring (Art. 72): Continuous monitoring and documentation of system performance
• Retention period: Documentation must be kept for 10 years after the high-risk AI system is placed on the market, which makes getting the risk classification right the step that sets your whole retention clock

Where the Conflict Gets Real

Training Data Records

The AI Act requires you to document your training data: its sources, characteristics, preparation methods, and bias assessments. If your training data contains personal data, GDPR says you should delete it when it's no longer needed for the original purpose.

The problem: Can you delete the training data but keep the documentation about it? The AI Act requires you to demonstrate data quality and bias mitigation, which may require access to the actual data, not just metadata.

Operational Logs

The AI Act requires automatic logging of AI system operations. These logs may contain personal data such as inputs, decisions made, and user identifiers. GDPR says this personal data should be minimized and deleted when no longer needed.

The problem: How long should you keep operational logs? Long enough for AI Act compliance and regulatory inspection, but not so long that you violate GDPR storage limitation?

Erasure Requests

When an individual exercises their GDPR right to erasure, you must delete their personal data. But if that data appears in AI system logs required by the AI Act, deletion may create gaps in your compliance records.

Practical Strategies

Strategy 1: Separate Documentation from Data

Keep your AI Act documentation (technical specifications, risk assessments, test results) separate from the personal data used to generate them.

• Document training data characteristics (statistical properties, distributions, representativeness) rather than storing the data itself
• Use anonymized or aggregated summaries for bias assessments rather than retaining individual-level data
• Keep model performance metrics and test results without retaining the test data

Strategy 2: Pseudonymize Operational Logs

AI Act logging requirements don't necessarily require identifying individuals. Design your logging to capture the information needed for traceability without personal identifiers.

• Use pseudonymous identifiers in logs, with mapping tables stored separately
• When an erasure request comes in, delete the mapping, and the logs remain useful for AI Act compliance while no longer being personal data
• Log AI system behavior (inputs, outputs, confidence scores) without logging who triggered each interaction

Strategy 3: Define Clear Retention Periods

Create a retention policy that addresses both regulations explicitly. It belongs alongside the data governance work in the five steps to high-risk compliance:

• Training data: Retain for model validation period, then delete personal data while keeping anonymized statistical summaries
• Operational logs (pseudonymized): 10 years (AI Act requirement for high-risk systems)
• Technical documentation: 10 years after system decommissioning
• Bias assessment data: Delete after assessment, retain anonymized results
• User interaction data: Minimum necessary period, pseudonymized for longer retention

Strategy 4: Design for Erasure from Day One

Build your AI systems with GDPR erasure in mind:

• Modular data architecture: Separate personal data from AI system data so erasure doesn't compromise compliance records
• Differential privacy: Train models with differential privacy guarantees so individual data points can't be extracted from the model
• Regular retraining cycles: Schedule periodic model retraining so erasure requests can be incorporated into the next training cycle

Strategy 5: Document Your Balancing Decisions

Whatever approach you take, document your reasoning. When GDPR and the AI Act create genuine tensions, regulators will want to see that you've:

• Identified the specific conflict
• Considered both regulations' requirements
• Chosen the approach that best satisfies both
• Implemented safeguards to minimize any negative impact
• Made the decision with appropriate legal and technical input

A Sample Retention Policy

Here's a template for an AI system retention policy that addresses both GDPR and the AI Act:

• Personal training data: Deleted after model training and validation. Statistical summaries and data quality reports retained for 10 years.
• Model artifacts: Retained for system lifecycle + 10 years. No personal data in model weights (verified through privacy testing).
• Operational logs: Pseudonymized at point of capture. Retained for 10 years. Mapping tables deleted upon erasure request.
• Test and validation records: Anonymized test results retained for 10 years. Raw test data deleted after validation.
• Risk assessments: Retained for 10 years. Updated with each significant system change.
• Incident records: Retained for 10 years. Personal data pseudonymized within 30 days of incident resolution.

The Key Takeaway

GDPR and the AI Act are not irreconcilable, but they do require thoughtful design. The companies that build data architectures with both regulations in mind from the start will find compliance manageable. Those that treat them as separate problems will find themselves stuck between contradictory requirements.

Need help designing a compliant data architecture for your AI systems? Contact us for a consultation.

Frequently asked questions

How long should AI system records actually be kept?

Long enough to satisfy the AI Act's traceability expectations across the system lifetime and after withdrawal, which is measured in years rather than months. The retention period belongs in a written policy per artifact type, because a single blanket rule will either over-retain personal data or under-retain evidence.

Does a deletion request wipe our training records?

Not usually in full. The right to erasure applies to personal data, not to the aggregate artifacts and documentation you are separately obliged to keep. The workable design separates the two from the start so that honouring a request does not destroy your compliance evidence.

What should logs contain to be useful later?

Enough to reconstruct a specific decision: the model version, the inputs as they were at the time, the output, the timestamp, and any human override. Logs that record only the output are the ones that fail an audit, because they cannot answer why the system did what it did.

Can we retain data in aggregate to avoid the conflict?

Often yes, and it is the most useful single technique here. Aggregates, hashes, and pseudonymised records frequently satisfy traceability without holding identifiable data, though the decision has to be made before the data is collected rather than retrofitted afterwards.