What Evidence Should Internal Audit Request for a Generative AI Workflow?

A practical request list for reconstructing what the model received, what it produced, what the human did, and what happened next.

Ian Hafkenschiel

July 27, 202627 min read

What Evidence Should Internal Audit Request for a Generative AI Workflow?

By Ian Hafkenschiel · Published and reviewed July 26, 2026

Internal audit should request enough retained evidence to reconstruct one specific AI-assisted outcome without relying on interviews, memory, current configurations, or a recreated demonstration.

At minimum, the evidence should identify:

the exact model, provider, version, and material configuration;
the fully rendered prompt and system instructions;
the input data as it existed at the time;
the sources, records, or document chunks retrieved;
the original AI output before human editing;
the human reviewer and what that person saw;
the approval, edit, rejection, escalation, or override record; and
where the evidence was retained and how the records are linked.

For an AI workflow that calls tools or changes another system, internal audit should also request the ordered tool calls, authorization decisions, action results, downstream system receipts, and any rollback or exception records.

Policies, architecture diagrams, screenshots, model cards, and ordinary application logs may all be useful. None of them, by itself, proves what happened in a particular AI-assisted outcome.

That distinction matters because the Global Internal Audit Standards require internal auditors to gather information that is relevant, reliable, and sufficient. Information is sufficient when a prudent, informed, and competent person could repeat the engagement work and reach the same conclusions. (The Institute of Internal Auditors)

Begin with one workflow and one sampled outcome

“Provide evidence for our AI” is too broad to be a useful audit request.

Begin by identifying:

one named workflow;
one consequential AI-assisted output, recommendation, memo, classification, or action;
the date or period being tested;
the accountable business and technical owners;
the systems and third parties involved; and
the business outcome that followed.

The sample might be:

one AI-assisted credit memorandum;
one claim-routing recommendation;
one legal-research answer used in a filing;
one transaction flagged for investigation;
one candidate summary shown to a hiring manager;
one contract clause finding;
one customer response that triggered an operational action; or
one agent execution that changed a downstream record.

The audit question is not initially whether the organization has an AI policy. It is:

Can the organization show, from retained evidence, how this particular AI-assisted result was produced, reviewed, changed, approved, and connected to the action that followed?

Invariant Engineering calls this the Six-Month Reconstruction Test. The method deliberately narrows the examination to one workflow, one outcome, and the evidence trail that should exist when someone later asks what happened. (Invariant Engineering)

“Six months” is a practical stress-test horizon. It is not a universal legal retention period.

Three different kinds of evidence

A useful AI audit separates three evidence layers that are often blended together.

Evidence layer	Question it answers	Examples
Governance and control design	What was supposed to happen?	Policy, risk classification, approved use, architecture, accountable owner, vendor assessment, control description
Control operation	Did the surrounding controls operate?	Access reviews, change approvals, evaluations, monitoring records, incidents, exceptions, training records
Decision-instance reconstruction	What actually happened in this sampled run?	Model record, rendered instructions, input snapshot, retrieved sources, original output, human review, approval, downstream action

All three layers matter.

A policy can show management’s intention. An architecture diagram can show how the workflow was designed. A change ticket can show that a prompt release was approved.

But those records do not necessarily establish:

which prompt was rendered for the sampled run;
which source version was retrieved;
what the model originally produced;
what the reviewer actually saw;
what the reviewer changed;
why the final result was approved; or
whether the approved result matches the downstream action.

The eight evidence elements below address that third layer. They are not a replacement for a complete audit of AI governance, model risk, cybersecurity, data governance, privacy, fairness, performance, third-party risk, or compliance.

The fieldwork-ready evidence request

For one sampled AI-assisted outcome, request the following.

