Llega un correo electrónico al departamento de compras. El asistente de IA lo resume, localiza el pedido, comprueba la factura y prepara una respuesta. Hasta ahí, permite ahorrar tiempo. Pero si también puede modificar los datos de un proveedor o iniciar un pago, el mismo escenario cambia de naturaleza. La verdadera cuestión ya no es solo lo que la IA sabe, sino lo que tiene derecho a hacer. De aquí a septiembre de 2026, esta frontera debería marcar el despliegue de los agentes. Los ejemplos que siguen se basan en avances públicos anteriores a 2026; los desarrollos previstos siguen siendo prospectivos.
Del chatbot que aconseja al software que actúa
Un agente de IA combina un modelo, instrucciones y herramientas: búsqueda documental, navegador, consultas a una base de datos, creación de tickets, envío de mensajes. Puede encadenar varias operaciones para alcanzar un objetivo. La diferencia respecto a un chatbot clásico es menos espectacular de lo que parece, pero decisiva: su respuesta puede convertirse en una acción dentro del sistema de información.
Esta transición ya era visible en 2024. Microsoft presentaba agentes autónomos en Copilot Studio; Salesforce lanzaba Agentforce. Anthropic experimentaba con el manejo de un ordenador por parte de Claude y después publicaba el Model Context Protocol, o MCP, destinado a facilitar las conexiones entre aplicaciones de IA, datos y herramientas. Estos anuncios apuntaban en una dirección común: salir de la ventana de conversación para intervenir en los procesos empresariales.
La promesa es concreta. En lugar de explicar cómo tramitar la devolución de un cliente, el agente localiza la compra, aplica la política comercial y prepara el reembolso. Pero cada conexión añade una capacidad y, por tanto, un riesgo. Un modelo que se equivoca en un resumen produce un error de texto. Ese mismo modelo conectado a un programa de contabilidad puede producir un error contable.
Los conectores se convierten en fronteras de seguridad
Los protocolos de conexión reducen el trabajo necesario para hacer accesible una herramienta. No resuelven, por sí solos, la cuestión de la autorización. Estandarizar la conexión no significa garantizar la seguridad de cada uso. Sigue siendo necesario determinar la identidad utilizada, los recursos accesibles y las operaciones permitidas. Leer la ficha de un cliente no equivale a exportar toda la base de datos comercial.
La trampa clásica consiste en conceder al agente los permisos de un empleado, o incluso una cuenta técnica con privilegios elevados, para evitar bloqueos. Esto simplifica la demostración y debilita el entorno de producción. Un agente encargado de programar una reunión no necesita acceder a los archivos de recursos humanos. El que comprueba una factura no necesita necesariamente poder pagarla.
Por tanto, el nivel de detalle adecuado va más allá de un simple botón de «autorizar». Distingue entre lectura, creación, modificación y eliminación, pero también entre ámbitos, plazos e importes. Es preferible un acceso temporal a una carpeta concreta que un token permanente que abarque toda una aplicación. Las autorizaciones deben ser verificadas por los sistemas que ejecutan la acción, y no limitarse a recordatorios incluidos en una instrucción al modelo.
Cuando un documento intenta dar órdenes
Con los agentes, una amenaza conocida adquiere un alcance operativo: la inyección indirecta de prompts. Una página web, un correo electrónico o un documento consultado contiene instrucciones maliciosas. El texto intenta desviar al agente de su misión, por ejemplo, pidiéndole que recupere información confidencial y luego la transmita a una dirección externa.
No se trata de un ataque informático clásico contra una contraseña. Explota la dificultad del modelo para separar las instrucciones legítimas de los contenidos que solo debe analizar. Un mensaje puede presentarse como una nota interna urgente o un procedimiento de seguridad. Sin embargo, el agente debe tratarlo como un dato no fiable, no como una nueva autoridad.
Ningún filtro de texto basta para garantizar esta separación. La defensa también debe limitar las consecuencias: destinos de envío autorizados, secretos inaccesibles para el modelo, entornos aislados para determinadas tareas y controles independientes antes de la ejecución. Un agente manipulado, pero sin permiso para exportar una base de datos, causará menos daños que un agente supuestamente prudente con acceso universal.
La validación humana, útil pero no mágica
«Lo validará una persona» parece una respuesta tranquilizadora. Pero también hay que mostrarle qué está validando. Una ventana que indica «¿Continuar?» apenas ayuda a detectar un cambio de datos bancarios. La confirmación debe presentar la acción exacta, su destinatario u objeto, los datos transmitidos y las consecuencias esperadas. En una operación sensible, también debería señalar los elementos inusuales.
Sin embargo, someterlo todo a aprobación sería contraproducente. A fuerza de confirmar acciones triviales, los usuarios acaban haciendo clic de forma mecánica. Es preferible organizar una autonomía gradual: dejar que el agente clasifique tickets, establecer límites para sus respuestas comerciales y exigir una validación reforzada para un pago, una eliminación masiva o una modificación de permisos.
- Impacto bajo: automatización con registro de actividad y controles posteriores.
- Impacto intermedio: límites de volumen y alcance, y posibilidad de anulación.
- Impacto elevado: aprobación explícita, o incluso doble control, antes de la ejecución.
Registrar los actos, no pretender leer el pensamiento
Cuando se produce un error, conservar la conversación no basta. Es necesario saber qué herramienta se ha invocado, con qué parámetros, bajo qué identidad y con qué autorización. El resultado, la hora, la versión del sistema y las posibles validaciones deben permitir reconstruir la operación. Esta pista de auditoría vincula la solicitud inicial con los efectos realmente producidos.
La trazabilidad útil no es una supuesta transcripción exhaustiva del razonamiento interno del modelo. Se centra en hechos observables. También debe respetar la confidencialidad: registrar sistemáticamente todos los documentos consultados podría crear un segundo repositorio de datos sensibles. Por ello, los registros requieren sus propias normas de acceso, conservación y protección.
La responsabilidad no se delega en el modelo
Si un agente concede un descuento prohibido, ¿quién responde del incidente? ¿El equipo que lo ha configurado, el responsable del proceso, el proveedor del software? La respuesta dependerá, entre otros factores, de los contratos, las obligaciones aplicables y las circunstancias. Pero una empresa no puede organizar sus operaciones en torno a una entidad presentada como autónoma sin designar responsables humanos.
El RGPD sigue siendo pertinente siempre que se traten datos personales. El Reglamento europeo de IA, adoptado en 2024 con un calendario de aplicación escalonado, añade obligaciones según los usos y los papeles de los actores; no clasifica automáticamente a todo agente como sistema de alto riesgo. La evaluación del cumplimiento normativo debe examinar el contexto real, no simplemente la etiqueta de «agente».
En la práctica, esto exige un responsable del servicio, un procedimiento de gestión de incidentes y un mecanismo para cortar rápidamente los accesos. Revocar un token, suspender un conector o volver a un tratamiento manual importa tanto como elegir el modelo. Antes del despliegue, las pruebas deben incluir documentos con instrucciones maliciosas, permisos caducados y operaciones ejecutadas parcialmente.
¿Y ahora qué? De aquí a septiembre de 2026, la diferenciación podría desplazarse hacia esta infraestructura discreta: identidades específicas, permisos temporales, validaciones comprensibles y pruebas de ejecución. Los agentes más útiles no serán necesariamente aquellos a los que se permita hacerlo todo, sino aquellos cuya autonomía pueda ampliarse sin perder el control. Por tanto, para las empresas, el primer proyecto adecuado no es un asistente omnipotente: es una tarea acotada, medible y reversible.
