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 evidence questions to adapt for higher-consequence healthcare and PHI workflows. Move from assurances to inspectable operational records, testing, and coverage evidence.

Version
v1.0
Published
11 June 2026
Format
OVERT or equivalent
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 is an evidence set your reviewer can inspect: signed records, published keys, tests, and coverage analysis. A signed record checks integrity and signer attribution for covered fields; it does not alone establish source truth, control effectiveness, or complete capture.

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

Independently checkable records in OVERT or an equivalent inspectable format.

The vendor produces independently checkable records for the workflows in scope. If contemporaneity matters, require separate trusted-time and deployment evidence rather than inferring timing from the record alone.

Signing and witness path stated precisely.

Require the vendor to identify who signs each receipt. Portal receipts may carry a Glacis service-operated witness countersignature and inclusion proof; SDK or self-hosted receipts may be operator-signed only. A second signature does not by itself establish organizational independence.

Hash-chained receipt history.

A reviewer can detect modification within a sequence they already possess. Detecting omitted events or suffix truncation also requires an externally held checkpoint, expected sequence count, or other reference outside the vendor-controlled history.

The configured path reports control invocation and outcome at the stated boundary.

The record identifies the configured path’s claim about PHI and sensitive-data control invocation and outcome. Corroborate execution and boundary coverage separately.

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, versioned verification-key history.

The trust material needed to verify records is published and versioned, with safe rotation and enough history to check records 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 record to see what passing looks like.

03

Boundary & egress

A documented, data-minimizing evidence path.

Producing evidence should not create an unnecessary copy of protected content. Ask which payloads remain local, which hashes, outcomes, signatures, or metadata travel, and how that boundary is tested.

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.

Scoped incident reconstruction with bounded disclosure.

Records can support reconstruction of covered events. Completeness and any PHI disclosure depend on the retained fields, coverage, and investigation procedure.

Evidence retention policy stated in writing.

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