Checkpoints y Rollback

000". El flujo de trabajo se confirma, falla a mitad de la ejecución y se reanuda. Si solo se comprueba la clave de idempotencia y se reanuda la ejecución, la transferencia se ejecuta una vez (correcto). Pero consideremos que, entre la falla y la reanudación, el saldo de A cae a $500 debido a un flujo de trabajo diferente. La comprobación de idempotencia sigue pasando, pero la precondición no. Sin una comprobación de precondición, generamos un sobregiro.

Cada acción importante necesita ambas cosas:

• Clave de idempotencia: evita la doble ejecución.
• Comprobación de precondición: confirma que el estado sigue siendo consistente con lo aprobado.

Verificación posterior a la acción

"La herramienta devolvió 200" no es verificación. La verificación real vuelve a leer el estado de destino y confirma que el efecto secundario realmente ocurrió. Patrones:

• Actualización de base de datos: UPDATE ... RETURNING * y luego asegurar (assert) que la fila devuelta coincide con el estado previsto.
• Envío de correo electrónico: verificar la carpeta de enviados en busca del ID del mensaje después de la entrega.
• Escritura de archivo: volver a leer el archivo y calcular su hash.
• Llamada a API: realizar un GET de seguimiento en el recurso de destino.

Si la verificación falla, el flujo de trabajo se encuentra en un estado que se sabe que es malo. El rollback se activa.

Planes de rollback

Cada acción importante en proponer-luego-confirmar (Lección 15) incluye un plan de rollback. Tipos:

• Rollback in-band: revertir el efecto secundario directamente (DELETE después de INSERT, Send-correction-email después del envío).
• Transacción de compensación: una nueva acción que neutraliza la original (patrón tradicional SAGA).
• Rollback out-of-band: alertar a un humano, pausar el flujo de trabajo, dejar el estado incorrecto para su investigación.

El rollback no-op ("no podemos deshacer esto") debe indicarse en la propuesta. Las acciones sin rollback requieren una mayor participación de un humano en el bucle (HITL) al momento de la confirmación (desafío y respuesta de la Lección 15).

Lectura operativa del Artículo 14 de la Ley de IA de la UE

El Artículo 14 exige una "supervisión humana eficaz" para los sistemas de alto riesgo. En términos operativos, quienes lo implementan lo interpretan como:

• Los checkpoints son consultables por un auditor.
• Los rollbacks se ensayan (se prueban de extremo a extremo al menos una vez).
• La pista de auditoría sobrevive a un despliegue (el backend de checkpoint no es efímero).
• Las verificaciones fallidas se alertan, no se registran silenciosamente.

Un flujo de trabajo que falla a mitad del commit, se reanuda y completa el efecto secundario sin una vía de verificación + rollback no supera la prueba del Artículo 14.

El modo de falla crítico: la doble ejecución

El incidente de producción más común en este ámbito:

1. Acción aprobada, clave de idempotencia k.
2. Comienza el commit, se ejecuta, devuelve 200.
3. El flujo de trabajo falla antes de persistir el estado "confirmado" (committed).
4. El flujo de trabajo se reanuda; ve "aprobado pero no confirmado"; se vuelve a ejecutar.
5. El efecto secundario se dispara dos veces.

Mitigación: persistir una intención "en tránsito" (in-flight) antes de la ejecución, ejecutar con una clave de idempotencia y luego marcar como "confirmado" solo después de que la verificación posterior a la acción sea exitosa. Si la acción se dispara y la escritura del estado falla, sabrá que debe verificar y (si es necesario) volver a disparar. Si la escritura del estado es exitosa y la acción falla, usted verifica y dispara exactamente una vez a través de la ruta de recuperación.

Pruébalo

code/main.py implementa un flujo de trabajo con checkpoint, idempotencia, precondiciones, verificación y rollback. El controlador simula cuatro escenarios: ejecución limpia, reintento después de una falla (la idempotencia lo captura), falla de precondición (el flujo de trabajo se cancela sin dispararse) y falla de verificación (el rollback se activa).

Envíalo

outputs/skill-rollback-rehearsal.md diseña una prueba de ensayo de rollback para un flujo de trabajo propuesto y audita el backend de checkpoint para la persistencia de la pista de auditoría.

Ejercicios

1. Ejecute code/main.py. Verifique los cuatro escenarios. Para el caso de falla durante la confirmación, confirme que la acción se dispara exactamente una vez a lo largo de los reintentos.

2. Modifique el patrón "marcar como hecho primero, luego hacerlo" para que la escritura del estado se realice después de la acción. Vuelva a ejecutar el escenario de falla. Mida cuántas acciones duplicadas se disparan.

3. Diseñe un plan de rollback para una acción de producción específica (por ejemplo, "publicar en un canal de Slack"). Clasifíquelo como in-band, de compensación o out-of-band. Justifique la elección.

4. Tome un flujo de trabajo que conozca. Identifique cada transición de estado. Marque cada una con un requisito de durabilidad (persistir / no persistir). Cuente las que actualmente no está persistiendo.

5. Prueba de rollback ensayado: diseñe una prueba de extremo a extremo que ejecute un flujo de trabajo real, lo haga fallar y confirme que se activa la ruta de rollback. ¿Qué valida (assert) la prueba?

Términos Clave

Término	Lo que la gente dice	Lo que realmente significa
Checkpoint	"Punto de guardado"	Cada transición de estado del grafo persiste en un almacenamiento durable
Concesión (Lease)	"Reclamación del worker"	Reclamación de corta duración de que un worker está ejecutando una ejecución; expira al fallar
Precondición	"Filtro de estado"	Afirmación de que el estado sigue siendo consistente con la acción aprobada
Verificación posterior a la acción	"Comprobación de relectura"	Confirmar que el efecto secundario realmente ocurrió en el sistema de destino
Rollback in-band	"Deshacer directo"	Revertir el efecto secundario con la operación inversa
Transación de compensación	"Deshacer SAGA"	Una nueva acción que neutraliza la original
Marcar como hecho primero	"Orden de escritura del estado"	Persistir el estado de confirmado antes de retornar del commit
Artículo 14	"Supervisión humana de la Ley de IA de la UE"	Operativo: checkpoints consultables, rollbacks ensayados, pista de auditoría

Lecturas Adicionales

• Microsoft Agent Framework — Checkpointing and HITL — primitivas de checkpoint y recuperación de concesión.
• Cloudflare Agents — Human in the loop — Durable Objects como sustrato de estado.
• EU AI Act — Article 14: Human oversight — línea de base regulatoria.
• Anthropic — Measuring agent autonomy in practice — marco de confiabilidad para flujos de trabajo de largo alcance.
• Anthropic — Claude Code Agent SDK: agent loop — forma del flujo de trabajo para Claude Code Routines.