AI Audit Trails: What You Need
to Log and Why Regulators
Are Checking

From 2022 to 2025 the SEC fined financial firms more than a billion dollars for not what they said, but for not keeping the record of having said it. That enforcement logic is coming for AI. The EU AI Act makes automatic logging a legal requirement for high risk systems, and a chat transcript is not an audit trail. Here is what a defensible one actually looks like.

$81M
paid by 16 firms in a single SEC action for failing to preserve required records
€15M / 3%
of worldwide turnover — the EU AI Act fine tier covering record-keeping and deployer obligations
6 months
minimum retention for automatically generated logs from high-risk AI systems
2 Dec 2027
the new date Annex III high-risk logging duties apply — deferred from Aug 2026 by the Digital Omnibus

There is a pattern in financial regulation that most AI teams have not learned yet. In the last few years, the SEC's biggest and most repetitive enforcement campaign was not about market manipulation or fraud. It was about record-keeping – firms whose employees did business on personal texts and messaging apps and who could not produce the records the law required them to keep. The firms admitted the failures. They paid, in aggregate, well over a billion dollars. The regulator's position was simple and unsentimental: if you cannot produce the record, you have violated the rule, no matter whether the underlying conduct was innocent.

That's what is being done to AI now. The EU AI Act makes automatic event logging a design requirement for high-risk AI systems. The 2026 oversight report of FINRA had a new section on generative-AI and told firms to have governance and to track what autonomous agents do. Sectoral rules that are not even AI-related – HIPAA's audit controls, PCI DSS Requirement 10, SEC and FINRA books-and-records rules – apply to AI systems the instant they touch regulated data, because none of them were written to exclude a technology that did not exist yet. In this guide we cover what regulators actually ask for, what a defensible AI audit record looks like field by field, what the real retention floors are, and where most logging implementations quietly fail.

Free Tool · Polygraf AI Risk Calculator

Find out what a missing audit trail actually costs you

Regulatory exposure is not a theoretical concept. Polygraf's AI Risk Calculator maps your company's exposure to breach, regulatory, litigation and reputational risk and shows you which record-keeping obligations apply to you, from the EU AI Act to HIPAA, PCI DSS and financial books-and-records rules.

  • Quantified exposure across every major risk category
  • A tailored read on which logging and retention duties you're subject to
  • Gaps surfaced across evidence, retention, and tamper-evidence
  • Modeled reduction from adding inline logging and policy enforcement
Run the free AI Risk Assessment →
Sample result
Regulatory
Total Potential Exposure
$49.8M
Data breach
Regulatory
Litigation
Reputational

The Precedent: Fined for the Missing Record, Not the Message

It is worth getting to the details because they set the enforcement stance AI will be left with.

$81M
16 firms, one announcement, February 9, 2024

The SEC has charged five broker-dealers, seven dually registered broker-dealers and investment advisers and four affiliated advisers with systematic and long-standing failure to maintain and preserve electronic communications. The firms admitted the facts, admitted that they violated federal securities recordkeeping laws and agreed to a combined civil penalty of more than $81 million. One firm that self-disclosed paid $1.25 million; those that did not paid between $8 million and $16.5 million. This was one wave of a multi-year campaign.

Sep 2022 · 16 firms
$1.1B
Aug 2023 · 11 firms
$289M
Feb 2024 · 16 firms
$81M
Aug 2024 · 26 firms
$390M

Notice what these firms were not charged with. Not fraud. Not misleading clients. They were charged because business occurred on a channel the firm did not capture and the record was not available when the regulator asked for it. Now replace employee texting on a personal phone with employee prompting an AI tool that logs nothing your compliance team can get to. The structural break is the same and so is the risk.

Can Your Logs Answer These Six Questions?

This is the practical test. When the regulator, auditor or plaintiff's counsel comes, they don't want to see your logging architecture, they want to know about a particular decision on a particular date. Click on each one to see why a transcript fails it and what a real audit record needs.

Interactive · The regulator's six questions

Transcript vs. audit trail, question by question

