AI Vendor Runtime Evidence Checklist · v1.0 · June 2026 Maintained by GLACIS · glacis.io

Free checklist · No form, no email

AI Vendor Runtime Evidence Checklist.

Twelve requirements for any AI vendor whose system touches patients or PHI. Not assurances that controls exist. Evidence that they ran.

Version
v1.0
Published
11 June 2026
Format
OVERT 1.1 receipts
License
Free to copy and redistribute

How to use

01

Attach it to the questionnaire.

Add this checklist to the security questionnaire your team already sends AI vendors. It stands alone: no tooling, no account, and no Glacis relationship required.

02

Require the artifacts before contract.

An acceptable answer to each item is an artifact your reviewer can check: receipts, published keys, an evidence pack. A policy PDF or a commitment to log is not evidence that controls ran.

03

Verify one receipt yourself.

Verification runs in your browser at glacis.io/verify. It takes about a minute, needs nothing from the vendor, and shows your reviewers what a passing receipt looks like.

Vendor System under review Reviewer Date
01

Runtime evidence

Verifiable runtime receipts in the open OVERT format.

The vendor produces independently verifiable runtime receipts in the open OVERT format (v1.1) for the workflows in scope, generated at execution time rather than assembled afterward.

Operator-signed and independently countersigned.

Each receipt is signed by the vendor as the operator and countersigned by an independent witness, so no single party can alter the record after the fact.

Hash-chained receipt history.

Receipts are hash-chained in sequence, so gaps and deletions are detectable by your reviewer, not just by the vendor.

Control execution recorded at the model egress boundary.

Execution of PHI and sensitive-data controls is recorded at the model egress boundary: the point where data would leave the vendor’s environment.

02

Verification

Verification without vendor tooling.

Receipts verify offline or in-browser, with no vendor software, vendor account, or vendor assistance in the loop.

Published, stable verification keys.

The keys needed to verify receipts are published and stay stable, so receipts remain checkable across the life of the contract.

A sample receipt your team verifies themselves.

The vendor provides a sample receipt during review, and your reviewer checks it independently. You can verify a real signed receipt now to see what passing looks like.

03

Boundary & egress

Zero sensitive-data egress in the evidence path.

Producing evidence must not create a new data flow: fingerprints cross the boundary, content does not. No prompts, outputs, or PHI leave the environment to make the proof.

Documented coverage accounting.

The vendor states in writing which traffic and action classes are in scope for evidence and which are excluded, so your review covers what the receipts cover.

04

Review artifacts

An evidence pack assembled from receipts.

Receipts are assembled into an evidence pack your security and compliance teams can review without specialist tooling.

Incident reconstruction without new PHI disclosure.

When something goes wrong, the sequence of events can be reconstructed from receipts without any new disclosure of PHI to the people investigating.

Evidence retention policy stated in writing.

The vendor states how long receipts are retained, where they live, and what survives contract termination.