Who this questionnaire is for
Product leaders, business owners, governance/risk teams, and engineering leads deciding what AI use cases to build or ship.
What it assesses
Whether a proposed AI use case is safe to pilot or ship, by tiering risk (impact if wrong, decision proximity, user exposure, data sensitivity, and reversibility) and mapping it to required controls.
How it helps
Creates a consistent intake gate so AI doesn’t become “production by default.” Results give you a clear tier (low → critical) plus a practical control checklist for what must exist before you ship (owners, logs, evidence, human-in-the-loop, monitoring, rollback authority).
Best used when
- Approving new AI use cases
- Expanding scope from pilot → production
- Aligning product speed with governance requirements
- Deciding “do not ship” boundaries
AI Use-Case Intake & Risk Tiering
Use this intake to decide what to build/ship — and what controls are required before a use case can move from idea → pilot → production. Your risk tier and required actions update as you answer.
Section A — Use Case & Impact
1) What’s the impact if the system is wrong?
2) How close is the system to a final decision?
3) Who is exposed to the output?
4) Is the use case regulated or high-stakes by policy (e.g., finance, health, employment, legal, eligibility)?
5) Is there a clear “do not do” scope boundary for this use case?
Section B — Data, Privacy & Access
6) What data types will be used or exposed?
7) Are data sources mapped with ownership, freshness, and access rights?
8) Are outputs grounded with evidence (citations, document IDs, timestamps) when making factual claims?
9) Are permissions least-privilege with periodic review (tools, actions, data access)?
10) Do you have a retention policy and audit-ready logs (inputs, retrieval, outputs, versions)?
Section C — Controls & Shipping Gates
11) Is there a “safe to ship” definition (quality threshold, refusal behaviour, escalation for high-stakes)?
12) Are failure paths tested (missing evidence, contradictions, prompt injection, tool failure)?
13) Is monitoring in place with owners (quality/drift, refusal, latency/cost) and alerting?
14) Is incident response defined for this use case (triage, rollback/kill, comms, learning loop)?
15) Are change logs and approvals required (prompts, models, tools, data access) before shipping changes?
Tip: Use this before every new use case. If the tier is High/Critical, treat “controls” as prerequisites — not post-launch fixes.
Risk tier
—
—
Decision
—
—