Definir objetivos de servicio y presupuesto de fallo

«El modelo responde bien» no es una definición operativa. Un equipo de producción necesita saber qué significa prestar un servicio aceptable, cómo detectar que deja de hacerlo y qué decisiones se toman cuando la fiabilidad, la calidad o el coste se apartan de lo esperado.

En sistemas de IA conviven dos familias de señales: las tradicionales de un servicio distribuido y las específicas de una función cuyo resultado puede ser técnicamente válido y semánticamente incorrecto. El objetivo es unir ambas sin inventar un «SLO de inteligencia» imposible de medir.

Empieza por el recorrido crítico del usuario

Describe una unidad de servicio completa.

Ejemplo:

«Un analista envía una consulta sobre documentación interna y recibe una respuesta fundamentada, con las fuentes autorizadas, dentro del tiempo objetivo.»

La unidad no es «una llamada al modelo». Incluye:

entrada → autorización → recuperación → modelo → validación → respuesta

Si cualquiera de esas etapas falla, la función puede dejar de ser útil aunque la API principal devuelva HTTP 200.

Para cada recorrido identifica:

• usuario;
• tarea;
• outcome esperado;
• impacto de fallo;
• tiempo relevante;
• dependencias;
• segmentos de riesgo;
• fallback disponible.

Distingue SLI, SLO y SLA

Google SRE utiliza tres conceptos que conviene separar.

SLI — Service Level Indicator. Medida cuantitativa del nivel de servicio.

SLO — Service Level Objective. Objetivo para ese indicador.

SLA — Service Level Agreement. Compromiso contractual o de negocio que puede incluir consecuencias cuando no se cumple.

En una aplicación interna quizá solo necesites SLI y SLO.

Ejemplos de SLIs:

• disponibilidad de la función completa;
• latencia p95;
• porcentaje de outputs estructuralmente válidos;
• porcentaje de tareas aceptadas por revisión;
• groundedness sobre muestra;
• tasa de acciones no autorizadas;
• coste por tarea útil.

No todos deben convertirse en SLO.

Separa fiabilidad técnica y calidad semántica

Un indicador de disponibilidad puede calcularse en tiempo casi real.

La calidad de una respuesta puede requerir:

• referencia;
• revisión humana;
• eval automática;
• feedback;
• comprobación del outcome.

Por eso puedes tener:

SLO técnico

99,5 % de solicitudes elegibles completan el pipeline sin error de infraestructura.

Objetivo de calidad

Al menos X % de la muestra auditada cumple la rúbrica mínima.

La cifra X debe surgir del caso. No existe un porcentaje universal para «IA fiable».

Diseña objetivos por segmento

Una media global puede ocultar una clase crítica.

Segmenta por:

• tarea;
• cliente o tenant;
• idioma;
• riesgo;
• tipo de documento;
• uso de herramienta;
• versión;
• longitud;
• canal.

Una tasa de éxito del 95 % puede ser inaceptable si el 5 % de fallos se concentra en decisiones de alto impacto.

Define un error budget con cuidado

En SRE, el error budget deriva del SLO y expresa cuánto incumplimiento se tolera antes de activar una política.

Ejemplo conceptual:

SLO disponibilidad: 99,5 %
budget: 0,5 % de solicitudes no satisfactorias por disponibilidad

Para una métrica semántica quizá no sea apropiado hablar literalmente de error budget si la muestra llega con retraso o no es continua. Puedes usar una tolerancia de calidad y una política equivalente.

Lo importante es que exista una regla de decisión.

Vincula presupuesto con acciones

Ejemplo:

Budget saludable

• despliegues normales.

Budget consumiéndose rápido

• congelar cambios no urgentes;
• ampliar muestreo;
• investigar.

Budget agotado

• priorizar fiabilidad;
• limitar tráfico;
• rollback;
• suspender ampliaciones.

La política debe estar acordada antes del problema.

Incluye coste

Un servicio puede ser preciso pero económicamente inviable.

Define:

• coste por consulta;
• coste por tarea completada;
• coste de revisión humana;
• coste de retries;
• coste de RAG/reranking;
• presupuesto por tenant.

No confundas «tokens baratos» con «servicio barato». El coste relevante es el outcome.

Incluye seguridad como guardrail

Determinados fallos no deben promediarse.

Ejemplos bloqueantes:

• cross-tenant;
• escritura sin autorización;
• secreto expuesto;
• tool de alto impacto sin aprobación.

Puedes tener una política:

cualquier incidente crítico de autorización → detener rollout

aunque las demás métricas estén verdes.

Usa NIST como marco, no como obligación

NIST AI RMF puede ayudarte a estructurar gobierno, medición y monitorización, pero NIST lo presenta como un marco voluntario. No lo conviertas en una obligación legal general.

Ejercicio

Para una función real, construye una ficha:

• recorrido;
• 3–5 SLIs;
• SLOs;
• objetivos de calidad;
• segmentos;
• fallos bloqueantes;
• costes;
• política de consumo;
• owner;
• fuente de datos;
• cadencia de revisión.

Después simula que la calidad se mantiene pero el p95 se duplica y el coste aumenta 80 %. Decide qué hace el equipo.

Resultado de la lección

Debes terminar con una definición operativa de «funciona»: indicadores, objetivos, tolerancias y decisiones. La siguiente lección construirá la evidencia necesaria para medir la parte que no puede observarse solo con métricas técnicas.