Evidence element	What to request	Common false positive
1. Model version	Provider, exact model or deployment identifier, material inference configuration, timestamp, routing or fallback record, and provider request identifier where available	“We use Provider X’s enterprise model”
2. Prompt or system instruction	The complete rendered instruction stack used for the run, including populated variables and injected context	The current prompt template in source control
3. Input data	The input snapshot as it existed when the output was generated, including material transformations and attachments	The source-system record as it exists today
4. Retrieved sources	Retrieval query, filters, source and version identifiers, exact chunks, ranking results, corpus or index version, and context supplied to the model	A link to the current document or citations in the final answer
5. Original output	The unedited response, structured fields, tool requests, refusals, or validation results produced by the model	The final human-edited memo or business record
6. Human reviewer	Reviewer identity, role, timestamp, information presented, applicable review instructions, and evidence that review occurred	A username showing that a screen was opened
7. Approval or override record	Approval, rejection, edits, escalation, override, rationale, authority, and material before-and-after differences	A final status of “approved” without the basis or changes
8. Retained evidence	Common identifiers, storage location, retention rule, access controls, integrity protections, and a tested retrieval procedure	“It should be somewhere in our logs”

These are the eight elements used in Invariant Engineering’s public reconstruction methodology and worksheet. (Invariant Engineering)

1. Exact model version and configuration

The request should identify more than the model family.

Ask for:

model provider;
model, snapshot, or deployment identifier;
hosted endpoint or deployment name;
invocation timestamp;
model-routing decision;
fallback model, if one existed;
relevant inference settings;
tool or function schema version;
guardrail or content-filter configuration;
provider request or response identifier; and
any organization-controlled model alias mapped to the underlying deployment.

The material configuration will depend on the system. It may include temperature, sampling settings, token limits, response format, seed behavior, tool availability, reasoning settings, or organization-specific routing rules.

Common false positives

These answers are usually insufficient:

“The workflow uses GPT.”
“We use the latest version of Claude.”
“The vendor automatically updates the model.”
“Here is the current deployment screen.”
“The model name is in the source code.”

A current configuration does not prove the historical configuration.

A model alias such as production-model may also be insufficient if the alias can point to different underlying deployments over time.

Suggested audit test

Select one sampled output and trace its execution identifier to the retained invocation record. Reconcile the retained model identifier to:

the configuration that was active at the time;
the organization’s routing logic;
the provider record, where available; and
the related change-management history.

Where the provider does not expose an immutable model version, document that limitation rather than silently treating a mutable model name as equivalent evidence.

NIST’s Generative AI Profile recommends including underlying foundation models, model versions, access modes, provenance information, and human-oversight roles in system inventory records. (NIST Publications)

2. The fully rendered prompt and system instructions

A prompt template is not necessarily the prompt that the model received.

The rendered instruction record should cover the complete message or instruction stack, as applicable:

system instructions;
developer or application instructions;
user input;
populated prompt variables;
injected policy text;
retrieved context;
few-shot examples;
guardrail instructions;
tool descriptions;
output-format instructions;
hidden workflow-generated messages; and
the version or release identifier of each material template.

Why rendering matters

Suppose the source-controlled template says:

Summarize the following transaction and identify possible policy exceptions: {{transaction_data}}

The model did not receive {{transaction_data}}. It received whatever the workflow inserted into that variable.

If the workflow populated the variable with:

stale data;
a truncated record;
conflicting values;
an outdated policy excerpt; or
text transformed by another model,

the template alone will not reveal it.

Common false positives

The current template from a prompt-management platform.
A screenshot of the user-visible chat message.
A Git commit without the populated variables.
A system instruction without the retrieved context.
A reconstructed prompt assembled after the audit request.
A statement that the application “has not materially changed.”

Suggested audit test

Compare:

the retained rendered instruction record;
the approved prompt-template version;
the source data used to populate the variables; and
the application’s rendering logic.

Confirm that the rendered record is captured during execution rather than recreated later from the current template.

COSO’s 2026 guidance treats prompts, system prompts, retrieval connectors, and transformation rules as governed configurations that should have version history, approval workflows, and rollback plans. (COSO)

3. Input data as it existed at decision time

The input request should identify what the AI system actually processed—not merely where the data originated.

Ask for:

the original user or system input;
structured fields submitted to the model;
attached documents or images;
the relevant source-system snapshot;
normalization, extraction, redaction, or transformation results;
timestamps;
source record identifiers;
material data-quality flags;
sensitivity classification; and
hashes or stable references where retaining full content is inappropriate.