Most AI deployments log the conversation. Almost none log the decision.
Q1Which model and configuration produced this specific output?
Transcript
Shows the answer text. It doesn't say anything about which version of the model, system prompt, temperature or configuration was active at that time. If you upgraded the model in between, the output is no longer reproducible and cannot be explained.
Audit trail
Pins the decision to an exact artifact: model_version, system_prompt_hash, config_hash. An auditor can match the decision to the exact system state that produced it.
Q2What data did the system retrieve or access to reach this answer?
Transcript
Shows what the model said, not what it read. If a RAG system pulled a document the user was not entitled to see, the transcript looks completely clean. Under GDPR you are expected to know what personal data was processed.
Audit trail
Records retrieved_docs[] with IDs and access basis, plus every tool_call and its parameters — including the ones that errored and were retried. (For biometric identification systems specifically, the EU AI Act goes further and mandates recording the exact reference database checked and the input data that produced a match.)
Q3Which named individual reviewed or approved this, and when?
Transcript
Usually assigns the activity to a service account or an application, not a person. HIPAA technical safeguards require a unique user to be identified; the AI did it is not an accountable actor.
Audit trail
Captures actor, role, and — for consequential actions — human_reviewer, review_action, and review_ts. The AI Act's biometric logging provisions explicitly call for identifying the natural persons who verified results.
Q4What policy was applied here, and what did it block or redact?
Transcript
Records only what got through. The interactions your controls stopped leave no trace — so you have no evidence the policy was ever enforced, only a document asserting it exists.
Audit trail
Logs every governance decision: policy_applied, decision (allow / redact / block), matched_rules[], redactions[]. "We have a policy against X" is only defensible when you can show a history of that policy being evaluated and applied.
Q5Can you prove this record hasn't been altered since it was written?
Transcript
Application logs are stored on infrastructure that someone in your organization can change. If they can be changed silently and you cannot prove otherwise, their evidentiary value in a proceeding is close to zero.
Audit trail
Tamper-evident by construction: hash-chained records (prev_hash, record_hash) or WORM-equivalent storage with access controls, written by the security team's system rather than the application owner's.
Q6Show me every AI decision affecting this individual over the last six months.
Transcript
In per-application stores with no common subject key. It takes weeks of engineering to reconstruct this and gives a partial answer and looks exactly like what a company with something to hide would give.
Audit trail
Queryable by subject_id and correlation_id across systems, retained past the applicable floor, and exportable on demand. This is the difference between an afternoon and a crisis.

Anatomy of a Defensible AI Audit Record

Here's the concrete schema. Each field group exists because a specific regulator asks for it. Treat this as a floor, not a ceiling — and note that the record separates identity, system state, content, governance, and integrity, because auditors examine those independently.

ai_decision_record · v1 ✓ tamper-evident
"event_id": "evt_8f2a...c41", "timestamp_utc": "2026-07-09T14:22:07.318Z", "correlation_id": "req_a91f...20d", "subject_id": "cust_44127", "actor": "j.reyes@firm.com", "role": "claims_adjuster_II", "session_id": "ses_77b2...9ef", "auth_method": "sso_saml", "system_id": "claims-triage-agent", "model_version": "internal-llm-2026.06.1", "system_prompt_hash": "sha256:3d9c...7a2", "config_hash": "sha256:be40...118", "input_ref": "blob://prompts/8f2a", "retrieved_docs": ["kb_2291", "policy_88"], "tool_calls": [{"name":"lookup_claim", "status":"ok"}], "output_ref": "blob://outputs/8f2a", "policy_applied": "pii_egress_v4", "decision": "redact", "matched_rules": ["ssn_pattern", "dob_adjacent"], "redactions": 2, "human_reviewer": "m.okafor@firm.com", "review_action": "approved", "review_ts": "2026-07-09T14:24:51.002Z", "prev_hash": "sha256:c118...4fa", "record_hash": "sha256:71e5...9b3", "signed_by": "audit-svc.prod"
Event context
Timestamps and correlation IDs allow you to reconstruct a chain across systems and query by affected person.
Identity
Not a service account. A named human. HIPAA needs a unique user. Every regulator wants an accountable actor.
System state
Model version and config hashes lock the decision to a reproducible system state – the heart of explainability.
Content & governance
What was retrieved, what tools ran, which policy fired, what it blocked – and who approved. This is the layer almost nobody skips.
Integrity
Hash chaining makes silent change detectable. Without it a log is a claim, not evidence.
Store References, Not Raw Sensitive Data

Note that the record above stores input_ref and output_ref — pointers — rather than raw prompt and response text. This is on purpose. An audit log that inlines full prompts becomes a new long-retention copy of every piece of sensitive data your AI ever saw and GDPR's storage-limitation principle is a direct push against storing personal data longer than needed. Log the metadata and the governance decision immutably, store the content separately under its own access controls and deletion lifecycle. Otherwise your compliance artifact is a breach in the making.

What Most Teams Log vs. What Regulators Ask For

✗ What's usually captured
The transcript
Prompt text and response text
Application-level timestamps
Service account or app identifier
Errors and latency metrics
Mutable files on app infrastructure
Retained per default log rotation
Owned by the application team
✓ What's actually asked for
The decision chain
The reasoning chain: retrieval, tool calls, order
Model version and configuration at execution
A named, authenticated human actor
Every policy evaluation — including blocks
Tamper-evident, integrity-verifiable storage
Retention meeting the longest applicable floor
Owned by security/compliance, not the app owner
The Structural Trap: Whose Infrastructure Holds Your Evidence?

