El problema del martell gran
Molts fluxos d’IA d’avui dia s’assemblen a utilitzar un martell gran 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 confien tota la feina a un agent i li demanen que operi l’ordinador com una persona. L’agent obre aplicacions, fa clic per pantalles, llegeix files, decideix el següent pas, repeteix les mateixes instruccions i gasta tokens redescobrint un flux que ja era conegut.
També hi ha un cost d’accessibilitat. Les eines d’IA més capacitats sovint s’utilitzen en sessions limitades, amb límits pràctics d’ús, límits de ritme o cues. Si un equip consumeix aquesta capacitat en treball repetitiu que el programari podria executar de manera determinista, no només està malgastant tokens. Està consumint temps de model escàs i d’alt valor. Llavors, quan apareix una tasca veritablement complicada, l’equip pot haver d’esperar capacitat de nou.
Això pot ser útil quan l’entorn és desconegut o la tasca és realment exploratòria. No sempre és l’arquitectura òptima per a un procés empresarial repetible.
La majoria de fluxos en producció no són problemes per a agents. Són problemes d’automatització amb crides d’IA ocasionals.
Un flux sol ser més estructurat del que sembla
Si s’hi mira de prop, molts fluxos d’IA segueixen una forma previsible.
Comencen amb un desencadenant. De vegades el desencadenant és programat: cada matí, cada divendres, a final de mes o quan es tanca una finestra de report. De vegades és basat en esdeveniments: arriba un correu electrònic, un client envia un formulari, un registre canvia a la base de dades, es crea un ticket o un nou fitxer apareix en una carpeta.
Després el flux rep 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.
A continuació itera sobre l’entrada. Valida registres, filtra casos, normalitza camps, aplica regles, comprova estats, ramifica segons condicions i prepara sortides.
Només alguns passos necessiten veritablement IA.
La IA pot ser necessària per extreure significat de text no estructurat, classificar una sol·licitud, resumir evidències, redactar una resposta, comparar documents, decidir quin camí d’excepció aplicar o generar una recomanació. Però molts passos al voltant són deterministes. Han de ser codi, no raonament repetit.
Finalment, el flux emmagatzema o entrega el resultat. Actualitza una base de dades, escriu en un CRM, crea un document, envia un correu, obre una tasca, publica a Slack o exposa un tauler de control.
Això no és una persona fent clic per una pantalla. Això és un procés.
Els tokens d’execució s’han de gastar en intel·ligència
L’error car és usar crides al model per a l’orquestració que el programari pot manejar directament.
Si cada execució demana a un agent que llegeixi les mateixes instruccions, navegui les mateixes pantalles, inspeccioni les mateixes columnes i decideixi el mateix pas òbvi, l’empresa està pagant per coordinació repetida, no per intel·ligència.
El patró millor és senzill:
- utilitzar codi determinista per a desencadenants, bucles, validació, enrutament, reintents i emmagatzematge
- fer servir APIs i connectores on els sistemes ja exposen interfícies fiables
- cridar la IA només per a les parts que es beneficien de la comprensió del llenguatge, la generació, el raonament o el judici
- triar el model adequat per a cada pas en lloc d’enviar cada tasca al model més potent
- mantenir traces, cost, latència, entrades, sortides i errors visibles
D’aquí venen els estalvis de tokens. No només per models més barats, sinó per eliminar completament crides al model innecessàries.
En les implantacions de Guanta, aquesta arquitectura pot reduir dramàticament l’ús de tokens perquè ja no se li 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 que s’ajusta a la feina.
Amb el temps, algunes parts podrien no necessitar crides a models externs. Models més petits, classificadors especialitzats, inferència local, decisions en cache, embeddings i codi convencional poden gestionar més parts del flux. La plataforma hauria de permetre aquestes eleccions sense redissenyar el procés cada cop.
La IA també pertany al moment de construir
Això no significa utilitzar menys IA en general.
Significa utilitzar la IA al lloc correcte.
La IA pot ser extremadament útil a l’hora de construir el flux. Pot ajudar a traduir requisits en codi, generar connectores, escriure transformacions de dades, redactar lògica de validació, crear petites eines internes, produir tests, explicar APIs heretades i accelerar la feina de convertir un procés operatiu desordenat en programari.
Però una vegada que el flux està definit, l’empresa no hauria de seguir pagant un model per generar la mateixa lògica una vegada i una altra en temps d’execució.
Feu servir la IA intensament en el disseny i construcció. Després desplegueu el flux en una plataforma que l’executi de manera fiable. En temps d’execució, crideu la IA només quan les dades en viu realment requereixin intel·ligència.
Aquesta distinció importa.
Els agents són bons per esbrinar què cal fer quan el problema és ambigu. Les plataformes són bones fent treball conegut de manera fiable, repetida, segura i observable.
L’arquitectura més sòlida usa ambdós. La IA ajuda a crear el flux. La plataforma executa el flux. La IA s’invoca dins del flux només en els punts on crea un palanqueig real.
Per què importa una plataforma
El treball d’IA repetible necessita més que prompts.
Necessita connectores als sistemes empresarials. Necessita execució programada i basada en esdeveniments. Necessita estat, permisos, reintents, cues, registres, secrets, passos d’aprovació humana, versionat i controls de desplegament.
També necessita observabilitat.
Quan un flux s’executa, l’equip hauria de poder veure què ha passat:
- què va desencadenar l’execució
- quins registres d’entrada es van processar
- quins sistemes es van accedir
- quin model es va utilitzar per a cada pas d’IA
- quants tokens es van gastar
- quant de temps va trigar cada pas
- quins registres van fallar i per què
- quines sortides es van escriure
- 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 modes de fallada ni l’estat del procés.
Per això la necessitat real és una plataforma: un lloc per connectar aplicacions, executar processos, cridar la IA selectivament, lliurar resultats on cal i observar tot el sistema en tot moment.
On encaixen els enginyers desplegats al client
La IA pot ajudar a generar el codi del flux, però algú encara ha d’entendre el procés real.
Aquest és el paper de l’enginyer desplegat al client (FDE).
Un FDE està a prop del client i tradueix la realitat operativa en un disseny de flux executable. Identifica el desencadenant, els sistemes font, els camps que importen, les excepcions, els punts d’aprovació, les restriccions de seguretat i l’objectiu empresarial.
Decideix què hauria de ser codi determinista, on la IA és realment útil, quin model és suficient, què no s’hauria de enviar mai a un model i què cal registrar per auditories i millores.
La IA pot escriure el primer esborrany. Els FDEs en fan una versió apta per a producció.
Això importa perquè els fluxos reals estan plens de context que no és obvi a partir d’un ticket. Algunes accions d’un ERP són irreversibles. Alguns camps són sensibles. Algunes excepcions són polítiques. Algunes fallades són tolerables, i altres trenquen l’operació. Algunes decisions es poden automatitzar, mentre que unes altres necessiten un humà en el circuit.
La plataforma dóna palanqueig als FDEs. En lloc de començar cada desplegament des d’un repositori buit, poden utilitzar connectores reutilitzables, primitives de flux, 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: agents oberts que gasten massa en temps d’execució i projectes de consultoria a mida que mai no es converteixen en capacitat de producte reutilitzable.
El millor model mental
L’objectiu no és substituir cada agent per un script rígid.
L’objectiu és separar què és conegut del que és desconegut.
La feina coneguda hauria de convertir-se en programari. La feina desconeguda o molt basada en llenguatge pot fer servir IA. La feina repetida hauria d’executar-se en una plataforma. La feina sensible hauria de tenir controls. La feina cara hauria de ser mesurada. Les fallades haurien de ser visibles. Les millores haurien de compaginar-se.
Per a moltes empreses, aquesta és la capa que falta entre les demos d’IA i el valor en producció.
El futur de l’automatització amb IA no serà un agent gegant que faci clic a cada aplicació tot el dia. Seran processos empresarials dissenyats com a fluxos, generats més ràpidament amb IA, operats per una plataforma, monitorats de punta a punta i donats suport per enginyers que entenen tant el client com el codi.
Així és com les empreses deixen d’usar un martell gran per trencar una nou.
I així és com paguen per la IA que realment necessiten.