Use this template for a proposed or existing AI use case. Scale the depth of review to the potential impact. The answers should link to evidence rather than relying on unverified statements.
1. Use-case definition
- What business problem does the system address?
- Who uses it, and who is affected by its output?
- What does the system recommend, create, decide, or do?
- Which uses are expressly out of scope?
- Who is the accountable business owner?
Evidence: workflow map, owner acceptance, intended-use statement, and user population.
2. Data and knowledge
- Which data enters the system, and how is it classified?
- What are the source, permission, quality, freshness, and retention rules?
- Does the system connect to internal repositories or third parties?
- Can outputs expose, infer, or reproduce sensitive information?
Evidence: data inventory, access model, retention setting, vendor terms, and test samples.
3. Impact and affected people
- What happens if the output is wrong, biased, late, or unavailable?
- Is the impact consequential, difficult to reverse, or broad in scale?
- Could people be treated differently or lose a meaningful opportunity?
- Are vulnerable populations or regulated activities involved?
Evidence: impact analysis, subject-matter review, and escalation thresholds.
4. Autonomy and system access
- Can the system take action or only make a recommendation?
- Which tools, credentials, systems, and records can it access?
- Are permissions limited to the minimum needed?
- Which actions require explicit human approval?
Evidence: permission map, tool list, approval logic, and sandbox test.
5. Evaluation
- What are the most likely and most severe failure modes?
- Does the test set represent real conditions and difficult cases?
- What quality, safety, fairness, security, and reliability thresholds apply?
- Were limitations and negative results recorded?
Evidence: evaluation plan, results, exception samples, red-team findings, and acceptance decision.
6. Human oversight
- Who reviews the output, at what point, and with what context?
- Can the reviewer detect a plausible error and override the system?
- What happens when confidence is low or information conflicts?
Evidence: operating procedure, reviewer training, audit samples, and fallback process.
7. Monitoring and incidents
- Which measures indicate quality, drift, misuse, or control failure?
- Who reviews them, how often, and against which threshold?
- Who can pause the system?
- How are incidents reported, investigated, and learned from?
Evidence: dashboard, alert rules, incident owner, response playbook, and review schedule.
Final decision gate
Record the risk tier, approved scope, required controls, residual risks, approvers, launch date, monitoring owner, and next review date. Choose one decision: approve, approve with conditions, pilot only, remediate and resubmit, or do not proceed.