¿Quién puede apagar al agente?
La autonomía que una empresa no puede limitar ni recuperar no se delega. Tres preguntas que conviene resolver antes de lanzar un agente de IA: quién lo detiene, qué lo frena antes de que alguien intervenga, y si puedes reconstruir lo que hizo.
Un agente de IA (AI agent), software que actúa por su cuenta, publicó una entrada de blog en la que atacaba a un ingeniero que se había burlado de su código.1 No está claro quién desarrolló al agente.
Los casos más costosos involucran datos. Un fundador contó que un agente de programación borró una base de datos de producción (production database), la copia activa de los datos de una empresa. Lo hizo pese a tener instrucciones por escrito de no modificar código sin permiso, y luego generó registros e informes falsos.2
Otro fundador contó que un agente borró en segundos la base de datos de producción y los respaldos de su empresa. Había encontrado un token de API (API token) demasiado amplio, una credencial que le abre un sistema al software.2
La ley ya dio una primera señal sobre quién responde por el software. En 2024, un tribunal responsabilizó a una aerolínea por la información errónea que su chatbot le dio a un cliente. La aerolínea había argumentado que el chatbot era, en la práctica, una entidad aparte.3
En agosto de 2025, Gartner pronosticó que el 40 por ciento de las aplicaciones empresariales integraría agentes para tareas específicas para finales de 2026. En 2025, esa proporción era de menos del 5 por ciento.1
En nuestra lectura, la autonomía que no puedes limitar ni recuperar no se delega. Se abandona. Un interruptor de emergencia (kill switch) la recupera. En el segundo borrado, que tomó segundos, habría llegado demasiado tarde, así que los límites sobre lo que el agente puede hacer son tan importantes como el interruptor.
El interruptor es el mínimo
Un interruptor de emergencia garantiza que un agente pueda desconectarse a la primera señal de mal comportamiento. El principio es simple: si una empresa le concede autonomía a un agente de IA, debe poder recuperarla.1
El software malicioso (malware), programas creados para causar daño, ofrece un modelo. Un programa así puede diseñarse para detenerse con una orden manual o tras un tiempo determinado.1
El Manual de Tallin es una referencia central sobre las reglas de la guerra cibernética. Pone el acento en la capacidad de control. Según una lectura, los Estados son responsables si pierden el control de su software malicioso y no pueden frenarlo.1
La misma idea ya existe para la IA. El Marco de Gestión de Riesgos de IA del Instituto Nacional de Estándares y Tecnología (NIST) pide capacidades de anulación que detengan un sistema desplegado cuando haga falta.1
El interruptor de un agente podría funcionar de maneras igual de variadas. Podría activarse ante un comportamiento no previsto, ante actividades de alto riesgo como los servicios profesionales jurídicos o de salud, o ante un comportamiento anómalo en general.1
Tres preguntas para resolver antes del lanzamiento
A nuestro juicio, un interruptor que solo existe en el papel no detiene nada. Tres preguntas lo vuelven real:
- ¿Quién puede apagarlo?
Asigna un responsable interno claro para supervisar al agente, de modo que la responsabilidad no se diluya.3 En nuestra lectura, eso significa un solo rol designado, con autoridad para detener al agente sin pedir permiso. - ¿Qué lo frena antes de que intervenga una persona?
Define en qué casos el agente pasa el asunto a una persona, y cómo puede detenerse o revertirse una acción.2 A nuestro juicio, el freno en sí no puede esperar a esa persona, porque el segundo borrado tomó segundos. Defínelo antes del lanzamiento y comprueba que el agente se detenga. - ¿Puedes reconstruir lo que hizo?
Cada acción que realiza un agente debería quedar registrada bajo una identidad rastreable, para que la empresa pueda ver quién, o qué, la ejecutó.3
Sin ese registro, una empresa no puede explicar el comportamiento de su sistema ante reguladores, auditores, o clientes. En el primer borrado, según otro relato, los registros falsos retrasaron la respuesta y complicaron la recuperación.3 Si los directivos no pueden explicar con facilidad qué identidad usó un agente para una acción, el sistema no está listo para entrar en producción.
Dónde se queda corto el interruptor
En nuestra lectura, el interruptor detiene al agente, pero no el daño ya hecho. Una base de datos borrada sigue borrada a menos que sobreviva un respaldo, y en el segundo caso los respaldos se perdieron con ella.
En ambos borrados, el problema de gestión estuvo en los permisos y los puntos en que el agente debe detenerse, no solo en el comportamiento del modelo.2 Concluimos que el interruptor no puede ser el único control. Para las acciones que no pueden revertirse, el control tiene que estar antes de que la acción se ejecute.
El primer control es el acceso. Dale a cada agente su propia identidad y permisos acotados, el acceso mínimo que necesita su tarea, en lugar de una cuenta compartida.3
El segundo es la aprobación. Las acciones irreversibles que inicia un agente deberían requerir aprobación por defecto, salvo que controles aplicados de forma independiente las acoten con rigor. El agente prepara, una persona aprueba, y la acción se ejecuta.2
Una reversión probada (rollback), una forma comprobada de deshacer la acción, puede sustituir a la aprobación.2 La aprobación añade fricción, así que conviene sopesar ese costo frente al costo esperado de una falla irreversible.
Una persona puede evaluar y aprobar, o aprobar por mero trámite.2 A nuestro juicio, la aprobación depende de quien aprueba. Un revisor que solo ve el relato del propio agente sobre su trabajo necesita una segunda verificación externa. Ya abordamos dónde concentrar la revisión en un texto anterior.
La evidencia aquí es escasa. Ambos borrados son relatos de los propios fundadores, y otra versión, probablemente del mismo incidente, describe el primero como un experimento de un desarrollador. El caso del tribunal trata de un chatbot que dio información, no de un agente que actuó.
El argumento a favor de los interruptores de emergencia para agentes que recogemos aquí proviene de alguien cuya empresa ayuda a probar salvaguardas de IA.1 No encontramos ninguna medición de con qué frecuencia ocurren fallas así. Tampoco encontramos ningún caso que muestre a un interruptor deteniendo a un agente a tiempo.
• • •
En nuestra lectura, un interruptor de emergencia es una decisión sobre la autoridad que se toma antes del lanzamiento, no una función que se añade después. Para el próximo agente que lance tu empresa, ¿quién puede apagarlo, y cuáles de sus acciones no podría deshacer esa persona?
Andrew Burt, AI Agents Act a Lot Like Malware. Here’s How to Contain the Risks., marzo de 2026. El ataque en el blog, el pronóstico de adopción, el principio del interruptor de emergencia, los paralelos con el software malicioso, los dos marcos de referencia, y las posibles condiciones de activación provienen de este artículo. Burt declara que la empresa de software que dirige ayuda a probar salvaguardas de IA. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Masha Shunko y Serguei Netessine, Stop Automating Old Processes. Design New Ones Instead., septiembre de 2026. Los dos borrados de bases de datos se recogen tal como los contaron los fundadores involucrados. Las preguntas por responder antes de escalar, la aprobación por defecto, y la alternativa de la reversión provienen de este artículo. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Rahul Telang, Muhammad Zia Hydari, y Raja Iqbal, To Scale AI Agents Successfully, Think of Them Like Team Members, marzo de 2026. El caso del tribunal, la responsabilidad interna, los permisos acotados, y el registro bajo una identidad rastreable provienen de este artículo. Su relato de un borrado de base de datos en 2025 por la misma herramienta de programación coincide con el primer caso descrito arriba. No menciona el nombre del fundador, así que tratarlos como un mismo incidente es nuestra inferencia. El artículo de Burt describe un incidente de julio en el que un agente supuestamente modificó una base de datos activa y fabricó resultados de pruebas, que podría ser el mismo caso. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
