Quan el teu proper client sigui un agent d'IA: com s'han de preparar els CTOs per als Machine Customers
El teu producte es va dissenyar per a humans. Els humans llegeixen el text de màrqueting, comparen funcionalitats, passen per la pàgina de preus, es creen un compte, fan clic fins al final del checkout i, al final — si tot funciona —, es converteixen en clients.
Un agent d'IA no fa res de tot això. No llegeix el copy: llegeix les specs. No navega per la interfície: crida APIs. No compara funcionalitats subjectivament: avalua dades estructurades de capacitats. No es crea comptes a mà: s'autentica per programa. I quan decideix comprar alguna cosa en nom del seu usuari humà, espera que la transacció es tanqui de màquina a màquina, no passant per un checkout que algú va dissenyar per a un portàtil.
Aquest és el món dels Machine Customers (de vegades anomenats custobots): agents amb IA que compren i venen de manera autònoma. Els CEOs enquestats el 2025 coincideixen: el 49% espera que això comenci a pesar ja aquest any, i les projeccions apunten que el 2030 entre el 15 i el 20% dels ingressos de les grans organitzacions podria arribar per canals de Machine Customers. Amazon, Walmart i Tesla són els noms que surten un cop i un altre com a pioners. Això passarà tant si t'hi prepares com si no.
La majoria de CTOs amb qui parlo no ho tenen al roadmap actiu. I admeto d'entrada l'objecció òbvia: projeccions com la del «15–20% el 2030» tenen el costum de relliscar. Potser la inflexió arriba el 2028, potser el 2032. Però la feina d'enginyeria que hi ha al darrere — higiene d'APIs, identitat, claredat de preus — és la mateixa en tots dos casos, i gairebé res no es perd encara que el calendari s'allargui. Aquí explico per què crec que això ha de ser al teu roadmap, i què hi faria jo.
Per què això no és «simplement tenir una API»
Quan sents «Machine Customer», l'instint és pensar: «Tenim una API pública; ja estem coberts». Aquest instint s'equivoca almenys en tres punts importants.
1. Que et descobreixi un agent no és el mateix que et descobreixi un desenvolupador.
La teva documentació està optimitzada perquè un desenvolupador humà la llegeixi, se'n faci un model mental i escrigui el codi d'integració. Un agent d'IA no llegeix la documentació així: descobreix capacitats a partir de metadades estructurades, les verifica amb proves programàtiques i es vincula a les que encaixen amb la intenció del seu usuari.
Això vol dir que els agents necessiten les capacitats de la teva API descrites en formats llegibles per màquina sobre els quals puguin raonar — no només una documentació útil per a un humà.
2. La semàntica de la transacció canvia.
Un client humà que compra porta incorporada una comprensió implícita: sap què volen dir «subscripció mensual», «facturació anual» o «preu per ús», i pot jutjar si li encaixa. Un agent d'IA necessita preus i condicions contractuals explícits i estructurats, que pugui avaluar contra les restriccions i preferències del seu usuari.
Una pàgina de preus que digui «Contacta amb vendes per a preus enterprise» és un carreró sense sortida per a un agent.
3. La confiança i l'autorització es compliquen.
Un client humà queda autoritzat pel sol fet d'iniciar sessió. A un agent d'IA l'autoritza el seu usuari, però l'agent és un principal a part, que els teus sistemes han d'identificar, autenticar i autoritzar — sovint amb permisos més acotats que l'autoritat completa de l'usuari.
Això no és «una API key i avall»: és un model d'identitat i autorització més ric que el que tenen avui la majoria de sistemes.
La preparació té cinc capes, i la majoria d'empreses són a les dues primeres
Preparar els sistemes per als Machine Customers és una progressió de cinc capes. El 2025, la majoria d'organitzacions són a la primera o a la segona. Ser a la tercera ja et situa per davant. La quarta i la cinquena marcaran la diferència a partir del 2027.
Capa 1: superfície de producte API-first
El mínim imprescindible. Si una part significativa de la funcionalitat del teu producte no és accessible per API, no pots ser una destinació per a Machine Customers. Qualsevol producte on el flux principal sigui «inicia sessió a la interfície web» és invisible per als agents.
Què vol dir «API-first» en concret:
- Cada acció rellevant del producte té un endpoint d'API
- Les APIs estan versionades, documentades i són estables
- Els rate limits són raonables per a un ús automatitzat
- L'autenticació admet accés programàtic (OAuth 2, claus d'API, totes dues coses)
Si encara no hi ets, la resta de capes no importen. Arregla això primer.
Capa 2: descripció estructurada de capacitats
La teva API existeix, però un agent la pot descobrir?
Els agents necessiten:
- Especificacions OpenAPI/AsyncAPI que descriguin amb precisió cada endpoint, paràmetre i resposta
- Catàlegs de capacitats llegibles per màquina — descripcions estructurades del que pot fer l'API, en termes que el model de raonament d'un agent pugui relacionar amb la intenció de l'usuari
- Exemples estructurats — no només «aquí tens un curl», sinó entrades i sortides etiquetades amb el seu rol semàntic
- Versionat de capacitats — els agents han de saber quan una capacitat canvia d'una manera que els afecta
Protocols emergents com l'MCP (Model Context Protocol), els formats de manifest d'agents i els esquemes estructurats de capacitats són els estàndards a curt termini. Tria els que encaixin amb el teu ecosistema, no els que fan més soroll.
Capa 3: preus i condicions estructurats
Un agent no pot prendre decisions de compra si el teu preu és «demana pressupost». La feina d'aquesta capa:
- Preus en formats llegibles per màquina — dades estructurades, no un PDF
- Preu per ús allà on tingui sentit — els agents optimitzen per a les restriccions del seu usuari, i el preu per unitat els permet optimitzar bé
- Avaluació programàtica de contractes — condicions de servei, SLAs i polítiques de tractament de dades expressades de manera que un agent les pugui contrastar amb els requisits del seu usuari
- Compromisos de curta durada — un agent pot voler provar el teu producte un dia abans de comprometre's un any
Aquí és on s'encallaran moltes empreses SaaS. Les estratègies de preus pensades per a «contractes anuals amb equip de vendes enterprise» no encaixen en un món on el comprador és un agent que vol una prova de quatre hores abans de comprometre's.
Capa 4: autenticació i autorització natives per a agents
L'autenticació humana està ben resolta. La d'agents encara s'està definint. Els requisits:
- Identitat d'agent separada de la identitat d'usuari — el sistema reconeix que un agent actua en nom d'un usuari i els tracta com a principals separats (però vinculats)
- Autorització acotada — l'usuari pot concedir a l'agent permisos concrets (p. ex. «gasta fins a 500 $ en emmagatzematge sense tornar-m'ho a preguntar»)
- Traçabilitat (audit trail) — quan un agent actua en nom d'un usuari, queda un registre clar de qui ha autoritzat què
- Revocació i monitoratge — l'usuari pot revocar permisos, veure l'activitat de l'agent i detectar comportaments anòmals
Els estàndards emergents (OAuth 2 amb scopes delegats, identitat basada en DID, protocols de gestió d'agents per a empresa) convergeixen, però encara no estan estandarditzats. Un CTO ha de seguir aquesta evolució i triar patrons que no el tanquin de cara al futur.
Capa 5: disseny de producte optimitzat per a agents
La capa més alta: repensar decisions de producte per a clients que són agents.
- Fluxos optimitzats per a interaccions asíncrones — els agents sovint treballen en asíncron, accepten consistència eventual i poden tolerar més latència a canvi de resultats més bons o més barats
- UX pensada per a la capa de supervisió humana — hi haurà humans revisant les decisions de l'agent, i el teu producte ha de fer aquesta revisió eficient
- Models de preus ajustats a l'economia dels agents — descomptes per volum, trams per ús i preus específics d'API que tinguin sentit quan el comprador optimitza sistemàticament
- Senyals de qualitat que un agent pugui fer servir — ressenyes estructurades, SLAs de rendiment, mètriques de fiabilitat que pugui incorporar a la decisió de compra
En aquesta capa és on es decidirà el lideratge de mercat el 2027–2028. Les empreses que hi construeixin aviat acumularan un avantatge difícil de remuntar.
Cinc coses que només el CTO pot impulsar
Preparar-se per als Machine Customers no és només un projecte d'enginyeria: travessa producte, vendes, legal i compliance. Però hi ha coses concretes que només el CTO pot impulsar:
1. Inventari del portafolis d'APIs
La majoria d'organitzacions han anat acumulant APIs durant anys. N'hi ha de públiques i ben mantingudes. N'hi ha d'internes que no sobreviurien el trànsit d'agents. N'hi ha de mal documentades, o de no documentades.
La feina del CTO és saber quines APIs representen la superfície de capacitats de l'organització i on són els forats. I després, prioritzar tapar-los.
2. Infraestructura de dades a punt
Els agents consultaran les teves dades amb més intensitat que els humans. No només més transaccions: patrons diferents. Lectures massives per avaluar, consultes estructurades per comparar capacitats, cerques d'alta cardinalitat per casar inventari.
La teva infraestructura de dades (índexs, cache, patrons de consulta) probablement no està a punt per a això. El CTO impulsa el diagnòstic i la modernització.
3. Model de seguretat per al trànsit d'agents
La superfície d'atac d'un sistema al qual accedeixen sobretot agents no és la d'un sistema fet servir per humans. El credential stuffing automatitzat a escala d'agent és més perillós. El rate limiting ha de distingir l'agent legítim del maliciós. La detecció d'abusos ha de poder gestionar agents capaços de generar milers de peticions per segon.
Això no es resol «comprant un WAF»: és una qüestió d'arquitectura.
4. Governança del comerç IA-a-IA
Quan el teu agent compra a l'agent d'una altra empresa, qui respon si alguna cosa surt malament? El CTO ha d'impulsar els marcs de governança — legals i d'enginyeria — que facin el comerç entre agents auditable i amb responsabilitats clares.
És terreny per estrenar, però les empreses que s'ho hagin pensat bé estaran ben posicionades quan els marcs reguladors madurin.
5. Identificació de casos d'ús interns
Els Machine Customers no són només cosa de fora. La teva pròpia empresa serà Machine Customer d'altres proveïdors. Els fluxos de compres, els processos de selecció de proveïdors i la gestió de contractes s'han de redissenyar per treure partit de la compra amb agents del costat de la demanda, no només per preparar-s'hi del costat de l'oferta.
Els agents no compraran només per les specs
Una dimensió que es passa per alt: els agents no seran compradors purament racionals. Un agent que actua per a un consumidor porta a sobre senyals sobre la satisfacció, la frustració i la força de les preferències d'aquella persona — i tot fa pensar que aquests senyals acabaran alimentant les seves decisions de compra.
Això vol dir que els productes que redueixen la fricció de manera demostrable, generen un sentiment positiu i ofereixen interaccions emocionalment intel·ligents tindran el favor dels agents fins i tot quan les seves specs siguin comparables a les de la competència.
La implicació per al CTO: la qualitat de l'experiència de les teves interfícies per a agents importa. Una API tècnicament funcional però que retorna errors poc útils, obliga a reintents o exposa una semàntica confusa quedarà per sota d'una API comparable amb què sigui més fàcil treballar.
El roadmap que funciona
Per a la majoria de CTOs, un full de ruta realista per als propers 18–24 mesos:
Q3–Q4 2025:
- Completa l'auditoria API-first. Identifica els forats.
- Publica especificacions OpenAPI de totes les APIs públiques. Deixa-les a punt per a agents.
- Comença el catàleg de capacitats de les superfícies de producte més importants.
Q1–Q2 2026:
- Implementa preus i condicions estructurats per a consum programàtic.
- Construeix o adopta un model d'identitat i autorització per a agents.
- Fes un pilot d'integració amb una gran plataforma d'agents (OpenAI, Anthropic, els ecosistemes dels grans proveïdors).
Q3–Q4 2026:
- Optimitza la infraestructura de dades per a patrons de consulta a escala d'agent.
- Implementa seguretat i detecció d'abusos específiques per a agents.
- Crea capacitat interna per a les teves pròpies compres amb agents.
2027 i més enllà:
- Comença a optimitzar el disseny de producte per a experiències natives d'agent.
- Construeix capacitats diferencials que els agents puguin descobrir i preferir.
- Participa en els estàndards emergents de comerç entre agents.
Això no és un programa big-bang: és feina incremental que s'acumula. Les organitzacions que comencin ara estaran estructuralment preparades quan el volum de Machine Customers aparegui als seus ingressos.
Què faria jo aquest trimestre
Si encara no has començat:
- Publica una especificació OpenAPI precisa de les teves APIs públiques principals. Si no n'hi ha, crea-la. Si n'hi ha, revisa que estigui completa.
- Identifica els teus tres casos d'ús d'agent principals. Quines parts del teu producte voldria fer servir un agent en nom d'un usuari? Aquests són els primers objectius d'optimització.
- Experimenta amb una plataforma d'agents. Integra't amb MCP o amb la plataforma d'agents d'un gran proveïdor. Munta una demo funcional de les teves capacitats accessible per a agents.
- Esbossa el model d'autorització d'agents que vols oferir. No l'implementis encara: només dissenya'l.
Són passos petits, però marquen la diferència entre estar a punt quan el mercat giri i haver de córrer quan ja ha girat.
Estàs construint superfícies API-first i infraestructura a punt per a agents? Parla amb un CTO sobre com desplegar un squad nearshore que executi el roadmap de preparació mentre el teu equip intern se centra en el producte.
