On 27 July 2026, Regulation (EU) 2026/1744 — the Digital Omnibus on AI — entered into force and moved one date. The duty to keep at least six months of automatically generated logs from a high-risk AI system had been due to bite on 2 August 2026. It now applies from 2 December 2027 for stand-alone systems under Annex III, and 2 August 2028 for systems embedded in products under Annex I. Sixteen months of extra runway on the stand-alone track, granted because, in the amending regulation's own words, delayed standards, common specifications, guidance and national authorities "risk a significant increase in implementation costs in a way that does not justify maintaining their initial date of application."

Nothing moved on the other side of the ledger. The personal data sitting in agent traces today is governed by the same storage-limitation principle and the same right to erasure as in July. The deferral bought a collection window, not an exemption, and the trace store has been filling the whole time.

AI agent log retention is the set of decisions about what an agent's execution telemetry records, where it is stored, and how long it survives. It is distinct from log capture, an instrumentation question, and from log access, an authorisation question. Retention is the one that turns an engineering default into a data-protection position, because the obligation attached to a record depends on what that record contains.

What the statute actually asks for

Article 12(1) of the AI Act requires that high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 19(1) puts the keeping duty on providers; Article 26(6) puts the same duty on deployers — the role most enterprises occupy when they run an agent they did not build. Both are drafted in near-identical terms on the part that matters. In Article 19(1)’s wording, the logs

"shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data."

Read the subordinate clause twice, because it carries the architecture of the whole thing. The Act does not override data-protection law in order to get its traceability. It defers to it. There is no statutory instruction to keep personal data for six months, and never was. There is an instruction to keep a record for six months, with an explicit carve-out where privacy law says otherwise.

So the deadline moving to December 2027 changed the easy half — switching logging on — and left the hard half where it was. The hard half is deciding what goes into the log, because that is what makes a six-month floor trivial or a liability: whether the thing you keep is a decision record or a second copy of your customers' data.

Why the deferral is a collection window

An agent trace is among the richest artefacts in the stack, by design: teams instrument agents to answer why did it do that, and answering it requires the prompt, the tool arguments, the retrieved context and the result. Any of those fields can carry personal data, and a trace has no schema marking which ones do.

The industry's own documentation is direct about it. Arize's guidance on masking and redacting trace data opens with the problem stated plainly: "Keep real user data out of your traces. Your traces carry messages, prompts, and responses — anything sensitive in them follows into Arize AX." The mechanism it documents is the OpenInference specification's set of masking switches — OPENINFERENCE_HIDE_INPUTS, OPENINFERENCE_HIDE_PROMPTS, OPENINFERENCE_HIDE_OUTPUT_MESSAGES, OPENINFERENCE_HIDE_EMBEDDING_VECTORS and the rest. Each of the eleven hide-switches in that table is documented with a default of False.

That is the right default for an observability standard, not a flaw in it: a tracer that hides inputs by default is a tracer nobody can debug with. It does mean the privacy posture of your telemetry is a property of your instrumentation code, not of your vendor's certifications. The same guidance walks through the finer-grained option — a custom span processor that scrubs emails, phone numbers, social security numbers, card numbers, IP addresses and dates of birth by regex, or hands off to Microsoft Presidio for the entities regex cannot catch. That processor, in Arize's words, "runs in your application — sensitive data never leaves your infrastructure."

Arize's trust centre states the division of labour in one sentence: "Our customers are responsible for the content of the data they ingest into the Arize AI Platform and their company's appropriate access, compliance, and usage." On that division, the content of a span sits on the customer's side of the line — the correct place for it, and also the place where it gets decided once at instrumentation time and never revisited.

Practitioners circle this without quite naming it. On a Hacker News thread about an agent framework that queries production systems, a developer asked how teams "handle PII or other sensitive data that the LLM shouldn't know or care about." The first reply reframed it as an ordinary permissions problem: add filters so the caller reads only what they are entitled to. That is right about the read path and silent about the write path. Authorising a query does not govern the copy it leaves behind in a span.

Two records, two lifetimes

The structural error here is conflation, not negligence. Telemetry gets asked two questions, and they want different artefacts.

The traceability question is which agent did what, on whose behalf, under which policy, when. It needs an actor, a target, a decision, the rule that produced it, and a timestamp — almost none of which is personal data beyond the identity of the operator, and identity is the field you are least likely to want deleted, because it is what makes the record evidence.

The diagnostic question is why did it produce that output. It needs the payload: prompt, arguments, retrieved chunks, response. Almost all of the personal data lives here, and almost none of it is needed six months later.

Collapse both into one trace stream and each obligation makes the other harder. The record you must keep for six months becomes the record you must minimise, so every retention setting is a compromise between a compliance floor and a privacy ceiling. And erasure stops being a targeted delete: instead of removing a row, you are searching an append-only span store for one person's appearances across arbitrary free-text fields, in traces never designed to be queried that way.

