¿Hasta dónde dejamos actuar a un agente de IA?

Estimated reading time: 9 minutos

Hay bastante diferencia entre permitir que un agente de IA busque un expediente y dejarle cerrarlo. Entre esas dos cosas, además, cabe casi todo el trabajo administrativo que podamos imaginar.

El tema de los agentes de IA hoy en día sonaría a ciencia ficción hasta hace muy poco tiempo. Pueden consultar el CRM para localizar a un cliente, revisar qué solicitudes tiene abiertas, buscar documentación relacionada y reunir los antecedentes de un caso. También pueden dejar preparado el alta de un expediente, proponer una clasificación o redactar una respuesta. Y, si tiene los permisos necesarios, podrían ir todavía más lejos y realizar directamente esas operaciones en los sistemas.

Y esto, para la gestión del back office resulta ciertamente sorprendente. Si les damos acceso a herramientas y aplicaciones ya no se limitan a responder. Pueden hacer cosas.

Decidir cuáles de esas cosas vamos a permitirles hacer es una parte fundamental del proceso.

Antes de dar permisos hay que saber qué trabajo queremos delegar

Lo primero que debemos decir es que existen procesos administrativos no hacen que se deleguen en un agente. No nos dejemos encandilar por cantos de sirenas.

Si conocemos perfectamente todas las reglas y el recorrido apenas cambia, un workflow tradicional sigue siendo la solución más sencilla y previsible. El sistema recibe una entrada, comprueba determinadas condiciones y va ejecutando los pasos que ya hemos definido.

Los agentes pueden brillar con situaciones algo más complejas ya que pueden encontrarse una situación, consultar diferentes fuentes, utilizar una herramienta, comprobar el resultado y decidir qué necesita hacer después.

Anthropic utiliza precisamente esta diferencia para separar los workflows de los agentes. En los primeros, el recorrido está definido mediante código; en los segundos, el modelo dirige de forma más dinámica el proceso y las herramientas que utiliza.

También ellos recomiendan empezar por las soluciones más sencillas y solo añadir autonomía cuando realmente hace falta. Y en un entorno administrativo es sensato.

Si diez mil operaciones al mes recorren exactamente el mismo camino, quizá no necesitemos que un agente decida qué hacer diez mil veces. En cambio, cuando las solicitudes llegan de formas diferentes, hay información repartida por varios sistemas o aparecen situaciones que no siempre encajan en una regla cerrada, la capacidad de adaptarse empieza a tener más valor.

Una misma solicitud puede dejarle hacer cosas muy diferentes

En el ejemplo de una solicitud que ha llegado por correo con varios documentos adjuntos, podemos dejar al agente que lea la información, busque al remitente en el CRM, compruebe si ya existe un expediente y localice otros antecedentes relacionados. Cuando termine, tendremos localizado en un mismo sitio lo que antes hubiéramos tenido que buscar por distintas aplicaciones.

Eso si le dejamos solo consultar la información. Pero con los agentes podemos llegar más lejos y permitirles que preparen el trabajo. Por ejemplo, que proponga a qué departamento corresponde la solicitud, deje rellenos los datos para abrir el expediente y redacte el acuse de recibo. La persona que lleva el caso solo tendría que revisar y continuar.

Pero también podríamos ir más lejos y permitirle crear directamente el expediente, asignarlo, cambiar su estado y enviar esa comunicación.

Son tres maneras bastante distintas de utilizar el mismo agente sobre el mismo proceso.

La separación entre consultar, preparar y ejecutar no pretende ser una clasificación técnica universal. Es una forma bastante práctica de decidir qué estamos delegando realmente.

Porque en una conversación sobre “automatizar la gestión de solicitudes” es fácil meter todas esas acciones dentro del mismo saco, cuando el riesgo no tiene mucho que ver.

Una clasificación incorrecta que todavía está pendiente de aprobación se corrige con facilidad. Un correo incorrecto que ya ha salido de la organización plantea otro problema. Y modificar un dato maestro o iniciar una operación económica tiene consecuencias todavía diferentes.

El acceso a una aplicación no debería abrir todas sus puertas

Vamos con asuntos más peliagudos que muchas veces delegamos en el equipo de TI cuando, en realidad, afecta directamente al diseño del proceso.

En procesos en los que interfieren herramientas como el ERP o el CRM. Puede tener sentido que el agente vea determinados datos de un proveedor o que pueda leer una ficha. Pero en todos estos casos hay que distinguir fielmente lo que hace. Por que no es lo mismo añadir una nota que cambiar un estado. Son operaciones diferentes y deberían poder autorizarse por separado.

OWASP recomienda aplicar precisamente este criterio a los agentes. Su guía específica de seguridad aconseja conceder únicamente las herramientas necesarias para cada tarea, separar los permisos de lectura y escritura y exigir controles adicionales cuando una actuación sea sensible, irreversible, financiera, administrativa o visible para terceros.

Parece una precaución bastante obvia, pero se vuelve importante cuando el agente trabaja en varios sistemas. Una cuenta técnica con permisos generales resulta cómoda durante una prueba. Pero al entrar en producción puede convertir un error relativamente pequeño en una actuación mucho más seria.

