Cuando la IA deja de responder y empieza a actuar en las empresas

Estamos asistiendo a una mutación profunda en la forma en que la inteligencia artificial se incorpora al trabajo diario de las empresas. Durante los últimos años la adopción se ha centrado en asistentes conversacionales y copilotos que responden preguntas, resumen textos o facilitan búsquedas. Sin embargo, la tendencia que hoy toma fuerza es la de agentes de IA capaces no solo de dialogar, sino de planificar, razonar y ejecutar acciones en sistemas empresariales en nombre de usuarios u organizaciones.

Este salto —de "responder" a "actuar"— cambia por completo el panorama de riesgos. Los nuevos agentes no se limitan a mostrar información: interactúan con aplicaciones, consultan bases de datos, lanzan flujos de trabajo y, en algunos casos, modifican recursos. Esa capacidad de intervención transforma a la IA en una entidad que exige controles distintos a los de un bot tradicional.

No todos los agentes generan el mismo peligro. El nivel de riesgo depende fundamentalmente de dos variables: a qué pueden acceder y cuánta independencia tienen para actuar sin supervisión humana. Un asistente que solo busca en una documentación local supone un riesgo muy distinto al de un agente que puede, por ejemplo, ejecutar despliegues en la nube o cambiar configuraciones críticas.

En la práctica conviene distinguir, por lo menos, tres familias de agentes corporativos. Las primeras versiones son los chatbots integrados en plataformas gestionadas: aparecen en herramientas de productividad, sistemas de atención al cliente o bases de conocimiento y se activan con la interacción humana para recuperar o condensar información. Suelen ser de baja autonomía, pero no están exentos de problemas: si emplean conectores con credenciales estáticas o permisos demasiado amplios, se convierten en puertas de acceso privilegiadas a recursos sensibles.

La segunda categoría, y probablemente la más problemática por su rápida expansión, son los agentes locales que corren en los endpoints de los empleados. Estos asistentes se integran con editores de código, terminales, herramientas de análisis o scripts automatizados y heredan las credenciales y permisos del usuario que los ejecuta. Esa propiedad facilita la adopción porque elimina pasos de provisión centralizada, pero también genera un agujero de gobernanza: cada empleado puede, sin darse tanto cuenta, convertir su entorno de trabajo en un vector de acción con permisos corporativos.

El tercer grupo lo constituyen los agentes de producción: servicios continuos que orquestan tareas complejas, responden a eventos y actúan sin intervención humana. Se usan para automatizar respuesta a incidentes, pipelines de DevOps o procesos de negocio y operan con identidades de máquina y credenciales dedicadas. Aquí los riesgos son más evidentes porque combinan autonomía elevada, acceso a infraestructuras críticas y, con frecuencia, el procesamiento de entradas externas que pueden contener instrucciones maliciosas.

El hilo conductor entre estos escenarios es la identidad. Cada agente es, de hecho, una nueva clase de identidad digital dentro de la empresa: pide tokens, consume APIs, escribe en repositorios y dispara trabajos. Si esas identidades están mal gestionadas —permisos excesivos, ciclo de vida incontrolado, rotación defectuosa— el agente se transforma en una ventana para atacantes o en una fuente de errores con consecuencias operativas y regulatorias.

Además, la configuración típica de arquitecturas con múltiples agentes puede generar cadenas de confianza ocultas: un agente puede invocar a otro y así escalar privilegios o propagar acciones no previstas. Y no hay que subestimar la exposición a inyecciones de instrucciones (prompt injection), un vector donde entradas externas manipulan el comportamiento del modelo para inducirlo a realizar acciones no deseadas; sobre este tema conviene revisar recursos especializados como la guía de OWASP sobre prompt injection (OWASP Prompt Injection).

Para quienes lideran seguridad (CISOs), la prioridad deja de ser debatir si la IA entrará en la organización y pasa a identificar dónde ya está y cómo opera. Es necesario conocer qué agentes existen, qué identidades utilizan, a qué sistemas pueden acceder y si esos permisos corresponden al propósito declarado de cada agente. Esa visión es la base para decidir en qué orden abordar riesgos y qué controles aplicar.

Algunas referencias de buen gobierno y gestión de riesgos pueden ayudar a estructurar esa respuesta. El marco de gestión de riesgos para IA del NIST ofrece principios y herramientas para evaluar y mitigar riesgos específicos de sistemas inteligentes (NIST AI RMF), mientras que las guías de identidad digital de NIST son útiles para entender cómo debería gestionarse el ciclo de vida de identidades humanas y de máquina (NIST SP 800-63). En el extremo de la cadena de suministro, las recomendaciones del Centro Nacional de Ciberseguridad del Reino Unido sobre la seguridad de la cadena de suministro de software son valiosas para mitigar riesgos asociados a plugins y dependencias externas (NCSC Software Supply Chain Security).

En términos prácticos, las organizaciones deberían invertir en detección y visibilidad: descubrir agentes desplegados, inventariar identidades y registrar las acciones que ejecutan. A partir de ahí, conviene aplicar el principio de menor privilegio y mecanismos de acceso dinámico que limiten lo que cada identidad puede hacer y por cuánto tiempo. La rotación automática de credenciales, el uso de identidades federadas y el control de uso de plugins de terceros son medidas que reducen la superficie de amenaza sin frenar la productividad.

No menos importante es instrumentar la telemetría: trazas, registros de auditoría y alertas que permitan reconocer comportamientos anómalos de un agente. Las pruebas de resiliencia frente a instrucciones adversas y la validación segura de entradas externas ayudan a atajar vectores como la inyección de prompts. Para diseñar estas pruebas conviene consultar buenas prácticas de plataformas que ofrecen modelos y APIs, que suelen incluir recomendaciones específicas de seguridad (OpenAI Security Guidance) y documentación sobre inteligencia artificial responsable por parte de proveedores de nube (Microsoft Responsible AI).

La paradoja de la era de los agentes es que la velocidad y la autonomía que los hacen tan útiles son también las que exigen un replanteamiento de controles tradicionales. Las herramientas de identidad y acceso pensadas para humanos y para servicios convencionales no bastan: hacen falta soluciones que manejen identidades de agentes a escala, con provisión, reglas de acceso temporales, rotación automática y capacidades de auditoría específicas para actividades automatizadas.

Al final, asegurar la IA no es prohibirla, sino gobernarla. Las organizaciones que avancen más deprisa serán las que sepan mapear sus agentes, alinear permisos con intenciones operativas y aplicar controles de identidad como plano de control. En ese sentido, la identidad deja de ser un componente más de la arquitectura: se vuelve la palanca central para permitir la adopción segura de agentes que actúen sin supervisión humana frecuente.

Si su empresa está desplegando o evaluando agentes, conviene empezar por un inventario, definir criterios de riesgo basados en acceso y autonomía, y priorizar controles sobre aquellos agentes con mayor capacidad de impacto. La literatura y las pautas de organismos como NIST y los equipos de seguridad de proveedores de plataformas ofrecen marcos sólidos para estructurar esa transición hacia una IA que aporte valor sin comprometer la seguridad.