Hace unos días, Vercel — una empresa de infraestructura que usan miles de equipos de desarrollo en todo el mundo — confirmó que sufrió un incidente de seguridad. No por un ataque sofisticado contra sus servidores. No por una vulnerabilidad en su código. Sino porque un empleado instaló una herramienta de inteligencia artificial, le dio acceso amplio a su cuenta corporativa de Google, y esa herramienta fue comprometida por un tercero que usó ese acceso para moverse dentro de los sistemas de Vercel.

El detalle técnico que circuló en redes fue el de los tokens OAuth. La discusión que siguió giró alrededor de permisos, supply chain attacks, rotación de credenciales. Todo correcto, todo útil, todo llegando tarde.

Lo que casi nadie dijo fue lo más simple: el empleado que conectó esa herramienta no entendía lo que estaba autorizando.

No porque sea negligente. No porque no sepa trabajar. Sino porque la manera en que presentamos las herramientas de inteligencia artificial hoy invita a ese malentendido. Las interfaces son simples. Los flujos de autorización parecen administrativos. Y la promesa que rodea a estos productos — que van a hacer el trabajo por vos, que van a entender lo que necesitás, que van a actuar en tu nombre — crea la ilusión de que hay criterio del otro lado.

No lo hay.

Esto no es una crítica a la inteligencia artificial. Es una descripción técnica precisa.

Un agente de IA es un programa que ejecuta acciones sobre sistemas reales usando credenciales reales. Cuando le das acceso a tu cuenta de Google, no estás configurando una preferencia. Estás entregando una llave. El agente no sabe si esa llave debería abrir ese cuarto. No sabe si la acción que está ejecutando es razonable en el contexto de tu organización. No sabe si el momento es el correcto, ni si las consecuencias son las esperadas. Ejecuta lo que puede ejecutar, dentro del perímetro de lo que le autorizaste.

El problema no es que los agentes hagan cosas malas. El problema es que hacen exactamente lo que les permitiste hacer, sin la capacidad de evaluar si deberían.

Esta distinción importa. Porque cuando un humano ejecuta una acción dentro de un sistema, hay un proceso implícito antes: leer el contexto, evaluar el riesgo, decidir si es el momento, consultar si hay dudas. Ese proceso es invisible, pero existe. Un agente de IA no lo tiene. Tiene instrucciones, tiene permisos, y tiene la capacidad técnica de ejecutar. Con eso opera.

El patrón que describió el incidente de Vercel no es nuevo para quienes trabajamos en infraestructura desde hace tiempo.

Hace años, antes de que existieran los agentes de IA, ya existía la versión humana del mismo problema: el técnico al que le daban acceso de administrador a todos los sistemas porque era más cómodo que gestionar permisos granulares. La organización razonaba que era de confianza, que sabía lo que hacía, que no valía la pena el esfuerzo de limitarle el acceso. Y muchas veces tenía razón. Pero cuando algo salía mal — un error, una cuenta comprometida, una decisión tomada sin el contexto correcto — el daño era proporcional al acceso que tenía, no al error que cometió.

Los agentes de IA son esa lógica llevada a escala, con velocidad de ejecución automatizada, y sin la fricción natural que tiene un humano cuando hace algo que no le parece bien.

Un empleado que tiene acceso excesivo a un sistema puede dudar. Puede preguntar. Puede decidir no hacer algo aunque técnicamente pueda. Un agente no duda. Si tiene el permiso, ejecuta.

Lo que ocurrió con Vercel fue esto, en términos concretos: un empleado usó su cuenta corporativa para suscribirse a un producto de IA llamado Context AI. Durante el proceso de configuración, autorizó el acceso "Allow All" a su Google Drive. Esa autorización no era maliciosa ni descuidada en el sentido convencional — era la opción que el producto ofrecía, presentada como un paso de configuración entre otros.

Meses después, Context AI fue comprometido. Los atacantes tomaron los tokens OAuth que esa herramienta tenía almacenados, y desde ahí accedieron a la cuenta de Google del empleado de Vercel, y desde ahí a sistemas internos de Vercel. Variables de entorno. Credenciales. Datos de clientes.

El empleado no hizo nada fuera de lo que el producto pedía. El producto hizo exactamente lo que estaba autorizado a hacer. Y la cadena entera funcionó contra la organización porque nadie, en ningún punto del proceso, evaluó si esos permisos tenían sentido.

Eso no es un problema de seguridad técnica solamente. Es un problema de comprensión.