Why a historical snapshot is necessary

Source data may change after the run.

A customer record can be corrected. A financial statement can be replaced. A policy can be revised. A document can be re-OCRed. An analyst can amend a narrative. A database query executed six months later may therefore return different data from what the model received.

The audit request must distinguish:

the authoritative business record;
the version of that record at the time;
the transformed model input; and
any conflicts introduced or discovered between them.

Common false positives

A current database export.
The final document rather than the submitted version.
An upstream record with no evidence of downstream transformation.
A hash with no controlled method for resolving it to the relevant historical content.
A screenshot with no timestamp or record identifier.

Suggested audit test

Reconcile the model-input snapshot to the relevant source records and transformation steps. Test whether the organization can explain material differences.

The IIA’s AI Auditing Framework emphasizes input-data governance, integrity, completeness, user access, processing controls, and traceability through effective audit logs or related information. (The Institute of Internal Auditors)

4. Retrieved sources and retrieval context

For a retrieval-augmented generation workflow, a final citation is not a complete retrieval record.

Request:

the retrieval query or queries;
query-rewriting output;
access-control and metadata filters;
corpus or knowledge-base identifier;
corpus, index, or collection version;
embedding-model version where relevant;
source-document identifiers and versions;
the exact chunks or passages returned;
retrieval scores and ranks;
reranking results;
deduplication or source-selection decisions;
context-window truncation;
the context actually supplied to the model; and
any sources rejected or excluded by a material control.

Why a document link is not enough

A document can change after the answer is generated.

The current version may differ from:

the version indexed at the time;
the version returned by retrieval;
the exact passage supplied to the model; or
the source the final answer claims to cite.

A reconstruction should be able to answer:

What information was available to retrieval?
What did retrieval select?
In what order?
What reached the model?
What source version did the selected text come from?

Common false positives

A link to the current policy.
A list of documents in the knowledge base.
Citations displayed in the final answer.
A vector-database record without the source version.
A retrieval trace that omits reranking or truncation.
The current corpus configuration.

Suggested audit test

For a sampled output:

resolve each retrieved chunk to its historical source version;
verify that the source existed and was approved at the time;
reconcile the retained chunk to the source text;
inspect the ranking and filtering record; and
confirm that the retained context matches what was supplied to the model.

NIST AI 600-1 addresses retrieval-augmented generation, source verification, data provenance, and documentation of how models are adapted for their specific generative task. It also describes provenance metadata as including origin, date and time, modifications, and sources. (NIST Publications)

5. The original model output

Internal audit should request the output as first produced—before an analyst corrected, shortened, reformatted, or approved it.

Depending on the workflow, the original-output record may include:

raw generated text;
structured response fields;
citations;
confidence or validation metadata;
a refusal;
a safety-filter result;
requested tool calls;
generated arguments;
provider response identifier;
finish reason;
truncation status; and
automated post-processing results kept separately from the raw response.

Why the original matters

Without the unedited output, the auditor cannot determine:

what the model contributed;
what the human corrected;
whether the human introduced an error;
whether a material claim survived review unchanged;
whether the final record conceals a weak original response; or
whether an automated transformation changed the output before review.

Common false positives

The final memorandum.
The text currently visible in the business system.
A reviewer’s summary of the AI output.
A recreated response generated from the same prompt.
A diff that lacks the original baseline.
A provider request identifier when the provider no longer retains the response.

Suggested audit test

Reconcile the original output to:

the rendered prompt;
the human-reviewed version;
the final approved record; and
the downstream action.

The system does not need to regenerate identical wording. Generative systems may not produce identical outputs on rerun. The stronger control is to retain the output that actually occurred.

6. The human reviewer and what that person saw

A reviewer name is useful, but it does not prove that meaningful review occurred.

Request:

reviewer identity;
organizational role;
review timestamp;
authority or qualification;
the version presented for review;
source material and warnings visible to the reviewer;
review checklist or instructions;
material alerts or conflicts shown;
reviewer disposition;
time sequence relative to approval and downstream action; and
escalation records, where applicable.

The reviewer-visible record matters

A reviewer cannot be expected to catch a conflict that the interface hid.

