When the Regulator Calls: Why You Can't Reconstruct What Your Agent Did

March 15. Your AI agent processed a batch of loan applications. One of them, a small business owner in Frankfurt, was rejected.

June 3. The applicant files a complaint with their national data protection authority. BaFin opens a formal inquiry. They give you 30 days to produce evidence.

The question they ask is simple: "What information did your AI system use to make the decision on March 15, and what safeguards were in place?"

Your engineering team starts pulling records. What they find looks like this:

• Application logs show an API call at 14:37 CET
• The agent returned status REJECT with a confidence score
• The model version in the config file is claude-opus-4-6
• The context window for that session: gone, rotated at 30 days
• The retrieval chunks your RAG system used: overwritten
• The intermediate reasoning steps: never logged
• The tool calls the agent made to external scoring APIs: timestamps only, no payloads

You have logs showing that a decision happened. You cannot prove what the agent actually processed.

This is the retroactive evidence problem. It is not a theoretical risk. EU AI Act enforcement has been live since August 2025, and the first audit cycles are producing exactly this gap.

Why Logs Are the Wrong Tool for Audit Evidence

The distinction matters technically, and it matters legally.

Logs are operational monitoring artifacts. They record events at the infrastructure layer: API calls, errors, latency, status codes. They answer the question "did the system behave normally?" for on-call engineers who need to diagnose incidents in real time.

Audit evidence is different. It must answer: "What did this agent know when it made this decision?" That requires:

• The exact input context passed to the model
• Which retrieval chunks were assembled and why
• What tools were called, with what parameters, and what they returned
• Which model version processed the request
• What the agent's reasoning path was
• A timestamp that cannot be retroactively altered

Infrastructure logs provide none of that by default. Log pipelines are designed for volume and recency. They aggregate, sample, and rotate. By the time an audit investigation begins, the execution-level detail has been discarded.

This is not a logging configuration problem. It is a fundamental architectural mismatch between what logs are built to capture and what forensic compliance requires.

The Context Window Problem

Even if you log everything, there's a harder problem: context is ephemeral by design.

A modern RAG pipeline assembles context at inference time. It retrieves relevant chunks from a vector store, formats them with the query, injects system instructions, and passes the assembled context to the model. The assembled context, exactly what the model saw, exists for milliseconds before being consumed.

Six months later, when an auditor asks "what did your agent know about this applicant when it made this decision?", that assembled context is gone. The vector store may have been updated. The retrieval algorithm may have changed. The ranking weights are different. Even if you reconstruct the query, you cannot reproduce the exact chunks that were retrieved in March.

This matters because EU AI Act Article 13 requires systems to provide "adequate information" about automated decisions that significantly affect individuals. Information about an automated decision requires information about what drove it. The assembled context is the direct evidence of what the model was told.

You cannot reproduce it retroactively. You can only capture it prospectively.

Model Drift Makes Reconstruction Impossible

Assume you kept perfect logs. Assume you can reproduce the query and the retrieval context exactly. You still face a harder problem: the model you run today is not the model that ran in March.

Claude Opus 4.6 received updates between March and June. The API returns the same model identifier, but the model weights have changed. The outputs for identical inputs are different.

When an auditor asks you to demonstrate the agent's behavior for a given input, you cannot run the demonstration on the current model and call it representative of March's behavior. You'd need:

• The exact model snapshot that ran on March 15
• The exact context window contents
• Proof that both are unaltered since execution time

None of these are available by default. Cloud providers version models by release name, not by snapshot. You cannot retrieve "Claude Opus 4.6 as it existed on March 15." Once a model is updated, the prior state is not recoverable.

This is why forensic compliance requires execution-time proof, not post-hoc reconstruction. The execution record must be created when the execution happens, sealed cryptographically so it cannot be altered, and stored independent of the infrastructure that generated it.

What EU AI Act Article 12 Actually Requires

Article 12 specifies that high-risk AI systems must have logging capabilities that:

"allow for the monitoring of the operation of the high-risk AI system with a view to detecting significant risks to health, safety or fundamental rights"

And that logs must be kept for a period appropriate to the intended purpose, with a minimum of six months for general purpose systems.

The phrase "detecting significant risks" is often read as operational monitoring. But under regulatory interpretation, it extends to retrospective forensic capability: can you investigate what happened, in what context, when a risk materialized?

The six-month retention requirement is a minimum. Audits typically open months after the incident and require evidence going back further. Many financial and healthcare applications face 7-year retention requirements under sector-specific regulation.

Retaining logs for six months is not the same as retaining execution-level evidence for six months. Infrastructure logs satisfy the letter of Article 12. Forensic compliance (the ability to answer specific questions about a specific decision) requires execution-state records that current systems don't produce.

The Forward-Looking Compliance Gap

The failure mode is not that teams are unaware of the requirements. Most compliance teams have read Article 12. Many have invested in log aggregation platforms, retention policies, and compliance dashboards.

The gap is structural: these investments capture operational monitoring data, not execution evidence. They're the right tool for incident response. They're the wrong tool for forensic audit.

When an EU AI Act enforcement action opens against your system, the auditor is not asking about your monitoring infrastructure. They're asking about a specific decision made by a specific agent instance at a specific timestamp. Can you reconstruct exactly what that agent processed?

If the answer requires your engineering team to manually assemble fragments from log files, Splunk queries, database backups, and model changelogs, that reconstruction is not evidence. It's a narrative. Narratives are disputable. Cryptographic proofs are not.

The only approach that works for forensic compliance is prospective: capturing execution evidence at the moment of execution, sealing it against alteration, and making it retrievable independent of the infrastructure that processed the request.

Regulatory audits are retrospective by nature. The EU AI Act enforcement timeline is creating its first wave of these inquiries now. The compliance gap that surfaces most consistently is not governance documentation or risk management procedures. It's the inability to prove what agents actually did when specific decisions were made.

Architecture built for operational monitoring cannot be retrofit for forensic evidence after the fact. The moment to close this gap is before the inquiry, not during it.

arkforge.tech/en/pricing -- Trust Layer captures cryptographic execution records at inference time, independent of your infrastructure stack.