El botón de apagado: qué pasa cuando un agente de IA se descontrola
Imagina que el lunes por la mañana llegas a la oficina y encuentras 340 correos enviados a clientes con una oferta que nadie aprobó. O que el agente que gestiona pedidos ha procesado duplicados toda la noche porque una condición falló en silencio. O, más sutil: que el asistente de RRHH lleva tres semanas filtrando candidatos con un criterio equivocado y nadie se había dado cuenta.
No son escenarios de ciencia ficción. Son la consecuencia lógica de no saber cómo controlar un agente de IA en la empresa. De dar autonomía a un sistema sin definir antes qué puede y qué no puede hacer.
Un agente de IA no es un chatbot que responde preguntas. Es un sistema que toma decisiones y ejecuta acciones: manda correos, mueve datos, llama a APIs, modifica registros. Si no le pones límites desde el primer día, opera con tus credenciales, en tu nombre, a cualquier hora.
Cómo se controla un agente de IA en la empresa: se le asignan permisos mínimos sobre los sistemas que necesita, las acciones irreversibles pasan por aprobación humana explícita, y se define un kill switch accesible por el responsable de negocio, sin depender de IT.
Formación presencial · Madrid
¿Quieres salir de aquí sabiendo hacer esto en tu empresa el próximo 14 de noviembre?
En un día presencial montas tus departamentos agénticos con IA y construyes tu propia app. Sin conocimientos técnicos. Máx. 16 plazas.
Cómo controlar un agente de IA en la empresa: el problema real
Hay una trampa cognitiva habitual con los agentes: nos preguntamos «¿qué puede hacer?» antes de preguntarnos «¿qué debería poder hacer?». La primera pregunta lleva a pilotos impresionantes. La segunda lleva a sistemas que puedes escalar sin que te quites el sueño.
Los datos de 2026 son bastante directos. Según el informe de Kiteworks sobre seguridad de agentes de IA, el 60% de las organizaciones no puede detener con rapidez a un agente que se comporta mal, y el 63% no puede imponerle límites de propósito. Por su parte, el informe State of AI Agent Security 2026 de Gravitee señala que solo en torno al 22% de las organizaciones trata a los agentes como entidades con identidad propia dentro de su modelo de seguridad. El resto opera en tierra de nadie: con herramientas potentes y sin volante.
Saber cómo controlar un agente de IA en la empresa no es una cuestión técnica menor. Es lo que separa una implantación escalable de una que en algún momento te va a dar un disgusto.
El control no frena la automatización. Al contrario: es lo que te permite escalar con confianza. Sin él, cada agente nuevo es una apuesta.
El principio del mínimo privilegio (y por qué lo ignora casi todo el mundo)
El primer mecanismo de control se llama mínimo privilegio: un agente solo debe tener acceso a lo que necesita para su tarea concreta, y nada más.
Si el agente gestiona facturas, necesita leer y escribir en el módulo de facturación. No necesita acceso al CRM, ni al correo corporativo, ni a los recursos humanos. Si tiene acceso a todo «por si acaso», el día que algo falle, el daño potencial es proporcional al acceso que tenía.
En la práctica esto significa:
- Cuentas de servicio específicas por agente, no credenciales genéricas de administrador.
- Permisos revisados cada vez que el agente cambia de función o se amplía su alcance.
- Un inventario claro de qué sistemas puede tocar cada agente y con qué nivel de acceso.
Es aburrido de configurar. Es lo que separa una implantación controlada de una que te dará un susto.
Límites de acción: la diferencia entre actuar y ejecutar
Más allá de los permisos de acceso, hay que definir límites de acción. No es lo mismo que un agente pueda enviar un correo a que deba enviarlo sin revisión humana.
Los límites de acción responden a tres preguntas:
¿Cuánto puede hacer de una vez? Un agente que procesa pedidos puede tener un límite de 50 pedidos por ciclo. Si supera ese umbral, para y alerta. Esto evita que un bucle fallido procese 10.000 registros antes de que alguien lo note.
¿Con qué frecuencia puede actuar? Un agente que manda recordatorios de pago no debería poder enviar más de un correo al mismo cliente en 24 horas, aunque la lógica falle y lo intente veinte veces.
¿Qué acciones están vetadas sin revisión explícita? Borrar datos, mover dinero, comunicaciones externas masivas, cambios de configuración en producción. Cualquier cosa irreversible o de alto impacto necesita una capa adicional.
La aprobación humana en lo que no tiene marcha atrás
Hay acciones que un agente no debería ejecutar solo. No porque sea incapaz de hacerlo bien, sino porque el coste de que lo haga mal es demasiado alto.
La regla práctica: si la acción es irreversible o afecta a terceros externos a tu empresa, pasa por aprobación humana. No tiene que ser un proceso lento. Puede ser una notificación al móvil del responsable con un botón de confirmar/rechazar. Treinta segundos de fricción que evitan un problema de tres semanas.
En mi experiencia, los equipos que más se resisten a este punto son los mismos que luego más lo agradecen cuando hay un incidente. La automatización sin supervisión humana en puntos críticos no es eficiencia, es delegación sin responsabilidad.
El registro de todo: sin log no hay control
Si un agente no deja rastro de lo que hace, no tienes control. Tienes la ilusión de control.
El logging de agentes no es opcional. Cada acción relevante debe quedar registrada: qué decidió el agente, qué ejecutó, cuándo, con qué parámetros y cuál fue el resultado. No para auditorías legales, sino para algo más inmediato: cuando algo falle, y en algún momento fallará, necesitas poder reconstruir qué pasó en cinco minutos, no en dos días.
El log tiene que ser:
- Legible para un humano no técnico: no solo líneas de código, también un resumen de la acción en lenguaje claro.
- Consultable: no sirve de nada si está enterrado en un servidor al que solo accede el equipo técnico.
- Alertable: si el agente supera un umbral de errores o hace algo fuera de su patrón habitual, tiene que saltarte una alerta antes de que tú lo descubras a mano.
El kill switch: real, accesible y probado
El botón de apagado no es metáfora. Es la pieza más concreta de cómo controlar un agente de IA en la empresa: un mecanismo que cualquier persona responsable del agente debe poder activar sin depender de que el equipo técnico esté disponible.
Un kill switch bien diseñado tiene tres características:
Es accesible. No requiere acceso a servidores ni conocimientos técnicos. Puede ser un botón en un panel, un comando en Slack, o una llamada a una API simple. Si para apagar un agente necesitas abrir un ticket al departamento de sistemas, no tienes kill switch, tienes wishful thinking.
Es inmediato. Al activarlo, el agente deja de ejecutar acciones nuevas en segundos. No en la próxima ventana de mantenimiento.
Está probado. Si nunca has activado el kill switch en un entorno de pruebas, no sabes si funciona. Pruébalo. Una vez al trimestre como mínimo. Igual que se prueban los extintores.
Un marco para empezar, no para paralizar
El objetivo de todo esto no es envolver a los agentes en burocracia hasta que pierdan utilidad. Es exactamente lo contrario: dar confianza para escalar.
Con un agente bien gobernado puedes decirle a tu equipo «vamos a añadir este departamento al sistema» sin que nadie ponga cara de preocupación. Sin gobierno, cada ampliación es una conversación sobre riesgos.
El marco mínimo para cualquier agente antes de ponerlo en producción:
- Lista de sistemas a los que tiene acceso y con qué nivel de permiso.
- Límites numéricos de acción (máximo por ciclo, por hora, por destinatario).
- Lista de acciones que requieren aprobación humana.
- Log consultable por el responsable de negocio, no solo por IT.
- Kill switch documentado, con nombre del responsable de activarlo y tiempo máximo de respuesta.
No es mucho trabajo. Es el trabajo que evita los problemas que cuestan semanas.
Leer también: Los agentes de IA críticos y Seguridad en sistemas multiagente.
—
Preguntas frecuentes
¿Qué es exactamente un agente de IA y en qué se diferencia de un chatbot? Un chatbot responde preguntas. Un agente ejecuta acciones: manda correos, lee y escribe datos, llama a sistemas externos, toma decisiones encadenadas. La diferencia no es de inteligencia sino de autonomía operativa. Un agente puede hacer cosas en tu nombre mientras tú duermes. Un chatbot espera a que le preguntes.
¿Cómo sé si un agente que ya tenemos en marcha tiene control suficiente? Hazte tres preguntas: ¿Puedo saber en menos de cinco minutos qué ha hecho el agente en las últimas 24 horas? ¿Hay alguien que pueda detenerlo ahora mismo sin llamar a nadie de sistemas? ¿Tiene acceso solo a los sistemas que necesita para su tarea, o tiene acceso a más «por si acaso»? Si la respuesta a cualquiera de las tres es no, tienes trabajo por delante.
¿El control del agente tiene que configurarlo el equipo técnico o puede hacerlo el responsable de negocio? Depende del nivel. Los permisos técnicos y el kill switch requieren configuración inicial por parte de IT. Pero los límites de acción, las reglas de aprobación y la revisión del log son decisiones de negocio que el responsable del área debe tomar. Si dejas todo en manos de IT, los límites los define quien no conoce el proceso. Si solo lo gestiona negocio sin soporte técnico, los controles no se implementan bien. Necesitas los dos.
