Scope
This guide outlines the technical and procedural requirements for managing AI system logs that may serve as evidence in litigation, audits, or investigations. It focuses on logging architecture, retention design, authentication requirements, and the gap between deferred regulatory obligations and immediate evidentiary needs.
You'll need this guide when:
- Designing logging infrastructure for AI systems that make decisions or take actions
- Responding to preservation requests that include AI-generated records
- Preparing for audits where AI conduct is under scrutiny
- Evaluating vendor systems for evidentiary adequacy
This guide does not cover general application logging or non-AI telemetry systems.
Key Concepts and Definitions
Automatic event logging: Continuous capture of AI system inputs, decisions, and outputs over the system's operational lifetime. Under EU AI Act Article 12, this becomes mandatory for high-risk systems on December 2, 2027 (Annex III systems) and August 2, 2028 (systems embedded in regulated products).
Retention floor: The minimum period logs must remain accessible. Article 26(6) of the AI Act sets a six-month baseline, though litigation holds and Records Control Schedules may impose longer periods.
Authentication: The process of establishing that a log accurately reflects what the system did at a specific time. Under Federal Rule of Evidence 901(b)(9), this requires showing the process or system produces an accurate result.
Observability: An engineering practice focused on real-time system monitoring and debugging, distinct from evidentiary logging, which prioritizes long-term retention and authentication.
Model version metadata: Information identifying which version of an AI model produced a given output. Unversioned output cannot be authenticated because you can't establish what system actually ran.
Requirements Breakdown
Logging Architecture
Your logging system must capture:
- Inputs: Complete prompts, queries, or instructions the system received
- Model state: Version identifiers, configuration parameters, and any fine-tuning applied
- Retrieval context: For retrieval-augmented systems, which documents or data the system accessed
- Outputs: The system's decisions, recommendations, or generated content
- Timestamps: When each event occurred, with sufficient precision to reconstruct sequences
- User context: Who initiated the action or approved the output
ISO/IEC 24970, which entered its final draft ballot on August 28, 2026, will standardize these requirements. Implement them now rather than waiting for publication.
Retention Design
Set retention periods based on:
- Regulatory floors: Six months under Article 26(6) for EU AI Act-covered systems
- Litigation risk: Consider your industry's typical discovery window
- Audit cycles: How far back regulators typically look in your sector
- Records Control Schedule: Align AI logs with retention rules for the business function they support
The EU AI Act's logging obligations don't take effect until December 2027 and August 2028, but preservation requests and audit demands operate on their own calendar. A deferred regulation is not a deferred question.
Authentication Requirements
To meet Rule 901(b)(9) authentication standards:
- Implement fixity checks (cryptographic hashes) at log creation
- Maintain an unbroken chain of custody from generation to production
- Document your logging process in writing
- Version your logging infrastructure and track changes
- Store logs in immutable or append-only systems where feasible
Consider a security team that captures agent decisions but stores them in a mutable database with no version control. Months later, during discovery, opposing counsel asks: how do you know this log reflects what actually happened? Without fixity and versioning, you can't answer.
Implementation Guidance
Start with Instrumentation Decisions
Logging is authorship. What you choose to capture, how you label it, and what you discard shapes the story the record will tell. Ask:
- Which agent actions create legal or compliance risk?
- What evidence would exonerate you if challenged?
- What context would you need to reconstruct a disputed decision?
Write these requirements before you write code.
Separate Observability from Evidence
Your real-time monitoring dashboard and your evidentiary log serve different purposes. Observability tools prioritize recent data and may sample or aggregate to manage volume. Evidence requires completeness and immutability. Run both, but don't confuse them.
Address Retrieval-Augmented Systems
When your AI agent searches internal documents before answering, the retrieval step often disappears first. It's expensive to log, and engineering teams treat it as intermediate state. But in discovery, which documents the system accessed can matter as much as what it said. Capture retrieval events separately and retain them under the same schedule as outputs.
Plan for Vendor Opacity
If you're deploying a vendor's AI system, your procurement contract determines what logs you'll have access to later. Before you sign:
- Require logging capabilities that meet your evidentiary standards
- Specify retention periods in the agreement
- Confirm you can export logs in a structured, authenticated format
- Establish who owns the logs and under what conditions you can access them
Vendor opacity is a choice you make at procurement, not a condition you inherit.
Test Authentication Before You Need It
Run a mock authentication exercise. Pull a log from six months ago and ask: can you establish this output came from the system you say it did, running the model version you claim, at the time you specify? If you can't answer with documentation and technical proof, your logging infrastructure isn't ready.
Common Pitfalls
Treating prompts as ephemeral: Multiple 2025 and 2026 orders, including in Concord Music Group v. Anthropic and Conservation Law Foundation v. Shell Oil Co., have treated prompts as discoverable inputs. Don't discard them.
Assuming machine output isn't hearsay: While Rule 801(a) requires a "person" for hearsay, proposed Rule 707 would address machine-generated statements. The comfort is smaller than it sounds.
Delegating without documenting: If your AI agent acts with delegated authority, document the scope of that delegation and the human oversight in place. Moffatt v. Air Canada declined to treat a chatbot as separate from the company that ran it.
Ignoring the multi-agent problem: When several agents contribute to one decision, responsibility diffuses unless you've designed accountability in from the start. Log which agent did what.
Waiting for regulatory deadlines: The AI Act's Chapter III obligations are deferred to 2027 and 2028, but litigation and audits don't wait. Build logging infrastructure now.
Quick Reference Table
| Requirement | Standard/Rule | Timeline | Action |
|---|---|---|---|
| Automatic event logging | EU AI Act Article 12 | Dec 2, 2027 (Annex III); Aug 2, 2028 (regulated products) | Implement now; don't wait for deadline |
| Retention floor | EU AI Act Article 26(6) | Aug 2, 2028 | Set minimum six months; align with Records Control Schedule |
| Authentication | Fed. R. Evid. 901(b)(9) | Immediate | Document process; implement fixity checks |
| Logging standard | ISO/IEC 24970 | Final draft ballot Aug 28, 2026 | Monitor for publication; align architecture |
| Prompt preservation | Concord Music, Conservation Law Foundation | Immediate | Treat prompts as discoverable inputs |
| Model versioning | Lorraine v. Markel | Immediate | Version all models; capture in logs |
Your logging architecture is the first draft of your defense. Design it with that in mind.
