Respuesta directa
En pocas palabras
Para definir SLI, SLO y error budget de un AI Sales Copilot, empieza por un recorrido comercial observable y delimita qué eventos cuentan. El SLI mide el resultado recibido; el SLO fija una proporción objetivo dentro de una ventana; y el error budget representa la parte que puede fallar sin superar ese objetivo. Segmenta por función, versión y riesgo, incluye exactitud o seguridad cuando corresponda y acuerda por anticipado qué decisiones provoca cada nivel de consumo. Un SLO interno no es automáticamente un SLA contractual.
Un SLO sirve para decidir, no para decorar un dashboard
Un objetivo de nivel de servicio traduce una expectativa de quien usa el sistema en una medida que producto, operación y negocio pueden discutir. Para un AI Sales Copilot, no basta con saber que la API respondió. La persona necesita recuperar el contexto correcto, conservar moneda y fuente, recibir una salida dentro de un tiempo útil y poder revisar el resultado antes de actuar. Si la medición no cambia ninguna decisión, todavía no es un objetivo operativo.
Google SRE recomienda partir de lo que importa al usuario y mantener pocos objetivos representativos. NIST AI RMF pide medir y documentar desempeño, incertidumbre y riesgos durante la operación. Estas referencias ayudan a diseñar el proceso, pero no fijan un porcentaje universal para ventas, IA generativa o México. El objetivo debe corresponder al recorrido, la población, el riesgo y la capacidad real de responder.
Distingue SLI, SLO, SLA y error budget antes de elegir números
El SLI es el indicador cuantitativo: por ejemplo, la proporción de propuestas elegibles cuyo catálogo, moneda y total pasan una validación definida. El SLO es el objetivo para ese indicador durante una ventana: una proporción acordada en treinta días, por versión y recorrido. El error budget es la fracción que puede quedar fuera del objetivo. El SLA es un acuerdo con consecuencias explícitas y requiere revisión comercial, contractual y legal.
No llames SLA a una meta interna ni publiques consecuencias que nadie aprobó. Tampoco mezcles un KPI de adopción con un SLI de confiabilidad. La cantidad de sugerencias aceptadas puede describir comportamiento comercial; no demuestra que las respuestas fueron correctas, oportunas o seguras. Cada nombre debe conservar una definición, un dueño y una fuente de cálculo.
| Criterio | Pregunta | Uso operativo |
|---|---|---|
| SLI | ¿Qué resultado medimos? | Indicador con eventos válidos y fuente |
| SLO | ¿Qué nivel buscamos en una ventana? | Objetivo interno y criterio de decisión |
| SLA | ¿Qué consecuencia fue acordada? | Compromiso contractual revisado |
Empieza por el recorrido comercial, no por la métrica disponible
Dibuja el recorrido desde la intención hasta el resultado visible. Un flujo de cotización puede incluir abrir la oportunidad, recuperar cuenta y catálogo, seleccionar productos, conservar moneda, generar el documento, revisar, exportar y compartir. Define dónde empieza y termina la responsabilidad del copiloto, qué dependencias participan y qué observa la persona usuaria. Medir solo el servidor puede ocultar una exportación vacía o un precio sin fuente.
Prioriza recorridos que cambian una decisión o pueden causar daño: preparar contexto, sugerir el siguiente paso, generar una cotización, mostrar una Buyer Room o actualizar señales del pipeline. No necesitas un SLO para cada botón. Agrupa recorridos con expectativas y riesgos semejantes; separa aquellos donde un mismo porcentaje escondería una diferencia material.
Define eventos elegibles, buenos y válidos sin mover el denominador
Escribe el SLI como una fracción reproducible: eventos buenos entre eventos elegibles. Un evento elegible cumple las precondiciones del recorrido; uno bueno alcanza el resultado definido; uno inválido no puede evaluarse por una razón registrada. Conserva por separado cancelaciones del usuario, datos de prueba, solicitudes mal formadas, mantenimientos y fallas de dependencias. Excluirlos o incluirlos debe ser una decisión estable, no una forma de mejorar el resultado al final del mes.
Registra el evento cerca de la experiencia observada y conserva identificadores, tiempos, versión y razón de fallo sin copiar datos comerciales sensibles. Prueba duplicados, reintentos, timeouts y operaciones asíncronas. Si un reintento produce dos documentos, contar el segundo como éxito puede ocultar un problema de integridad aunque la respuesta final parezca disponible.
Mide disponibilidad, latencia, calidad y seguridad como dimensiones distintas
La disponibilidad responde si el recorrido produjo un resultado utilizable. La latencia mide si llegó dentro de un tiempo relevante. La calidad comprueba propiedades como fuente, moneda, suma, cobertura o consistencia. La seguridad observa acciones bloqueadas, límites de acceso y exposición. No las combines en un promedio opaco: una respuesta rápida con un precio incorrecto no compensa una respuesta lenta pero válida.
Para resultados generativos, define evaluaciones deterministas donde sea posible y revisión humana o muestreo cuando la propiedad requiere juicio. Documenta rúbrica, conjunto, tamaño de muestra, desacuerdo y margen de incertidumbre. Una tasa de aceptación no equivale a exactitud: puede reflejar prisa, confianza excesiva o falta de alternativa. Mantén indicadores de supervisión y calidad separados del volumen de uso.
Segmenta antes de que un promedio esconda a la población afectada
Calcula por recorrido, versión, canal, organización, región, modelo, integración y nivel de riesgo cuando esas diferencias puedan cambiar la experiencia. Conserva moneda y producto como contexto si afectan validación. Un resultado global puede verse estable mientras una versión nueva falla en distribuidores o una integración pierde los precios de una sola organización.
No abras cientos de series sin dueño. Define segmentos obligatorios y una ruta de exploración para diagnósticos. Publica el volumen elegible junto con la proporción: noventa y nueve por ciento sobre cien eventos no tiene la misma estabilidad que sobre cien mil. Para poco tráfico, complementa la tasa con conteos, ventanas más largas, pruebas sintéticas y revisión de eventos individuales.
Elige una ventana que refleje uso, estacionalidad y velocidad de respuesta
La ventana puede ser móvil o de calendario. Debe capturar ciclos reales del negocio sin retrasar una señal material. Un recorrido usado al cierre de mes necesita observar ese pico; una función diaria puede requerir una ventana más corta para operación y otra más larga para dirección. Define zona horaria, retraso de datos, fecha de corte y tratamiento de periodos sin tráfico.
Evita promedios que borren la cola. Para latencia, usa umbrales y percentiles apropiados al recorrido; para calidad, conserva clases de error y severidad. Una media rápida puede coexistir con un grupo pequeño que espera demasiado. Una tasa mensual aceptable puede esconder una interrupción concentrada en la hora exacta en que ventas debía enviar propuestas.
Selecciona el objetivo con evidencia y riesgo, no copiando los nueves de otro servicio
Reúne una línea base suficientemente limpia, expectativas de usuarios, impacto de fallos, alternativas manuales, capacidad de soporte, dependencias, costo de mejora y tolerancia acordada. Empieza con un objetivo que permita aprender y revísalo cuando cambien el recorrido o la evidencia. No adoptes el rendimiento actual de forma automática ni prometas cien por ciento: ambos extremos pueden fijar una deuda o exigir una operación desproporcionada.
Declara el objetivo con fórmula completa. Ejemplo ilustrativo, no recomendación: durante una ventana móvil de veintiocho días, una proporción acordada de cotizaciones elegibles debe conservar producto, moneda, fuente y total al exportarse, medida desde el resultado final y segmentada por versión. El porcentaje solo se aprueba después de revisar línea base, impacto, muestra y capacidad de respuesta.
Convierte el objetivo en un error budget con unidades que el equipo entienda
Si el SLO es una proporción de eventos buenos, el presupuesto de error es uno menos ese objetivo. Después conviértelo a eventos o tiempo según el indicador y la ventana. Muestra presupuesto inicial, consumido, restante y proyección. No sumes fallos con gravedad incomparable en un único saldo si una sola violación de seguridad exige respuesta inmediata aunque todavía quede presupuesto.
Usa ejemplos claramente ilustrativos para enseñar el cálculo. Con diez mil eventos elegibles y un objetivo hipotético de noventa y nueve por ciento, el presupuesto aritmético sería cien eventos fuera del objetivo. Eso no autoriza cien precios incorrectos: la política puede excluir del presupuesto tolerable ciertas clases, activar un incidente desde el primer caso o definir presupuestos separados por recorrido y severidad.
Observa velocidad de consumo y no esperes a cerrar la ventana
El consumo indica cuánto presupuesto se gastó; la tasa de consumo muestra qué tan rápido ocurre. Una falla breve y concentrada puede agotar el margen antes de que el promedio mensual cambie de forma evidente. Usa ventanas rápidas y lentas para distinguir un evento urgente de una degradación sostenida, y conecta cada señal con una acción verificable.
En servicios de poco tráfico, una sola solicitud puede producir una tasa extrema. Google SRE advierte que las alertas basadas en burn rate necesitan adaptación cuando hay pocos eventos. Combina conteos mínimos, duración, pruebas sintéticas, criticidad y revisión humana. No ignores un fallo material por falta de volumen, pero tampoco despiertes a una persona por cada evento aislado sin contexto.
Acuérdate de la política antes de consumir el presupuesto
Define niveles y decisiones: observar, abrir ticket, investigar, limitar despliegues, exigir aprobación adicional, activar modo degradado, congelar cambios de riesgo o declarar incidente. Identifica quién propone, quién decide, excepciones permitidas, evidencia, vigencia y salida. La política debe distinguir correcciones que reducen riesgo de funciones nuevas que podrían aumentarlo.
No uses el error budget como permiso para fallar deliberadamente ni como castigo al equipo. Sirve para negociar confiabilidad y velocidad con una regla visible. Si producto y operación no aceptan actuar cuando el presupuesto se agota, el número no gobierna nada. Si cada incumplimiento congela todo sin considerar severidad y causa, la política tampoco será sostenible.
Diseña un tablero que explique estado, causa probable y siguiente decisión
Muestra recorrido, definición, objetivo, ventana, volumen, resultado actual, presupuesto restante, consumo por periodo, segmentos, cambio reciente y dueño. Permite abrir los eventos que componen el indicador sin exponer contenido sensible. Distingue dato retrasado, detector sin cobertura y objetivo incumplido; los tres requieren respuestas diferentes.
Las alertas deben indicar qué persona necesita actuar y con qué urgencia. Google SRE separa páginas, tickets y registros: atención inmediata, trabajo próximo o evidencia para análisis. Enlaza el runbook, la versión y el panel exacto. Una alerta sin destinatario, umbral comprensible y primera acción termina convertida en ruido.
Conserva versión, aprobación e incertidumbre como parte del objetivo
Cada SLO necesita nombre, propósito, dueño de producto, dueño técnico, indicador, consulta, fuente, exclusiones, segmentos, ventana, objetivo, política, aprobadores, fecha efectiva y próxima revisión. Guarda cambios de definición junto con la razón y recalcula tendencias cuando sea posible. No compares periodos como si fueran equivalentes después de cambiar el denominador o el detector.
Registra cobertura, retraso, calidad del dato, muestreo y desacuerdo. NIST AI RMF reconoce que algunos riesgos son difíciles de medir y recomienda combinar métodos cuantitativos y cualitativos. Lo desconocido debe aparecer en la decisión; una celda vacía no se vuelve verde por falta de telemetría. Escala cuando la incertidumbre impide estimar impacto.
Implanta pocos objetivos, ensaya la política y revisa el comportamiento
Empieza con uno o dos recorridos críticos. Instrumenta eventos, valida el cálculo contra muestras, publica un tablero sin consecuencias durante un periodo de observación y corrige definiciones. Después acuerda el objetivo y ensaya escenarios: caída completa, degradación lenta, error de calidad, poco tráfico, datos retrasados y dependencia externa. Comprueba si el equipo toma la decisión prevista y si el runbook sigue siendo ejecutable.
Revisa tras cambios de modelo, prompt, catálogo, integración, población, política o arquitectura. También después de incidentes y cuando el objetivo se cumple de forma constante sin orientar prioridades. El éxito no es tener más SLO: es reducir discusiones ambiguas, detectar impacto antes y decidir con evidencia cuándo innovar, estabilizar, limitar o retirar una función.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre SLI, SLO y SLA?
El SLI es una medida cuantitativa del servicio. El SLO fija un objetivo para esa medida durante una ventana. El SLA es un acuerdo con consecuencias explícitas y requiere revisión contractual. Un objetivo interno no se convierte en SLA por aparecer en un dashboard o una presentación.
¿Qué es un error budget?
Es la parte del objetivo que puede quedar fuera del resultado esperado dentro de una ventana. Si el SLO se expresa como proporción de eventos buenos, el presupuesto aritmético es uno menos el SLO. La política define qué decisiones provoca su consumo y qué fallos no son tolerables aunque exista saldo.
¿Qué SLI debe usar un AI Sales Copilot?
Depende del recorrido. Puede medir disponibilidad útil, latencia, integridad de datos, calidad verificable, cobertura de fuente o cumplimiento de controles. Debe observar el resultado recibido por la persona, definir eventos elegibles y segmentar por versión y riesgo. No existe un indicador universal para todos los copilotos.
¿Se debe usar 99.9% como SLO?
No por defecto. El objetivo se elige con línea base, necesidad del usuario, impacto, alternativas, dependencias, costo y capacidad de respuesta. Copiar un porcentaje externo puede producir una promesa innecesaria o esconder un recorrido que exige una propiedad distinta, como exactitud o seguridad.
¿Qué hacer cuando se agota el error budget?
Ejecuta la política acordada: investigar, limitar cambios, priorizar confiabilidad, activar controles adicionales o escalar. La decisión depende de causa, severidad, población y riesgo. No debe improvisarse al final de la ventana ni suspender automáticamente correcciones que reducen el problema.