El botón de apagado de agentes de IA: defínelo antes de lanzar el tuyo
Sábado, cuatro de la tarde. Estás lejos de la laptop y un agente en producción entra en un bucle: llama una y otra vez a la misma herramienta, gasta presupuesto y le escribe a clientes lo que no debe. ¿Quién lo apaga? ¿Y cuánto tarda en lograrlo? Esa respuesta vive en el botón de apagado de agentes de IA que definas antes del lanzamiento.
En mi artículo sobre agentes en Salesforce terminé con una pregunta: quién le entrega las llaves al agente, para qué puertas y durante cuánto tiempo. Hoy toca la pregunta hermana, la que casi nadie quiere contestar antes del lanzamiento: ¿cómo le quitas esas llaves cuando algo sale mal?
Qué dice Salesforce que ya existe
Según el comunicado de Salesforce México de septiembre de 2026, Agent Kill Switch ya está disponible de forma generalizada como parte de Agent Fabric, a través de Omni Gateway. El texto parte del mismo escenario del sábado por la tarde y sostiene que, en la mayoría de las plataformas, la única medida disponible es desmontar el entorno donde corre el agente, lo que desconecta también a los agentes que sí funcionan bien.
Esto es lo que Salesforce describe:
Cuatro alcances posibles: una sola solicitud, una sesión, una instancia concreta de un agente o todo un inquilino en una emergencia.
Hard Stop: detiene el tráfico de inmediato y bloquea la comunicación del agente con Model Proxy y con otros agentes de la red.
Restore: devuelve al agente al estado exacto en que estaba antes de la congelación, sin reparar datos a mano.
Un registro a prueba de manipulaciones, encadenado por hash, de quién intervino, en qué ámbito, a qué afectó y cuándo.
Todo eso lo dice el fabricante y yo no lo he probado. Además hay tres datos que no pude confirmar: el precio, las licencias que pide y si el mismo botón alcanza a agentes de otras plataformas. El comunicado no los aclara. Si lo vas a evaluar, esas tres preguntas se hacen directo a Salesforce.
Las reglas del botón de apagado de agentes de IA las pones tú
Lo que más me sirvió del comunicado es su argumento. Salesforce plantea que los operadores dudan en accionar la palanca cuando la señal es ambigua, y que esa duda convierte incidentes menores en incidentes caros. Si cada intervención se puede revertir, dice, un falso positivo cuesta segundos y un fin de semana de limpieza queda fuera de la cuenta. Mi lectura es que el argumento se sostiene: un freno barato se usa a tiempo y uno caro se pospone.
Las reglas del botón las define tu equipo. Antes de producción, debería poder contestar cuatro cosas por cada agente crítico:
Qué se detiene: ¿una solicitud, una conversación, el agente completo?
Quién puede apagarlo, incluso un sábado, sin pedir tres permisos.
Qué pasa con lo que ya estaba en curso, como correos a medio enviar o registros a medio escribir.
Cómo se restaura y quién da el visto bueno para volver a encenderlo.
El propio comunicado cierra con dos tareas parecidas: definir qué significan soft stop y hard stop para cada agente crítico y documentarlo antes de necesitarlo, y hacer una prueba de desactivación y restauración en un agente que no esté en producción. Me parece lo más honesto del texto.
Cuándo frenar de golpe y cuándo con calma
Este criterio es mío, sin respaldo del fabricante.
Frena de inmediato (hard stop) cuando:
El agente puede escribirle a clientes o mover dinero y el error se repite.
Sospechas que se desvió de sus instrucciones, por ejemplo por una inyección de comandos, un escenario que el comunicado menciona.
No sabes qué está haciendo. Si no puedes explicarlo, páralo.
Frena con calma, acotado a una solicitud o a una sesión, cuando:
El fallo está en una conversación concreta y el resto funciona.
El agente solo propone y una persona aprueba, así que nada sale solo.
Detener todo costaría más que el error mismo.
El freno rinde más con vigilancia al lado. En su resumen de Dreamforce 2026, Salesforce presenta Agent Health Monitoring, que marca como disponible de forma general, con más de 16 métricas integradas y alertas, y Custom Scorers, con la API disponible y la interfaz todavía en beta, para calificar sesiones con criterios propios. Salesforce las plantea como forma de atrapar las fallas que pasan inadvertidas. Confirma el estado de cada pieza antes de apoyar tu plan en ella.
Entonces, la pregunta incómoda: si tu agente se equivoca esta noche, ¿sabes quién lo apaga y qué pasa después? Si la respuesta es «alguien lo resolverá», todavía no está listo para producción.
Comentarios