El problema del martell enorme
Actualment, molts fluxos de treball d’IA semblen com utilitzar un martell enorme per trencar una nou.
La tasca és prou senzilla: llegir un full de càlcul, comprovar registres nous, enriquir alguns camps, classificar una sol·licitud, crear un informe, actualitzar un CRM, enviar una notificació o preparar una resposta per revisar.
Però, en lloc de dissenyar el procés, els equips encomanen tota la feina a un agent i li demanen que operi l’ordinador com una persona. L’agent obre aplicacions, fa clic per les pantalles, llegeix files, decideix el pas següent, repeteix les mateixes instruccions i gasta tokens redescobrint un flux de treball que ja es coneixia.
També hi ha un cost de disponibilitat. Les eines d’IA més capaces sovint s’utilitzen en sessions limitades, amb límits d’ús pràctics, límits de velocitat o cues. Si un equip consumeix aquesta capacitat en tasques repetitives que el programari podria executar de manera determinista, no només malgasta tokens. També consumeix temps escàs i valuós dels models. Després, quan apareix una tasca realment difícil, és possible que l’equip hagi d’esperar de nou per obtenir capacitat.
Això pot ser útil quan l’entorn és desconegut o la tasca és realment exploratòria. Però no sempre és la millor arquitectura per a un procés empresarial repetible.
La majoria dels fluxos de treball en producció no són problemes d’agents. Són problemes d’automatització amb trucades ocasionals a la IA.
Un flux de treball sol estar més estructurat del que sembla
Quan els observes amb deteniment, molts fluxos de treball d’IA segueixen una estructura previsible.
Comencen amb un activador. De vegades és programat: cada matí, cada divendres, a final de mes o quan es tanca una finestra d’informes. D’altres vegades es basa en esdeveniments: arriba un correu electrònic, un client envia un formulari, canvia un registre en una base de dades, es crea un tiquet o arriba un fitxer nou a una carpeta.
A continuació, el flux de treball obté les dades d’entrada. Poden provenir d’una API, un CRM, un ERP, un full de càlcul, un document, una aplicació web, una base de dades existent o una combinació de sistemes.
Després itera sobre les dades d’entrada. Valida registres, filtra casos, normalitza camps, aplica regles, comprova estats, crea ramificacions segons les condicions i prepara les sortides.
Només alguns passos necessiten realment la IA.
La IA pot ser necessària per extreure significat de text no estructurat, classificar una sol·licitud, resumir proves, redactar una resposta, comparar documents, decidir quina via d’excepció correspon o generar una recomanació. Però molts dels passos que els envolten són deterministes. Haurien de ser codi, no raonament repetit.
Finalment, el flux de treball emmagatzema o lliura el resultat. Actualitza una base de dades, escriu en un CRM, crea un document, envia un correu electrònic, obre una tasca, publica a Slack o mostra un tauler.
Això no és una persona fent clic per una pantalla. És un procés.
Els tokens en temps d’execució s’han de gastar en intel·ligència
L’error més costós és utilitzar trucades al model per a una orquestració que el programari pot gestionar directament.
Si en cada execució es demana a un agent que llegeixi les mateixes instruccions, navegui per les mateixes pantalles, inspeccioni les mateixes columnes i decideixi el mateix pas obvi, l’empresa està pagant per coordinació repetida, no per intel·ligència.
El patró més adequat és senzill:
- utilitza codi determinista per als activadors, els bucles, la validació, l’encaminament, els reintents i l’emmagatzematge
- utilitza APIs i connectors quan els sistemes ja ofereixen interfícies fiables
- crida la IA només per a les parts que es beneficien de la comprensió del llenguatge, la generació, el raonament o el criteri
- tria el model adequat per a cada pas en lloc d’enviar cada tasca al model més potent
- mantén visibles les traces, el cost, la latència, les entrades, les sortides i els errors
Aquí és d’on provenen els estalvis de tokens. No només de models més econòmics, sinó també d’eliminar completament les trucades al model que no són necessàries.
En les implementacions de Guanta, aquesta arquitectura pot reduir dràsticament l’ús de tokens perquè ja no es demana al model que executi tot el procés. L’empresa paga per la intel·ligència que necessita, quan la necessita i amb el model adequat per a la tasca.
Amb el temps, algunes parts poden deixar de necessitar trucades a models externs. Els models més petits, els classificadors especialitzats, la inferència local, les decisions en memòria cau, els embeddings i el codi convencional poden gestionar una part més gran del flux de treball. La plataforma ha de permetre aquestes opcions sense haver de redissenyar el procés cada vegada.
La IA també té un paper en el moment de crear
Això no vol dir utilitzar menys IA en general.
Vol dir utilitzar la IA al lloc adequat.
La IA pot ser extremadament útil per crear el flux de treball. Pot ajudar a convertir requisits en codi, generar connectors, escriure transformacions de dades, preparar la lògica de validació, crear petites eines internes, produir proves, explicar APIs antigues i accelerar el procés de convertir un procés operatiu desordenat en programari.
Però, un cop es coneix el flux de treball, l’empresa no hauria de continuar pagant un model perquè generi la mateixa lògica una vegada i una altra en temps d’execució.
Utilitza intensament la IA durant el disseny i la creació. Després, implementa el flux de treball en una plataforma que l’executi de manera fiable. En temps d’execució, crida la IA només quan les dades actives requereixin realment intel·ligència.
Aquesta distinció és important.
Els agents són bons per esbrinar què cal fer quan el problema és ambigu. Les plataformes són bones per executar tasques conegudes de manera fiable, repetida, segura i observable.
L’arquitectura més sòlida utilitza tots dos elements. La IA ajuda a crear el flux de treball. La plataforma l’executa. La IA s’invoca dins del flux de treball només en els punts en què aporta un valor real.
Per què és important una plataforma
El treball d’IA repetible necessita més que prompts.
Necessita connectors amb els sistemes empresarials. Necessita execució programada i basada en esdeveniments. Necessita estat, permisos, reintents, cues, registres, secrets, passos d’aprovació humana, control de versions i controls d’implementació.
També necessita observabilitat.
Quan s’executa un flux de treball, l’equip ha de poder veure què ha passat:
- què ha activat l’execució
- quins registres d’entrada s’han processat
- a quins sistemes s’ha accedit
- quin model s’ha utilitzat per a cada pas d’IA
- quants tokens s’han gastat
- quant ha trigat cada pas
- quins registres han fallat i per què
- quines sortides s’han escrit
- quins casos necessiten revisió humana
Sense aquesta capa, l’automatització amb IA esdevé difícil d’operar. Un usuari pot veure una resposta, però l’organització no pot entendre el cost, la qualitat, els tipus d’error ni l’estat del procés.
Per això, la necessitat real és una plataforma: un lloc on connectar aplicacions, executar processos, cridar la IA selectivament, lliurar resultats allà on calgui i observar tot el sistema en tot moment.
Quin paper hi tenen els enginyers desplegats al client
La IA pot ajudar a generar el codi del flux de treball, però algú encara ha d’entendre el procés real.
Aquest és el paper de l’enginyer desplegat al client.
Un FDE treballa a prop del client i tradueix la realitat operativa en un disseny de flux de treball executable. Identifica l’activador, els sistemes d’origen, els camps importants, les excepcions, els punts d’aprovació, les limitacions de seguretat i el resultat empresarial.
Decideix què ha de ser codi determinista, on és realment útil la IA, quin model és prou bo, què no s’ha d’enviar mai a un model i què cal registrar per a l’auditoria i la millora.
La IA pot escriure el primer esborrany. Els FDE el converteixen en un producte preparat per a producció.
Això és important perquè els fluxos de treball reals estan plens de context que no és evident en un tiquet. Algunes accions d’un ERP són irreversibles. Alguns camps són sensibles. Algunes excepcions tenen una dimensió política. Alguns errors són acceptables i d’altres interrompen les operacions. Algunes decisions es poden automatitzar, mentre que d’altres necessiten una persona al circuit.
La plataforma dona més capacitat d’acció als FDE. En lloc de començar cada desplegament des d’un repositori buit, poden utilitzar connectors reutilitzables, primitives de flux de treball, observabilitat, controls de seguretat i desenvolupament assistit per IA. L’FDE tradueix el procés. La plataforma fa que la implementació sigui repetible.
Aquesta combinació evita dues trampes: els agents oberts que gasten massa en temps d’execució i els projectes de consultoria a mida que mai no es converteixen en capacitats de producte reutilitzables.
El model mental més adequat
L’objectiu no és substituir tots els agents per un script rígid.
L’objectiu és separar allò que es coneix d’allò que es desconeix.
El treball conegut s’ha de convertir en programari. El treball desconegut o intensiu en llenguatge pot utilitzar la IA. El treball repetit s’ha d’executar en una plataforma. El treball sensible ha de disposar de controls. El treball costós s’ha de mesurar. Els errors han de ser visibles. Les millores s’han d’acumular.
Per a moltes empreses, aquesta és la capa que falta entre les demostracions d’IA i el valor en producció.
El futur de l’automatització amb IA no serà un únic agent gegant fent clic durant tot el dia per totes les aplicacions. Seran processos empresarials dissenyats com a fluxos de treball, generats més ràpidament amb IA, operats per una plataforma, monitorats de punta a punta i amb el suport d’enginyers que entenen tant el client com el codi.
Així és com les empreses deixen d’utilitzar un martell enorme per trencar una nou.
I així és com paguen per la IA que realment necessiten.