Retention is also commonly priced as a product tier rather than set as a policy. Waxell's own published pricing is a fair illustration: data retention runs 14 days on Free, 30 on Team, 90 on Business and 365 or more on Enterprise. Six months is roughly 180 days. A statutory floor expressed in months and a retention allowance sold as a plan feature are not the same kind of object, and reconciling them is an architecture question before it is a procurement one.

Separating the two records is what resolves it. A decision record with no payload in it can be kept for years without accumulating privacy exposure, because there is nothing in it to erase. A payload-rich trace can then be aged out aggressively without weakening the compliance artefact, because the compliance artefact lives somewhere else.

How Waxell handles this

Waxell MCP Gateway is built on that separation, and its product page says so in terms. Every tools/call the gateway brokered is stored in the audit log "with the resolved identity, the decision, and the rules that fired," described as "durable for years" and exportable to CSV, with "no payloads stored." The page spells out the consequence: the log "records what happened (who called what tool, what decision applied, which rules fired, when) without retaining the argument values or result bodies that passed through. Sensitive content is handled by the redaction pipeline. The compliance artifact proves what happened without holding the data that did."

That is a traceability record built to outlive the incident it documents, holding none of the payload data an erasure request targets.

The payload is handled earlier, at the gate rather than in the store. Each call is evaluated before dispatch and its result again on the way back, and the documented policy actions include redact_args and redact_result, which strip named keys from arguments or results; dlp_scan_args and dlp_scan_result, which run DLP scanners for PII and credentials and record the findings; and dlp_block_args and dlp_block_result, which block the call when a scanner hits. The scanning actions observe and record; the blocking actions stop the call — a distinction worth keeping straight, because a scanner that records a finding has not prevented anything. Where several rules match, precedence is fixed — deny beats require-approval, which beats redaction, which beats allow — and the documentation states that every decision, including a redaction and the rule that fired, is recorded in the audit log.

Two scope limits are worth stating rather than discovering. The gateway governs the calls that traverse it, so an agent holding its own upstream credentials, or a locally registered MCP server, sits outside that boundary until it is routed through. And the audit log is the tool-call record; the richer execution traces that answer why an agent decided something live on the Waxell Observe trace surface, and that is the record whose retention window you want short. Where neither record may leave the network, the same gateway image runs single-tenant inside a customer VPC, with policy decisions, credential storage and audit data staying inside it.

FAQ

Does the AI Act require me to keep personal data for six months?

The text does not say that. Articles 19(1) and 26(6) require logs to be kept for at least six months, and both qualify it with "unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data." The duty attaches to the record, not to any particular content in it. If your log is a decision record rather than a payload archive, the six-month floor and data minimisation stop competing.

When do these obligations apply now?

Regulation (EU) 2026/1744 set the application date for Sections 1, 2 and 3 of Chapter III of the AI Act — where Articles 12, 19 and 26 sit — to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028 for those classified under Article 6(1) and Annex I. The Omnibus itself entered into force on 27 July 2026. It moved the dates; it did not change the six-month figure or the wording of the keeping duty.

My agents are not a high-risk AI system. Does this matter?

The logging articles may not bind you, but the data-protection position does not depend on the AI Act. If your traces contain personal data, storage limitation and erasure already apply to them, independently of any risk classification. The AI Act date is a forcing function for a decision you already own.

Can I just turn off input and output capture?

You can, and for some services that is the right answer. The cost is diagnostic: a trace with hidden inputs and outputs tells you that a step ran and how long it took, and little about why. The more sustainable pattern is to decide per field rather than per switch — mask or redact the payload at instrumentation time, and keep a separate, payload-free record of the decisions, so turning capture down does not also destroy the audit trail.

How does an erasure request reach a trace store?

That is the question worth answering before the request arrives. Payload-bearing spans are free text, so finding one person's appearances is a search problem rather than a lookup, and the result is rarely provably exhaustive. Two mitigations are structural rather than procedural: keep the retention window on payload-bearing telemetry short enough that most data has already aged out, and keep personal data out of the long-lived record so there is nothing there to find.

Sources

• European Parliament and Council, "Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 12, 19, 26 and 113", OJ L, 12 July 2024

• European Parliament and Council, "Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI)", OJ L, 2026/1744, 24 July 2026

• European Commission, "AI Omnibus enters into force", Shaping Europe's Digital Future, updated 31 July 2026

• Council of the European Union, "Artificial Intelligence: Council and Parliament agree to simplify and streamline rules", press release, 7 May 2026, updated 18 May 2026

• European Parliament and Council, "Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 5 and 17", consolidated text

• Arize AI, "Mask and Redact Sensitive Data", Arize AX documentation

• Arize AI, "Arize Trust Center"

• Hacker News, "How do you handle PII or other sensitive data", comment thread on Show HN: EnrichMCP, 19 June 2025

• Waxell, "MCP Gateway — Governed AI Tool Access"

• Waxell, "Policies & Approvals", Waxell documentation

• Waxell, "Pricing", Waxell documentation

The deferral bought sixteen months before anyone asks how long you keep agent logs. It bought none before someone asks what is in them.

Put the durable record where there is nothing to erase — book a 30-minute demo of the Waxell MCP Gateway.