Blog/Evidence

A request log is not evidence

14 July 20267 min readObstruo team
EvidenceAuditCompliance

Every gateway writes logs. Almost none of them answer the question an auditor asks eleven months later.

Ask a platform team whether they have an audit trail for AI usage and the answer is usually yes. There is a log. It has timestamps, model names, token counts, status codes, maybe a latency histogram. It is a good log.

Then an auditor asks whether personal data was minimised on requests from EU users on 14 March, which rule was in force at the time, and who approved the model that answered. The log cannot answer any of the three, because it was built to debug an outage, not to defend a decision.

The deadline moved. The question did not.

On 27 July 2026, Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force, three days after publication in the Official Journal. It pushes the AI Act's high-risk obligations, record-keeping among them, from 2 August 2026 to 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for AI embedded in regulated products. After nine months of provisional agreements, those are now dates in law.

If your record-keeping programme was aimed at next Sunday, you just got sixteen months back. Almost nothing else about the problem changed.

  • Article 50 transparency still applies on 2 August 2026, five days from now. Two of its exemptions are claims about a workflow rather than about an output: text published on matters of public interest escapes labelling only where a qualified person examined the substance and someone holds editorial responsibility. That is a fact about last March that you either recorded or did not.
  • GDPR has required you to demonstrate compliance, not merely achieve it, since 2018.
  • Your customers' security reviews did not move to December 2027.
  • And the eleven-month question does not care which statute prompted it.

The extension is runway, not relief. It is the difference between building an evidence layer deliberately and retrofitting one during a deal.

Observability and evidence are different design goals

ObservabilityEvidence
Optimises forthe recent pastthe distant past
Retentiontwo weeks is generoussix months is a statutory floor, not an answer
Volumehigh, cheap writeslow, expensive writes
Mutabilityfine, nobody litigates a p95 chartabsence of edits must be demonstrable
Audiencethe team that built the systemsomeone who does not trust the system that produced the answer
Question answeredwhat brokewhat was required, and what we did about it

A good log fails at evidence in five specific places:

Which rule was in force. A log records what happened, not what was required at the time.

What was removed before it left. Payloads are stored raw or not at all, rarely as category counts.

What the agent actually did. One line per HTTP call, not the model turns and tool calls as a single chain.

Whether anyone edited history. Anyone with store access can, and nothing shows it.

Who approved this model or tool. That lives in a ticket in another system.

What the AI Act actually asks for, and where it stops

Worth reading the record-keeping provisions closely, because their shape explains why so many teams believe they already comply.

Article 12 is the design-time duty on providers of high-risk systems: the system has to be technically capable of automatic logging across its lifecycle. Article 12(2) gives three purposes rather than a schema: identifying situations that present a risk or a substantial modification, supporting post-market monitoring, and supporting the deployer's operational monitoring.

Articles 19 and 26(6) are the runtime duties. Providers and deployers keep the automatically generated logs under their control for a period appropriate to the intended purpose of the system and at least six months, unless other Union or national law says otherwise, in particular data protection law. Financial institutions fold these into the documentation they already maintain under financial services law.

Three things follow that teams routinely miss.

The Act prescribes purposes, not fields. Outside a narrow category of biometric systems, where minimum log contents are spelled out, there is no schema to fail against. "We have logs" is not falsifiable against the text. That is comfortable right up to the moment a specific question arrives.

Six months is a floor, not a target. The wording is "appropriate to the intended purpose", and a system whose decisions have long-lived effects, a credit model or a hiring tool, needs a window that matches the life of the decision, not the life of the debugging session.

Buying the system does not move the duty. Deployers hold their own retention obligation for logs under their control, whoever built the model.

The retention trap, and the way out of it

Retention pulls in two directions at once. The AI Act sets a floor of six months. GDPR's storage limitation and minimisation principles push the other way, and the AI Act text itself defers to data protection law where the two collide.

Teams resolve this badly in both directions. Some keep raw payloads for a year and create a personal data store with a compliance label on it. Others keep nothing and have no answer in month eleven.

The way out is to design the record so it does not contain the data it describes. A record that says three national identifiers and one IBAN removed under policy version 4.2, request from a German user, decision: redacted and forwarded is evidence. It is also, deliberately, not a copy of the identifiers. It can be retained for years without becoming a liability, because the sensitive material never entered it.

That single design choice is what makes long retention affordable, and long retention is what makes the record worth having.

What an evidence record has to carry

  • The policy version, pinned to the request rather than looked up later.
  • The redaction outcome as categories and counts, so the record is useful without holding the personal data it describes.
  • The decision itself: allowed, redacted, blocked, held for a human.
  • The identity context: which project, which jurisdiction, which principal. Retrofitting this is the expensive part, because it has to be propagated, not inferred.
  • The approval that made the model or tool available, linked to the record it enabled.
  • The agent chain as one object, so a multi-step run reads as a decision rather than as seven unrelated calls.
  • An append-only structure, so the absence of edits is demonstrable rather than asserted.
  • A retention window set by the life of the decision, with six months as the floor rather than the plan.

None of this is exotic. It is a different retention policy, a different write path, and a decision to treat the record as a product surface instead of a debugging byproduct.

The eleven-month test

Pick a date eleven months ago. From your current logs alone, reconstruct what policy applied to a single request, what it removed, and who authorised the model that answered it.

If you cannot, you have observability. That is not an insult; observability is the harder engineering problem and the one that keeps the service up. It is simply a different artefact, and no amount of retention turns one into the other.

Run the test before someone else does. There is a longer version of it in the companion checklist, including what a passing answer looks like.

The practical benefit is not the audit

Teams expect this to pay off during certification. It does, and under the AI Act it eventually pays off in a harder setting, since the records are what a deployer hands to a competent authority during a serious-incident review.

But the bigger return arrives much earlier: at the security review at the start of a deal. Answering with a record instead of a promise shortens the review, because the reviewer stops testing your intentions and starts reading your data.

That asymmetry is the real argument for building this now rather than in late 2027. The regulator's deadline moved. The buyer's did not.

This is an engineering perspective on record design, not legal advice. Whether the high-risk record-keeping provisions apply to a given system turns on its classification, and retention periods interact with sector rules and data protection law.

Sources

Companion checklistThe eleven-month testOpen the checklist