--- title: "EU AI Act record-keeping for AI agents" description: "The EU AI Act requires record keeping for high-risk AI systems. What Articles 12, 19 and 26 ask for, and what agent memory must support to answer them." canonical: https://past.dev/guides/eu-ai-act-record-keeping last-updated: 2026-09-02 --- # EU AI Act record-keeping for AI agents Source: https://past.dev/guides/eu-ai-act-record-keeping The EU AI Act sets record keeping duties for high-risk AI systems: Article 12 of Regulation (EU) 2024/1689 requires automatic event logging over the system's lifetime, and Articles 19 and 26 require providers and deployers to keep those logs for at least six months, longer where other law applies. For an AI agent with memory, EU AI Act record keeping in practice means the knowledge state behind an action must be reconstructable, with dates and sources. ## What the AI Act actually requires [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) attaches its record duties to risk classification. High-risk systems must be technically capable of automatic event recording throughout their lifetime (Article 12), providers must keep the generated logs they control for at least six months (Article 19), and deployers keep the logs they control for at least six months as well (Article 26), in each case longer where Union or national law requires. Whether a given agent is high-risk depends on its use, and that classification is the operator's analysis to make, with counsel. This page covers what the duties mean for memory design once they apply. ## Event logs alone do not reconstruct behavior The purpose written into the record duties is traceability: authorities and operators must be able to work out how the system behaved. A request log shows what the agent was asked and what it did. It does not show why, because the why lives in the information the agent held at that moment. Two identical requests a month apart can produce different actions from the same model for one reason: the memory changed in between. Reconstruction therefore needs the memory side of the record: which facts were current at the time of the event, from which sources, and with what dates. That is the same requirement an [audit trail](/guides/ai-audit-trail) has, made a legal duty for the deployments the Act covers. ## Memory design that supports reconstruction - **Event time on every fact**, from the source's own timestamp, so the timeline reflects the world rather than the import schedule. See [event time vs ingestion time](/guides/event-time-vs-ingestion-time). - **Validity windows and supersession**, so the facts current on any past date are a query rather than an investigation. See [facts that change over time](/guides/facts-that-change-over-time). - **Provenance on every fact**, so each item in a reconstruction points at the record that supports it. See [data provenance](/guides/data-provenance). - **Explicit status values on recall**, so the record distinguishes an answer the evidence supported from a conflict or an absence of support. With these properties, the loggable unit is the recall response the agent acted on: ranked evidence, dates, sources, and one of the four status values. Storing that response per consequential action gives the event log its missing half. ## Practical steps 1. Determine with counsel whether and where the system is high-risk; the record duties follow the classification. 2. Log the recall evidence and status value alongside each consequential action the agent takes. 3. Keep superseded facts: reconstruction needs the values that were current then, and deletion-on-update destroys them. 4. Align the retention horizon of these logs with the at-least-six-months floor and any longer applicable requirement, inside the general [retention policy](/guides/ai-data-retention). 5. Reconcile the records with erasure duties: the operational record keeps that events and erasures happened, while [erased content](/guides/gdpr-memory-deletion) itself is removed. 6. Test point-in-time reconstruction on a schedule, the same drill an audit would run. ## Where past.dev fits past.dev stores facts with event time, validity windows, supersession links and sources, and [recall](/docs/memory-api/quickstart) returns dated evidence with an explicit status, so the knowledge state behind an action is reconstructable by design. Self-hosted deployments keep the memory in the customer's own Postgres, which keeps the generated records under the deployer's control; see [self-hosting](/docs/memory-api/self-hosting). past.dev holds SOC 2 Type II, ISO 27001 and ISO 27701 certifications, and recall behavior on changing and unsupported facts is documented on the [benchmarks](/benchmarks) page. ## Frequently asked questions ### Does the EU AI Act apply to AI agents with memory? It applies by risk classification of the system's use case rather than by the presence of memory. If the deployment is high-risk, the record-keeping duties apply, and memory design determines whether they can be met. ### How long must logs be kept under the EU AI Act? Providers and deployers of high-risk systems must keep the logs under their control for at least six months, and longer where other Union or national law requires it. ### Can record-keeping and GDPR erasure coexist? Yes. Erasure removes personal content and what only it supported, while the operational record keeps that the events and the erasure occurred. The retention policy states the horizon for each record class. ## Related - [Audit trail for AI agent decisions](https://past.dev/guides/ai-audit-trail) - [Data retention policies for AI memory](https://past.dev/guides/ai-data-retention) - [How to handle facts that change over time](https://past.dev/guides/facts-that-change-over-time) - [Data provenance for AI agents](https://past.dev/guides/data-provenance) - [Self-hosting](https://past.dev/docs/memory-api/self-hosting)