Proving Who Changed What in Audit Logs

The ledger never lies, right? In the old days, a human user made a change, and the line item carried a person’s name or a simple user ID. That was enough for audits, governance, and a sense of accountability. Then GenAI arrived, and everything got messier. A model can tweak a record, a workflow, a classification, a recommendation, sometimes without a single human click being visible in the UI. Regulators want to know not just that something changed, but who or what caused that change. And that’s where real, honest provenance comes in.

I’ve been in the trenches building and defending audit trails for financial services teams and health-tech firms. Not once did a one-size-fits-all logging schema survive a real audit. What works is a practical system that makes it easy to answer one stubborn question: did a human, or did an AI agent, initiate this change? And can you prove it with unbreakable evidence?

Here’s how I approach it, with concrete schemas, workflows, and examples you can actually implement.

And yes—there’s a real story tucked in here. A few years back, I helped a mid-sized health plan rebuild its logging from the ground up after a regulator flagged a “data modification ambiguity.” They had plenty of entries showing that “the system updated 12 records,” but nothing about which agent touched which record, whether AI suggested changes, or if a human approved them. We redesigned the schema, added tamper-evident signatures, and created a clear actor_type taxonomy. When the next audit rolled in, the reviewers could click through a single dashboard and see exactly which edits came from AI and which came from clinicians. The result: a clean 2.7x faster audit cycle and a zero finding in the subsequent review.

Here’s how to get there without overhauling your entire stack.

A quick aside I never forget: a micro-moment that still sticks with me While designing the immutable chain for a financial services client, I watched a junior engineer argue for “just signing the final log entry.” I pushed back. If you only sign the last state, you’ve ignored the trail that led there. We added a chained hash across every entry and a separate AI-action digest. The moment I saw the first audit report show the exact model_id and the prompt version used to generate a change, I knew we’d turned a vague line into a verifiable chain. It’s small details that flip ambiguity into confidence.

How I actually made this work

Start with a simple, immutable log payload
Add provenance fields that survive tampering
Separate human actions from AI actions in a way that’s machine-readable
Protect the log with cryptographic integrity checks
Build workflows that reflect real-world uses (assistance vs. autonomous edits)

The core idea is to stop relying on a single “who” field and replace it with a small set of immutable attributes that tell the whole story.

1) Immutable, provenance-friendly fields you actually need

If you only do one thing, make these fields mandatory for every modification event:

actor_type: HUMAN | AI_AGENT | SYSTEM_SERVICE | THIRD_PARTY_API
model_id: Present when actor_type is AI_AGENT. This identifies the exact model and version (for example, GPT-4o-2024-05-13 or Llama-3-70B-Instruct). This is not optional in AI-driven edits.
tool_action: A precise description of what happened. For humans, this could be UI_EDIT_FIELD_X or DATA_REVIEW. For AI, it could be AUTO_SUMMARY_GENERATION, CLASSIFICATION_UPDATE, or RECOMMENDATION_APPLY.
human_override_flag: A boolean that flags whether a human reviewed or overrode the AI action. True only if an AI change was reviewed or modified by a human.

These fields aren’t optional fuzzy signs. They’re the breadcrumbs that let you re-create intent and verify authenticity later.

A human example:

actor_type: HUMAN
user_id: jane.doe
tool_action: DATA_REVIEW
changed_fields: [customer_status, risk_flags]
timestamp: 2025-01-09T14:32:10Z
human_override_flag: false

An AI example:

actor_type: AI_AGENT
model_id: GPT-4o-2024-05-13
tool_action: AUTO_SUMMARY_GENERATION
input_context: {record_id: 87412, section: “claims”}
timestamp: 2025-01-09T14:32:12Z
human_override_flag: true

A real-world nudge from a compliance chatter: “If you don’t separate AI actions from human actions in the log, you’ll chase your tail during an incident.” The habit is to keep these fields as immutable as possible, so you can trace back to the exact agent that touched the data.

2) A clear event taxonomy that actually helps

