Set AI alert thresholds with review capacity in view
Compare missed problems, false alarms and review time before choosing an AI alert threshold. Includes a worked example with explicit capacity limits.
Choose an AI alert threshold by looking at missed problems, false alarms and the team's ability to review the resulting queue. A threshold that catches more problems can also create more review work. Neither an accuracy score nor a smaller inbox settles the operating decision.
First define the errors you cannot accept. A safety or product-release requirement cannot be traded away merely because the reviewer is busy. The worked example below concerns a document-review pilot with limited risk in which people retain the final decision.
Compare thresholds on the same labeled cases
Use a fixed evaluation set and an agreed reference judgment. For a threshold comparison, keep the model, inputs and scoring method unchanged so the test isolates the threshold. Retain uncertain reference cases separately until the process owner resolves them.
Here is an invented set of 100 purchase-document drafts. Twenty contain the defined problem; 80 do not. Two candidate thresholds produce these fictional results:
| Result | Threshold A | Threshold B |
|---|---|---|
| Problems flagged | 18 of 20 | 15 of 20 |
| Problems missed | 2 of 20 | 5 of 20 |
| Correct drafts flagged | 24 of 80 | 8 of 80 |
| Total review queue | 42 | 23 |
| Review time at 3 minutes per flag | 126 minutes | 69 minutes |
The arithmetic is explicit: A creates 18 + 24 = 42 flags, requiring 42 × 3 = 126 minutes. B creates 15 + 8 = 23 flags, requiring 23 × 3 = 69 minutes. B saves 57 review minutes in this example but misses three additional known problems.
Those are synthetic results, not product performance or production error rates. The deliberately chosen problem prevalence also affects how many flags are useful. Use the defect-evaluation primer to check the basic error categories and denominators.
Add the queue limit without hiding the misses
Suppose the fictional reviewer has 90 minutes available for these flags. A needs 36 minutes more than that capacity. B fits, but its five misses may still make it unacceptable.
The choice is not limited to accepting B or silently letting A's queue grow. The team could narrow the pilot's scope, add qualified review capacity, improve the input, or keep the current process while testing another approach. These are operating alternatives to evaluate, not guaranteed fixes.
Record the consequence of a miss and of a false alarm separately. A missed incorrect purchase amount can matter more than a flag that takes a few minutes to clear. Do not force every consequence into a dollar value if the evidence does not support it. State the process owner's unacceptable outcomes first, then compare effort among options that meet those conditions.
Test the review queue as part of the system
Run the pilot with the person who would receive the flags. Check that a flagged record contains the evidence needed to decide, that waiting work remains visible and that an unresolved item cannot be mistaken for reviewed work.
Measure actual review time by case type. The three-minute assumption may be wrong when a flag requires calling a supplier or locating an attachment. Repeat the workload calculation with observed pilot effort before planning capacity.
NIST's AI RMF Core calls for appropriate metrics, documented evaluation and performance measurement under conditions resembling deployment. It also calls for monitoring system behavior in production. The threshold-and-queue worksheet is a proposed application of those principles, not an acceptance standard supplied by NIST. NIST AI RMF Core.
Approve a threshold together with the evaluated task, reference set, review capacity and escalation rule. Recheck the decision when those conditions change. If the team cannot handle the flags or explain the remaining misses, keep the pilot bounded rather than turning its score into a release promise.