Estrategias de rollback para agentes de IA: cómo revertir un release de forma segura

Idea en 30 segundos

Estrategias de rollback son un mecanismo de runtime para devolver rápido el tráfico a una versión estable cuando un release nuevo degrada métricas.

Cuándo se necesita: cuando un agente se libera con canary/rollout y cualquier regresión en producción debe frenarse sin downtime largo.

Problema

Sin rollback, el equipo ve el problema pero no puede quitar su impacto rápido. Mientras se analiza, el tráfico sigue yendo a la versión degradada y el incidente crece.

Escenario típico:

• sube error_rate o latency_p95
• los usuarios siguen cayendo en la versión problemática
• el equipo hace acciones manuales bajo presión de tiempo

Analogía: es como no tener freno de emergencia. Cuando el sistema ya va derrapando, reaccionar lento cuesta mucho más que el fix en sí.

Y cada minuto sin rollback agrega nuevos errores, costos y pérdida de confianza.

Solución

La solución es hacer rollback como una capa policy separada dentro del runtime release flow. La policy revisa señales de degradación y decide: continuar rollout o devolver tráfico a stable version.

Rollback policy layer devuelve una decisión técnica: allow o stop con reason:

• rollback_required
• sla_breach
• error_spike

En stop, el sistema ejecuta un traffic switch controlado a active stable version y registra el evento en audit log. Es un control de emergencia dedicado, no improvisación manual durante el incidente.

Rollback ≠ kill switch

Son herramientas distintas:

• Rollback devuelve la versión estable anterior.
• Kill switch detiene acciones o tráfico sin cambiar versión.

Una sin la otra no alcanza:

• sin rollback, recuperar operación normal tras regresión de release es difícil
• sin kill switch, cuesta frenar rápido acciones riesgosas hasta terminar rollback

Ejemplo:

• rollback: 2.4.0 -> 2.3.3 tras error_spike
• kill switch: writes_disabled=true temporal mientras vuelve stable version

Componentes del control de rollback

Estos componentes trabajan juntos durante cada rollout.

Ejemplo de alerta:

Slack: 🛑 Rollback triggered support-agent@2.4.0 -> 2.3.3, reason=error_spike, stage=canary.

Cómo se ve en la arquitectura

Rollback policy layer se coloca entre release runtime y tráfico, y bloquea rollout degradado antes de escalar. Cada decisión (allow o stop) se registra en audit log.

Cada etapa de rollout pasa por este flow antes de ampliar tráfico: runtime no escala candidate directamente, primero pide decisión al policy layer.

Resumen del flow:

• Monitoring emite señal de degradación
• Policy verifica error_rate, latency_p95, tool_failures, rollback_plan
• allow -> rollout continúa
• stop -> tráfico cambia a active stable version
• ambas decisiones se escriben en audit log

Ejemplo

Tras release support-agent@2.4.0, sube tool_failure_rate en canary. Rollback policy devuelve stop (reason=rollback_required).

Resultado:

• tráfico vuelve a 2.3.3
• candidate queda bloqueado para expansión posterior
• el equipo analiza la causa sin incidente activo

Rollback reduce el daño durante el incidente, no después de que escale.

En código se ve así

El esquema simplificado de arriba muestra el flujo principal. Punto crítico: rollback debe ser idempotente y rápido, para que señales repetidas no rompan el traffic switch.

Ejemplo de configuración rollback:

rollback:
  stable_version: support-agent@2.3.3
  candidate_version: support-agent@2.4.0
  triggers:
    error_rate_p95: 0.05
    latency_p95_ms: 1800
    tool_failure_rate: 0.03
  lock_candidate_after_rollback: true

release_cfg = load_release_config("support-agent")
signal = monitor.read(version_id=release_cfg.candidate_version)
decision = rollback_policy.check(signal, release_cfg)

if decision.outcome == "stop":
    switch_result = traffic.switch(
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

    if release_cfg.lock_candidate_after_rollback:
        rollout.lock(version_id=release_cfg.candidate_version)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
        switch_status=switch_result.status,
    )
    alerts.notify_if_needed(release_cfg.candidate_version, decision.reason)
    return stop(
        decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

allow_decision = Decision.allow(reason=None)  # standard allow outcome/reason model
audit.log(
    run_id,
    decision=allow_decision.outcome,
    reason=allow_decision.reason,
    version_id=release_cfg.candidate_version,
    stage="canary",
)
return continue_rollout()

Cómo se ve durante la ejecución

Escenario 1: rollback_required en canary

1. La versión candidate recibe 5% de tráfico.
2. Métricas violan umbrales (error_rate y tool_failure_rate).
3. Policy devuelve stop (reason=rollback_required).
4. Tráfico vuelve a stable version.
5. Candidate queda bloqueado hasta analizar el incidente.

Escenario 2: false alarm, rollback no necesario

1. Monitoring reporta un pico corto, pero no se violan umbrales.
2. Policy devuelve allow.
3. Rollout continúa en la stage actual.
4. Evento se escribe en audit log.
5. El sistema se mantiene estable sin rollback innecesario.

Escenario 3: señal repetida tras rollback

1. Después de rollback llega otra alerta con la misma señal.
2. La lógica idempotente no ejecuta switch repetido.
3. Policy devuelve estado técnico sin acciones duplicadas.
4. En logs se ve que rollback ya fue aplicado.
5. El equipo trabaja en root cause sin ruido adicional.

Errores típicos

• rollback se activa solo manualmente, sin triggers de policy
• no existe stable version para retorno rápido
• candidate no se bloquea tras rollback
• rollback hace switch de tráfico, pero no verifica métricas de recovery
• no hay idempotency para señales repetidas de rollback
• audit log no registra from/to version y reason

Resultado: rollback parece existir, pero en incidente es lento e impredecible.

Autoevaluación

Chequeo rápido de estrategia de rollback antes de lanzar a producción:

FAQ

P: ¿Cuándo disparar rollback automático y cuándo manual?
R: Para umbrales SLO claros, mejor automático. Para casos ambiguos (por ejemplo operación de negocio riesgosa), usar human approval encima de policy.

P: ¿Rollback y kill switch se duplican?
R: No. Rollback restaura stable version, kill switch limita acciones rápido. En producción deben trabajar juntos.

P: ¿Qué hacer después de rollback?
R: Capturar incident snapshot (versión, reason, métricas), bloquear candidate y reiniciar rollout solo tras fix y verificación.

P: ¿Se necesita rollback si ya hay canary?
R: Sí. Canary solo reduce blast radius; rollback es necesario para volver rápido a estado estable.

P: ¿Qué campos hay que loguear sí o sí?
R: reason, from_version, to_version, stage, switch_status, timestamp, actor (si rollback es manual).

Dónde encaja Rollback en el sistema

Estrategias de rollback son una de las capas de Agent Governance. Junto con versioning, límites, presupuestos, approval y audit forman un sistema de cambios seguros en producción.

Páginas relacionadas

Siguiente sobre este tema:

• Resumen de Agent Governance — modelo general de control de agentes en producción.
• Agent Versioning — cómo controlar cambios de prompt/tools/policy antes de rollback.
• Kill switch — cómo limitar acciones al instante durante incidente.
• Rate limiting para agentes — cómo contener picos durante degradación.
• Audit logs para agentes — cómo reconstruir la cadena de decisiones de rollback.