Use this worksheet before approving an AI tool pilot, vendor evaluation, or rollout. It helps leaders move from “the demo looked good” to “the claim is testable, the risks are visible, and the next step has a boundary.”
How To Use This Worksheet
Work top to bottom. First capture the claim, then define how it could be tested, then decide what evidence is strong enough for the current stage: demo, reference, pilot, or rollout.
Do not treat any single table as approval. The decision happens only in the Go / Limit / Stop Sign-Off after evidence, data gates, residual risk, and ownership are visible.
Evidence Tiers At A Glance
- Demo: proves a scenario is possible, not that it fits your workflow.
- Reference: shows another organization used it, not that your controls match.
- Pilot: tests realistic examples with review rules and failure cases.
- Rollout: expands only after evidence, support ownership, monitoring, and rollback are clear.
Claim Inventory
Capture the claim before evaluating it. A good inventory turns a marketing phrase into a decision question someone can test.
| Claim | What it appears to promise | Who would rely on it |
|---|---|---|
| AI-powered search finds the right answer. | Search can answer from approved source material without leaking or inventing details. | users who rely on search results for work |
Rewrite each broad claim as a specific question:
- What task does the tool perform?
- What source material does it use?
- What output does it produce?
- What result would count as success?
- What wrong result would matter?
Test Design
For each claim, define a check. A weak test proves the happy path; a useful test includes edge cases, wrong inputs, permission boundaries, and expected failure behavior.
| Claim | Test example | Pass condition | Stop condition |
|---|---|---|---|
| AI-powered search finds the right answer. | ask a question where the answer exists in an allowed source and a similar answer exists in a restricted source | cites only the allowed source and says when evidence is missing | exposes restricted material or invents a confident answer |
Include normal examples, edge cases, and expected failure cases. A tool that only passes the happy path is not proven.
Data And Security Gates
Mark each gate as pass, partial, or not ready.
Do not let a strong demo outrun the data review. If the tool cannot explain access, retention, training use, and auditability, the next step should be limited.
- Approved data types are defined.
- Sensitive data boundaries are clear.
- Retention and training-use expectations are understood.
- User permissions are enforced when the tool searches source material.
- Prompt, output, and action audit trails are available when needed.
- Tool access is limited to the workflow being tested.
- Material model, feature, source, or permission changes trigger retesting.
Gate decision:
Data and security are
[pass / partial / not ready]because[evidence or gap].
Framework Mapping
Use public frameworks as prompts for better questions.
Frameworks help keep the review consistent. They do not replace legal, security, procurement, or architecture review.
| Lens | Question to answer | Evidence |
|---|---|---|
| NIST AI RMF | What risk is being governed, mapped, measured, and managed? | |
| OWASP LLM Top 10 | Which AI-specific misuse or security patterns were considered? | |
| CSA AI Controls Matrix | Which control responsibilities are clear across buyer, vendor, and operator? |
The worksheet does not replace security, legal, or procurement review. It gives those teams clearer inputs.
Evidence Collected
Record what you actually have.
Separate what was shown from what was proven. Demo evidence can justify exploration; rollout needs real examples, failure cases, reviewers, and operating ownership.
- Demo evidence:
- Reference evidence:
- Pilot evidence:
- Evaluation examples:
- Failure examples:
- Review burden observed:
- Open gaps:
If all evidence is demo evidence, say so. That may be enough for exploration, but it is not enough for broad rollout.
Residual-Risk Register
Residual risk is what remains after controls are named. If no owner can accept or reduce a risk, the decision is not ready.
| Risk | Current control | Remaining gap | Owner |
|---|---|---|---|
Common residual risks:
- unsupported answers that sound confident
- weak source traceability
- unclear review ownership
- data handling uncertainty
- access that is broader than the workflow needs
- support or change-notice gaps
- users treating draft output as final
Worked Mini-Example
Claim: “The tool gives accurate answers from company documents.”
Testable question: Can it answer from approved documents, cite the source, and refuse when the source does not contain the answer?
Test: use one answer in approved source material, one similar answer in restricted material, and one question with no source answer.
Evidence gate: go only if the tool cites the approved source, does not expose restricted material, and labels the missing-source case as unknown.
Decision: limit. The tool may continue to a small pilot for approved documents only; broader rollout waits for permission-boundary evidence and support ownership.
Common Mistakes
- approving a tool on demo evidence alone
- accepting “approved, but watch it” instead of writing a boundary
- testing only happy-path examples
- letting access be broader than the workflow requires
- skipping named ownership for review, escalation, support, and rollback
Go / Limit / Stop Sign-Off
- Reviewer:
- Date:
- Tool or workflow:
- Evaluation stage: demo / reference / pilot / rollout
- Decision: go / limit / stop
- Approved scope:
- Explicit limits:
- Required next evidence:
- Owner for review and escalation:
- Rollback or pause path:
Decision statement:
We are choosing
[go / limit / stop]because[evidence]. The next boundary is[scope].
Reference Links
These references are for deeper review. The worksheet above is original LIW training guidance.