Saltar al contenido principal
Esencial•8–14 horas

Laboratorio de observabilidad, SLO y evidencia de runtime de IA

Construye un contrato de observabilidad para una carga de IA: trazas end-to-end, SLI/SLO segmentados por riesgo, señales de calidad y coste, telemetría consciente de privacidad, postcondiciones autoritativas y evidencia de runtime que diferencie el estado real de producción de un dashboard atractivo.

observabilidad de IAtracing distribuidodiseño SLI/SLOevidencia de runtimeatribución de costestelemetría consciente de privacidad

Escenario

Tarea

Un servicio de IA tiene uptime en verde y latencia mediana aceptable, pero las tareas de alto riesgo se degradan tras un cambio de revisión del modelo, retrieval o dependencia de tool. El dashboard agregado no lo muestra y los prompts sin filtrar en las trazas crean un riesgo de privacidad. Construye un contrato de observabilidad que vincule cada request con el behavior fingerprint, los spans de model/retrieval/tool, el resultado real de negocio y el coste, sin convertir la telemetría en otro almacén de secretos.

Ejecución paso a paso

1. Diseña la traza como grafo de evidencia, no como volcado de logs

Resultado: Una tarea puede rastrearse por model, retrieval, tool, approval y resultado autoritativo sin perder la identidad del release.

Tareas

  • →Definir correlation/run ID y contrato de spans parent-child
  • →Añadir behavior fingerprint sin secrets
  • →Separar spans de model/retrieval/tool/approval/outcome
  • →Marcar estados de telemetría sampled, dropped y unavailable

Comprobaciones

  • ✓La traza permite identificar la revisión concreta de model/config
  • ✓Un span ausente no se interpreta como éxito
  • ✓Las etiquetas de alta cardinalidad no generan una explosión de costes sin control

2. Establece el límite de privacidad y minimización de datos

Resultado: La observabilidad aporta evidencia suficiente para diagnosticar sin copiar de forma incontrolada prompts, PII y payloads de tools.

Tareas

  • →Clasificar metadata, content y campos sensibles
  • →Aplicar redaction o hashing antes de exportar
  • →Definir política de retention y access
  • →Tratar la ruta provider/exporter como un límite separado de data egress

Comprobaciones

  • ✓Secrets y credentials no llegan a los spans
  • ✓El contenido sensible no está habilitado por defecto para todas las trazas
  • ✓Retention y deletion tienen responsable y estado de policy verificable

3. Construye SLO segmentados por riesgo y unit economics

Resultado: El equipo ve no solo uptime, sino también calidad, resultado verificado y coste para distintas clases de tareas.

Tareas

  • →Definir SLI para latency, availability, quality y authoritative task success
  • →Separar segmentos normal/high-risk/no-answer/tool-write
  • →Añadir coste por tarea verificada con éxito
  • →Asignar error budget y blocking threshold para segmentos críticos

Comprobaciones

  • ✓El promedio agregado no oculta una regresión de un segmento crítico
  • ✓Una tarea fallida o insegura no cuenta como resultado exitoso
  • ✓Cada SLO tiene una fuente de datos, ventana y responsable concretos

4. Ejecuta un simulacro de runtime evidence e incidente

Resultado: Una alerta conduce a una causa reproducible y el incidente se convierte en un control de regresión.

Tareas

  • →Inyectar un fingerprint obsoleto de model/retrieval
  • →Simular timeout de tool con side effect incierto
  • →Verificar la ruta UNKNOWN → reconciliation → verified outcome
  • →Minimizar el fallo en un caso replay/regression y vincularlo al release gate

Comprobaciones

  • ✓Un runtime mismatch no puede finalizar como PASS
  • ✓No se ejecuta retry antes de reconciliar un side effect incierto
  • ✓El informe del incidente contiene enlace a trace/evidence, cambio de control, responsable y regression test

Criterios de aceptación

  • Una traza end-to-end vincula release fingerprint, etapas model/retrieval/tool y resultado autoritativo
  • La telemetría tiene contrato de minimización de datos, redaction, retention y access
  • Los SLI/SLO están separados por segmentos de riesgo/tarea e incluyen coste por tarea verificada con éxito
  • La evidencia de runtime ausente u obsoleta termina como UNKNOWN/FAIL, nunca como false-green PASS
  • Al menos un incidente inyectado se convierte en replay minimizado y caso permanente de regresión