Un asistente prepara un reembolso, abre el programa de facturación y hace clic en «validar». El cliente recibe su dinero. Después, un empleado descubre que la solicitud era fraudulenta. ¿Quién debe responder por el error: el proveedor del modelo, el integrador, el responsable del área de negocio o la empresa que le dio acceso a la cuenta? Con los agentes de IA, la cuestión ya no es solo saber si una respuesta es correcta, sino quién autoriza sus consecuencias. Este escenario ilustra el reto que aguarda a las organizaciones de aquí a septiembre de 2026.
Este análisis se basa en avances documentados hasta 2024; los desarrollos previstos para septiembre de 2026 son de carácter prospectivo. Una distinción esencial en un sector donde las demostraciones espectaculares suelen preceder a las pruebas de fiabilidad.
Del asesoramiento a la ejecución: el verdadero cambio
Un chatbot clásico produce texto. Un agente combina un modelo con herramientas: un motor de búsqueda, mensajería, una base de datos de clientes, un terminal informático o una interfaz de pago. Puede descomponer una solicitud, seleccionar una operación, examinar su resultado y continuar. El grado de autonomía sigue siendo variable: algunos procesos están muy delimitados, mientras que otros dejan al modelo un mayor margen de actuación.
Esta trayectoria ya era visible en 2023 con las funciones que permitían a los modelos invocar herramientas, los experimentos con AutoGPT y los asistentes conectados a las aplicaciones empresariales. En 2024, las demostraciones de agentes de programación ampliaron esa promesa: pasar de «así se hace» a «yo me encargo». Pero una demostración exitosa no garantiza ni la robustez en producción ni el control de las excepciones.
El beneficio potencial es concreto. Un departamento de compras podría automatizar la recopilación de presupuestos y preparar un pedido. Un servicio de soporte informático podría diagnosticar una avería y después restablecer un acceso. Sin embargo, el riesgo cambia de naturaleza: una mala sugerencia se puede debatir; una eliminación de archivos, una divulgación de información o una transferencia pueden surtir efecto antes de cualquier revisión.
Una responsabilidad distribuida, no diluida
Decir que «la IA decidió» no resuelve nada. Un agente no es, por el mero hecho de su autonomía técnica, un sujeto jurídico al que transferir la culpa. Según el país, el contrato y el daño, pueden concurrir varias responsabilidades: la de la empresa usuaria, la del proveedor de un componente, la del integrador o la de un prestador de servicios encargado de la operación.
Un caso canadiense ya lanzó una advertencia en 2024. En el asunto Moffatt contra Air Canada, el tribunal civil de Columbia Británica consideró responsable a la aerolínea por la información errónea que su chatbot había facilitado sobre una tarifa por duelo. No se trataba de un agente que ejecutara una operación autónoma. No obstante, el caso recuerda que una empresa no puede simplemente presentar su interfaz automatizada como ajena a sus obligaciones con sus clientes.
Con un agente, la investigación se vuelve más compleja. ¿Interpretó mal el modelo una instrucción? ¿Le otorgaba la integración demasiadas facultades? ¿Faltaba una regla de negocio? ¿Disponía el empleado de información suficiente para dar su aprobación? Hay que distinguir entre la causa técnica, la responsabilidad jurídica y la responsabilidad operativa. No necesariamente corresponden al mismo actor.
Los permisos se convierten en la primera salvaguarda
El error sería asignar a un agente los permisos del empleado al que asiste. Un trabajador puede consultar legítimamente expedientes sensibles, autorizar gastos y enviar correos electrónicos. Su asistente no necesita acumular todas esas capacidades para clasificar facturas. El principio de mínimo privilegio, de larga tradición en ciberseguridad, se convierte aquí en una condición elemental para el despliegue.
En concreto, cada agente debería disponer de una identidad técnica diferenciada y de permisos limitados y, cuando sea posible, temporales. Leer no implica modificar; preparar no implica enviar; crear un beneficiario no implica poder pagarle. Los límites financieros, los destinatarios autorizados y las prohibiciones deben estar controlados por el sistema de ejecución, y no solo solicitarse mediante una instrucción al modelo.
- Acciones reversibles: automatización posible dentro de un ámbito definido, con control posterior a la ejecución.
- Acciones sensibles: aprobación explícita antes de un envío, una publicación o una modificación importante.
- Acciones críticas: separación de funciones, doble validación o exclusión de la autonomía.
Otra amenaza es la inyección de instrucciones maliciosas en un documento o una página consultada. Un agente encargado de resumir un correo electrónico podría encontrar en él una instrucción que le pidiera exportar archivos. Ese contenido externo debe seguir siendo un dato, no convertirse en una autoridad. Las restricciones de acceso y el filtrado de las salidas deben limitar los daños incluso si el modelo se deja engañar.
Supervisar no significa hacer clic en «aprobar»
La supervisión humana parece una respuesta evidente. Sin embargo, puede convertirse en una ficción organizativa. Si un empleado recibe decenas de solicitudes incomprensibles y urgentes, corre el riesgo de validarlo todo. La intervención humana sigue existiendo entonces sobre el papel, pero ya no ejerce un control real.
Una validación útil presenta la acción prevista, sus consecuencias, los elementos que la justifican y las incertidumbres pertinentes. En el caso de un reembolso, esto significa mostrar el importe, el beneficiario, la regla aplicable y las posibles anomalías. El supervisor debe poder rechazar, corregir e interrumpir el proceso, sin ser penalizado por haber ralentizado la ejecución.
Por tanto, la pregunta adecuada no es «¿contamos con una validación humana?», sino «¿puede una persona competente impedir realmente el daño?». Esto requiere tiempo, formación y capacidad de decisión. De cara a septiembre de 2026, cabe prever que esa capacidad real de control se convertirá en un criterio de elección más importante que el número de tareas prometidas.
Garantizar la trazabilidad de los actos sin registrarlo todo
Tras un incidente, no basta con una conversación guardada. Hay que reconstruir qué herramientas se invocaron, qué parámetros se transmitieron, qué permisos estaban disponibles, qué respuestas se recibieron y qué validaciones se obtuvieron. También importan la versión del modelo, la configuración del agente y las reglas aplicables: un mismo objetivo puede dar lugar a procesos distintos después de una actualización.
Esta trazabilidad no requiere exponer un supuesto razonamiento interno exhaustivo del modelo. Exige, sobre todo, pruebas observables de sus actos. Los registros deben estar protegidos contra alteraciones, ser accesibles para las personas autorizadas y estar sujetos a plazos de conservación proporcionados. Registrarlo todo sin criterio crearía otro riesgo: acumular datos personales, secretos comerciales o credenciales.
La ley establece el marco; la organización debe adaptarse
Adoptado en 2024, el reglamento europeo de IA prevé una aplicación gradual, con una fecha general fijada en el 2 de agosto de 2026 en su calendario inicial y algunas excepciones. No clasifica automáticamente a todos los agentes como sistemas de alto riesgo: el uso y las condiciones previstas en el texto son determinantes. El RGPD, el derecho contractual y las normas sectoriales también siguen siendo pertinentes. Ninguna etiqueta de «agente» elimina estas obligaciones.
¿Y ahora qué? El escenario creíble no es el de una empresa abandonada a programas informáticos soberanos, sino el de una autonomía gradual, probada y revocable. Antes de ampliar el despliegue de un agente, los directivos deberían poder responder a tres preguntas: ¿qué compromisos puede asumir, quién puede detenerlo y qué pruebas quedarán mañana? La confianza dependerá menos de su soltura para conversar que de la solidez de los límites que lo rodean.