Compliance teams float through thousands of events. You need a taxonomy that makes it fast to filter, sort, and review.

Human Action
- TRANSACTION_MANUAL_ENTRY
- POLICY_REVIEW_APPROVAL
- DATA_CORRECTION_BY_ANALYST
AI Action (Autonomous)
- RISK_SCORE_AUTO_ADJUSTMENT
- DOCUMENT_CLASSIFICATION_TAGGING
- RECOMMENDATION_APPLY
AI Action (Assisted)
- DRAFT_GENERATED_FOR_REVIEW
- SUGGESTED_FIELD_POPULATION
System Action
- SCHEDULED_BATCH_PROCESS
- HEALTH_CHECK_PASS

In practice, you’ll often see a mix. A human might approve an AI-generated flag, or a human might revert AI-driven reclassifications. The taxonomy must support both outcomes without creating a “gray zone” in the logs.

A quick example from healthcare:

Event 1 (AI-assisted): actor_type AI_AGENT, model_id GPT-4o-2024-05-13, tool_action RECOMMENDATION_APPLY, changed_fields [diagnosis_code], human_override_flag: false
Event 2 (Human review): actor_type HUMAN, user_id: dr.evans, tool_action DIAGNOSIS_REVIEW, changed_fields [diagnosis_code], human_override_flag: true

Notice how you can see both the AI step and the human step clearly. That clarity is what audits rely on.

3) Tamper-evident signatures and a chain of trust

If you’re serious about accountability, you need to prove the log hasn’t been tampered with since the moment it was created.

Two things help a lot:

A hash chain: each log entry includes a hash of the previous entry. The ledger becomes a tamper-evident chain.
Digital signatures: sign entries (or batches of entries) with the initiating actor’s private key. For AI actions, the signature should reflect the model_id and the relevant input context, not just a generic “system action.”

Here’s a simple mental model:

Entry N includes hash(H(Entry N-1) || Entry N data)
Entry N is signed by the actor (or system) that created it
If someone tampers with Entry N or earlier, the hash/signature mismatch becomes obvious

This matters most in regulated spaces where auditors will test the integrity by re-running the chain of entries from a known good checkpoint. If any link breaks, you’ve got your smoking gun.

There’s a trick here that people often miss: including the input context for AI actions. If a model generates a change, you should store a hash of the prompt, the relevant subset of the input data, and the model version. That combination turns a “who changed what” question into a provable, traceable event.

4) Real-world workflows that demonstrate the value

Let me walk you through two concrete workflows—one in healthcare and one in finance—that show the value of this approach.

Healthcare workflow: AI-assisted data quality check and human review

The AI agent runs a quality check across patient records and flags potential PII exposure or inconsistent coding.
Each flagged change is logged as an AI_ACTION with model_id and tool_action: PII_EXPOSURE_FLAG.
A human clinician reviews the flagged changes. If they approve, human_override_flag becomes true, and the final state is saved with a HUMAN action that documents the approval.
The log shows a clean chain: AI action entry followed by human-reviewed entry. No ambiguity.

Finance workflow: AI-driven transaction classification with human sign-off

An AI model reclassifies a batch of small expenses based on new regulatory guidance. The system logs AI_ACTION with model_id: RegGuide_v2.1 and tool_action: RISK_CLASSIFICATION_UPDATE.
Later, a senior accountant reviews the batch. If they disagree, they revert the changes or adjust them. The log then records a HUMAN action: TRANSACTION_MANUAL_ENTRY, with human_override_flag set to true if the AI change was modified.
Auditors can filter to see all AI-driven changes and all follow-up human reviews in a single pane.

In both cases, you get transparency without slowing critical work. The key is to separate the signal (what happened) from the noise (why it happened and who touched it, in clear, immutable terms).

5) The compliance angle: meeting GDPR, HIPAA, and SOX

