Un ritual de 5 pasos para evitar que flujos sin revisión se publiquen

Eres el responsable de operaciones que decide quién puede publicar automatizaciones. Antes del 4 de agosto, un usuario de n8n con acceso de publicación podía poner un flujo en producción con un solo clic. Una matriz de permisos más grande no lo solucionará. Un pequeño ritual que hace visible la matriz de permisos dentro de un ciclo de trabajo normal, sí: proponer el flujo, revisarlo, acotarlo, documentarlo y solo entonces dejarlo ejecutarse.

La puerta es el botón de publicación

La versión 2.34.0 de n8n añadió un ciclo de revisión que mantiene un flujo fuera de producción mientras esa revisión siga abierta. Esa es la puerta que necesitas en cada automatización. La versión de n8n con fecha 2026-09-01 hace que el editor de roles de instancia personalizada emita una advertencia sobre un rol que solo lleva el permiso Manage project roles, ya que quien lo posee puede modificar el alcance de cualquier rol personalizado de tipo proyecto. Deja esa advertencia en el ticket. Si un rol puede editar alcances, puede ampliar silenciosamente el radio de impacto. Si aparece la advertencia, trata el rol como una solicitud de cambio.

Acota al agente, no al equipo

Un conjunto de alcances amplio convierte una automatización defectuosa en un incidente a nivel de empresa. Una nota de parche convierte una corrección del runner en algo que la siguiente persona de guardia puede verificar. La prueba es simple: si un agente puede leer, escribir o invocar algo que no necesita para su tarea, el alcance es demasiado amplio. La versión 2.34.0 de n8n añadió gestión de alcances MCP a nivel de agente, permitiendo que una instancia asigne distintos alcances MCP a distintos agentes en lugar de un conjunto compartido. Entre el 5 y el 7 de agosto, n8n publicó cuatro actualizaciones puntuales para corregir un defecto de health-check que hacía que los despliegues en modo cola con task runners externos reportaran falsos negativos; las correcciones se identificaron en 2.34.4 y 2.33.7. Empieza con un valor predeterminado más restrictivo y amplía solo cuando una tarea lo requiera.

La lista de verificación es el ritual

Cada paso siguiente es verificable en un minuto, y cada uno debe aparecer en el ticket del flujo antes de la publicación. La lista es un conjunto mínimo de comprobaciones, no un documento de política. Si una comprobación no se puede completar en un minuto, probablemente es la comprobación equivocada.

• Abre una revisión antes de publicar y confirma que la puerta está activa.
• Designa un revisor que apruebe o solicite cambios, y verifica que el registro de revisión muestre una decisión.
• Aprueba la revisión y verifica que la publicación se realice automáticamente, sin un paso manual de despliegue separado.
• Asigna alcances MCP por agente y confirma que cada agente tiene solo los alcances que necesita.
• Añade una nota de parche para configuraciones de task-runner a escala.

Los puntos de publicación mantienen el camino honesto. El punto de alcance impide que el agente herede más acceso del que la tarea requiere. Deja la nota de parche en el mismo ticket que la revisión.

El bucle de revisión necesita una regla de parada

El flujo de equipo de agentes Claude Code de ejemplo de AWS se detiene tras un tercer ciclo de revisión fallido, bloqueando el alcance afectado para decisión humana en lugar de iniciar otra ronda de compilación-revisión. En el ejemplo de AWS, cada ciclo de revisión produce un único review.md y un único veredicto de aprobado o rechazado del pool de review-agent. En ese ejemplo, el veredicto de un review-agent rechaza el trabajo cuando falta un nivel de prueba requerido o cuando una aserción comprueba un mock en lugar del sistema real. El ejemplo de AWS controla cada paso del flujo con cuatro niveles de prueba: T1 pruebas unitarias, T2 pruebas de integración o de contrato, T3 verificación de recursos desplegados y T4 recorridos de extremo a extremo.

El número de niveles importa menos que la regla de parada. Un nivel ausente es una parada definitiva, no una nota para más adelante. La misma lógica se aplica a un mock. Si la prueba demuestra el falso, no ha demostrado el flujo. La automatización con humano en el bucle funciona cuando el bucle tiene un estado terminal.

La lista de verificación del CISO de Armosec enmarca la aprobación de producción de agentes de IA como siete puertas, cada una vinculada a un estándar concreto de evidencia. La lista de Armosec exige que la entrada de inventario de tiempo de ejecución de un agente de IA muestre los runtimes de herramientas MCP adjuntos, el revisor de seguridad designado y la fecha en que se añadió la entrada. Eso le da al responsable de operaciones una forma de responder quién puede tocar qué y cuándo. La entrada debe ser aburrida. Debe responder a las preguntas que un nuevo responsable de operaciones hace durante un incidente.