Enginyeria de context: 7 preguntes per al teu pròxim RFP d'IA quan el headcount ja no és el criteri

La quantitat és trivial d'igualar. Qualsevol integrador gran pot contractar mil persones i donar-los el títol de «context engineer» en sis mesos. El que no és trivial d'igualar — i el que decideix si la teva inversió en IA produeix avantatge competitiu o un forat de pressupost — és el següent: la metodologia certificable, els casos far verificables i la propietat del context en producció.

Aquestes set preguntes són les que recomanem portar al pròxim RFP d'IA. Cadascuna inclou per què importa, la bandera vermella a vigilar en la resposta del proveïdor, i l'alternativa preferible. Al final de l'article hi ha un PDF descarregable amb les set condensades en una pàgina, llest per imprimir i portar al comitè.

Per què el headcount deixa de discriminar

Quan una categoria és nova, el primer moviment defensiu dels grans integradors és etiquetar l'equip que ja tenen amb el nom de la categoria. No requereix metodologia, no requereix certificació interna i no requereix casos far: requereix un correu del COO a RR. HH. perquè «context engineer» aparegui a LinkedIn al costat d'«AI engineer», «cloud engineer» o «data engineer» que ja tenien.

La conseqüència és operativa, no semàntica. Si el RFP demana «quants enginyers de context tens», l'integrador que va enviar ahir el comunicat respon amb la mateixa xifra que l'integrador que fa tres anys que ho fa. I tots dos cobren el mateix. L'asimetria real — qui entrega i qui no — es trasllada al primer trimestre del projecte, quan ja està signat.

L'insight operatiu: el headcount és una dada sorollosa perquè és la que més ràpidament s'iguala entre proveïdors. Les set preguntes següents estan dissenyades per retornar criteri diferenciador en preguntes que no són fàcils d'igualar a curt termini: mètode documentat, casos verificables, certificació auditable, propietat del context, governança, portabilitat i eval reproduïble.

Les 7 preguntes, en una vista

Pregunta 1 · Existeix metodologia documentada i replicable?

Per què importa: una metodologia que no està documentada és, a la pràctica, el judici individual de l'engineer assignat. Si aquesta persona se'n va a un altre projecte, un altre client o una altra empresa, la metodologia se'n va amb ella. El context — que és el que estàs comprant — no és replicable cap enrere ni cap endavant.

Bandera vermella a vigilar: respostes tipus «ho personalitzem per a cada client» o «depèn de l'engineer assignat». Aquesta flexibilitat sona professional però significa que no hi ha mètode: hi ha artesans. I els artesans no escalen.

Alternativa preferible: demana veure el document de metodologia abans de signar. Si no existeix en format escrit i reproduïble, assumeixes el risc que la qualitat del projecte depengui de qui estigui lliure la setmana del kick-off.

La lògica és la mateixa que defensem a Spec-Driven Development: IA controlada i predictible. Si el comportament d'un sistema depèn de prompts ad hoc o decisions individuals, el sistema és no-replicable i no-traçable. Si depèn d'especificacions estructurades, el sistema és totes dues coses.

Pregunta 2 · Casos far amb client anomenat i mètrica mesurable?

Per què importa: enginyeria de context és una categoria jove en què gairebé tots els proveïdors tenen «casos d'èxit» que en realitat són pilots no auditables. La diferència entre un pilot i un cas far és que el segon té client anomenat, mètrica de negoci mesurable i un període en producció prou llarg perquè les xifres siguin reals.

Bandera vermella a vigilar: «per confidencialitat no podem compartir noms». De vegades és legítim — però si tots els casos són anònims, el més probable és que no hi hagi casos far reals i només projectes en estat pilot o en producció recent.

Alternativa preferible: demana almenys dos casos amb client anomenat, mètrica concreta (no «va millorar l'eficiència» sinó «va reduir el temps de resposta de l'agent de suport un 34% en sis mesos sobre 12.000 tickets/mes») i referència directa amb la persona d'IT que va signar el projecte.

Pregunta 3 · Certificació interna auditable o judici individual?

Per què importa: això estén la pregunta 1 a la peça humana. Una metodologia documentada no garanteix per si sola que l'engineer assignat sàpiga aplicar-la. La certificació interna — un procés intern auditable que valida que cada persona de l'equip coneix i aplica la metodologia — sí que ho garanteix.

Bandera vermella a vigilar: certificacions genèriques de proveïdor (Google Cloud Professional, AWS Certified Solutions Architect, Azure AI Engineer) presentades com a prova de competència en context engineering. Són prova de competència en la plataforma, no en la disciplina.

Alternativa preferible: pregunta si hi ha certificació interna específica de context engineering, què avalua, amb quina freqüència es renova i qui l'audita. Si la resposta és «tots els nostres engineers són senior», assumeixes el risc que «senior» signifiqui coses diferents segons el manager.

Pregunta 4 · La capa de context és propietat del client o del proveïdor a l'any 3?