If your AI governance runs through a third-party cloud gateway, your compliance evidence lives in someone else's infrastructure. The EU AI Act imposes a retention obligation on you as provider or deployer – and "our vendor has it" is a brittle response if that vendor has an outage, changes its retention policy, is acquired or is itself subpoenaed. You can't generate a six-month continuous log record retroactively. Evidence you are legally obliged to keep must be generated and stored where you control the chain end to end.

The four layers of an AI audit trail — miss one and the decision can't be reconstructed
An examiner reconstructs a decision by walking down these four layers in order 1 · ACTIONS Every tool call, write, message sent, escalation — in order, including retries and errors tool_calls[] 2 · REASONING Why each action was taken — an action without its rationale is uninterpretable after the fact model_version, config_hash 3 · DATA ACCESSED What was retrieved, processed, placed in context, and passed downstream — and under what entitlement retrieved_docs[] 4 · GOVERNANCE EVENTS Every policy applied, action blocked, threshold crossed, redaction made, human override recorded policy_applied, decision RECONSTRUCTABLE Most vendors log layer 1 and call it an audit trail. The examiner needs all four.

The Real Retention Floors

Retention is where the misinformation is thickest. A lot of published guidance mixes up different obligations – most commonly the EU AI Act's ten-year technical documentation obligation as if it was for operational logs. It is not. This is the real picture.

Regime What it requires Floor
EU AI Act
Art. 12, 19, 26(6)
High-risk systems must technically allow automatic recording of events over the system's lifetime. Providers and deployers keep those logs to the extent they're under their control. ≥ 6 months
EU AI Act
Art. 18
A separate duty covering technical documentation and conformity records — not the event logs. Frequently and incorrectly cited as a log-retention period. 10 years
SEC / FINRA
Rule 17a-4, FINRA 4511
Books-and-records rules for broker-dealers. Records must be preserved in a non-rewriteable form or under a compliant audit-trail alternative, with the most recent portion readily accessible. 3–6 years
by record type
HIPAA
§164.312(b), §164.316(b)
Requires audit controls that record and examine activity in systems containing ePHI. The six-year period attaches to required documentation — many organizations extend it to audit logs by policy. 6 years
(documentation)
PCI DSS v4.x
Req. 10.5.1
Audit log history must be retained and available for analysis, with the most recent months immediately available. ≥ 12 months
3 immediately available
GDPR
Art. 5(1)(e)
Sets no retention floor and pushes the opposite way: personal data must not be kept longer than necessary. Your trail needs a defined, defensible lifecycle — not indefinite storage. minimize
Design to the Longest Applicable Floor, Minimize the Content

These obligations are pulling in opposite directions: sectoral rules require retention for years, GDPR requires minimization. The solution is the architecture above – retain the decision metadata and governance record for as long as it is necessary and hold the content under a separate, shorter, deletion-able lifecycle. You do not keep the evidence that a decision was made correctly without keeping a permanent copy of every person's personal data.

The EU AI Act Timeline Just Changed — Here's Where It Actually Stands

If you have read anything about AI logging in the last year, you have probably seen "August 2, 2026" as the deadline for high risk obligations such as Article 12 record keeping. The date has changed and a lot of published material has not.

The European Commission proposed the Digital Omnibus on AI in November 2025 after the implementation of the high-risk regime was clearly lagging behind – no harmonised standards were adopted and notified bodies were not appointed. The political agreement was reached in May 2026. The European Parliament formally endorsed it on 16 June 2026, and the Council gave its final approval on 29 June 2026, with entry into force following publication in the Official Journal. The effect on logging is direct: Article 12's obligations for standalone Annex III high-risk systems now apply from 2 December 2027, not August 2026, and embedded Annex I systems from 2 August 2028.

EU AI Act application dates after the Digital Omnibus
2 Feb 2025 Art. 5 bans Art. 4 literacy in force 2 Aug 2025 GPAI rules Art. 99 penalties in force 2 Aug 2026 Art. 50 transparency unchanged 2 Dec 2026 NCII / CSAM ban Art. 50(2) legacy 2 Dec 2027 Annex III high-risk Art. 12 LOGGING moved from Aug 2026 2 Aug 2028 Annex I embedded deferred ~16 months by the Digital Omnibus Prohibitions, GPAI rules, penalties and transparency duties were not deferred. Only the high-risk regime moved.
Don't Read the Deferral as a Reprieve