En 2026 NIST puso además en marcha una iniciativa específica sobre estándares para agentes de IA y está trabajando en cuestiones de identidad y autorización. Uno de los problemas que plantea es precisamente cómo saber qué agente está actuando, con qué autoridad y en nombre de quién cuando accede a datos y aplicaciones empresariales.

Si después tenemos que investigar una operación, interesa poder distinguirla de cualquier otra. Qué agente la realizó, qué herramienta utilizó, qué permisos tenía en ese momento y quién había autorizado esa capacidad.

Poner una persona en medio de todo

No es práctico dejar que el agente haga el trabajo, pero antes de cualquier acción pedimos que alguien pulse “aceptar”.

Para una fase inicial puede servir y ser útil, pero si lo mantenemos para absolutamente todo, corremos el riesgo de cambiar una tarea administrativa por otra.

Habrá operaciones que puedan ejecutarse directamente porque están muy acotadas, son fáciles de comprobar y, si algo falla, también son fáciles de corregir. Y habrá otras donde conservar una aprobación previa tenga todo el sentido.

Quizá el agente pueda abrir determinados expedientes y asignarlos automáticamente cuando se cumplen unas condiciones conocidas. Si falta documentación, encuentra información contradictoria o el caso no encaja en lo habitual, lo envía a una persona.

Con una modificación sensible podemos establecer otro criterio. El agente hace todo el trabajo previo y deja preparada la acción, pero no la ejecuta.

No parece muy razonable aplicar la misma supervisión a actualizar una etiqueta interna que a modificar una cuenta bancaria, aprobar un pago o enviar una comunicación con consecuencias jurídicas.

Ya hemos tratado en el blog de Normadat esta cuestión desde la perspectiva más general de qué tareas del back office conviene automatizar y cuáles mantener bajo supervisión. Con los agentes añadimos otra capa, porque ahora el sistema no solo ejecuta una secuencia que hemos programado previamente, sino que puede decidir qué herramienta utilizar para avanzar en la tarea.

Cuidado con lo que llega dentro de los documentos

Hay una peculiaridad del back office que merece atención. Gran parte de la información con la que trabaja el agente no la genera la propia organización. Llega por correo, mediante formularios, en documentos adjuntos o desde aplicaciones externas.

El agente necesita leer ese contenido para hacer su trabajo, pero no todo lo que encuentra dentro debería poder convertirse en una instrucción.

Aquí aparece la llamada prompt injection. Un archivo o un correo pueden contener texto preparado para intentar que el modelo ignore sus reglas, revele información o utilice alguna de las herramientas a las que tiene acceso.

Con un asistente que únicamente resume un documento el alcance puede ser limitado. Si ese mismo sistema puede consultar información privada, escribir en una base de datos y mandar correos, la situación cambia bastante.

OWASP incluye la manipulación de instrucciones, el exceso de autonomía y el abuso de herramientas entre los riesgos relevantes de los agentes. Por eso insiste en que los permisos y las autorizaciones sensibles se controlen fuera del propio razonamiento del modelo.

Esto no obliga a desconfiar de cada documento que entra en Administración. Obliga a diseñar bien la frontera entre la información que el agente debe leer y las órdenes que tiene permitido obedecer.

Lo que funciona sobre el papel hay que verlo después en el proceso

Tampoco hace falta decidir desde el principio que un agente podrá llegar hasta el final.

Podemos empezar viendo qué ocurre cuando consulta y prepara. Qué excepciones aparecen, en qué casos necesita ayuda, dónde se equivoca y cuánto trabajo ahorra realmente.

Después se pueden abrir algunas acciones.

Si la creación de un determinado tipo de expediente ha funcionado correctamente durante un periodo, quizá podamos automatizarla bajo unas condiciones concretas. Si otra tarea que parecía sencilla empieza a producir demasiadas excepciones, se mantiene la revisión.

Ese ajuste continuo importa más de lo que parece porque los procesos también cambian. Se incorpora un nuevo documento, se modifica una aplicación, aparece una excepción que nadie había previsto o cambia una regla interna.

Y para poder hacer esos ajustes necesitamos trazabilidad.

No bastará con saber que el expediente quedó creado. Interesa saber qué información utilizó el agente, qué herramientas consultó, qué operaciones hizo y dónde pidió intervención. Si algo salió mal, ese historial permite reconstruirlo; si todo salió bien, sirve para detectar qué partes del proceso pueden asumir algo más de autonomía.

Ahí es donde los agentes empiezan a encajar de verdad en el back office, bastante lejos de la idea de poner una IA a trabajar sola y esperar que resuelva el proceso.

En unos casos podrán llegar hasta la ejecución. En otros harán casi todo el trabajo y dejarán una decisión pendiente. También habrá tareas en las que un workflow convencional continúe siendo más práctico.

Lo importante es saberlo antes de dar acceso al ERP, al CRM, al gestor documental y al correo corporativo.

Incorporar agentes de IA al back office no obliga a construir internamente toda la infraestructura, las integraciones y la supervisión necesarias para operarlos. Normadat puede asumir la ejecución del proceso, utilizando automatización, IA y control humano allí donde haga falta.

Contacta con nosotros si quieres estudiar qué parte de tu back office puede externalizarse y automatizarse.

Preguntas Frecuentes