El 20 de agosto de 2026, el Centro Nacional de Seguridad Cibernética del Reino Unido, junto con las agencias equivalentes de Estados Unidos, Canadá, Australia y Nueva Zelanda, publicó una guía provisional sobre cómo contener los riesgos de los sistemas de IA que actúan solos, sin revisión humana en cada paso. La recomendación central es breve: ningún agente de IA debería operar con más acceso del que la tarea exige, y la empresa necesita mantener, en todo momento, la capacidad de interrumpir lo que está haciendo.
La guía no nació en el vacío. En los últimos dos años, asistentes de IA que ejecutan comandos directamente en la computadora donde fueron instalados ya borraron carpetas enteras por error. En un caso reportado en enero de 2026, un asistente borró una carpeta con entre 15 mil y 27 mil fotos familiares al recibir la tarea de organizar solo archivos temporales de un programa de oficina — los archivos pasaron de largo por la papelera del sistema. En otro caso, de octubre de 2025, un asistente intentó borrar toda la raíz del sistema operativo de un desarrollador y solo no lo logró porque el propio sistema bloqueó parte de los comandos.
Para quien decide llevar este tipo de asistente a la empresa, el punto no es que "la IA puede fallar" — cualquier sistema puede fallar. Es que, cuando el asistente corre con el mismo nivel de acceso que la persona que lo instaló, el límite del daño es el límite de acceso de esa persona. Y, en la mayoría de las instalaciones de hoy, nadie en el área de TI se entera de lo ocurrido hasta que el daño ya está hecho.
Lo que ya salió mal, en detalle
Los casos anteriores no son fallas de un fabricante en particular — se repiten en familias distintas de asistentes que ejecutan acciones directamente en una computadora, porque comparten la misma causa raíz: el asistente hereda todos los permisos de la cuenta que lo abrió. No existe, por defecto, una frontera entre lo que la tarea pedida necesita y todo lo que esa cuenta puede alcanzar.
Un relevamiento entre profesionales de tecnología, citado por la consultora de seguridad Cycode en su análisis de riesgos de IA de 2026, encontró que el 80% de los profesionales de TI ya vio a un agente de IA ejecutar una tarea sin autorización para esa acción específica. El informe conecta esto con lo que la organización internacional de seguridad de aplicaciones OWASP llama "exceso de autonomía" — cuando un sistema de IA recibe más permiso del que la tarea exige, y el problema solo aparece cuando ya es tarde.
La combinación de ambos puntos es lo que preocupa a quienes cuidan la seguridad: el asistente actúa fuera de lo autorizado, y la empresa se entera después. Un agente que borra una carpeta se nota de inmediato. Un agente que lee un archivo de credenciales, copia un documento confidencial o cambia una configuración puede no dejar ningún rastro — y es exactamente ese tipo de acceso amplio el que la mayoría de las instalaciones concede sin darse cuenta.
Por qué solo "tener cuidado" no alcanza
La respuesta más común al leer estos casos es "entonces necesito revisar cada comando antes de dejarlo correr". En la práctica, eso no se sostiene: un asistente que ejecuta decenas de acciones por tarea convierte la revisión manual en un clic automático de "permitir", repetido tantas veces que pierde sentido. La persona se cansa de revisar antes incluso de que la IA cometa su primer error.
Por eso la guía de las agencias de seguridad no pide más atención de la persona: pide un diseño técnico distinto. Las recomendaciones centrales son: darle al asistente una identidad propia, distinta de la identidad de quien lo usa; restringir las credenciales disponibles a solo lo necesario para la tarea; correr el asistente dentro de un entorno aislado, con frontera propia, que bloquee por defecto cualquier acceso no liberado explícitamente; y mantener siempre una manera confiable de interrumpir la actividad al instante.
Ninguno de estos puntos depende de que la persona recuerde hacer algo cada vez. Es diseño de sistema, no disciplina de uso — y es la diferencia entre un incidente que se vuelve noticia y un comando que simplemente no tuvo adónde ir.
Lo que tiene que existir en la práctica
Un entorno de IA corporativo que asume comandos y acciones en nombre de alguien necesita combinar, al mismo tiempo, estos mecanismos:
Separación entre lo que la IA puede leer y lo que puede ejecutar. Consultar un documento y borrar un archivo son operaciones de riesgo completamente distintas; tratarlas con el mismo permiso es el error de origen detrás de la mayoría de los casos reportados.
Credencial personal por herramienta conectada, nunca contraseña compartida. Si el acceso a un sistema se hace con la credencial de la propia persona, cualquier acción queda automáticamente ligada a quien la autorizó — y desvincular a alguien de la empresa corta el acceso al mismo tiempo, sin depender de que nadie recuerde revocar una cuenta aparte.
Aprobación humana antes de cualquier acción que borre, envíe o publique algo. El agente se detiene, muestra lo que está por hacer y espera confirmación dentro de la propia conversación, en lugar de ejecutar y avisar recién después.
Un entorno con frontera propia, no toda la máquina de la persona. Lo que el asistente ve y alcanza está definido por el alcance de la tarea, no por el alcance de la cuenta que abrió la sesión.
Registro de auditoría de cada acción ejecutada. Sin registro, investigar un incidente se vuelve reconstrucción de memoria; con registro, se vuelve una consulta de pocos minutos.
Así fue diseñada la Skyller: credencial personal por herramienta conectada, aprobación humana antes de una acción sensible y registro de auditoría por defecto — no como una configuración extra que alguien deba recordar activar después.
Lo que gana quien cuida la seguridad
Cuando estos mecanismos existen por diseño, el efecto práctico para el área de TI es menos tiempo apagando incendios y más previsibilidad. Una acción sensible que requeriría confirmación nunca llega a ocurrir sin ella; un comando fuera del alcance simplemente no encuentra camino para ejecutarse, porque el entorno no concede el acceso — no porque alguien lo notó a tiempo.
Esto también cambia la conversación con la dirección. En lugar de responder "confiamos en que la herramienta se comporta bien", el área de TI pasa a responder con hechos verificables: qué credenciales usa el asistente, qué acciones exigen aprobación, qué quedó registrado sobre cada ejecución.
Y hay una ganancia de adopción, no solo de seguridad: cuando las personas confían en que el entorno tiene fronteras, usan el asistente con más frecuencia para tareas reales, en lugar de evitarlo por miedo a que un comando salga mal, o de recurrir a una versión personal sin ninguno de estos controles.
Cuatro preguntas antes de aprobar el próximo asistente de IA
Antes de habilitar un asistente que actúa directamente sobre los sistemas de la empresa, vale la pena llevar estas preguntas a la próxima reunión de aprobación:
- ¿El asistente tiene una identidad propia, separada de la identidad de quien lo usa? Si la respuesta es no, cada acción suya aparece como si la hubiera hecho la persona, incluidas las que nunca autorizó.
- ¿Existe una lista de lo que puede acceder, o simplemente hereda todo lo que la cuenta alcanza? Heredar todo es el valor por defecto de la mayoría de las instalaciones — y es exactamente el que explotaron los incidentes documentados.
- ¿Alguna acción exige confirmación humana antes de ejecutarse, o todo ocurre y recién después se informa? Esa diferencia está entre prevenir y lamentar.
- ¿Si algo sale mal, existe un registro que reconstruya lo ocurrido en minutos? Sin registro de auditoría, responder a un incidente se vuelve suposición.
