AI Reliability: Designing Measures and Release Acceptance

Reviewed and updated October 8, 2026.

An AI service can be available and fast while giving an unusable answer. Design its reliability measures around both the request path and the work the user needs completed. Conventional availability and latency measures remain useful; add task-specific quality and action-safety measures where the service needs them.

Google's SRE guidance distinguishes a service level indicator, which measures behavior, from an objective, which sets a target. It includes correctness as well as availability and latency. Variable model behavior does not make those concepts obsolete.

Define the event before choosing the target

Write the numerator, denominator, observation point and measurement window for each indicator. “AI accuracy” is too broad. Specify the task population, the answer criteria, the evaluator and what unavailable or inconclusive judgments mean.

• Availability: eligible requests receiving the defined response rather than an application error. Report degraded responses separately.
• Latency: time from the user's request to a usable completed result, including retrieval and tools. Streaming the first token measures a different experience.
• Task success: evaluated requests meeting the agreed domain rubric, with the evaluated sample and coverage visible.
• Unsafe action: observed attempts and executed actions that violate the action policy. Keep these separate; a blocked attempt is not an executed violation.
• Recovery: time and operator work needed to restore an approved mode after a detected failure.

An illustrative knowledge assistant

Consider a policy assistant with three required behaviors: identify the applicable policy, support its answer with the current source and abstain when the source does not answer. This example defines measurements; it does not report service results.

A returned answer counts toward transport availability even if it cites an expired policy. It fails task success. An abstention can pass the task rubric when the question is outside the approved sources. A successful source lookup followed by an incorrect explanation should be recorded as a generation failure rather than a retrieval outage.

Use a versioned test set containing current policies, conflicting versions, missing evidence and access-denied cases. Review a production sample as a separate population. A test-set score cannot be presented as the success rate for every live request. Label sample size, selection method and unresolved judgments; repeat trials when run-to-run variation matters.

Connect acceptance to a release decision

Agree objectives with the workflow owner before evaluating a change. Some failures justify stopping a release even when the average score improves. For example, an unauthorized disclosure should not be averaged away by many correct answers.

The voluntary NIST AI RMF measure function calls for testing before deployment and while in operation, with uncertainty and limitations documented. Use that principle to record which populations and harms your acceptance cases cover, and which remain unmeasured.

Version prompts, models, source indexes and graders with the evaluation results. Choose thresholds for the particular service; there is no universal AI success target. Keep runtime controls and permission enforcement even when an evaluation passes.

This article covers measurement design. Operating AI agents in production covers alerts and response. For agreeing acceptance before implementation, see how ALLTIPLY works, or request a project review with the task and unacceptable failures.