El problema del martillo demoledor
Hoy, muchos flujos de trabajo de IA parecen usar un martillo demoledor para partir una nuez.
La tarea es lo suficientemente simple: 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 en pantallas, lee filas, decide el siguiente paso, repite las mismas instrucciones y gasta tokens redescubriendo un flujo que ya se conocía.
También hay un coste de disponibilidad. Las herramientas de IA más capaces suelen usarse en sesiones acotadas, con límites prácticos de uso, límites de tasa o colas. Si un equipo consume esa capacidad en trabajo repetitivo que el software podría ejecutar de forma determinista, no solo está malgastando tokens. Está consumiendo tiempo de modelo valioso y escaso. Luego, cuando aparece una tarea realmente difícil, el equipo puede estar esperando capacidad otra vez.
Eso puede ser útil cuando el entorno es desconocido o la tarea es genuinamente exploratoria. No siempre es la mejor arquitectura para un proceso empresarial repetible.
La mayoría de los flujos de trabajo en producción no son problemas para agentes. Son problemas de automatización con llamadas ocasionales a IA.
Un flujo de trabajo suele ser más estructurado de lo que parece
Si miras de cerca, muchos flujos de trabajo de IA siguen una forma predecible.
Comienzan con un disparador. A veces el disparador está programado: cada mañana, cada viernes, a fin de mes o después de que cierre una ventana de informes. A veces es basado en eventos: llega un correo, un cliente envía un formulario, cambia un registro en una base de datos, se crea un ticket o un nuevo archivo aparece en una carpeta.
Después el flujo recibe datos de entrada. Pueden venir 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.
Luego itera sobre la entrada. Valida registros, filtra casos, normaliza campos, aplica reglas, comprueba estados, bifurca según condiciones y prepara salidas.
Solo algunos pasos necesitan realmente IA.
La IA puede ser necesaria para extraer sentido de texto no estructurado, clasificar una solicitud, resumir evidencias, redactar una respuesta, comparar documentos, decidir qué ruta de excepción aplicar o generar una recomendación. Pero muchos pasos circundantes son deterministas. Deberían ser código, no razonamiento repetido.
Finalmente, el flujo almacena o entrega el resultado. Actualiza una base de datos, escribe en un CRM, crea un documento, envía un correo, abre una tarea, publica en Slack o expone un panel.
Eso no es una persona haciendo clics en una pantalla. Eso es un proceso.
Los tokens en tiempo de ejecución deben gastarse en inteligencia
El error caro es usar llamadas al modelo para la orquestación que el software puede manejar directamente.
Si cada ejecución 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 mejor es simple:
- usar código determinista para disparadores, bucles, validaciones, enrutamiento, reintentos y almacenamiento
- usar APIs y conectores cuando los sistemas ya exponen interfaces fiables
- llamar a la IA solo para las partes que se benefician de comprensión, generación, razonamiento o juicio en lenguaje
- elegir el modelo adecuado para cada paso en lugar de enviar cada tarea al modelo más potente
- mantener trazas, coste, latencia, entradas, salidas y fallos visibles
Ahí es donde provienen los ahorros de tokens. No solo por modelos más baratos, sino por eliminar llamadas al modelo innecesarias por completo.
En 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, con el modelo que encaja con la tarea.
Con el tiempo, algunas partes pueden no necesitar llamadas a modelos externos en absoluto. Modelos más pequeños, clasificadores especializados, inferencia local, decisiones en caché, embeddings y código convencional pueden manejar más del flujo. La plataforma debería permitir esas elecciones sin rediseñar el proceso cada vez.
La IA también pertenece al tiempo de construcción
Esto no significa usar menos IA en general.
Significa usar la IA en el lugar correcto.
La IA puede ser extremadamente útil al construir el flujo de trabajo. Puede ayudar a traducir requisitos en código, generar conectores, escribir transformaciones de datos, redactar lógica de validación, crear pequeñas herramientas internas, producir pruebas, explicar APIs heredadas y acelerar el trabajo de convertir un proceso operativo desordenado en software.
Pero una vez que ese flujo está definido, la empresa no debería seguir pagando a un modelo por generar la misma lógica una y otra vez en tiempo de ejecución.
Use IA intensamente en diseño y construcción. Luego despliegue el flujo en una plataforma que lo ejecute de forma fiable. En tiempo de ejecución, invoque la IA solo donde los datos en vivo realmente requieran inteligencia.
Esa distinción importa.
Los agentes son buenos para averiguar qué hacer cuando el problema es ambiguo. Las plataformas son buenas para hacer trabajo conocido de forma fiable, repetida, segura y observable.
La arquitectura más sólida usa ambos. La IA ayuda a crear el flujo. La plataforma ejecuta el flujo. La IA se invoca dentro del flujo solo en los puntos donde genera una palanca real.
Por qué importa una plataforma
El trabajo repetible con IA necesita más que prompts.
Necesita conectores a sistemas empresariales. Necesita ejecución programada y basada en eventos. Necesita estado, permisos, reintentos, colas, registros, secretos, pasos de aprobación humana, versionado y controles de despliegue.
También necesita observabilidad.
Cuando un flujo se ejecuta, el equipo debería poder ver qué pasó:
- qué disparó la ejecución
- qué registros de entrada se procesaron
- qué sistemas se accedieron
- qué modelo se usó en cada paso de IA
- cuántos tokens se gastaron
- cuánto tiempo tomó cada paso
- qué registros fallaron y por qué
- qué salidas se escribieron
- qué casos necesitan 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 entender coste, calidad, modos de fallo o salud del proceso.
Por eso la necesidad real es una plataforma: un lugar para conectar aplicaciones, ejecutar procesos, llamar a la IA selectivamente, entregar resultados donde se necesitan y observar todo el sistema en todo momento.
Dónde encajan los ingenieros desplegados en campo (FDE)
La IA puede ayudar a generar el código del flujo, pero alguien todavía tiene que entender el proceso real.
Ese es el rol del ingeniero desplegado en campo.
Un FDE está cerca del cliente y traduce la realidad operativa en un diseño de flujo ejecutable. Identifica el disparador, los sistemas fuente, los campos relevantes, las excepciones, los puntos de aprobación, las restricciones de seguridad y el resultado de negocio.
Decide qué debe ser código determinista, dónde la IA es realmente útil, qué modelo es suficientemente bueno, qué nunca debería 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 producción.
Esto importa porque los flujos reales están llenos de contexto que no es obvio a partir de un ticket. Algunas acciones en un ERP son irreversibles. Algunos campos son sensibles. Algunas excepciones son políticas. Algunos fallos son aceptables y otros rompen las operaciones. Algunas decisiones pueden automatizarse, mientras que otras necesitan un humano en el bucle.
La plataforma da palanca a los FDE. En lugar de empezar cada despliegue desde un repositorio en blanco, pueden usar conectores reutilizables, primitivas de flujo, observabilidad, controles de seguridad y desarrollo asistido por IA. El FDE traduce el proceso. La plataforma hace que la implementación sea repetible.
Esa combinación evita dos trampas: agentes abiertos que gastan demasiado en tiempo de ejecución y proyectos de consultoría personalizados que nunca se convierten en capacidades de producto reutilizables.
El mejor modelo mental
El objetivo no es reemplazar 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 usar IA. El trabajo repetido debe ejecutarse en una plataforma. El trabajo sensible debe tener controles. El trabajo caro debe medirse. Los fallos deben ser visibles. Las mejoras deben acumularse.
Para muchas empresas, esa es la capa que falta entre las demos de IA y el valor en producción.
El futuro de la automatización con IA no será un agente gigante haciendo clic en cada aplicación todo el día. Serán procesos de negocio diseñados como flujos de trabajo, generados más rápido con IA, operados por una plataforma, monitorizados de extremo a extremo y respaldados por ingenieros que entienden tanto al cliente como al código.
Así es como las empresas dejan de usar un martillo demoledor para partir una nuez.
Y así es como pagan solo por la IA que realmente necesitan.