Un agente disponible no basta: SLOs de decisión, escalamiento y evidencia
Por Equipo Quantum Developers
Resumir:
Tesis operativa
Un agente puede estar disponible durante toda una jornada y, aun así, prestar un mal servicio: clasificar mal una excepción, escalarla tarde o ejecutar una acción sin dejar evidencia suficiente. La tesis es verificable: si el tablero solo mide uptime y latencia técnica, no puede demostrar que la decisión fue correcta ni que una persona pudo intervenir a tiempo. El contrato operativo debe medir tres resultados adicionales: calidad de decisión, latencia de escalamiento y completitud de evidencia.
Google SRE incluye la corrección entre los indicadores relevantes de salud y recomienda elegir pocos indicadores vinculados con lo que realmente importa al usuario, no todo lo que resulte fácil medir en su capítulo sobre SLOs. Para un agente, responder no equivale a resolver. La unidad de servicio no es la llamada al modelo: es el caso de negocio que llega a un estado aceptable.
De uptime a un conjunto de SLOs de negocio
Un SLO útil tiene indicador, población, ventana, objetivo y consecuencia. El siguiente conjunto separa dimensiones que suelen mezclarse:
| Dimensión | Indicador | Denominador | Consecuencia al incumplir |
|---|---|---|---|
| Disponibilidad operativa | casos aceptados por el flujo | casos elegibles recibidos | activar modo degradado |
| Calidad de decisión | decisiones confirmadas como correctas | casos con resultado verificable | reducir autonomía |
| Escalamiento | tiempo desde señal de riesgo hasta asignación humana | excepciones que exigen revisión | ampliar guardia o bajar alcance |
| Evidencia | casos con entrada, regla, decisión, actor y resultado ligados | casos cerrados | bloquear cierre |
| Aprobación | acciones irreversibles con aprobación válida | acciones sujetas a control | impedir ejecución |
Los objetivos concretos no deben copiarse de otra empresa. Se fijan con riesgo, capacidad de revisión y datos propios. NIST pide documentar roles humanos, condiciones de despliegue, métricas y limitaciones, y mantener medición en producción dentro de las funciones Govern, Map, Measure y Manage del AI RMF Core. Esa orientación convierte el SLO en una decisión de gobierno, no en un número decorativo.
El contrato mínimo de medición
Cada caso necesita una identidad estable. Sin ella, una alerta no puede unirse con la decisión ni con el resultado. Un evento mínimo puede incluir:
- case_id y business_object_id para seguir el caso y el objeto afectado;
- decision_type, decision y confidence_band, sin confundir confianza con corrección;
- policy_version, model_or_rule_version y referencias de entrada;
- risk_class y escalation_reason;
- assigned_human, assigned_at y resolved_at;
- approval_id cuando la acción lo requiera;
- evidence_artifact_ids y outcome_status;
- trace_id para unir actividad técnica y resultado operativo.
OpenTelemetry publica convenciones semánticas para dar nombres comunes a trazas, métricas y logs a través de plataformas y librerías. No define el objeto de negocio de Quantum, pero sí refuerza una práctica útil: acordar el vocabulario antes de construir paneles. El equipo puede extender esa disciplina con atributos de caso, política y aprobación.
Ejemplo ilustrativo: cien casos de una cola
Supongamos, solo para mostrar el cálculo, una ventana de cien casos elegibles. Ochenta se resuelven automáticamente; veinte se escalan. Después, un revisor puede determinar el resultado de noventa casos porque diez siguen abiertos. De esos noventa, ochenta y cinco decisiones coinciden con el resultado confirmado. Dieciocho de las veinte excepciones fueron asignadas dentro del límite interno y ochenta y ocho cierres incluyen el paquete completo de evidencia.
Este ejemplo no es un benchmark. Sus indicadores serían: calidad confirmada igual a ochenta y cinco sobre noventa; escalamiento oportuno igual a dieciocho sobre veinte; evidencia completa igual a ochenta y ocho sobre cien. El denominador importa tanto como el numerador. Reportar ochenta y cinco decisiones correctas sobre cien ocultaría que diez todavía no son evaluables. El tablero debe mostrar cobertura de verificación por separado.
La consecuencia también debe estar escrita antes del incidente. Si se consume el presupuesto de error de calidad, el agente puede pasar de ejecutar a recomendar. Si falla evidencia, el caso no se cierra. Si sube la latencia de escalamiento, se reduce el universo elegible o se asigna una cola adicional. Un SLO sin respuesta acordada es una métrica, no un mecanismo de control.
Responsabilidad sin ambigüedad
Cada indicador necesita un dueño de señal y un dueño de respuesta. Operaciones puede responder por la cola; el área de negocio, por la definición de resultado correcto; riesgo o control interno, por las acciones irreversibles; ingeniería, por telemetría y modos degradados. NIST señala que las responsabilidades y líneas de comunicación deben ser claras y que el desempeño se evalúe en condiciones similares al despliegue real. Un RACI genérico no basta: la guardia debe saber quién puede bajar autonomía y quién puede reabrirla.
En Quantum Automation Center, el catálogo, el estado de ejecución, las líneas de tiempo, artefactos, logs y aprobaciones humanas pueden servir como superficies de evidencia. El punto no es acumular pantallas. Es ligar cada señal con el mismo case_id y conservar qué política estaba vigente cuando ocurrió la decisión.
El mejor contraargumento
El mejor argumento en contra es práctico: medir corrección exige etiquetas, revisión humana y espera hasta observar el resultado. Un equipo que todavía explora el problema puede invertir más en instrumentación que en aprender. Además, demasiados SLOs producen incentivos contradictorios: mejorar velocidad enviando más casos al humano puede deteriorar capacidad; subir automatización puede bajar cobertura de verificación.
La respuesta no es medir todo. Es empezar con un indicador por dimensión material, declarar los huecos y aumentar rigor con el riesgo. En una etapa asistiva puede bastar una muestra revisada y evidencia de cada acción. La autonomía se amplía cuando la cobertura permite defender la decisión, no cuando una demo parece fluida.
Cuándo no usar este enfoque
No use este contrato completo para una tarea creativa sin respuesta objetivamente correcta, una exploración de una sola vez o un flujo sin dueño capaz de definir consecuencias. Tampoco lo use para disfrazar de precisión una muestra demasiado pequeña. Si todavía no se puede observar el resultado, mantenga al agente como asistente y mida primero la calidad del proceso de revisión.
Sí conviene usarlo cuando el agente decide sobre casos repetidos, existen acciones con impacto operativo y una excepción tardía genera trabajo o riesgo. La prueba final es sencilla: ante una decisión cuestionada, el equipo debe poder reconstruir qué ocurrió, quién debía responder y qué cambió después.
Sources
Temas del artículo