For example, the workflow may have retained:

the original source document;
the AI output; and
the reviewer’s approval.

But if the organization cannot show whether the reviewer was presented with the original source, the conflicting value, or the relevant policy exception, the existence of a human approval does not prove that the control operated as intended.

Common false positives

A username in an access log.
A record that the page was opened.
A generic statement that “all outputs receive human review.”
The approved final record without the reviewer-visible version.
A training certificate presented as evidence of review.
A workflow status that changed automatically when the reviewer closed the screen.

Suggested audit test

Inspect the reviewer-visible record and compare it with the control’s stated purpose.

Determine whether the reviewer had:

the necessary source information;
enough time and authority to challenge the output;
a clear method to accept, reject, modify, or escalate it; and
evidence that the selected disposition was recorded.

For high-judgment GenAI outputs, COSO’s 2026 guidance emphasizes qualified reviewers, formal sign-off responsibilities, citations, capture of disagreement or contrary information, and decision records that include sources, model or configuration version, and known limitations. (COSO)

7. Approval, editing, escalation, and override

Approval is not a single binary field in every workflow.

The relevant record may need to distinguish among:

accepted as generated;
accepted after modification;
rejected;
returned for correction;
escalated;
overridden;
approved with an exception;
approved subject to another control; or
prevented from producing a downstream action.

Request:

the disposition;
reviewer or approver;
timestamp;
approval authority;
original and final versions;
material edit diff;
stated reason;
exception or override rationale;
supporting evidence;
escalation;
any second-level approval; and
the relationship to the downstream business action.

Do not capture meaningless detail

A useful review trail does not necessarily require permanent retention of every cursor movement or keystroke.

The objective is to preserve material evidence of:

what changed;
who changed it;
why it changed;
what contrary information was considered;
who had authority to approve the result; and
whether the final action remained within the permitted workflow boundary.

Common false positives

“Approved” with no approver.
An approver with no version reference.
A final version with no original.
A text diff with no reason.
An override count with no underlying cases.
A reason stored in an unlinked email or chat.
A downstream action that occurred before approval.

Suggested audit test

Sample an approval, a material edit, and an override or exception.

For each, trace:

the original AI output;
the information presented to the reviewer;
the recorded disposition;
the rationale;
the final approved artifact; and
the downstream action.

NIST’s Generative AI Profile specifically recommends monitoring and documenting instances in which human operators or other systems override a generative AI decision and evaluating those cases. (NIST Publications)

8. Retained evidence, integrity, and retrievability

Evidence is not useful merely because it was once generated.

Request:

common workflow, transaction, case, and execution identifiers;
evidence-storage location;
ownership;
access restrictions;
retention and deletion rules;
record-creation timestamps;
integrity or tamper-evidence controls;
links among records;
legal hold or exception handling where applicable;
failed-capture monitoring;
evidence-completeness checks; and
the documented retrieval procedure.

Common identifiers are essential

The workflow may create records in:

the application database;
a model gateway;
an observability platform;
a prompt-management system;
a document store;
an approval tool;
a case-management system; and
the final system of record.

A timestamp alone may not reliably join them.

A stronger design propagates a controlled transaction, case, or execution identifier through each material stage.

Integrity should be proportionate

Not every workflow requires the same technical mechanism.

Depending on the consequences and threat model, relevant controls may include:

append-only storage;
cryptographic hashes;
digital signatures;
write-once retention;
restricted service identities;
immutable object versions;
controlled record amendments;
separation between operational users and evidence administrators; or
periodic completeness and integrity testing.

The objective is not to claim that every record is mathematically immutable. It is to establish reasonable confidence that the evidence is complete, linked, protected from unauthorized change, and retrievable when needed.

Suggested audit test

Ask a knowledgeable employee who was not involved in the original transaction to retrieve the evidence using the documented procedure.

Record:

which artifacts were found;
how long retrieval took;
which required interviews or manual inference;
which records could not be linked;
which fields were populated only from current configuration; and
which evidence could not be produced.

That exercise often reveals a gap that a policy review will not.

Additional evidence when the AI calls tools or takes action

An AI workflow that only drafts text presents a different risk from an AI agent that:

