Un asistente que inventa una respuesta hace perder tiempo. Ese mismo asistente, conectado al software de facturación, puede enviar un recordatorio de pago injustificado a un cliente estratégico. Conectado al sistema de compras, puede convertir una mala interpretación en un pedido en firme. El cambio decisivo no es solo la inteligencia del modelo: es su permiso para actuar. De cara a septiembre de 2026, el verdadero trabajo en torno a los agentes de IA se perfila, por tanto, menos en las ventanas de conversación que en las reglas de acceso a los sistemas empresariales.
Del asesoramiento a la ejecución, un cambio de naturaleza
La trayectoria ya es visible en los anuncios y productos aparecidos en 2024 y a principios de 2025. Salesforce presentó Agentforce, Microsoft desarrolló las capacidades de agentes de Copilot Studio y OpenAI dio a conocer Operator, capaz de interactuar con interfaces web. Estos hitos documentados no demuestran una autonomía generalizada. Sin embargo, apuntan a una dirección común: pasar de una herramienta que sugiere una acción a un software que intenta llevarla a cabo.
Lo que sigue corresponde a un análisis prospectivo, no a un balance verificado de septiembre de 2026. En las empresas, esta evolución podría desplazar la cuestión central. En lugar de preguntarse únicamente si la IA responde correctamente, habrá que establecer qué puede modificar, en nombre de quién y dentro de qué límites. Un resumen erróneo sigue siendo rectificable. Una eliminación de datos o un pago iniciado requieren otras protecciones.
Tomemos un caso ficticio, pero habitual: «Regulariza las facturas pendientes de este proveedor». ¿Hay que localizar los documentos que faltan, corregir una referencia, preparar un pago o ejecutarlo? Para un empleado, el contexto y los procedimientos suelen delimitar la tarea. Para un agente, esta frase puede convertirse en una sucesión de llamadas a funciones de software. Cada paso exige una autorización distinta, que la fluidez de la conversación tiende a ocultar.
Una cuenta de servicio no es un mandato ilimitado
El atajo sería dar al agente las credenciales de un empleado y dejarlo trabajar. Eso supondría confundir dos cosas: los permisos de los que dispone una persona para ejercer su profesión y los necesarios para una tarea concreta. Una responsable financiera puede tener acceso a todos los proveedores. El agente encargado de verificar una factura no necesita poder cambiar sus datos bancarios.
El principio de mínimo privilegio, clásico en ciberseguridad, adquiere así una nueva dimensión. Los permisos deberían limitarse por operación, por recurso y, cuando sea posible, en el tiempo. Leer un expediente, proponer una modificación y validarla constituyen tres facultades diferentes. Reunirlas detrás de un botón de «conectar mi empresa» hace que la demostración resulte atractiva, pero dificulta el control del riesgo.
También hay que distinguir entre la identidad del agente, la de su usuario y la del servicio técnico que ejecuta la acción. Sin esta separación, una operación aparece simplemente como realizada por una cuenta compartida. Resulta entonces imposible determinar con facilidad quién la solicitó y bajo qué delegación. El agente debe recibir un mandato acotado, no heredar silenciosamente toda la autoridad de su usuario.
El documento consultado puede convertirse en una trampa
Los agentes reúnen dos propiedades delicadas: leen contenidos externos y, en ocasiones, disponen de herramientas potentes. Un correo electrónico, una página web o un documento compartido pueden contener instrucciones maliciosas dirigidas al modelo. Es el problema de la inyección indirecta de prompts: un texto que debería servir de información intenta convertirse en una orden.
Imaginemos un archivo adjunto que pide discretamente al asistente que envíe una exportación de datos de clientes a una dirección externa, con el pretexto de un control contable. El peligro no es que el documento posea por sí mismo un permiso informático. Es que el agente utilice sus propios permisos para seguir una instrucción procedente de una fuente no autorizada. En ese momento, ha desaparecido una frontera entre datos y órdenes.
La respuesta no puede basarse únicamente en una instrucción al modelo: «Ignora las instrucciones sospechosas». Los controles también deben existir fuera de él: destinos autorizados, filtrado de salidas, restricciones de acceso y verificación de los parámetros antes de la ejecución. Un componente determinista puede rechazar una transferencia prohibida aunque el agente la considere útil. La seguridad no debe depender únicamente de su capacidad para reconocer un engaño.
Conectar con mayor facilidad no significa autorizar correctamente
Presentado por Anthropic en noviembre de 2024, el Model Context Protocol, o MCP, ilustra la búsqueda de una interfaz común entre asistentes, datos y herramientas. Este tipo de estándar puede reducir el trabajo necesario para conectar un modelo a un entorno empresarial. Pero la compatibilidad técnica no resuelve, por sí sola, la gobernanza de las acciones.
Un conector indica cómo invocar una función. No determina necesariamente si esa función debe estar disponible en una situación concreta. Una empresa seguirá teniendo que examinar los permisos solicitados, la procedencia de los componentes y la información transmitida. El catálogo de herramientas merece la misma atención que un catálogo de aplicaciones: cada nueva conexión puede ampliar la superficie de ataque.
La validación humana debe tener contenido
«Un ser humano sigue en el circuito» puede convertirse en una fórmula vacía. Si una persona aprueba cincuenta propuestas opacas seguidas, corre el riesgo de hacer clic por costumbre. Una validación útil debe presentar la acción exacta, los datos afectados, sus consecuencias y los elementos que justifican la solicitud. Para una transferencia bancaria, mostrar únicamente «operación conforme» no permite un control riguroso.
El nivel de control debería ajustarse al riesgo. Clasificar una incidencia interna puede seguir siendo automático. Preparar una respuesta comercial puede requerir una revisión. Modificar un beneficiario bancario o eliminar archivos puede exigir una doble validación. Sobre todo, la aprobación debe referirse a los parámetros que realmente se ejecutan: si el importe o el destinatario cambian después de la aprobación, esta deja de ser válida.
Registrar las acciones, prever las reparaciones
La conversación no basta como registro de auditoría. Hay que conservar las herramientas invocadas, los parámetros transmitidos, las respuestas recibidas, los permisos utilizados y las validaciones obtenidas. El objetivo no es recopilar un hipotético razonamiento interno del modelo, sino reconstruir los hechos observables. Este registro debe, a su vez, proteger los datos personales y evitar almacenar secretos innecesariamente.
También hay que prepararse para los fallos. Algunas acciones pueden anularse; otras requieren una operación compensatoria, y un correo enviado no se puede recuperar realmente. Los límites de actividad, una parada de emergencia y las pruebas con escenarios adversos se vuelven indispensables. Los equipos deberán medir no solo las tareas realizadas con éxito, sino también las acciones no deseadas, los rechazos justificados y el tiempo necesario para restablecer la situación.
¿Y ahora qué? Para septiembre de 2026 y los años siguientes, el escenario más creíble no es necesariamente el de agentes con libertad para hacerlo todo. Es el de una autonomía gradual, ganada tarea a tarea gracias a resultados verificables. Empezar por un ámbito en el que las acciones sean reversibles, separar la propuesta de la ejecución y ampliar después los permisos tras una evaluación parece menos espectacular que una demostración sin supervisión. Pero la ventaja duradera podría provenir precisamente de ahí: saber confiar una acción a la IA sin renunciar al control de sus consecuencias.
