Claude Partner Network memberAI, engineered for the enterprise
Governance

The evidence an examiner asks for when AI touched the decision.

No examiner has ever closed a finding because a firm promised its AI was responsible. Findings close on evidence. When a decision that AI touched gets pulled into a bank exam, a market conduct review, an OCR audit, or discovery, the question is never whether you used a model. It is: show me what it did, and show me who was accountable.

The request looks the same in every vertical

A bank examiner working under SR 11-7 wants to see how the model was validated, what version produced the output in question, and where a human intervened. A state Department of Insurance running a market conduct exam wants the same thing for a claims recommendation. OCR, investigating a complaint, wants to know what PHI the system saw and who accessed the output. Opposing counsel in a malpractice case wants the record of what the clinician was shown before the decision was made.

Four different regulators, one shape of request. Reconstruct this specific decision. Show the inputs, the system's contribution, and the human's role. Do it from records you kept at the time, not from a narrative you assembled after our letter arrived. Reconstructions written after the request carry almost no weight, and examiners can tell the difference.

The five artifacts, in the order they get asked for

Start with input provenance. Which documents, records, or data fields did the system actually consume for this decision? Not what the corpus contains in general. What this run retrieved, with timestamps. If your RAG pipeline cannot say which policy version it cited on March 12, you cannot answer the first question.

Then model and version. Which model, which configuration, which system prompt was live when the output was generated? Models change. A defensible record ties every output to the exact system state that produced it. Third is the prompt and retrieval trace: the full request, the passages retrieved, and the citations the model relied on. Fourth, and most scrutinized, is the human decision record. Who reviewed the output, what did they see, did they accept, modify, or override it, and when? An approval click with no record of what was approved is not a decision record. Fifth is retention: all of the above, held for the period your regulator expects, with access controls showing who has touched the record since.

1Input provenancewhat the system consumed for this specific decision, timestamped
2Model & versionthe exact model, configuration, and system prompt in effect
3Prompt & retrieval tracethe request, the passages retrieved, the citations relied on
4Human decision recordwho reviewed, what they saw, accept or override, and when
5Retention & accessrecords held for the required period, with a log of who touched them
The five artifacts, roughly in the order an examiner requests them.

What is reasonable to produce versus what teams scramble for

Some of this is cheap if you decided to capture it on day one and nearly impossible to recover if you did not. Logging the model version and timestamp costs almost nothing at build time. Reconstructing which version was live eight months ago from deployment tickets is an archaeology project.

The scramble artifacts share a pattern: they depend on state that existed only at the moment of the decision. The retrieved passages. The reviewer's screen. The corpus as it stood that day. If you did not write them down then, they are gone. The producible artifacts are the ones your architecture emits as a side effect of running: request logs, version tags, access records. The design goal is to move everything from the left column to the right.

Scramble after the request

  • Which corpus version was cited that day
  • What the reviewer actually saw on screen
  • Why an override happened, from memory
  • Which system prompt was live last quarter

Produced from standing records

  • Timestamped retrieval trace per decision
  • Output shown to reviewer, captured at review
  • Override reason recorded at the moment of override
  • Version-tagged prompts and configurations
Evidence that depends on point-in-time state must be captured at that point in time.

Evidence is a design decision, not a documentation task

Teams often treat examiner readiness as a writing exercise: assemble the policy, describe the controls, keep the binder current. The binder matters, but it answers the question about your intentions. The artifacts answer the question about this decision. Only architecture produces those.

This is why auditability sits inside our Governed-by-Design framework rather than beside it. In the systems we build on Claude, every response is cited and logged as a condition of shipping, human review is a recorded step in the workflow rather than an assumed one, and access controls generate their own trail. Engagements are designed to support the evidentiary expectations of frameworks like SR 11-7, HIPAA, and privilege obligations under the FRCP. We do not certify compliance, and no vendor honestly can. What we can do is make sure that when the request arrives, your answer is an export, not an investigation.

  • Log at the decision level. One record per output, tying inputs, retrieval, model version, and reviewer action together under a single identifier.
  • Capture the reviewer's view. Store what the human was shown, not just the fact that they approved.
  • Version everything the model depends on. Prompts, configurations, and corpus snapshots, each tagged so any output can be traced to its exact system state.
  • Record overrides with reasons at the moment they happen. A one-line rationale captured live outweighs a paragraph written a year later.
  • Set retention to your longest applicable clock. Exam cycles, complaint windows, and litigation holds run on different calendars. Keep records for the longest one.

Run the request against yourself first

Pick one AI-assisted decision from last quarter and try to produce the five artifacts for it this week. Most teams find they can produce two, partially reconstruct one, and cannot produce the rest at all. That gap is the finding an examiner would write, and it is fixable before anyone asks.

Our free Claude Readiness Assessment includes exactly this exercise: we walk a real decision back through your current stack and show you which artifacts exist, which are recoverable, and which need to be built. If gaps are architectural, a Governed Pilot fixes them under a fixed scope with a success guarantee. If the agreed criterion is not met, you do not pay.

The examiner's question is already written. Show me what the system did, and show me who was accountable. The only variable is whether your answer takes an afternoon or a quarter.

Take the readiness assessment How we help