queries a customer system;
sends a message;
changes a record;
opens or closes a case;
approves a transaction;
creates code;
initiates a payment;
changes access; or
routes work to another person or system.

For action-capable workflows, request:

agent or service identity;
execution and parent-run identifiers;
ordered reasoning or orchestration steps to the extent retained and appropriate;
tool name and version;
tool arguments;
target resource;
policy and authorization result;
credentials or delegated authority used, without exposing secrets;
tool response;
error and retry history;
state before and after the action;
downstream system receipt;
human approval gate;
timeout or cancellation record;
rollback or compensating action; and
final outcome.

The auditor should be able to distinguish among:

the model proposing an action;
the orchestration layer authorizing it;
the tool executing it;
the downstream system accepting it; and
the business workflow treating it as final.

A model-generated tool call is not proof that the tool executed successfully. An HTTP success code is not necessarily proof that the intended business state changed. The downstream receipt or system-of-record entry closes that branch.

Why application logs are not a complete AI audit trail

Ordinary logs remain useful. The problem is assuming that one log source answers every reconstruction question.

Evidence source	What it may establish	What it may not establish
Application log	User, request time, endpoint, response code, error	Rendered prompt, complete input, retrieval context, original output, reviewer basis
Model-provider log	Provider request, model name, token use, possibly request and response	Upstream transformations, human edits, approval, downstream outcome
Observability trace	Execution path, latency, service calls, errors	Business authority, evidence integrity, review sufficiency, retention compliance
Prompt-management history	Template versions and releases	Which populated values were rendered in a particular run
Business-system audit log	Final record change, user, timestamp	Original AI contribution, retrieved sources, review and edit history
Identity log	Authentication and access	Whether the person performed the required substantive review
Decision evidence record	Linked run-level history	Whether the entire AI governance and control environment is effective

A good reconstruction frequently draws from several systems.

The auditability problem is not solved merely by creating more logs. It is solved by deciding:

which evidence matters;
where it is captured;
how it is linked;
how long it is retained;
who can change it;
how capture failures are detected; and
how an auditor can retrieve it without reverse-engineering the production system.

Synthetic example: an AI-assisted commercial credit memorandum

The following example is fictional. It is not a client case study, audit opinion, legal opinion, certification, or compliance conclusion.

Workflow boundary

In the synthetic workflow, Example Regional Bank uses AI to support commercial credit memorandum drafting and possible policy-exception identification.

The AI may:

assemble approved inputs;
retrieve applicable policy material;
draft sections of the memorandum; and
identify possible exceptions for analyst review.

The AI may not:

approve or deny credit;
set pricing or terms;
assign a final risk rating;
produce an adverse-action reason; or
replace analyst judgment.

The sampled transaction is identified as SCM-2026-0042.

The conflicting evidence

The fictional source set contains three relevant values:

policy threshold for largest-customer concentration: 25%;
dated structured snapshot: 31%; and
older narrative input: 28%.

That creates a simple but consequential reconstruction question:

Which value did the model receive, which value did it use, was the conflict visible to the analyst, and how was the final exception treatment approved?

A final memorandum that correctly states 31% is not enough evidence by itself.

Internal audit should still determine:

whether the rendered prompt contained 28%, 31%, or both;
which source was treated as authoritative;
whether the retrieval record included the applicable policy version;
whether the model flagged the conflict or silently selected one value;
what the original draft said;
what the analyst saw;
what the analyst changed;
whether the exception was explicitly accepted, rejected, modified, or escalated; and
whether the approved memorandum was the version connected to the downstream action.

The synthetic record chain

The packet uses linked synthetic records including:

Record	Illustrative purpose
`SCM-2026-0042`	Common synthetic transaction identifier
`SYN-OUT-0042-V0`	Original unedited model output
`SYN-MEMO-0042-V2`	Reviewed memorandum version
`SYN-APR-0042-01`	Approval record
`SYN-BOOK-0042-01`	Downstream action record
`SYN-REC-0042-01`	Reconstruction record
`SYN-EVIDX-0042-01`	Evidence index

