A use-case review is useful when it turns a broad idea into a task the team can test. It should identify the input, intended output, system access, reviewer and consequence of a mistake.
The categories below are an illustrative internal review aid. They are not legal AI Act classifications or a substitute for an organisation’s own risk assessment.
Describe the work before scoring it
Write a specific task such as “prepare a summary from this approved policy collection”. Identify who uses the output and where it goes next.
Avoid descriptions such as “automate finance” that hide several different decisions. Document interpretation, calculation, customer communication and payment authorisation should not be treated as one undifferentiated capability.
Establish the existing process and how its quality is checked. That gives the team a baseline for comparing the proposed system.
Compare information and action boundaries
Swipe or scroll horizontally to compare every column.
| Example task | Information boundary | Action boundary | Review question |
|---|---|---|---|
| Summarise an approved internal policy | User-authorised, current source collection | Read and draft only | Does the draft reflect the relevant source and version? |
| Prepare an external customer response | Approved customer record and business knowledge | No automatic sending in the initial scope | Who checks the recipient, accuracy and permitted content? |
| Extract fields for a financial review | Approved documents and source references | Prepare validated fields, not the professional decision | Can a reviewer trace each value and rerun calculations? |
| Propose a system update | The records needed for the task | Narrow permitted changes with defined approval | What validates and authorises the exact change? |
The same broad task can need a different treatment when it uses sensitive information or affects a consequential decision. “Internal” does not automatically mean low risk.
Separate deterministic work from interpretation
A reminder after a confirmed booking may only need a defined workflow. Interpreting a varied enquiry may benefit from a model. Choose the simpler implementation where the rules are already known.
For model-assisted interpretation, define the allowed outputs and missing-information path. Use software checks for required fields, permitted values and exact calculations. A well-formed response can still be substantively wrong.
Do not grant execution authority from an unvalidated confidence score. The access and approval rules remain separate from the model’s recommendation.
Choose an initial release boundary
A read-only or draft-only release can help evaluate usefulness without enabling every external action. It still needs privacy, access and operating controls.
Identify the users, sources and tasks included in the first scope. Define the conditions for stopping the trial, handling an incorrect output and expanding access later.
A shadow comparison may be useful when appropriate, but it still processes data. It is not inherently safe merely because its outputs do not drive the main business action.
Define acceptance evidence
Test representative tasks, ambiguous inputs, denied access and source conflicts. Include the requests the system must refuse or route to a person.
Measure source support, correction effort and the actual outcome of connected actions. A convincing final message should not stand in for confirmation from the system of record.
Record the model, prompt, tool and source versions used in evaluation. Otherwise a future change may invalidate the evidence without being noticed.
Agree who operates the use case
Name the process owner, technical owner and reviewer. Decide who maintains source access, handles failed tasks and reviews changes after launch.
Give users a clear way to report a problem and locate the affected task. A stopped workflow may leave completed external actions that need reconciliation rather than a simple restart.
Microsoft’s Copilot privacy and security documentation and the NIST AI RMF provide complementary product and risk references. Our How We Work page shows how a bounded scope becomes a build and verification plan.