Three reasons why the extra runway is a trap if you think of it as time off. First, the deferral is narrow – Article 5 prohibitions, the Article 4 AI literacy duty, GPAI obligations and the Article 50 transparency rules were not affected and Article 99's penalty regime has been in force since 2025 August. Second, the legal risk that was at stake did not shift at all: AI-caused harm in 2026 is still subject to GDPR, sectoral financial and health rules, product liability and anti-discrimination law – none of which was paused. Third, the hard part of this job is not the documentation template. It is to find every AI system in your company, classify it and instrument it so that the logs exist. This takes quarters not weeks and it does not get easier by starting later.

What US Regulators Are Signalling

There is no US AI logging statute. What there is is more important: technology-neutral rules that already apply and regulators who say they intend to apply them.

FINRA's 2026 Annual Regulatory Oversight Report added a dedicated generative-AI section — new for 2026. Per Sidley's analysis, FINRA expects firms to assess their regulatory obligations before deploying generative AI, to establish governance frameworks supervising its use, to maintain ongoing human monitoring of model outputs, and — most pointedly for audit trails — it notes that autonomous AI agents may require novel oversight, including tracking their actions and restricting system access. That is a logging requirement in all but name, arriving through existing supervision and books-and-records rules rather than a new one.

"Regulators don't fine you for the answer your model gave. They fine you for not being able to show how it got there. An unlogged AI decision isn't a compliant decision that lacks paperwork — for evidentiary purposes, it's a decision that never happened."

— Polygraf AI, on AI record-keeping

The Implementation Playbook

1
Inventory AI systems and classify by obligation
You can't log what you haven't found. List every model, agent and copilot – built, embedded and bought – and identify which regime it is in and which retention floor it is under. This is the dependency for everything that follows and the Omnibus didn't change it.
2
Define the event, then the schema
Begin with the smallest thing that must be reviewable later: a decision, recommendation, action, override or escalation that could have a material impact on a person or a regulated process. Design the record around that unit and separate identity, system state, content references, governance and integrity metadata.
3
Instrument at the boundary, not inside each app
If logging is done per-app, the coverage will be uneven and shadow AI will not show up at all. Capture at the control point every AI interaction goes through so the trail is uniform, complete and security's, not of the team that shipped the feature.
4
Make it tamper-evident and keep it under your control
Hash-chain records or WORM-equivalent storage, write them to a service that the application team cannot edit and store the evidence chain in infrastructure you control. A log that can be silently changed has little evidentiary value and evidence in a vendor's estate is not reliably yours.
5
Rehearse the audit before it happens
Practice the six questions above against a real decision from 90 days ago. Time yourself. If it takes engineers more than an afternoon to reconstruct the decision chain or if it gives you a partial answer, you have a finding and you found it before the regulator.
How Polygraf Produces the Audit Trail

Polygraf's Behavioral Control Plane is inline at the edge of all AI interaction, both user and agentic, which is exactly where a single audit trail has to be collected.Because it evaluates policy on every input and output, it records the governance layer most implementations miss entirely: which policy fired, what decision was reached (allow, redact, block), which rules matched, what was redacted, and which named, authenticated human was behind the request. It captures the decision chain, not the transcript.

And because Polygraf runs on-premise with zero data egress, the evidence chain never leaves your infrastructure. You are not relying on a third party's retention policy to meet a regulator's obligation on you. The logs are yours, created where the AI is actually running, sub 100ms latency and no GPU needed – that's the audit trail as a side effect of enforcement, not a project you need to fund and staff.

Not legal or compliance advice. This article is a general educational overview of Polygraf AI. Regulatory obligations are fact-based and depend on your jurisdiction, sector, role (provider vs deployer) and system classification. EU AI Act references are to Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI, final text and Official Journal publication should be verified with the official source; the original 2 August 2026 date is still valid until publication becomes law. Retention periods are summarised floors and not a complete statement of any rule. Verify your obligations with qualified counsel and the official legislative texts.
Polygraf AI

Turn AI Governance Into Evidence

Polygraf records every AI interaction and every policy decision – allow, redact, block – with a named actor and tamper-evident record inline where your AI runs. On-premise, sub-100ms, zero data egress. The audit trail regulators want, automatically generated.

Request a Demo →
Air-gap ready · EU AI Act · HIPAA · SOC 2

NEWS & More

Insights & Updates from Polygraf.

Blog Posts

Most enterprises have deployed AI but skipped the security controls. Polygraf's 25-point AI security checklist maps the controls every enterprise needs to know.

To learn more about Polygraf, please get in touch.

At Polygraf, we envision a future where AI augments human capabilities without compromising safety, privacy, or ethical standards. Trust in our commitment to building this future with you.

Products

thank you

Your download will start now.

Thank you!

Please provide information below and
we will send you a link to download the white paper.