The point of these identifiers is not the naming convention. It is that a reviewer should be able to move from the sampled transaction to the model invocation, source record, original output, human-reviewed version, approval, and downstream action without relying on approximate timestamps or personal knowledge.

Reconstruction result

The synthetic packet evaluates the eight elements as:

Fully present: 5
Partial: 2
Missing: 1
Overall posture: Partial auditability
Confidence: Moderate

That result illustrates an important distinction:

A workflow can be reconstructable in outline while still failing to provide enough evidence to resolve a material question confidently.

The packet’s remediation backlog therefore includes controls to:

require structured accept, reject, or modify dispositions for exceptions and conflicting inputs;
detect conflicting structured and narrative values;
prevent silent precedence between conflicting sources;
require either explicit resolution or an unresolved-conflict marker before generation;
map evidence artifacts to records-control requirements; and
run an automated evidence-completeness check before performing a fresh reconstruction test.

A useful retest is to repeat the 28% versus 31% conflict and verify that silent precedence is no longer possible.

Inspect the full fictional Synthetic Auditability Sample Packet. See the AI Workflow Evidence Map, Six-Month Reconstruction Test, Auditability Gap Register, Audit Committee Briefing Memo, and 30/60/90-Day Remediation Backlog.

How to begin without sensitive production data

An organization can begin with a design review and controlled synthetic run. Useful non-sensitive inputs include workflow diagrams, role descriptions, evidence schemas, logging-field inventories, blank review forms, and synthetic prompt-and-response records.

The synthetic run should include a difficult condition—a conflicting or outdated source, a human modification, an override, a tool error, or a failed downstream action. A clean happy path will not show whether the workflow records exceptions.

Testing operating effectiveness may eventually require an approved private sample or appropriately redacted production-derived evidence. Establish scope, authority, handling requirements, access restrictions, and a secure review channel before that step. A design review or synthetic test can expose gaps, but it is not proof that production controls operated effectively.

Invariant Engineering’s current Audit Grill-Me Sprint is designed to begin without sensitive production-data access wherever possible. Public intake is categorical and non-confidential; private evidence handling starts only after fit approval and the required engagement and secure-intake steps. (Invariant Engineering)

How to run the Six-Month Reconstruction Test

1. Choose one outcome that matters

Select an outcome consequential enough that management would need to explain it if challenged.

Avoid choosing only the cleanest demonstration record.

2. Freeze the reconstruction question

Write the question before gathering evidence.

For example:

Can the organization demonstrate which policy source, model configuration, input values, original output, analyst changes, and approval supported commercial credit memorandum SCM-2026-0042?

This prevents the evidence request from drifting into a general system walkthrough.

3. Request the eight elements

Request retained artifacts, not verbal descriptions of what the system is expected to do.

4. Validate the artifacts

For each element, determine whether it is:

Present: complete enough to answer the reconstruction question;
Partial: some evidence exists, but an important field, link, version, or corroborating record is missing;
Missing: the element cannot be produced from retained evidence; or
Inaccessible: it may exist, but cannot be retrieved under the current authority, contract, retention setting, or technical design.

“Inaccessible” should not be silently scored as present.

5. Identify false positives

Examples include:

current prompt presented as historical prompt;
current source presented as retrieved source;
final output presented as original output;
reviewer identity presented as proof of review;
an application timestamp presented as a common execution identifier; or
a provider model alias presented as an immutable model version.

6. Reconcile the evidence chain

Test whether the evidence supports a coherent sequence:

input → instructions → retrieval → model output → human review → approval or override → downstream action → retained record

A set of individually plausible records may still fail if they cannot be linked to the same run.

7. Assess the consequence of each gap

A missing source-version record may matter more in a legal-research or policy-exception workflow than in low-risk internal brainstorming.

A missing original output may matter more where human review is a key control.

A missing tool receipt may matter more where the system can alter a customer or financial record.

8. Prioritize remediation

Prioritize gaps based on:

consequence;
likelihood of examination;
difficulty of later reconstruction;
control dependency;
evidence sensitivity;
implementation effort; and
whether the workflow is scaling.

9. Retest

After remediation, select a fresh sample and repeat the test.

