Short answer
Do not preserve only the final file. Keep original sources with date and version, the actual input scope supplied to AI, model and instruction versions, raw output, human changes, material verification and final approver. Scale records to consequence: an ordinary personal draft may need a simple version history; contracts, research, finance, safety, public decisions and autonomous action need enough evidence to reconstruct which source passed through which systems and people to become which result.
Traceability does not mean collecting every chat forever
The purpose of a record is to answer concrete future questions. Where did this conclusion come from? What did AI see and fail to see? Who changed and approved it? Which model, rules and file versions applied? Which results are affected by a later-discovered error? Complete screenshots of every conversation do not solve those questions if they cannot be connected to the final propositions.
Excessive logging can also copy sensitive information, increase retention cost and bury material evidence in noise. Define what must be proven for the task's risk, then preserve enough to reconstruct it.
Australian Government AI adoption implementation guidance emphasises documentation, accountability, testing, monitoring and incident management. Together, these practices imply that AI work should remain explainable and reviewable rather than leaving only an output. Australian Government: Guidance for AI Adoption—Implementation Practices
Create a source–generation–edit–approval chain
The minimum chain has four layers. The source layer identifies documents, data, web pages, interviews or system records. The generation layer records selected input, instructions, model and tools. The edit layer preserves raw AI output and material human changes. The approval layer identifies final version, intended use, approver and date.
Connect layers with stable identifiers such as a project ID, file hash, document version ID or record link. A material statement in a final report should return to an exact source location, not merely a several-hundred-page PDF. For mutable web sources, record access date, title and an appropriate snapshot or archive location.
The chain should expose blanks, too: attachments not read, pages with failed OCR, the date through which data run, and propositions without independent support. Missing input is not irrelevant technical telemetry; it explains the boundary of the result.
Preserve original sources, not only AI summaries
An AI summary is a derivative. If a source page changes, a link breaks, the summary misreads it or a citation is disputed, the summary alone cannot support review. Preserve a lawful copy or controlled reference with title, author or institution, publication date, version, access date, page and link.
For databases and dynamic dashboards, record query, field definitions, filters, time zone and extraction time. For code-generated results, preserve commit, dependencies and runtime parameters. For meetings, retain policy-appropriate audio timestamps, chat and file versions. A source “version” needs to reproduce what was actually available then.
Copyright, privacy or contract may prohibit storing the full source. Retain precise location, authorised access and necessary excerpts instead of bypassing restrictions. Traceability does not create new copying rights.
Record the input scope AI actually saw
“Used the annual report” is not enough. A system may parse body text but omit charts and attachments; retrieval may supply only a few passages; context limits may truncate the end. Record file inventory, selected pages or chunks, parse failures, retrieved passages and necessary system instructions.
For sensitive input, do not duplicate full content into a general log. Preserve a controlled location, classification, hash and access authority so an authorised reviewer can reconstruct it. Logs need their own access and retention controls.
If input comes from a live connector, identify connector version, query scope and returned object IDs. Otherwise it may be impossible to know which version of a customer record the model saw.
A model name is not a complete generation version
Reproducibility can depend on model identifier, provider version or snapshot, system instruction, user prompt, sampling settings, tool definitions, retrieved content and safety configuration. “Generated by AI” has almost no diagnostic value. A brand alone may be insufficient because the backing model can change.
Where snapshots can be pinned, preserve the exact identifier. Otherwise record run time, visible product version and relevant settings, and acknowledge that exact reproduction is unavailable. Generative systems can vary even under apparently identical configuration. The realistic aim is often to reconstruct conditions and judgement, not promise identical wording.
Version instruction templates as well. A small change can alter structure, refusal, citations and tool calls. Store templates in controlled files or configuration rather than scattering them across personal chat histories.
Keep raw output and final human edits
If only the final document remains, nobody can tell whether an error came from a model or later editing. If only raw output remains, it does not prove what was released. Preserve both and show their differences. For high-risk material, record who accepted, rejected or rewrote material recommendations and why.
You need not audit every punctuation mark. Focus on edits that change facts, figures, responsibility, conclusions, conditions, promises or action status. Document version history, code commits or structured differences provide stronger evidence than a note saying “reviewed.”
For repeated AI rewrites, treat every cycle as a derivative version: input version, instruction and output version. Avoid copy-paste overwrites that break the source chain.
Connect verification to specific claims
“Fact-checked” is too broad. Record which facts were checked, by whom, against which source, on what date, and what remains unresolved. Preserve calculations, units and reconciliation for key figures; exact source location and supported proposition for citations; and scope of qualified review for professional conclusions.
Verification can expire. A policy link and market figure that supported an action at the time may not support it months later. Give time-sensitive checks an expiry or recheck trigger.
Do not allow the same model to generate the answer, compose a verification narrative and mark itself approved. It can organise evidence, but independent sources or controls must support final status.
Give the final version an unambiguous identity
A filename such as “final-final-v3” does not reliably express approval. Formal outputs need a stable ID, version number, state, publication date, owner and approver. Draft, in review, approved, withdrawn and expired should be explicit states rather than assumptions based on folder location.
When an approved version changes, create a new version and describe the difference rather than silently overwriting it. People who received the old version need to know whether they must act. Web pages and knowledge bases can display last-reviewed date and source version.
The final item should also link to its project or series record so a reader can find related evidence and scope instead of seeing an isolated file.
Content credentials help, but are not a truth button
Standards such as C2PA provide a technical representation of provenance and editing history, helping applications verify who signed an asset and which processing steps are declared. This is useful for images, video and other digital content. C2PA Technical Specifications
Provenance credentials establish a claim about origin and handling; they do not automatically establish truth, completeness or fairness. A person can sign a false statement. Absence of credentials does not prove falsehood. Metadata can also be stripped by some platforms. Combine technical provenance with source verification, competent judgement and organisational approval.
C2PA's explanatory material similarly presents Content Credentials as context about origin, not a single arbiter of whether something is true. C2PA Explainer
Design privacy and traceability together
Saving every input for audit can duplicate personal information, privileged material or secrets. Deleting everything for privacy can make incident investigation impossible. Use data layers: an ordinary audit log carries identifiers, class, time, operation and owner; sensitive source remains in controlled storage connected by a permissioned reference; different retention periods and legal-hold rules apply.
Protect logs from unauthorised change and record who views or exports them. Redact unnecessary personal information when sharing traceability records. A system intended for accountability should not become a new high-volume disclosure source.
Deletion also propagates. If a source must be erased or consent is withdrawn, assess derived summaries, vector indexes, caches, exports and downstream documents for deletion or correction, retaining only the minimum deletion evidence permitted.
Three record levels based on risk
Lightweight records suit personal brainstorming and low-risk internal drafts: preserve source links, the task or instruction, and final document version. Standard records suit client content, project analysis and publishable material: add input inventory, model time and configuration, raw output, differences, verification and approval.
Enhanced records suit legal, financial, clinical, safety, public-decision and AI-agent action: tamper-resistant event logs, precise versions, permission records, dual or specialist approval, decision reasons, monitoring results and incident links. Electronic signatures, hashes or a formal record system may be appropriate.
Escalate when risk changes. If a personal draft enters a public report, its original lightweight treatment does not excuse missing evidence. Complete source, verification and approval records before the new use.
Build the ability to analyse impact
Traceability often pays for itself after a fault appears. If a source dataset is wrong, a model version behaves badly, or a prompt omitted exceptions, you should be able to find affected articles, decisions, messages and actions. Without relationships, a team must recheck everything or allow errors to remain.
Record source IDs, model and prompt versions, and output purposes so queries work in both directions: which results used this source; which sources produced this result; which actions followed this approval. Prioritise those relationships for high-risk workflows.
Run periodic drills. Select a published conclusion and ask another person to find its source, AI version, changes and approval within a reasonable time. If they cannot, the records constitute storage, not usable traceability.
My assessment: preserve decision evidence, not technical ceremony
Screenshots of AI chats, a note saying “human reviewed” or the tool's brand can look transparent without explaining the result. Good records centre on decisions: where material claims came from, which changes people selected, why the result was accepted, and when review must recur.
A future reviewer should need less reliance on the original operator's memory. If only that person can explain the process, it has not become an organisational capability.
Record checklist
- Do sources have title, version, date, exact location and an authorised access path?
- Do you know which files, pages and chunks AI actually read and what it missed?
- Are model or product version, time, instruction template, tools and key settings recorded?
- Are raw AI output and final edit both preserved with material differences visible?
- Do key facts, figures, citations and professional judgements connect to verification evidence?
- Does the final version have a stable ID, state, owner, approver and release date?
- Do logs protect sensitive data with access, retention, deletion and integrity controls?
- Can a source or model fault be traced backwards to every affected result?
Conclusion
Preserving AI-assisted work is not the infinite accumulation of chats. It is a usable chain across sources, generation conditions, human editing, verification and approval. Scale the record to consequence, preserve missing and uncertain input, and connect the final version to evidence. When a source changes, a result is challenged or an error appears, the team can reconstruct judgement, locate impact and make a responsible correction.
Related questions
- How Can You Check Whether AI Citations, Data and Links Are Real?
- Why Can the Same Prompt Produce Different Answers After a Model Update?
Continue reading: All articles in How Far Should You Trust AI?
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.