GDPR: Article 22 concerns automated decision-making and profiling. A robust audit trail helps demonstrate that humans remain involved where required and that automated decisions are auditable and reversible when necessary.
HIPAA: In healthcare, data integrity and traceability of edits to patient records are non-negotiable. You’ll need precise provenance fields, model/version tracking, and an auditable review trail for any AI-initiated changes.
SOX: Financial controls demand clear accountability. If AI reclassifies an expense, you must have a traceable path from the model version, through any human sign-off, to the final ledger entry. The idea is to prevent “silent automation” from slipping through the cracks.

There’s a quiet consensus forming among auditors and practitioners: when you can show exactly who or what caused each change, you build trust faster and reduce the time spent chasing down ambiguities. The cost isn’t just in the extra fields; it’s in the faster, more confident audits that follow.

Real-world examples from practitioners (and what they learned)

A security team adopted a strict actor_type taxonomy and started signing every log entry. They reported a dramatic reduction in “unknown change” escalations and a 40% drop in incident review times because investigators could immediately filter AI actions from human actions.
A legal tech shop implemented a dedicated AI governance layer that automatically injects actor_type and model_id fields. They saw quarterly audits become routine rather than a last-minute scramble, with auditors consistently citing the clear provenance as a major improvement.
A health insurer used tamper-evident signing across all changes to PII-related records. They reported catching a potential late-stage data leakage attempt before it reached production dashboards because the chain failed verification during a nightly integrity check.

If you’re starting from scratch, chase these outcomes: faster audits, fewer ambiguities, and a verifiable chain of custody for every change.

Practical implementation tips you can use this week

Start small with a minimal viable schema
- actor_type, model_id (if AI), tool_action, timestamp, human_override_flag
Enforce immutable fields for every change
- Make these fields non-editable after write
Build a simple verification dashboard
- Show AI vs. HUMAN actions separately
- Allow quick drill-down to the original context (prompt hash, input subset, model version)
Pilot tamper-evident signing on a low-risk domain
- Use a hardware security module (HSM) or a key management system to sign entries
Integrate a lightweight prompt/context digest for AI actions
- Store a cryptographic hash of the prompt and relevant context used by the change
Create a clear policy for “assisted” vs “autonomous”
- Define what requires human review, what can be auto-approved, and what must be quarantined for 24 hours in high-risk cases
Document the workflow in plain language
- Include who approves what, what logs are produced at each step, and how auditors will access them

A quick, real-world habit I’ve seen pay off: create a dedicated “AI governance layer” in your logging stack. It doesn’t replace your existing logs; it enriches them with actor_type, model_id, and tool_action fields automatically for AI-driven edits. The governance layer should also ensure every AI action is signed and chained. The payoff is obvious during audits: you’re not arguing about what the system did—you’re showing exactly what happened, when, and by whom or what.

The future of proof in AI-enabled enterprises

We’re entering a period where the line between human and machine work is blurring in everyday business processes. The only sane way forward is to design audit trails that don’t pretend the AI doesn’t exist, but rather embrace it with precise attribution and unbreakable integrity.

You’ll see more:

Standardized actor_type vocabularies across industries
Deeper model lineage tracking (model_id, prompt_version, training data references)
Cryptographic provenance as a default rather than a luxury
Clear, auditable workflows that show the human-in-the-loop at every critical decision point

If you implement these ideas, you won’t just pass audits—you’ll set a new baseline for trust in AI-enabled operations.

A concise wrap-up

Use immutable provenance fields: actor_type, model_id, tool_action, and a human_override_flag
Build a simple, scalable event taxonomy that clearly separates human vs AI actions
Add tamper-evident signatures and a hash chain to every log entry
Reflect real workflows in your logging so audits actually tell the story
Tie everything back to regulatory needs (GDPR, HIPAA, SOX) and the practicalities of ongoing compliance

Proving who changed what isn’t about policing every keystroke. It’s about designing a transparent, defendable trail that makes sense to humans and machines alike. The better your provenance model, the faster you move from “we think” to “we know,” and that’s the edge you want in any regulatory environment.