Do not rely solely on a demonstration generated by the implementation team to show that its own control works.

For the public worksheet’s quick posture bands, count the elements that are fully present:

0–3: High reconstruction risk
4–6: Partial auditability
7–8: Stronger evidence posture

The result is an evidence-posture indicator, not a compliance score or audit opinion. (Invariant Engineering)

Retain enough evidence—but not everything forever

Auditability does not justify indiscriminate retention.

Prompts, inputs, retrieved context, and outputs may contain:

personal information;
health or financial information;
privileged material;
trade secrets;
customer confidential information;
security-sensitive instructions;
source code;
credentials or secrets; or
data subject to contractual or jurisdictional restrictions.

Evidence design should therefore address both reconstructability and minimization.

Relevant techniques may include:

redaction before model invocation;
field-level retention rules;
pseudonymized identifiers;
controlled references to separately governed source records;
encrypted evidence stores;
restricted evidence-review roles;
shorter retention for raw content than for non-content metadata;
cryptographic hashes where they genuinely support verification;
approved deletion and legal-hold procedures; and
explicit documentation of what is intentionally not retained.

A hash is not a substitute for the underlying evidence unless the organization has a controlled method for resolving and verifying the referenced record.

The correct retention period depends on the workflow, governing requirements, contractual commitments, litigation and investigation needs, privacy obligations, security risk, and the organization’s records-management policy.

The Six-Month Reconstruction Test asks whether the evidence would still exist after a realistic delay. It does not prescribe six months as the appropriate retention period for every record.

How this relates to established standards and guidance

Global Internal Audit Standards

The IIA’s 2024 Global Internal Audit Standards require relevant, reliable, and sufficient information to support engagement results. They also require engagement evidence to be documented so that an informed and competent person can repeat the work and derive the same results.

The eight-element reconstruction test applies that repeatability principle to a sampled AI-assisted business outcome. It does not replace the internal auditor’s responsibility to establish appropriate objectives, scope, criteria, sampling, and work programs. (The Institute of Internal Auditors)

The IIA’s Artificial Intelligence Auditing Framework

The IIA’s 2024 AI Auditing Framework addresses governance, management, input data, third parties, testing, transparency, and auditability. It notes the importance of maintaining traceability through effective audit logs or related information as AI augments important business and compliance processes. (The Institute of Internal Auditors)

Invariant’s method adds a narrower fieldwork question: can the auditor produce the run-level evidence behind one specific outcome?

NIST AI RMF 1.0 and NIST AI 600-1

NIST AI RMF 1.0 was released in January 2023 as a voluntary framework for managing AI risk. NIST published the Generative AI Profile, NIST AI 600-1, in July 2024 as a companion resource focused on generative AI. (NIST)

The Generative AI Profile supports practices involving:

model and data provenance;
underlying model versions;
human-oversight roles;
source verification;
documentation of retrieval-augmented generation;
monitoring and documenting overrides;
version history and metadata; and
tracking content origins and modifications. (NIST Publications)

NIST does not prescribe Invariant’s eight-element packet, and use of the Invariant method does not establish conformity with the NIST AI RMF.

COSO’s 2026 Generative AI guidance

COSO’s Achieving Effective Internal Control Over Generative AI applies the COSO Internal Control—Integrated Framework to generative AI capabilities.

It identifies prompts, retrieval connectors, transformation rules, source completeness, model changes, reviewer competence, and human–AI collaboration as relevant control concerns. It recommends governed configurations with version histories, approvals, and rollback plans, and provides illustrative artifacts such as decision memoranda, prompt libraries, source inventories, model cards, review records, and retrieval configuration logs. (COSO)

A reconstruction packet can provide evidence relevant to those concerns. It does not, by itself, establish that the organization’s entire system of internal control is effective.

Applicable laws and regulatory requirements

Some workflows may be subject to legal requirements concerning:

record retention;
explanations or notices;
human oversight;
data protection;
discrimination;
model governance;
consumer rights;
financial records;
professional responsibility; or
regulator access.

Those obligations vary by jurisdiction, industry, workflow, and role.

