El problema del mazo
Muchos flujos de trabajo con IA actuales parecen el equivalente a usar un mazo para romper una nuez.
La tarea es suficientemente sencilla: leer una hoja de cálculo, comprobar registros nuevos, enriquecer algunos campos, clasificar una solicitud, crear un informe, actualizar un CRM, enviar una notificación o preparar una respuesta para revisión.
Pero, en lugar de diseñar el proceso, los equipos entregan todo el trabajo a un agente y le piden que opere el ordenador como una persona. El agente abre aplicaciones, hace clic por las pantallas, lee filas, decide el siguiente paso, repite las mismas instrucciones y gasta tokens redescubriendo un flujo de trabajo que ya se conocía.
También existe un coste de disponibilidad. Las herramientas de IA más capaces suelen utilizarse en sesiones limitadas, con límites prácticos de uso, límites de velocidad o colas. Si un equipo consume esa capacidad en tareas repetitivas que el software podría ejecutar de forma determinista, no solo está desperdiciando tokens. También está consumiendo tiempo escaso de modelos de alto valor. Después, cuando aparece una tarea realmente difícil, el equipo puede tener que volver a esperar capacidad.
Esto puede ser útil cuando el entorno es desconocido o la tarea es verdaderamente exploratoria. Pero no siempre es la mejor arquitectura para un proceso empresarial repetible.
La mayoría de los flujos de trabajo de producción no son problemas de agentes. Son problemas de automatización con llamadas ocasionales a la IA.
Un flujo de trabajo suele estar más estructurado de lo que parece
Cuando se observan de cerca, muchos flujos de trabajo con IA siguen una estructura predecible.
Comienzan con un desencadenador. A veces está programado: cada mañana, cada viernes, al final de mes o después de cerrar un periodo de informes. Otras veces se basa en eventos: llega un correo electrónico, un cliente envía un formulario, cambia un registro en una base de datos, se crea un ticket o aparece un archivo nuevo en una carpeta.
Después, el flujo de trabajo obtiene los datos de entrada. Pueden proceder de una API, un CRM, un ERP, una hoja de cálculo, un documento, una aplicación web, una base de datos existente o una combinación de sistemas.
A continuación, itera sobre los datos de entrada. Valida registros, filtra casos, normaliza campos, aplica reglas, comprueba estados, crea ramificaciones según las condiciones y prepara resultados.
Solo algunos pasos necesitan realmente IA.
La IA puede ser necesaria para extraer significado de texto no estructurado, clasificar una solicitud, resumir evidencias, redactar una respuesta, comparar documentos, decidir qué ruta de excepción corresponde o generar una recomendación. Pero muchos de los pasos que los rodean son deterministas. Deben resolverse con código, no mediante razonamiento repetido.
Por último, el flujo de trabajo almacena o entrega el resultado. Actualiza una base de datos, escribe en un CRM, crea un documento, envía un correo electrónico, abre una tarea, publica en Slack o muestra un panel.
Eso no es una persona haciendo clic por una pantalla. Es un proceso.
Los tokens en tiempo de ejecución deben invertirse en inteligencia
El error costoso consiste en utilizar llamadas a modelos para una orquestación que el software puede gestionar directamente.
Si en cada ejecución se pide a un agente que lea las mismas instrucciones, navegue por las mismas pantallas, inspeccione las mismas columnas y decida el mismo siguiente paso obvio, la empresa está pagando por coordinación repetida, no por inteligencia.
El patrón más eficaz es sencillo:
- utiliza código determinista para desencadenadores, bucles, validación, enrutamiento, reintentos y almacenamiento
- utiliza API y conectores cuando los sistemas ya ofrecen interfaces fiables
- llama a la IA solo para las partes que se benefician de la comprensión del lenguaje, la generación, el razonamiento o el criterio
- elige el modelo adecuado para cada paso en lugar de enviar cada tarea al modelo más potente
- mantén visibles las trazas, el coste, la latencia, las entradas, las salidas y los fallos
De ahí proviene el ahorro de tokens. No solo de utilizar modelos más baratos, sino de eliminar por completo las llamadas innecesarias a modelos.
En las implementaciones de Guanta, esta arquitectura puede reducir drásticamente el uso de tokens porque ya no se pide al modelo que ejecute todo el proceso. La empresa paga por la inteligencia que necesita, cuando la necesita y con el modelo adecuado para cada tarea.
Con el tiempo, algunas partes pueden dejar de necesitar llamadas a modelos externos. Los modelos más pequeños, los clasificadores especializados, la inferencia local, las decisiones almacenadas en caché, los embeddings y el código convencional pueden encargarse de una mayor parte del flujo de trabajo. La plataforma debe permitir estas decisiones sin tener que rediseñar el proceso cada vez.
La IA también pertenece al momento de creación
Esto no significa utilizar menos IA en general.
Significa utilizarla en el lugar adecuado.
La IA puede ser extremadamente útil al crear el flujo de trabajo. Puede ayudar a traducir requisitos a código, generar conectores, escribir transformaciones de datos, preparar lógica de validación, crear pequeñas herramientas internas, producir pruebas, explicar API heredadas y acelerar el trabajo de convertir un proceso operativo desordenado en software.
Pero, una vez que el flujo de trabajo está definido, la empresa no debería seguir pagando a un modelo para que genere la misma lógica una y otra vez en tiempo de ejecución.
Utiliza la IA intensivamente durante las fases de diseño y desarrollo. Después, implementa el flujo de trabajo en una plataforma que lo ejecute de forma fiable. En tiempo de ejecución, llama a la IA solo cuando los datos en vivo requieran realmente inteligencia.
Esta distinción es importante.
Los agentes son buenos para averiguar qué hacer cuando el problema es ambiguo. Las plataformas son buenas para ejecutar de forma fiable, repetida, segura y observable un trabajo conocido.
La arquitectura más sólida utiliza ambos elementos. La IA ayuda a crear el flujo de trabajo. La plataforma ejecuta el flujo de trabajo. La IA se invoca dentro del flujo únicamente en los puntos donde aporta un valor real.
Por qué importa una plataforma
El trabajo repetible con IA necesita algo más que prompts.
Necesita conectores con los sistemas empresariales. Necesita ejecución programada y basada en eventos. Necesita estado, permisos, reintentos, colas, registros, secretos, pasos de aprobación humana, control de versiones y controles de implementación.
También necesita observabilidad.
Cuando se ejecuta un flujo de trabajo, el equipo debe poder ver qué ha ocurrido:
- qué desencadenó la ejecución
- qué registros de entrada se procesaron
- a qué sistemas se accedió
- qué modelo se utilizó en cada paso de IA
- cuántos tokens se consumieron
- cuánto tardó cada paso
- qué registros fallaron y por qué
- qué resultados se escribieron
- qué casos requieren revisión humana
Sin esta capa, la automatización con IA se vuelve difícil de operar. Un usuario puede ver una respuesta, pero la organización no puede comprender el coste, la calidad, los modos de fallo ni el estado del proceso.
Por eso, la verdadera necesidad es una plataforma: un lugar donde conectar aplicaciones, ejecutar procesos, llamar a la IA de forma selectiva, entregar resultados donde se necesitan y observar todo el sistema en todo momento.
El papel de los ingenieros desplegados cerca del cliente
La IA puede ayudar a generar el código del flujo de trabajo, pero alguien aún debe comprender el proceso real.
Ese es el papel del ingeniero desplegado cerca del cliente.
Un FDE trabaja cerca del cliente y traduce la realidad operativa en un diseño de flujo de trabajo ejecutable. Identifica el desencadenador, los sistemas de origen, los campos relevantes, las excepciones, los puntos de aprobación, las restricciones de seguridad y el resultado empresarial.
Decide qué debe resolverse con código determinista, dónde es realmente útil la IA, qué modelo es suficiente, qué nunca debe enviarse a un modelo y qué debe registrarse para auditoría y mejora.
La IA puede escribir el primer borrador. Los FDE lo convierten en una solución preparada para producción.
Esto es importante porque los flujos de trabajo reales están llenos de contexto que no resulta evidente en un ticket. Algunas acciones de un ERP son irreversibles. Algunos campos son sensibles. Algunas excepciones tienen implicaciones políticas. Algunos fallos son aceptables y otros interrumpen las operaciones. Algunas decisiones pueden automatizarse, mientras que otras necesitan una persona dentro del proceso.
La plataforma proporciona a los FDE una mayor capacidad de acción. En lugar de comenzar cada implementación desde un repositorio vacío, pueden utilizar conectores reutilizables, componentes básicos de flujos de trabajo, observabilidad, controles de seguridad y desarrollo asistido por IA. El FDE traduce el proceso. La plataforma hace que la implementación sea repetible.
Esta combinación evita dos problemas: los agentes abiertos que consumen demasiado en tiempo de ejecución y los proyectos de consultoría personalizados que nunca se convierten en capacidades de producto reutilizables.
El modelo mental adecuado
El objetivo no es sustituir cada agente por un script rígido.
El objetivo es separar lo conocido de lo desconocido.
El trabajo conocido debe convertirse en software. El trabajo desconocido o intensivo en lenguaje puede utilizar IA. El trabajo repetido debe ejecutarse en una plataforma. El trabajo sensible debe contar con controles. El trabajo costoso debe medirse. Los fallos deben ser visibles. Las mejoras deben acumularse.
Para muchas empresas, esa es la capa que falta entre las demostraciones de IA y el valor en producción.
El futuro de la automatización con IA no será un único agente gigante haciendo clic durante todo el día en todas las aplicaciones. Serán procesos empresariales diseñados como flujos de trabajo, generados más rápidamente con IA, operados por una plataforma, monitorizados de principio a fin y respaldados por ingenieros que entienden tanto al cliente como el código.
Así es como las empresas dejan de utilizar un mazo para romper una nuez.
Y así es como pagan por la IA que realmente necesitan.