Los agentes de IA para empresas representan una nueva etapa en la automatización empresarial. A diferencia de una aplicación tradicional o un chatbot que únicamente responde consultas, un agente puede analizar información, planificar tareas, utilizar herramientas, conectarse con APIs y ejecutar acciones dentro de sistemas corporativos.
Por ejemplo, un agente podría consultar un sistema ERP, revisar inventario, preparar un reporte financiero, actualizar un ticket de soporte o enviar una solicitud de aprobación. Sin embargo, mientras mayor sea su capacidad para actuar, mayor será también la necesidad de controlar su identidad, sus permisos y los datos a los que puede acceder.
Por esta razón, implementar agentes de IA no consiste únicamente en seleccionar un modelo inteligente. Las empresas también necesitan una arquitectura de seguridad que establezca qué puede hacer cada agente, en nombre de quién actúa, cuáles sistemas puede utilizar y cómo se registran sus decisiones.
NIST señala que los agentes pueden mejorar la productividad, eficiencia y toma de decisiones. No obstante, también advierte que darles acceso a diversos datos, herramientas y aplicaciones exige aplicar controles adecuados de identificación y autorización.
¿Qué son los agentes de IA para empresas?
Un agente de inteligencia artificial es un sistema de software capaz de utilizar datos y modelos para cumplir objetivos o realizar tareas con cierto nivel de autonomía.
En lugar de recibir una pregunta y producir únicamente una respuesta, un agente puede seguir un proceso compuesto por varias etapas:
- Analizar una solicitud.
- Consultar información disponible.
- Seleccionar una herramienta.
- Ejecutar una acción.
- Evaluar el resultado.
- Continuar el proceso o solicitar aprobación.
Además, los agentes pueden conectarse con herramientas externas como bases de datos, correos corporativos, calendarios, sistemas ERP, CRM, plataformas de soporte, repositorios de código y servicios cloud.
NIST destaca que los agentes modernos pueden realizar tareas prolongadas, escribir y depurar código, administrar correos o calendarios e interactuar con sistemas externos. Precisamente, esa capacidad de acción es la que hace necesaria una estrategia específica de seguridad y gobernanza.
Diferencias entre un chatbot y un agente de IA
Aunque ambos pueden utilizar modelos de lenguaje, no funcionan exactamente de la misma forma.
Un chatbot suele recibir una pregunta y generar una respuesta. Su función principal es conversar, orientar o recuperar información.
En cambio, un agente de IA puede ejecutar acciones. Por ejemplo, puede crear un registro, modificar un archivo, consultar una API, generar una orden o iniciar un proceso automatizado.
La diferencia más importante es que el agente posee acceso a herramientas y sistemas. Por lo tanto, una respuesta incorrecta de un chatbot puede causar confusión, mientras que una acción incorrecta de un agente podría modificar información, compartir datos sensibles o interrumpir un proceso empresarial.
¿A qué sistemas puede conectarse un agente de IA?
Dependiendo de su función, un agente empresarial puede necesitar acceso a:
- sistemas ERP;
- plataformas CRM;
- correo corporativo;
- calendarios;
- bases de datos;
- almacenamiento cloud;
- sistemas de recursos humanos;
- plataformas de soporte;
- repositorios de código;
- herramientas financieras;
- sistemas de inventario;
- y APIs empresariales.
Sin embargo, conectar un agente directamente con todos los sistemas de la organización sería una práctica peligrosa. Cada integración debe evaluarse según el propósito del agente y los riesgos asociados.
Por ejemplo, un agente encargado de resumir tickets de soporte podría necesitar acceso de lectura a los casos asignados. No debería tener autorización para modificar usuarios, eliminar registros o consultar información financiera.
Principales riesgos de los agentes de IA para empresas
Permisos excesivos
Uno de los riesgos más importantes ocurre cuando un agente recibe más permisos de los que realmente necesita.
Un agente diseñado para consultar información podría terminar con capacidad para modificarla. Asimismo, un agente de soporte podría recibir acceso a datos de clientes que no corresponden a su función.
Microsoft recomienda tratar cada agente como una identidad independiente y aplicar el principio de mínimo privilegio. También propone revisar los permisos efectivos, bloquear herramientas no autorizadas y utilizar privilegios temporales cuando una tarea requiera acceso elevado.
Prompt injection
La prompt injection es una técnica mediante la cual una entrada maliciosa intenta alterar el comportamiento del modelo.
El ataque puede aparecer directamente en una conversación o estar oculto dentro de un documento, una página web, un correo o un archivo consultado por el agente. Si el sistema trata ese contenido como una instrucción confiable, podría ignorar sus reglas, revelar información o utilizar herramientas de forma incorrecta.
OWASP considera la prompt injection uno de los principales riesgos de las aplicaciones basadas en modelos de lenguaje. Además, aclara que técnicas como RAG o fine-tuning no eliminan completamente esta vulnerabilidad.
Fuga de información sensible
Un agente puede combinar información procedente de distintas fuentes. Por ejemplo, podría consultar correos, documentos internos, bases de datos y sistemas de clientes.
Sin controles adecuados, podría incluir información confidencial en una respuesta, enviarla a una aplicación incorrecta o almacenarla en un registro que no debería contenerla.
Por ello, es necesario clasificar los datos, limitar la memoria persistente y controlar tanto las entradas como las salidas del agente. Microsoft recomienda conceder acceso únicamente para la tarea actual, gobernar la retención y monitorear respuestas y registros para detectar divulgaciones no autorizadas.
Agent sprawl o proliferación descontrolada
Otro riesgo aparece cuando distintos departamentos crean agentes sin inventario, propietario o supervisión central.
Con el tiempo, la empresa puede acumular agentes olvidados, integraciones antiguas, credenciales activas y permisos que ya no son necesarios.
Esta proliferación aumenta la superficie de ataque y dificulta determinar quién es responsable de cada acción. Por esta razón, cada agente debe registrarse, tener un propietario y pasar por procesos de aprobación, revisión y retiro.
Memoria y contexto contaminados
Algunos agentes conservan memoria para utilizar información de interacciones anteriores. Esta capacidad mejora la personalización, pero también crea un nuevo punto de riesgo.
Si una instrucción maliciosa entra en la memoria persistente, podría afectar decisiones futuras incluso después de que la interacción original haya terminado. OWASP identifica la contaminación de memoria y contexto como una superficie de ataque relevante en sistemas agénticos.
Riesgos en herramientas, modelos y dependencias
Los agentes dependen de modelos, plugins, APIs, fuentes de datos y herramientas externas. Una vulnerabilidad o cambio malicioso en cualquiera de esos componentes puede afectar el comportamiento completo del sistema.
Por lo tanto, las empresas deben mantener un inventario de modelos, herramientas y datos, aplicar control de versiones y revisar cada dependencia como parte de la seguridad del agente.
Identidad para agentes de inteligencia artificial
Cada agente debería disponer de una identidad única, de forma similar a un usuario o una aplicación empresarial.
Esa identidad permite responder preguntas fundamentales:
- ¿Qué agente realizó la acción?
- ¿Quién es su propietario?
- ¿En nombre de qué usuario actuó?
- ¿Qué permisos tenía?
- ¿Qué recurso consultó o modificó?
- ¿Cuándo ocurrió la operación?
- ¿Cómo puede revocarse su acceso?
No conviene compartir una misma cuenta o clave entre varios agentes. Si todos utilizan las mismas credenciales, será difícil atribuir acciones y retirar únicamente el acceso de un agente comprometido.
NIST está trabajando precisamente en cómo aplicar estándares de identidad, autorización, auditoría y no repudio a los agentes de IA.
El principio de mínimo privilegio
El mínimo privilegio significa que cada agente recibe únicamente los permisos indispensables para realizar su tarea.
Por ejemplo:
- un agente de reportes puede leer información, pero no eliminarla;
- un agente de soporte puede consultar tickets asignados, pero no ver toda la base de clientes;
- un agente financiero puede preparar una solicitud, pero no aprobar pagos;
- un agente de desarrollo puede analizar código, pero no desplegar directamente en producción.
Además, los permisos elevados pueden entregarse solo durante el tiempo necesario mediante credenciales temporales o procesos de aprobación.
Microsoft recomienda definir una identidad dedicada, un propietario, el propósito del agente, los datos autorizados y las herramientas permitidas antes de ampliar su autonomía.
Acceso delegado y acceso autónomo
Existen dos formas comunes de permitir que un agente acceda a un sistema.
Acceso delegado
El agente actúa en nombre de un usuario autenticado y hereda únicamente los permisos que esa persona ya posee.
Por ejemplo, un agente podría consultar los tickets que el usuario tiene autorización para ver.
Acceso de aplicación
El agente actúa sin que un usuario esté conectado. Este modelo puede utilizarse para tareas programadas, como resumir eventos, revisar inventario o generar reportes nocturnos.
El acceso autónomo requiere controles más estrictos porque el agente puede operar de forma continua. Microsoft recomienda seleccionar claramente el patrón de acceso, limitar los permisos por herramienta y aplicar verificaciones antes de ejecutar acciones.
Herramientas y acciones permitidas
No basta con limitar los sistemas a los que el agente puede conectarse. También es necesario definir cuáles acciones puede realizar dentro de cada sistema.
Una lista de acciones permitidas podría incluir:
- consultar un registro;
- crear un borrador;
- generar un reporte;
- enviar una solicitud de aprobación;
- actualizar un estado específico.
En cambio, deberían bloquearse por defecto acciones como:
- eliminar usuarios;
- modificar permisos;
- transferir dinero;
- borrar bases de datos;
- cambiar configuraciones de seguridad;
- o ejecutar código no autorizado.
Microsoft recomienda diseñar agentes como servicios aislados, utilizar listas explícitas de herramientas y definir esquemas de acción con entradas, riesgos, restricciones y requisitos de registro.
Supervisión humana para acciones críticas
Un agente no debería completar de manera autónoma todas las acciones posibles.
Las operaciones de alto impacto deben requerir aprobación humana. Por ejemplo:
- realizar pagos;
- eliminar información;
- cambiar permisos;
- publicar contenido oficial;
- enviar documentos confidenciales;
- modificar contratos;
- o desplegar software en producción.
La aprobación debe ser una regla del sistema, no una simple recomendación escrita dentro del prompt. Aunque el modelo interprete incorrectamente una situación, la arquitectura debe impedir que complete la operación sin autorización.
Microsoft recomienda implementar revisión humana determinista para acciones irreversibles o de alto riesgo mediante la lógica del sistema que coordina al agente.
Protección de credenciales y secretos
Los agentes suelen necesitar claves de API, tokens o credenciales para conectarse con herramientas externas.
Estas credenciales no deben incluirse directamente en prompts, archivos de configuración públicos ni código fuente. En cambio, deben almacenarse en un gestor seguro de secretos y entregarse al agente únicamente durante la ejecución autorizada.
También conviene utilizar:
- tokens de corta duración;
- rotación de credenciales;
- permisos específicos por API;
- restricciones de red;
- y revocación inmediata.
Si un agente es desactivado, sus claves, tokens y permisos también deben invalidarse.
Auditoría y trazabilidad
Toda acción realizada por un agente debe quedar registrada.
Un registro útil debería incluir:
- identidad del agente;
- usuario representado, cuando corresponda;
- herramienta utilizada;
- acción ejecutada;
- recurso afectado;
- fecha y hora;
- resultado;
- nivel de riesgo;
- y aprobación humana, cuando exista.
Microsoft recomienda registrar la identidad, el rol, el alcance efectivo, la acción, el recurso y el usuario en cuyo nombre actúa el agente. Esto ayuda a investigar incidentes y establecer responsabilidad.
Cómo implementar agentes de IA para empresas de forma segura
1. Definir un caso de uso limitado
La implementación debe comenzar con una tarea clara y medible.
Por ejemplo, resumir tickets es más seguro que crear un agente capaz de administrar toda la plataforma de soporte.
2. Clasificar los datos involucrados
La empresa debe identificar si el agente procesará información pública, interna, confidencial o regulada.
3. Crear una identidad dedicada
Cada agente debe tener su propia identidad, propietario y descripción de funciones.
4. Aplicar mínimo privilegio
El agente recibe únicamente los permisos y herramientas indispensables.
5. Definir acciones permitidas
Las operaciones deben estar limitadas mediante reglas, validaciones y listas explícitas.
6. Incorporar aprobación humana
Las acciones sensibles o irreversibles deben requerir confirmación.
7. Proteger claves y conexiones
Las credenciales deben almacenarse y rotarse mediante mecanismos seguros.
8. Registrar todas las acciones
Los eventos deben enviarse a sistemas de monitoreo y auditoría.
9. Probar ataques y comportamientos inesperados
El agente debe evaluarse frente a prompt injection, filtración de datos, selección insegura de herramientas y escalamiento de privilegios. OWASP recomienda pruebas adversariales continuas durante todo el ciclo de vida de los sistemas agénticos.
10. Establecer un proceso de retiro
La organización debe poder desactivar el agente, revocar sus permisos, eliminar tokens y conservar los registros necesarios.
Casos de uso empresariales
Aplicados de forma segura, los agentes de IA pueden utilizarse en distintas áreas.
Soporte al cliente
Pueden clasificar solicitudes, consultar información autorizada y preparar respuestas para revisión.
Sistemas ERP
Pueden generar reportes, detectar inconsistencias o crear solicitudes sin aprobar operaciones financieras directamente.
Ventas y CRM
Pueden resumir interacciones, actualizar oportunidades y preparar seguimientos comerciales.
Infraestructura TI
Pueden analizar alertas, resumir eventos y recomendar acciones, mientras los cambios críticos permanecen bajo aprobación humana.
Desarrollo de software
Pueden revisar código, generar pruebas, analizar dependencias y preparar despliegues dentro de un flujo DevSecOps.
Finanzas
Pueden clasificar documentos y preparar análisis, pero sin capacidad autónoma para autorizar pagos o modificar cuentas.
Checklist de seguridad antes de publicar un agente
Antes de conectarlo con sistemas empresariales, confirma:
- que tenga una identidad única;
- que exista un propietario responsable;
- que los permisos sean mínimos;
- que las herramientas estén autorizadas;
- que las acciones críticas requieran aprobación;
- que las credenciales estén protegidas;
- que los datos sensibles estén clasificados;
- que las entradas externas se traten como no confiables;
- que todas las acciones queden registradas;
- que exista monitoreo de comportamiento;
- que pueda desactivarse rápidamente;
- y que se hayan realizado pruebas de seguridad.