The evidence request should be adapted with qualified legal, compliance, privacy, security, records-management, and professional input as appropriate. A technically complete evidence packet does not by itself prove legal compliance.

Frequently asked questions

Is a screenshot sufficient evidence?

Usually not by itself.

A screenshot may support the record, but it may omit:

machine-readable values;
timestamps;
hidden instructions;
source versions;
complete content;
record identifiers;
prior versions; or
evidence of integrity.

Use screenshots as corroborating artifacts where appropriate, not as an automatic substitute for underlying records.

Is a provider request identifier enough?

No.

A provider identifier may help retrieve or corroborate a model invocation, but it may not establish:

the upstream input transformation;
the complete rendered instruction stack;
the human-reviewed version;
approval;
the downstream action; or
retention outside the provider’s system.

Must the exact prompt be retained?

For strong run-level reconstruction, the organization should be able to establish the complete instructions actually supplied to the model.

That does not necessarily mean placing sensitive prompt content into an unrestricted log. The record can be retained in a protected evidence store or represented through an approved architecture that preserves the necessary historical evidence without creating an unacceptable security or privacy risk.

Can an assessment begin without production data?

Yes.

A design review and controlled synthetic execution can identify substantial evidence gaps without sensitive production data.

However, a synthetic test alone should not be used to conclude that production controls operated effectively over a population of real transactions.

How long should AI evidence be retained?

There is no universal period for every workflow.

Retention should reflect applicable law, records policy, business consequences, investigation needs, privacy, security, contractual requirements, and the organization’s risk assessment.

Six months is a reconstruction-test horizon, not a universal rule.

Should the organization rerun the model during reconstruction?

A rerun may support testing, but it is not a substitute for the historical record.

The model, source corpus, configuration, or provider infrastructure may have changed, and generative output may not be identical even under similar conditions.

Retain what actually happened.

Does a complete evidence packet prove that the AI output was correct?

No.

A packet may make it possible to test accuracy, control operation, source use, and human review. It does not prove correctness merely by being complete.

A well-documented wrong result is still wrong—but it can be examined, understood, and remediated.

Does a complete packet prove compliance?

No.

The packet is evidence-readiness support. Compliance depends on the applicable legal and regulatory requirements, facts, control objectives, professional judgments, and scope of examination.

What if a third-party provider will not disclose an exact model version?

Document the limitation.

Then evaluate:

whether another stable deployment identifier exists;
what provider request metadata is available;
whether contractual notice of model changes exists;
whether organization-controlled routing and evaluation records compensate for the limitation;
whether the workflow’s risk remains acceptable; and
whether the limitation should be reported as an evidence gap.

Do not record the model element as fully present merely because the vendor is well known.

Test the evidence before someone asks for it

A consequential AI-assisted result should not depend on institutional memory.

For one sampled outcome, your organization should be able to show:

the model;
the rendered instructions;
the historical input;
the retrieved sources;
the original output;
the reviewer-visible record;
the approval or override; and
the retained, linked evidence trail.

That does not answer every AI governance question.

It answers a narrower question that becomes load-bearing when an auditor, regulator, customer, executive, investor, or litigant asks:

What happened in this specific case, and what evidence proves it?

Inspect the fictional sample packet

See how the five Audit Grill-Me deliverables fit together for an AI-assisted commercial credit memorandum:

AI Workflow Evidence Map
Six-Month Reconstruction Test
Auditability Gap Register
Audit Committee Briefing Memo
30/60/90-Day Remediation Backlog

View the Synthetic Auditability Sample Packet

Check one workflow in three minutes

Answer eight closed-ended questions without submitting confidential workflow details.

Run the Three-Minute Evidence Check

Review the methodology

See the public definition of the Six-Month Reconstruction Test and its eight evidence elements.

Read the Audit Grill-Me Methodology

Need a private, fixed-scope stress test?

The Audit Grill-Me Sprint currently covers one AI workflow over ten business days for a fixed price of $9,500, producing the five defined evidence-readiness deliverables. It is a technical auditability and evidence-readiness assessment—not legal advice, an independent audit opinion, or compliance certification. (Invariant Engineering)

Compare Fixed-Price Engagements

Apply for a Fit Review