Por qué los SLAs de IA son distintos

• No determinismo: misma entrada ≠ misma salida.
• Dependencias externas: proveedor LLM, vector DB, APIs de negocio.
• Calidad observable: JSON válido, groundedness y abstención importan tanto como la latencia.
• Costos variables: tokens y contexto afectan presupuesto por request.

SLI, SLO, SLA y presupuesto de error

• SLI (Indicador): métrica observable (p. ej., p95_latency_ms).
• SLO (Objetivo): meta para el SLI (p. ej., p95 ≤ 1200 ms).
• SLA: compromiso contractual (SLO + ventanas + remedios/exclusiones).
• Presupuesto de error: % de tiempo en que no cumples el SLO antes de accionar.

SLIs recomendados para sistemas con LLM

• Disponibilidad (end-to-end): % de requests con 2xx.
• Latencia p95 (end-to-end): ms desde request hasta respuesta moderada.
• % JSON válido: respuestas que pasan schema/gramática.
• Groundedness (si hay RAG): % de hechos con cita válida.
• Tasa de abstención sana: % de “no lo sé” cuando falta evidencia.
• % éxito herramientas: llamadas a tools/APIs sin error y dentro de política.
• Costo p95 por request: USD o tokens.

Ejemplos de SLO por plan (orientativos)

Tip: fija también presupuestos (por mes/trimestre) para latencia y costo.

Exclusiones y supuestos (ponlos por escrito)

• Caídas del proveedor LLM, vector DB o APIs de terceros.
• Tráfico fuera de límites o sin backoff por parte del cliente.
• Contenido bloqueado por políticas de seguridad/PII.
• Ventanas de mantenimiento planificadas (aviso ≥ 72 h).
• Índices en reindexación mayor (RAG) notificada.

Modos degradados (continuidad antes que perfección)

• Model routing: cambiar a SLM barato cuando el proveedor premium falla.
• Top-K/Contexto reducido y respuestas más cortas (con disclaimers).
• Safe answer y abstención cuando falta evidencia o hay riesgo.
• Cache de FAQs como fallback temporal.
• Desactivar herramientas de alto riesgo y mantener solo read-only.

Cómo medir cumplimiento

Usa telemetría (trazas + métricas) con request_id. El cálculo típico:

// Ejemplo (mensual)
availability = success_requests / total_requests
p95_latency_ms = percentile(lat_ms, 95)
json_valid_rate = valid_json / total_responses
groundedness = supported_claims / total_claims

Plantilla breve de SLA (YAML)

service: "Asistente IA - QA con RAG"
plans:
  - name: oro
    slo:
      availability: ">= 99.9%"
      p95_latency_ms: "<= 800"
      json_valid_rate: ">= 99%"
      groundedness_rate: ">= 85%"
      cost_p95_usd: "<= 0.008"
    error_budget:
      window: "30d"
      allowed_downtime: "43m"
    measurement:
      source: "llm_metrics, traces, guardrails"
      timezone: "UTC"
    exclusions:
      - "Outages proveedor LLM / APIs terceras"
      - "Mantenimiento programado (72h aviso)"
    remedies:
      - "Créditos prorrateados si availability < SLO"
      - "Mejoras prioritarias en backlog"
    degraded_modes:
      - "SLM fallback, Top-K reducido, respuestas breves con disclaimer"

Micro-workflow en n8n: “SLA Watchdog”

1. Cron (cada 5 min) → consulta métricas recientes.
2. Function → calcula SLIs vs. SLO y presupuesto de error.
3. IF → si p95 > objetivo o json_valid < umbral → activa modo degradado (feature flag).
4. Notifier → envía alerta con diff y recomendación (router, Top-K, cache).
5. HTTP → crea ticket/incident con severidad y runbook asociado.

Tips para Laravel/PHP

• Middleware SlaBudget: mide latencia, valida JSON y etiqueta petición con tier.
• Feature flags (config/DB) para activar degraded_mode por tenant.
• Policies por plan: límites de tokens, Top-K y herramientas permitidas.
• Tabla sla_snapshots: {ts, tenant, availability, p95, json_valid, groundedness, cost_p95, degraded_mode}.

// app/Http/Middleware/SlaBudget.php (boceto)
public function handle($req, Closure $next) {
  $t0 = microtime(true);
  $res = $next($req);
  $lat = (microtime(true)-$t0)*1000;
  event(new \App\Events\SliMeasured([
    'tenant'=>tenant(),
    'lat_ms'=>$lat,
    'json_valid'=>isJsonValid($res),
    'groundedness'=>$res->headers->get('X-Groundedness', null)
  ]));
  return $res;
}

Anti-patrones

• Prometer disponibilidad alta sin fallback de modelo ni cache.
• SLAs solo de latencia sin calidad (JSON/groundedness).
• No definir exclusiones ni ventanas de mantenimiento.
• Ocultar modos degradados (el usuario debe saber qué esperar).

Conclusión

Un buen SLA en IA combina disponibilidad + latencia + calidad + costo y define modos degradados claros. Con métricas confiables, presupuestos de error y automatización, cumples lo que prometes sin sobre-vender.

← Anterior: Seguridad en agentes: protege tu sistema de usos peligrosos o no deseados

Siguiente: MLOps sin dolor: versionado de prompts, datos y evaluaciones →