Use this risk checklist before you send a weak due diligence packet.
When procurement, security, privacy, or counsel already wants an AI due diligence packet, the fastest mistake is forcing half-known facts into a final answer. Use this checklist to tighten the named vendor chain, workflow scope, customer impact, training stance, proof links, approval owner, and unresolved risks before you branch into the template, scorecard, framework map, or audit.
This page is for the SaaS team answering the buyer's due diligence request. It helps clean up the operating facts before final contract, privacy, security, or counsel review.
Use this page when the due diligence packet is not ready yet
The vendor chain is still fuzzy
Name the visible AI vendor plus every downstream host, storage, analytics, support, or logging provider that touches the workflow.
The scope and owner are still hand-wavy
Capture the workflow reviewed, customer scope, approval owner, and next review gate instead of hiding behind general trust-center language.
The proof trail is thin
List the public links, screenshots, tracker rows, terms, review dates, and unresolved questions the buyer will ask for next.
Choose the lightest next route that matches the blocker.
Use the checklist to stabilize facts first. Move to the scorecard if you want a readiness score, the template if the packet shape is already obvious, the framework map if the buyer named NIST AI RMF or ISO/IEC 42001, and the evidence map if only one claim is weak.
The shortest useful AI due diligence risk checklist
| Checklist item | What to capture | Why it matters |
|---|---|---|
| Named AI vendor and workflow | The primary vendor, exact workflow, and whether it is planned, active, or replacing another process. | Prevents vague diligence answers that never identify the system under review. |
| Downstream provider chain | Hosting, storage, analytics, support, observability, or secondary model providers tied to the workflow. | Buyers increasingly care about the chain behind the top-level vendor. |
| Data categories and customer scope | What data is touched, which products or customers are in scope, and whether any region or contract requires special handling. | Scope questions drive most follow-up loops. |
| Training, retention, and review stance | Your current operating position plus the supporting vendor term, internal note, or reviewer comment. | Strong buyer-language packets need proof behind the stance, not only the stance itself. |
| Approval owner and escalation path | Who owns the packet, who approves changes, and what event triggers the next recheck. | Makes the packet executable instead of descriptive. |
| Proof links and open risks | Public pages, screenshots, tracker rows, framework notes, and the unresolved issues still blocking the packet. | Lets procurement, security, privacy, or counsel see exactly what is still open. |
What to do with the checklist result
Use the scorecard
If the owner path, scope, proof links, or downstream providers are still moving, score the draft before you send it.
Open scorecardUse the template or builder
If the facts are mostly clean, move into the packet route instead of staying in checklist mode, or route through the due diligence starter pack if the live blocker is now one answer.
Use the evidence map or audit
If the packet exists but one diligence claim still lacks proof, isolate that claim instead of rebuilding everything.
Copy-ready internal check
1. Workflow: Name the exact AI-assisted workflow and whether it is planned, active, or replacing another process.
2. Vendor chain: Name the primary vendor plus every downstream provider touched by the workflow.
3. Scope: State the data categories, customer segments, products, regions, and contract edge cases involved.
4. Governance: State the training or retention stance, approval owner, and next review trigger with supporting proof.
5. Open risks: State what remains unresolved, who owns the fix, and which NoticeKit route should handle it next.