A chain of custody for an AI output has to record how the output was made, not only who has handled it since. That is the whole difference from the custody records legal and evidence teams already run. A conventional chain of custody tracks an object that does not change, a drive, a recording, a sealed bag, a printed file, and it answers one question about whether anyone could have altered that object between collection and reliance. An AI output is not an object that was collected. It is an assertion that was produced, by a particular model, from a particular input, under a particular instruction, at a particular moment. A record covering only the handling is silent on almost everything a challenge will ask.
This matters for any team whose outputs end up in a filing, a disclosure package, a regulatory response or a public records release. If you are still working through where the model should run and who controls the infrastructure underneath it, that question is covered in on-premises AI. What follows assumes the deployment decision is made and asks what the record has to contain once the system is running.
Evidence law already anticipated most of this, which is the useful thing to know before designing anything. Under the Federal Rules of Evidence, Rule 901(b)(9) allows authentication by "evidence describing a process or system and showing that it produces an accurate result", and the 2017 amendments that took effect on 1 December 2017 added two self-authentication routes built on that idea. Rule 902(13) covers "a record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person", and Rule 902(14) covers "data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification", again by certification. Both let you establish authenticity by written certification instead of live witness testimony, provided you give notice.
Read 902(13) carefully and the difficulty for AI is right there in the words "produces an accurate result". A hash-based process of digital identification under 902(14) is deterministic and provable, which is why forensic imaging fits the rule comfortably. A generative model is not deterministic and its accuracy is a statistical property of a distribution, not a guarantee about a run.
That does not put AI output outside the rules, and the Advisory Committee anticipated the objection directly. Its 2017 note on the amendments says that "a certification authenticating a computer output, such as a spreadsheet, does not preclude an objection that the information produced is unreliable—the authentication establishes only that the output came from the computer." Authentication and reliability are separate fights. Getting an AI output admitted as what it is under 902(13) settles nothing about whether it is correct, and the reliability argument is fought under Rule 702, which was tightened effective 1 December 2023 to require the proponent to demonstrate "that it is more likely than not" that the testimony rests on sufficient facts, reliable methods and a reliable application of those methods. Conflating the two rules is the most common mistake here. The record described below is what feeds both.
The same note explains why 902(14) works so cleanly for copied data and why it does not stretch to generated data. Hashing establishes that "if the hash values for the original and copy are the same, it is highly improbable that the original and copy are not identical". Nothing equivalent exists for an assertion a model produced, which is why the record has to carry the process instead.
What makes an AI output different from a file
An AI output breaks several assumptions that conventional custody records quietly rely on, and each one breaks differently.
It is derived. A transcript is a claim about audio. A summary is a claim about a set of documents. A detection is a claim about what appears in a frame. A redaction is a claim about which parts of a file are exempt. Custody of the source establishes that the source is intact and says nothing about whether the derivation from it was sound. Those are two separate records and you need both.
It is probabilistic. A language model does not retrieve an answer, it produces a probability distribution over possible next tokens and something downstream selects from that distribution. Detection models behave the same way, emitting confidence scores that a threshold converts into a yes or a no. Whatever you keep is the result of a selection step, and that selection step has settings that belong in the record.
It may not reproduce, and this is the property that surprises people. Temperature governs how much randomness enters the selection. At higher temperatures lower-probability tokens are chosen more often, which is why the same prompt produces different phrasing each run. Setting temperature to zero makes the selection greedy, always taking the highest-probability token, and that removes the deliberate randomness without always producing byte-identical output. Floating-point arithmetic on GPUs is not associative, so the order in which parallel operations are combined can shift a result in its final decimal places. That order depends on how many other requests were batched alongside yours, which computation kernel the serving library picked, which version of that library was running, and which GPU the request landed on. Almost always the difference changes nothing. Occasionally it flips the ranking of the top two candidate tokens and the text diverges from there onward. Mixture-of-experts architectures add another route to variation, because routing can depend on the composition of the batch.
The defensible statement is that temperature zero makes an output far more likely to reproduce, not that it guarantees reproduction. Telling a compliance team otherwise sets them up to be contradicted by their own system.
The environment around the model also moves even when the model itself is pinned to a version. A retrieval index gains documents, a permission change alters which documents retrieval is allowed to see, a system prompt is edited between releases, and a hosted provider updates the weights sitting behind a stable model name. Any one of those changes the output while nothing in your own application appears to have changed, which is why the record has to describe the surroundings of a run rather than only the model that ran.
The record that has to exist
Each element below earns its place by answering a question that gets asked when someone disputes an output. If an element does not answer a question you can name, drop it.
| What you record |
The question it answers when the output is challenged |
| Model identity, version and build, including quantization |
Which system produced this, and is it the system your documentation describes? |
| The exact input artefact and its cryptographic hash |
Was this generated from the item in evidence, or from a different copy of it? |
| The prompt, and the system prompt behind it |
Was the model asked a neutral question, or one that steered it toward the answer? |
| The retrieval context, where the system used RAG |
What did the model have in front of it, as opposed to what was available in the library? |
| Runtime parameters, including temperature, sampling settings, any seed, and context limits |
How much latitude did the system have, and did the settings match the approved configuration? |
| Operator identity |
Who ran this, and were they authorized to run it? |
| Timestamp |
When did this run relative to the last index update and the last model change? |
| The human review action, including what the reviewer changed and the stated reason |
Did a person exercise judgement here, and what did that judgement consist of? |
Four of those rows are the ones organizations skip.
Retrieval context is the most commonly missing element and the hardest to add afterwards. Store the passages as they were retrieved, verbatim, with their source identifiers, rather than storing the query. A query is not a record, because an index that has gained or lost documents since will answer it differently.
The system prompt tends to live in configuration and change without a release note. Version it the way you version code and treat an edit as an event with an author and a time, because a system prompt shapes every output produced while it was in force.
Recording runtime parameters honestly costs almost nothing. A record showing temperature at 0.7 is a plain admission of deliberate variation, appropriate when the task is drafting and awkward when it is extraction from a source document. Being able to state the value beats being unable to find it.
Model version is hardest in hosted deployments, because the weights behind a model alias are the provider's to change on their own schedule. Self-hosting is what makes the version field meaningful, since you decide when it moves. Where the platform records these elements rather than leaving them to application code, the burden drops. Workflow graphs in VIDIZMO AI Intelligence Hub are versioned, and every chatbot answer carries source citations back to the material it drew on, which covers the retrieval row directly. Detailed model inventories and versioning, a bill of models, are available under NDA rather than published, worth knowing before writing a requirement that assumes any vendor keeps a public version list.
Reproducibility versus reconstruction
Because outputs may not reproduce byte for byte, do not build the record around a promise to re-run. The workable standard is reconstruction, showing what was done with enough specificity that a competent outsider could evaluate it, could re-run it if they chose, and could explain any divergence when they did.
That distinction has direct consequences for retention. Keep the input artefact rather than a pointer to a system that may have purged it. Keep the retrieved passages as retrieved. Keep the output exactly as produced, before any editing, alongside the edited version that was actually relied on. Keep the prompt, the system prompt and the parameters as versioned artefacts tied to the run. Set the retention clock from the longest applicable obligation, usually a records schedule or a litigation hold rather than whatever the platform defaults to.
Teams doing the highest-stakes work sometimes freeze a complete model image for the life of a matter. That control costs real money, since a frozen image stops receiving security patches and accuracy improvements alike while still having to be stored and secured for years. Apply it narrowly.
Human review belongs inside the record, not beside it
The reviewer sits between production and reliance, before an output leaves the organization or gets acted on, not after somebody complains about it. Where that placement is enforced by the workflow rather than by policy, review becomes an event with a record instead of a step that gets skipped under deadline.
Capture what the reviewer was shown, what they changed, what they left unchanged, their stated reason, their identity, and how long they spent. The last one is uncomfortable and the most informative. A review pass recorded at one second per item describes a click, and everyone reading the log will know it.
An unevidenced assertion that a human reviewed the output answers almost nothing, because it cannot be distinguished from someone opening a screen and closing it. The value of human review inside a custody record lives entirely in the specificity of what the human is recorded as having done, which is why an approval flag alone proves little and a recorded delta proves a great deal.
Record the routing decision too. Where review is triggered by a confidence score falling below a threshold, store the threshold in force and the score for the item, so the record explains why this output went to a person and that one did not.
AI Intelligence Hub uses confidence scoring with configurable thresholds that trigger escalation to human reviewers, and its workflow graphs include human review and approval nodes, so the review lands in the same audit trail as the processing rather than in a separate ticketing system that has to be correlated afterwards. How those gates fit into longer automated chains is covered in agentic AI workflows on your own infrastructure.
Retention and tamper evidence
The audit trail has to be protected at least as well as the material it describes, because under challenge the trail is the thing being examined. A log an administrator can edit with the same credentials that ran the job establishes very little about either.
This is not only a legal concern imported into a technical system. NIST built it into its own AI guidance. NIST AI 600-1, the Generative AI Profile, published July 2024, lists information integrity among the twelve generative AI risks it enumerates, and defines high-integrity information as information that "can be verified and authenticated, has a clear chain of custody, and creates reasonable expectations about when its validity may expire". A federal AI risk document naming chain of custody as a property of trustworthy information is the shortest route through an internal argument about whether any of this applies to you.
Three controls in NIST SP 800-53 Rev. 5 map onto this directly, and citing them by identifier saves an argument with an assessor. AU-10 requires "irrefutable evidence that an individual (or process acting on behalf of an individual) has performed" a defined action, and the parenthetical is what brings a model invocation inside the control. SI-7 requires integrity verification tools "to detect unauthorized changes" to software, firmware and information, which is the basis for hashing both the artefact and the record of it. SR-4 requires you to "document, monitor, and maintain valid provenance" of components and associated data, which is where a set of model weights and its origin belong. If your system security plan already claims those three, the chain of custody described here is how you evidence them rather than an extra project.
Hold the trail in append-only storage rather than a mutable table. Use cryptographic chaining or hashing so a modification is detectable rather than merely forbidden by policy. Put the archive under a retention lock so the record survives its schedule even against someone with rights over the system. Hash the input at ingestion and the output at production and store both hashes with the run, since rehashing an artefact later proves only what it contains now. Keep the account that runs the model separate from the account that can alter the record of it having run.
VIDIZMO holds audit logs in append-only Azure SQL ledger tables that are tamper-evident, so any modification is cryptographically detectable and provable, and archives them to Azure Blob storage under a locked time-based WORM retention policy leaving them non-rewriteable and non-erasable until retention expires. Event logs can also be streamed to customer-controlled systems by webhook, which matters more than it sounds, because a copy of the trail outside the vendor's control answers a different question than a copy inside it.
On the handling half, VIDIZMO DEMS produces a chain of custody report covering IP address, username, date and time, event type and event details, exportable as PDF and CSV, with SHA-384 hash-based tamper detection and WORM-enabled storage for the audit logs. Pair that with the production record described earlier and you hold both halves rather than one standing in for the other. The deployment side for agencies is in private cloud digital evidence management.
Where this goes wrong in practice
The model changed underneath a running system
A hosted model gets updated behind a stable alias, or an internal team upgrades a self-hosted deployment during a maintenance window. Outputs from before and after are indistinguishable in the record, and when one is questioned nobody can say which system produced it. A version field cannot be backfilled honestly, so the fix has to be in place beforehand. Asking a vendor how model versions are recorded alongside outputs belongs in procurement, and the security questionnaire for AI vendors covers where else to press.
Redaction with no record of what the reviewer overrode
A redacted file on its own cannot tell you why something was missed. The item might have fallen outside the detection types configured for the job, or never been detected at all, or been detected with a confidence score below the applied threshold, or been detected and then cleared by a reviewer who judged it not exempt. Those are four different failures with four different remedies and the released file looks identical in all of them. VIDIZMO Redactor makes the confidence threshold user-definable between 25 and 90 percent and applies only detections above it, which is exactly the kind of setting that has to travel with the output rather than sit in a configuration screen. It also carries redaction reasons and reviewer notes as annotations, layer history tracking, and a redaction copy preserving the original unredacted evidence. Recording overrides in that structure separates an explainable release from an unexplainable one.
A summary relied on in a filing with no record of its sources
Someone asks a system to summarize a document set, the summary goes into a filing, and months later a question arrives about a statement in it. The retrieval index has been rebuilt twice since, so re-running the query returns different passages and the answer to what the model was working from is genuinely unavailable. This is the most common serious gap, and it closes only by storing retrieved passages at the time of the run.
Prompts stored nowhere
Prompts rarely have a home of their own, which is how the instruction that shaped an output becomes the one part of the story nobody can produce afterwards. They get typed into a chat window, pasted from a colleague's message, buried in a script somebody wrote once, or held in a configuration file that changes without ceremony. Without them none of the other elements can be interpreted, because the same model and the same input under two different instructions produce two different outputs and the record cannot tell them apart. Treating prompts as something temporary is the surest way to make the rest of the record unusable.
A checklist you can adopt
- List the AI outputs your organization produces that someone outside the producing team relies on. That list is the scope, and it usually includes a system nobody had thought about. Mark the ones you might one day offer under Rule 902(13) or 902(14), because a certification asserting that a process produces an accurate result needs a signatory, and identifying that person early changes what you build.
- Confirm for each that model identity and version is recorded with the output rather than inferred later from a deployment date.
- Hash the input at ingestion and the output at production, and store both hashes alongside the run.
- Capture the prompt and the system prompt as versioned artefacts, treating an edit to either as a change event with an author and a time.
- Store retrieved passages verbatim instead of a query that would have to be re-run against an index that has moved.
- Record runtime parameters, and make sure you can state what temperature was set to for any output somebody asks about.
- Record the reviewer's identity, what they changed, what they declined to change, and their reason.
- Record what caused an item to be routed for review, including the threshold in force and the score wherever routing was automatic.
- Hold the audit trail in append-only storage under a retention lock, with a copy in a system your AI vendor does not control.
- Test the arrangement by picking an output from six months ago at random and reconstructing it end to end. The gaps announce themselves within an hour.
Most teams find out what is missing at the worst possible moment, when a question arrives about an output produced routinely a year earlier by a system that has been updated twice since. Closing the gaps is unglamorous work and mostly configuration rather than construction. It is far cheaper than the alternative, which is withdrawing reliance on an output you cannot account for, in front of the people who were relying on it.
