Three instruments answer this question, and they do not agree. The EU AI Act sets a floor of six months for the logs of high-risk systems. DORA, for financial entities, names no figure and lands at five years in supervisory practice. The GDPR names no figure either, for the opposite reason: it obliges you to delete. Which rule governs depends on who you are and what is inside the log.
6 months. The EU AI Act floor for high-risk decision logs, held by provider and deployer alike [1].
5 years. The DORA working figure, set by practice rather than by the regulation [3].
No longer than necessary. The GDPR's answer, which is an instruction to delete [5].
The short answer
| Regime | Who it binds | What must be kept | How long |
|---|---|---|---|
| EU AI Act, Regulation (EU) 2024/1689 | Providers and deployers of high-risk AI systems | Automatically generated event logs | At least six months (Articles 19 and 26(6)); technical documentation for ten years (Article 18) |
| DORA, Regulation (EU) 2022/2554 | Financial entities and their ICT chains | ICT incident records, audit trails, supporting telemetry | No fixed figure in the regulation; the technical standards say no longer than necessary, commensurate with criticality; sector practice has settled on around five years |
| GDPR, Regulation (EU) 2016/679 | Controllers and processors of personal data | Nothing, by default | No longer than necessary for the purpose (Article 5(1)(e)); no fixed period |
A worked example: the declined loan
Take a bank whose AI model declines a loan application. Credit scoring is an Annex III use, so from 2 December 2027 the bank must hold the decision logs under its control for at least six months, folded into its financial services documentation rather than kept as a separate pile [1]. If the scoring engine then fails in a way that disrupts service, DORA's clocks start: notification within four hours of classification, and the incident evidence retained on the five-year working figure [3]. The applicant's personal data inside the log is a different matter: once the decision, any appeal window and any complaint have run their course, the GDPR expects the identifiable record to fall away, while the anonymised trail of what the model did, and who reviewed it, persists [5].
The EU AI Act: six months as the floor
The Act splits the logging duty in two. Article 12 is the design duty: a high-risk system must be technically capable of recording events automatically across its lifecycle. Articles 19 and 26(6) are the retention duties: providers keep the logs under their control, deployers keep the logs under theirs, in each case "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data" [1]. Both halves of that sentence matter: sector law can lengthen the period, and data protection law can reshape it. Financial institutions keep no separate AI pile at all; they hold the logs inside the documentation kept under Union financial services law, which is where DORA takes over [1].
Two adjacent numbers belong in the same file. Under Article 18 the technical documentation, quality management records and conformity declarations sit on a ten-year clock, running from when the system is placed on the market [1]. And the calendar has moved: the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, deferred the Annex III high-risk regime from 2 August 2026 to 2 December 2027, with AI embedded in regulated products following on 2 August 2028 [2]. The six-month duty therefore bites from December 2027 for stand-alone high-risk systems, but logging capability is a design decision taken now, not in 2027. Breaches of the record-keeping duties fall in the penalty tier carrying up to €15 million or 3 per cent of worldwide annual turnover [1].
DORA: no number, five years in practice
DORA has applied since 17 January 2025, and it never names a retention period for logs. What it requires, through its regulatory technical standards, is an incident policy that retains all evidence relating to ICT incidents "for a period no longer than necessary for the purposes for which the data is collected", commensurate with the criticality of the affected functions [3]. The reporting clocks do the real work: an initial notification within four hours of classification and no later than twenty-four hours from awareness, an intermediate report within 72 hours, a final report within one month. An entity cannot meet those deadlines, or answer a supervisor's questions two examination cycles later, from a ninety-day log buffer. Five years or more is the widely adopted working figure for incident records and audit trails, set by practice rather than by the regulation, with the most recent twelve to twenty-four months searchable in minutes [3].
For a bank or insurer running AI in credit scoring or life-insurance pricing, both Annex III uses, the two regimes compound: the AI Act folds its log retention into the financial services documentation, so DORA-grade retention becomes the effective AI log period [1].
The penalty structure differs from the other two regimes. Article 50 leaves the ceilings to the member states, whose national caps run from €2 million to €20 million or 5 to 10 per cent of turnover depending on jurisdiction [4]. The one figure in the regulation itself attaches to designated critical ICT third-party providers, not to financial entities: a periodic penalty payment of 1 per cent of average daily worldwide turnover, charged daily for up to six months [4].
The GDPR: the obligation runs the other way
The GDPR never tells you how long to keep anything. Article 5(1)(e) requires personal data to be kept in identifiable form "no longer than is necessary for the purposes for which the personal data are processed" [5]. A decision log about a person, a declined loan, a screened-out CV, a flagged transaction, is personal data. Holding it for six months because the AI Act sets that floor is lawful while the purpose stands and the record stays necessary; holding it for ten years "for the audit" fails the same test. Over-retention is an enforceable breach, with fines running to 4 per cent of global turnover [5].
The resolution: split the record

The way to satisfy all three regimes at once is to stop treating the log as a single object. Keep the decision event, timestamp, model version, input class, output and human reviewer, in an anonymised or pseudonymised audit trail on the longest applicable clock. Let the identifiable payload fall away on the shortest defensible one, against a documented schedule with a named trigger event and a deletion mechanism you can demonstrate. Article 89 permits longer archiving for statistical and research purposes under safeguards; anonymisation that withstands reasonably likely means of re-identification takes the data outside the GDPR altogether [5].
Then write the schedule down: one line per system, with the legal basis, the period, the trigger and the mechanism. Six months is the statutory floor for high-risk AI, five years is the working number for financial entities, and the personal data inside either falls away as soon as its purpose ends. The schedule is the small cousin of the dependency register proposed in A UK Digital Sovereignty Act: a named owner, a stated basis, a document you can produce. When the supervisor or the commissioner asks, that document is the answer.
Notes and sources
- Regulation (EU) 2024/1689, the EU AI Act: Articles 12, 18, 19, 26 and 99.
- Regulation (EU) 2026/1744, the Digital Omnibus on AI, published 24 July 2026 and in force 27 July 2026.
- Regulation (EU) 2022/2554, DORA, applicable since 17 January 2025; EY, "DORA RTS: what are the upcoming requirements regarding the digital operational resilience of financial entities?", 31 July 2024, on the incident-evidence retention clause in the technical standards.
- DLA Piper, "DORA Penalty Regimes: Overview of Divergence Among Member States", 5 November 2025.
- Regulation (EU) 2016/679, the GDPR: Articles 5(1)(e) and 89(1), and Recital 26 on anonymisation.