Y esto no ocurre solo en empresas de tecnología. Ocurre en cualquier organización que empieza a incorporar IA a sus procesos operativos. El pedido parece razonable: unificar en una herramienta los informes que hoy están dispersos en Excel o archivos. Stocks, análisis, tickets de salida, facturación, contratos. Toda la información financiera y operativa real de la empresa, concentrada y accesible para que la IA coordine. Nadie en esa conversación pregunta qué herramienta va a procesar esos datos, dónde los almacena, quién tiene acceso a ese almacenamiento, o qué pasa si ese proveedor es comprometido. El pedido suena a eficiencia y reemplazo de gente perezosa. El acceso que habilita es otra cosa. La herramienta entrega valor visible — el informe, el análisis, el tiempo ahorrado. Y ese valor hace que el costo sea difícil de ver. Pero la información que subiste no desaparece cuando cerrás la pantalla. Queda en los servidores de alguien más. Y si esa empresa la vende, la expone, o simplemente tiene un empleado que decide usarla, el problema no va a llegar como un hackeo. Va a llegar como una decisión de tu competencia que no entendés de dónde salió. O como una negociación donde la otra parte sabe más de tu negocio que lo que debería saber.

Las organizaciones hoy están incorporando herramientas de inteligencia artificial con la misma lógica con la que incorporaron el software en la nube hace diez o quince años: rápido, sin inventario, sin política, y con la suposición de que el proveedor se ocupa de la seguridad.

Esa lógica fue cara en su momento. Va a ser más cara ahora.

La diferencia con el software en la nube es que esas herramientas almacenaban datos. Los agentes de IA ejecutan acciones. La distinción es crítica. Un archivo en un servidor comprometido es un dato expuesto. Un agente con permisos amplios en un entorno comprometido es una capacidad de acción en manos equivocadas.

No es lo mismo perder información que perder la capacidad de actuar dentro de tus propios sistemas.

El criterio que falta no es técnico. Es organizacional.

No se trata de que los técnicos entiendan mejor cómo funciona OAuth. Se trata de que las organizaciones entiendan que cada herramienta que conectan a su infraestructura — especialmente las que prometen actuar en nombre de alguien — necesita la misma evaluación que cualquier otro acceso privilegiado.

¿Qué puede hacer esta herramienta? ¿Sobre qué sistemas? ¿Quién controla lo que hace? ¿Qué pasa si esa herramienta es comprometida o actúa de manera incorrecta? ¿Hay alguien que revise lo que hizo?

Estas preguntas no son complicadas. Son las mismas que deberían hacerse cuando se incorpora a un proveedor con acceso remoto, cuando se integra un sistema externo con APIs internas, cuando se le da acceso a un técnico nuevo a la infraestructura. El proceso existe. Solo hay que aplicarlo también acá.

Lo que no puede pasar es que la facilidad de instalación de una herramienta de IA se convierta en la razón por la que nadie se hace esas preguntas. Que porque la interfaz es simple, el acceso también se trate como simple. La interfaz es simple. El acceso no lo es.

La inteligencia artificial no reemplaza el criterio. Lo necesita más que cualquier otra herramienta, porque opera a mayor velocidad, con menor fricción, y con la misma legitimidad técnica que una acción humana autorizada.

Cuando algo sale mal con un agente de IA, los sistemas no saben distinguir si la acción fue tomada por un humano o por un programa que actúa en su nombre. Ven credenciales válidas. Ven permisos otorgados. Ven una operación que técnicamente estaba autorizada. No hay alarma automática porque nada fue violado en sentido técnico estricto.

El control tiene que estar antes. En la decisión de qué acceso se otorga, a qué herramienta, bajo qué condiciones, con qué supervisión.

Eso es criterio. Y el criterio no viene incluido en ninguna suscripción de IA.

El incidente de Vercel va a repetirse. No necesariamente en Vercel, no necesariamente con Context AI. Pero el patrón — herramienta con acceso amplio, proveedor comprometido, movimiento lateral dentro de la organización — está demasiado consolidado como para tratarlo como un caso excepcional.

Las organizaciones que empiezan a trabajar con agentes de IA hoy están tomando decisiones de acceso que van a condicionar su postura de seguridad durante años. No porque sea inevitable que salga mal. Sino porque los permisos que se otorgan hoy no se revisan solos, los tokens que se generan hoy no se revocan automáticamente, y las herramientas que se integran hoy no vienen con un aviso cuando algo cambia en el entorno del proveedor.

La incorporación de inteligencia artificial a los procesos de trabajo es una decisión de arquitectura. No en el sentido técnico únicamente. En el sentido de qué se autoriza, quién lo controla, y qué pasa cuando algo falla.

Esa decisión necesita criterio humano. No hay IA que la pueda tomar por vos.