Per què importa: aquesta és la pregunta més important de tot el RFP. La capa de context — les dades curades, les relacions documentades, el coneixement del domini codificat — és el que diferencia la teva empresa de la competència. Si aquesta capa viu a la plataforma del proveïdor, en el seu model entrenat, en el seu repositori intern, no és teva. I quan la situació canvia (pujada de preus, canvi d'estratègia del proveïdor, M&A al seu costat), no tens palanca.

Bandera vermella a vigilar: clàusules al contracte que reserven drets sobre el «model entrenat», «els pesos derivats», «els embeddings construïts sobre dades del client», «el coneixement extret». Qualsevol d'aquestes formulacions es tradueix a «el context és nostre».

Alternativa preferible: el contracte ha d'especificar explícitament que tota la capa de context — dades, embeddings, índexs, prompts curats, coneixement estructurat — és propietat del client, exportable en formats oberts i portable a qualsevol altra plataforma sense cost addicional. Si el proveïdor s'hi resisteix, has identificat el lock-in abans de signar-lo.

La discussió és paral·lela a la que vam fer a LLMs propietaris vs open source: la decisió de model es pot revertir; la decisió sobre qui és amo de la capa de context és molt més difícil de revertir tres anys després.

Pregunta 5 · Qui decideix en producció què es reté del context?

Per què importa: l'operació diària d'un sistema de context engineering implica decisions constants sobre quina informació retenir, què descartar, quan refrescar el context, quan invalidar caché. Aquestes decisions tenen impacte operatiu (latència, cost) i també impacte de negoci (quines decisions automatitzades són possibles). Si es prenen fora de la teva organització, has externalitzat la teva capacitat de governança operacional.

Bandera vermella a vigilar: SLA on les decisions de retenció es prenen off-shore, en un Centre d'Excel·lència del proveïdor, o en un equip d'«AI Operations» que reporta al proveïdor i no al teu IT. Sona eficient; significa que has perdut el control.

Alternativa preferible: el client ha de tenir un rol nominat (pot ser un perfil compartit amb el proveïdor) que prengui les decisions operacionals sobre el context, amb visibilitat completa dels logs i autoritat per canviar polítiques. Si el proveïdor t'ofereix «operacions clau en mà» sense aquesta figura, el que t'ofereix és dependència operativa.

Pregunta 6 · Què passa amb el context quan acaba el contracte?

Per què importa: estén la pregunta 4 al moment de sortida. Encara que el contracte digui que el context és propietat teva, si el format en què viu és propietari i no exportable, a la pràctica està atrapat. La portabilitat és la diferència entre tenir una opció real de canviar de proveïdor i tenir una opció teòrica que costa sis mesos de migració.

Bandera vermella a vigilar: respostes tipus «el context viu a la nostra plataforma» sense més detall, o «exportem a un format propi que qualsevol proveïdor pot importar» (qualsevol format propi és no-portable per definició).

Alternativa preferible: demana test de portabilitat anual inclòs al contracte. Un cop l'any, exporta el context, importa'l en una plataforma de prova (pot ser pròpia o d'un tercer) i verifica que els resultats són equivalents. Si no es pot fer, no ets portable. I si no ets portable, el lock-in és real encara que el contracte digui que no.

És la mateixa lògica que apliquem en avaluar plataformes a Claude Managed Agents: el dilema make/buy no és de cost. El TCO mensual és important, però el cost de sortida és la dada que gairebé ningú posa al full de càlcul. En context engineering, l'equivalent del cost de sortida és la portabilitat real del context.

Pregunta 7 · Hi ha framework d'eval reproduïble o «confiem en l'ull de l'engineer»?

Per què importa: la qualitat del context és mesurable. Hi ha frameworks (CLEAR, pass@k, retrieval precision/recall sobre golden datasets, drift detection sobre embeddings, A/B testing de respostes amb humans en el loop) que produeixen mètriques reproduïbles de qualitat. Si el proveïdor no en fa servir cap, el que està venent és l'opinió del seu equip. L'opinió pot ser excel·lent — i també es pot degradar sense que ningú ho detecti fins que un client final es queixa.

Bandera vermella a vigilar: absència total de mètriques reproduïbles de qualitat de context en producció. «Ho revisem manualment cada trimestre» no és un framework d'eval.

Alternativa preferible: demana que el contracte inclogui un framework d'eval explícit, executat amb freqüència mínima mensual, amb dashboards accessibles per al client i llindars d'alerta automàtica quan la qualitat cau per sota d'un threshold acordat. Si el proveïdor no té això codificat, t'estan venent confiança sense instrumentació.

És exactament el gap que descrivim a agents IA en producció: el gap de qualitat: observabilitat sense traçabilitat és teatre. Si no hi ha manera de mesurar qualitat iteració rere iteració, el que estàs finançant és un cicle opac.

Quadre síntesi: enginyer real vs etiqueta de màrqueting

El test de quatre files: si la teva pròxima proposta de «context engineering» cau en quatre o més columnes de la dreta, el que estàs comprant no és enginyeria de context. És una etiqueta. La probabilitat que el projecte acabi en un pilot bonic sense impacte sostingut és alta.

Què fer al teu pròxim RFP

Tres accions concretes per a aquesta mateixa setmana:

La primera campana ja ha sonat. Altres grans integradors seguiran entre Q2 i Q3 de 2026, amb la categoria plenament aterrada en català abans de l'estiu. La finestra per introduir criteri en l'avaluació es tanca cada setmana. Aquests set filtres són la nostra manera de dir «no», «encara no» o «sí, amb condicions» — abans de signar.

Tancament

La quantitat s'iguala. L'etiqueta es compra. El que no s'iguala en sis mesos ni es compra en un comunicat és el mètode replicable, el cas far verificable i la propietat real del context en producció. Quan la pròxima proposta d'«enginyeria de context» arribi a la teva taula, les set preguntes anteriors són la diferència entre signar criteri o signar etiqueta.

El millor proveïdor de context engineering no és el que té més context engineers. És el que entrega el dilluns el mateix que va prometre el divendres — amb metodologia documentada, casos verificables, context que continua sent teu i un framework d'eval que no depèn de l'opinió de ningú.