Spanish Articles
Cómo un flujo de trabajo estructurado puede poner freno a los agentes de IA descontrolados
Los agentes de IA avanzan a gran velocidad dentro del software empresarial, desde las finanzas hasta el ámbito jurídico. Mariia Bulycheva y Karl Schmedders piden cautela y recomiendan flujos de trabajo claramente definidos.
En los consejos de administración y en las hojas de ruta de producto, una pregunta domina cada vez más la conversación: “¿Podría un agente de IA encargarse de esto?”. Desde la atención al cliente hasta el cumplimiento normativo, y desde los recursos humanos hasta la fijación de precios, los modelos de lenguaje de gran tamaño, conocidos como LLM, y los llamados “agentes” se están integrando en prácticamente todos los procesos empresariales. El año pasado, Gartner predijo que, de aquí a 2028, un tercio de las aplicaciones de software empresarial incorporará IA agéntica y que al menos el 15% de las decisiones operativas del día a día se tomarán de forma autónoma.
El empuje inversor también se aprecia en los datos. Una encuesta tecnológica de EY publicada en mayo de 2025 señalaba que el 92% de los líderes tecnológicos esperaba aumentar su gasto en IA durante los siguientes 12 meses y, entre quienes preveían elevar sus presupuestos, el 43% afirmaba que más de la mitad del gasto actual en IA ya se destinaba a tecnologías agénticas. Sin embargo, ese optimismo convive con la cautela. Un informe de Gartner de junio de 2025 estimaba que más del 40% de los proyectos de IA agéntica serán cancelados antes de 2027 debido al aumento de los costes y a la incertidumbre sobre su impacto real en el negocio.
La realidad detrás de estas cifras es más matizada de lo que sugiere el entusiasmo. Los sistemas agénticos pueden generar beneficios reales, especialmente en casos de uso muy acotados. Pero muchas organizaciones descubren que lo que resulta fácil de prototipar es mucho más difícil de escalar, gobernar y mantener en producción. El reto no es solo si un agente puede completar una tarea, sino si el sistema que lo rodea sigue siendo fiable, transparente y sostenible. En muchas compañías, los mejores resultados provienen de flujos de trabajo cuidadosamente diseñados, en los que los LLM son un componente más entre varios, y no de entregar procesos enteros a agentes autónomos.
Aquí defendemos un enfoque realista: primero los flujos de trabajo, después los agentes. Para los directores financieros, especialmente en sectores sensibles a los datos como la banca de inversión o los servicios jurídicos, este cambio puede mejorar de forma sustancial el control de costes, la transparencia y la protección de los datos.
Si un flujo de trabajo convencional es una receta, un agente es un chef improvisando en la cocina. Y esa flexibilidad complica la rendición de cuentas.
Si un flujo de trabajo convencional es como una receta, un agente es como un chef improvisando en la cocina. Esa flexibilidad dificulta la rendición de cuentas.
Por qué los agentes están en todas partes
El entusiasmo por la IA agéntica es comprensible. Cuando funciona, un agente de IA se parece a un junior incansable: se le plantea un objetivo —“resume esta cartera de operaciones y prepara unas ideas clave para la reunión de mañana con el cliente”— y el sistema descompone la tarea en pasos, llama a herramientas e interfaces de programación, redacta contenido y lo refina a partir del feedback recibido.
Los proveedores prometen automatización de extremo a extremo: agentes comerciales que orquestan sistemas de gestión de clientes, correo electrónico, precios y contratos; agentes financieros que concilian cuentas, clasifican y procesan facturas y detectan desviaciones respecto al presupuesto; y agentes jurídicos que leen miles de páginas de documentación e identifican riesgos.
Para directores financieros y directores jurídicos, esto suena a un salto de productividad. También encaja con una narrativa más amplia: la IA como copiloto que va asumiendo decisiones cada vez más complejas dentro de la empresa. Pero, bajo la superficie, están emergiendo tres problemas estructurales.
1 – Rutas de decisión opacas
Los sistemas agénticos encadenan decenas de llamadas al modelo e interacciones con herramientas, a menudo de formas difíciles de reconstruir. Si un flujo de trabajo convencional es una receta, un agente es un chef improvisando en la cocina. Esa flexibilidad resulta atractiva, pero hace más difícil exigir responsabilidades: ¿por qué el sistema recuperó unos documentos y no otros? ¿Qué respuesta intermedia hizo que la recomendación final fuera errónea? ¿Cómo se audita el recorrido cuando algo sale mal ante un cliente o un regulador?
No se trata de preocupaciones meramente teóricas. En 2025, una empresa de tecnología sanitaria reveló una brecha que afectó a más de 483.000 pacientes después de que un agente de IA semiautónomo enviara datos confidenciales a flujos de trabajo inseguros. McKinsey señala además que el 80% de las organizaciones afirma haberse encontrado con comportamientos de riesgo por parte de agentes de IA, incluida la exposición indebida de datos y el acceso no autorizado a sistemas. La misma firma ilustra el problema con un ejemplo concreto: un agente que procesa datos crediticios clasifica deuda a corto plazo como si fuera ingreso, y ese error termina contaminando la puntuación de riesgo y las decisiones posteriores de concesión de crédito.
A esto se suman las alucinaciones de los LLM. Como ha argumentado José Parra Moyano, la alucinación no es un “error” eliminable, sino una propiedad estructural de estos modelos. Las empresas deben asumir que siempre estará presente y diseñar su gobernanza en consecuencia. En cadenas agénticas largas, incluso una pequeña alucinación al inicio del proceso puede propagarse y amplificarse, lo que dificulta todavía más explicar a posteriori qué ha ocurrido.
En secuencias largas de decisiones agénticas, una pequeña alucinación inicial puede propagarse y amplificarse.
2 – Espirales de coste
Los marcos de agentes suelen fomentar la exploración iterativa: el agente prueba una herramienta, evalúa el resultado, llama a otra, vuelve a la primera, y así sucesivamente. Cada paso implica una nueva llamada de pago a una interfaz de programación y más cómputo en segundo plano, lo que genera costes adicionales.
A un desarrollador esto puede parecerle elegante. Para un director financiero, puede resultar alarmante. Una sola solicitud de usuario puede activar cientos de llamadas costosas al modelo y, multiplicado por miles de usuarios, la curva de costes deja rápidamente de ser lineal. Muchas organizaciones no lo descubren hasta que reciben las primeras facturas de IA y comprueban que son mucho más elevadas de lo esperado.
El informe State of the Cloud 2025 de Flexera muestra que el 84% de las organizaciones considera que la gestión del gasto en la nube y de sus fluctuaciones inesperadas es su principal desafío tecnológico. Y el problema se agrava a medida que las cargas de trabajo de IA multiplican las llamadas de pago a modelos. Investigaciones de Andreessen Horowitz, entre otros, muestran que la infraestructura de IA y las llamadas a interfaces de programación de modelos son sustancialmente más caras que las cargas de trabajo SaaS tradicionales, lo que refuerza la idea de que un uso sin restricciones puede disparar los presupuestos.
3 – Privacidad de datos y gobernanza
Los agentes plenamente autónomos suelen requerir un acceso amplio: deben atravesar múltiples fronteras de permisos dentro del entorno empresarial. En la práctica, esto puede significar acceso no solo a sistemas internos y fuentes de datos, sino también a interfaces de programación externas y capas de ejecución que la empresa no controla de forma directa.
Para sectores como la banca, los seguros o los servicios jurídicos, donde la confidencialidad del cliente y las exigencias regulatorias son esenciales, esto supone un reto serio. No es casualidad que bancos y despachos de abogados estén explorando despliegues privados y en infraestructura propia de LLM para mantener los datos sensibles dentro de su propio perímetro.
El objetivo no es sustituir los flujos de trabajo por agentes, sino permitir que agentes y LLM operen dentro de procesos bien definidos.
En largas cadenas de agentes, incluso una pequeña alucinación al principio del proceso puede propagarse
y amplificarse.
Pensar en flujos, no en magos
¿Cómo aprovechar el poder de los LLM sin perder el control sobre costes, transparencia o datos? El verdadero desafío de diseño no es si los agentes pueden hacer más, sino cómo darles suficiente autonomía para que sean útiles sin renunciar al control. Y eso empieza por tener clara la diferencia entre un agente y un flujo de trabajo.
Un agente de IA es un sistema que recibe un objetivo de alto nivel —“prepara un briefing para un cliente”— y decide por sí mismo qué herramientas usar, en qué orden y cuándo detenerse. Un flujo de trabajo, en cambio, es una secuencia predefinida de pasos diseñada de antemano por personas: qué sistemas se consultan, qué entradas y salidas se esperan y en qué puntos hacen falta aprobaciones. Los agentes optimizan la flexibilidad; los flujos de trabajo optimizan la claridad, el control y la repetibilidad.
El objetivo no debería ser reemplazar los flujos por agentes, sino permitir que agentes y LLM operen dentro de procesos bien definidos. Eso empieza diseñando el proceso como si la IA no existiera y solo después insertando llamadas al LLM allí donde la comprensión del lenguaje aporte valor real.
Eso obliga a distinguir entre dos capas:
La capa de flujo de trabajo
Una secuencia de pasos explícitos, diseñada por humanos: recuperar y transformar datos, aplicar reglas y solicitar aprobaciones. Se implementa con bloques ya conocidos —microservicios, procesos ETL, motores de workflow u orquestadores como Airflow o Temporal— y se gobierna con los controles, registros y permisos ya existentes.
La capa de inteligencia
Los LLM y otros modelos se utilizan dentro de pasos concretos: para clasificar, resumir, extraer campos o proponer opciones. Cada llamada al modelo tiene un propósito claro, una entrada acotada y un formato de salida esperado. También se definen mecanismos de respaldo: qué ocurre si el modelo duda, es inconsistente o falla.
En lugar de pedir a un agente que “se encargue de la revisión del contrato”, conviene definir un flujo estructurado —un orden de acciones con un formato o esquema de entrada y salida predefinido— y dejar que el modelo gestione solo las partes genuinamente ambiguas.
El objetivo no es sustituir los flujos de trabajo por agentes, sino permitir que los agentes y los sistemas de gestión del lenguaje natural (LLM) operen dentro de flujos bien definidos.
Del “agente mágico” al flujo estructurado
¿Cómo funciona esto en la práctica? Pensemos en un despacho que quiere acelerar la revisión de contratos. El enfoque plenamente agéntico podría formularse así: “Lee este contrato, identifica riesgos, compáralo con nuestras plantillas estándar y redacta una recomendación”. A partir de ahí, el agente improvisa: decide qué secciones leer, cuándo buscar precedentes internos y cómo redactar la nota final. Puede ofrecer demos impresionantes hasta que una alucinación o una cláusula omitida genera un riesgo inaceptable para un cliente importante.
Un enfoque centrado en flujos, en cambio, haría lo siguiente:
Ingesta y clasificación. Una lógica determinista identifica el tipo de contrato, las partes, la jurisdicción y la ley aplicable.
Extracción de cláusulas clave. Una serie de llamadas dirigidas al LLM extrae elementos concretos —terminación, límites de responsabilidad, confidencialidad, etc.— en un esquema estructurado.
Comparación con la política interna. Reglas basadas en lógica y, cuando hace falta, otra llamada al modelo señala desviaciones respecto al playbook del despacho.
Generación de un borrador de resumen. El modelo elabora un resumen conciso y estructurado para el abogado, apoyándose en el esquema extraído.
Revisión y aprobación humana. Un asociado senior o un socio revisa, edita y aprueba antes de que nada llegue al cliente.
El número de llamadas al modelo se reduce y se vuelve predecible, cada llamada está acotada y los flujos de datos quedan controlados. Y, sobre todo, el despacho puede explicar a clientes y reguladores exactamente cómo se ha producido una recomendación, por ejemplo, durante una auditoría.
Qué aspecto tiene esto en servicios financieros
Un patrón similar está surgiendo en instituciones financieras que experimentan con flujos basados en grafos de conocimiento, especialmente en actividades intensivas en información, guiadas por relaciones y que exigen sintetizar múltiples fuentes internas y externas. En banca corporativa y de inversión, esto puede apoyar tareas prácticas como preparar una reunión con un cliente, identificar operaciones comparables, resumir la exposición a un sector o localizar al experto interno adecuado para una oportunidad activa.
En lugar de desplegar un agente bancario libre, con acceso indiscriminado a todo, estas instituciones suelen optar por un enfoque más estructurado: construir un grafo de conocimiento de entidades —clientes, operaciones, productos, regiones y expertos internos—; definir un pequeño conjunto de flujos canónicos, como “preparar briefing de cliente”, “resumir exposición al sector X” o “identificar operaciones similares del pasado”; y utilizar LLM en puntos concretos, por ejemplo para traducir una pregunta en lenguaje natural a consultas sobre el grafo, resumir la información recuperada o redactar una primera versión de una nota.
Tomemos el caso de “preparar un briefing de cliente”. Antes de una reunión importante, un gestor de relación con el cliente puede necesitar reunir historial de operaciones, exposición actual, novedades del cliente, contexto de mercado y conocimiento interno relevante. Hoy, eso suele implicar buscar en múltiples sistemas y documentos y ensamblar manualmente la información. En un entorno basado en flujos, el recorrido de recuperación está predefinido, mientras que el LLM se utiliza solo allí donde la comprensión del lenguaje y la síntesis aportan valor real.
La misma lógica se aplica a “identificar operaciones similares del pasado”. En originación y estructuración, las transacciones comparables suelen ser el punto de partida para fijar precio, posicionamiento y documentación. Tampoco aquí hace falta un agente plenamente autónomo improvisando a través de toda la infraestructura del banco. Lo que se necesita es un flujo controlado que recupere la información correcta y utilice el modelo para resumirla y presentarla con claridad.
La orquestación —qué sistemas se consultan, en qué orden y con qué permisos de acceso— sigue siendo determinista y auditable. La inteligencia se incorpora allí donde la ambigüedad es alta y el razonamiento a nivel de lenguaje resulta útil.
Para la dirección, los beneficios son tangibles:
Control de costes: estimaciones realistas del uso del modelo por ejecución del flujo.
Transparencia: trazabilidad clara de qué fuentes de datos y qué lógica han conducido a una recomendación.
Protección de datos: límites estrictos sobre qué información se envía, si es que se envía, a una interfaz de programación externa.
El giro hacia la IA privada y local
La pieza final del rompecabezas es dónde se ejecutan estos modelos. En sectores con elevadas exigencias de privacidad —banca, derecho, salud y administración pública— estamos viendo una aceleración hacia los LLM privados: modelos que corren en servidores propios o en nubes privadas virtuales estrictamente controladas, en lugar de enviar instrucciones sensibles a interfaces públicas.
El hardware moderno ha cambiado la economía de esta decisión. Para muchas organizaciones medianas, ya es viable operar uno o dos servidores GPU internos y desplegar un modelo de código abierto —por ejemplo, de la familia Llama o Mistral—; ajustarlo con documentos, plantillas y taxonomías propios; reentrenarlo con regularidad a medida que llega nueva información; y mantener todas las instrucciones, salidas y registros dentro de su propia infraestructura.
Combinado con el enfoque centrado en flujos descrito antes, esto da lugar a una arquitectura convincente:
Flujos de trabajo: explícitos, auditables e integrados con los sistemas existentes.
Modelos: potentes, pero limitados a funciones específicas dentro de esos flujos.
Despliegue: bajo control directo de la empresa y alineado con su marco de riesgo y cumplimiento.
No se trata de rechazar por completo a los agentes. En algunos contextos —especialmente tareas estrechas, bien acotadas y con herramientas y salvaguardas claras— los patrones agénticos pueden ser muy eficaces. Pensemos en un agente de atención al cliente de una aerolínea: puede estar autorizado a recolocar a un pasajero afectado por un retraso, procesar un reembolso o redirigir equipaje perdido, pero solo dentro de un conjunto muy definido de reglas y sistemas. Ahí es precisamente donde el diseño agéntico funciona mejor: no como autonomía abierta, sino como autonomía dentro de límites. La dirección en la que avanzan muchas organizaciones sofisticadas parece clara: menos “magos de IA” y más flujos cuidadosamente diseñados, en los que la autonomía se concede de forma selectiva y siempre bajo supervisión.
Para finales de esta década, muchos más programas informáticos incorporarán algún grado de autonomía orientada a objetivos.
De la ambición a la ejecución
Los LLM y la IA agéntica seguirán transformando la empresa. Las previsiones de los analistas y las hojas de ruta de los proveedores no están equivocadas: de aquí a finales de esta década, mucho más software incorporará algún grado de autonomía orientada a objetivos. La pregunta estratégica para los líderes es cómo se introduce esa autonomía.
Resulta tentador tratar a los agentes como solucionadores mágicos de problemas de extremo a extremo, pero ese enfoque añade riesgos innecesarios. Diseñar primero los flujos de trabajo y utilizar LLM y agentes como componentes cuidadosamente acotados dentro de esos flujos es menos vistoso, pero mucho más sólido.
Para directores financieros, responsables de riesgo y directores jurídicos, este enfoque ofrece una vía pragmática. Los costes pueden preverse y gestionarse, los procesos pueden explicarse ante consejos, auditores y reguladores, y los datos permanecen donde deben estar.
Las empresas que triunfen con la IA no serán las que desplieguen más agentes, sino las que diseñen flujos claros y sepan decidir dónde debe residir la inteligencia.
Sobre los autores
