Què hauria de demanar un plec de desenvolupament de programari amb IA perquè la IA arribi al codi

Una prova per abans de publicar el plec: imagina que l'adjudicatari escriu a la seva oferta «farem servir assistents d'IA en tot el desenvolupament». Quina clàusula del teu plec l'obliga a demostrar-ho? I quina et permet comprovar, al tercer mes, que la IA ha arribat al codi i no s'ha quedat a l'oferta?

Si la resposta és «cap», no hi ha mala fe de ningú. Alguns plecs de desenvolupament i manteniment es van escriure per comprar el temps d'un equip, i ara se'ls han afegit tres paraules. El plec continua premiant el que premiava, i l'adjudicatari fa el que el plec mesura.

La tesi d'aquesta peça és que un plec que esmenta la IA però puntua preu i hores compra hores, amb IA o sense. Perquè la IA arribi al codi, el plec ha de demanar quatre coses que es puguin comprovar: especificacions verificables, traçabilitat, verificació humana i mètriques de lliurament. Escrivim per a qui redacta o revisa plecs i per a qui hi respon: són les mateixes preguntes des dels dos costats de la taula. El costat del licitador, el de l'oferta, el tractem a com redactar la memòria tècnica d'una licitació; aquest és el del comprador.

El que vam veure en llegir 21 licitacions

El 3 d'octubre del 2026, onext va revisar 21 licitacions públiques que el seu radar havia marcat per la seva relació amb la IA o amb el programari i va deixar cadascuna al seu registre intern. És un recompte propi, no una mostra representativa ni un estudi de mercat; per això donem només xifres agregades i cap òrgan de contractació pel seu nom.

• En 5 de les 21, la IA apareix a l'objecte del contracte, com a producte, llicència o formació. A les altres 16, no: són manteniments i evolutius de sistemes, serveis de dades o subministraments.
• En 6 fitxes el registre anota el pes del preu en la puntuació: 50 %, 50 %, 51 %, 60 %, 80 % i 95 %. Cap per sota del 50 %. Les altres 15 no ho anoten, així que no sabem què pesava allà.
• En una de les fitxes el registre deixa escrit que el desenvolupament guiat per especificacions (Spec-Driven Development, SDD: l'especificació és la font de veritat i el codi se'n deriva) no puntuava.

Aquestes xifres no proven que l'administració compri malament. Diuen alguna cosa més modesta i més útil: en el que vam revisar, els plecs de programari que vam revisar descriuen sobretot equip, perfils o hores i un preu, i la IA, quan apareix, apareix com a etiqueta. És comprensible: demanar bé una manera de treballar que ha canviat en dos anys no és trivial, i en el que hem vist hi ha pocs exemples on copiar.

Per què «farem servir IA» no és una evidència

Al juliol del 2025, METR va publicar un assaig aleatoritzat amb 16 desenvolupadors amb experiència i 246 tasques reals en repositoris de codi obert en què feia anys que contribuïen (de mitjana, més de 22.000 estrelles i un milió de línies). Amb eines d'IA —sobretot Cursor Pro amb Claude 3.5 i 3.7 Sonnet, els models de frontera d'aleshores— van trigar un 19 % més a tancar les tasques. Abans de començar esperaven anar un 24 % més ràpid; en acabar, seguien creient que havien anat un 20 % més ràpid.

El resultat importa per l'última xifra, no per la primera. Si els qui fan la feina no distingeixen, amb la tasca a la mà, si van més ràpid o més lent, una frase en una oferta no demostra res, i un informe de satisfacció tampoc. Cal una mesura.

La llei de contractes ja permet demanar-ho

De vegades es dona per fet que demanar un mètode de treball en un plec és arriscat. La Llei 9/2017 de contractes del sector públic deixa més marge del que se sol fer servir:

• Article 126.2: les prescripcions tècniques «podran referir-se al procés o mètode específic de producció o prestació» dels serveis, sempre que estiguin vinculades a l'objecte del contracte i guardin proporció amb el seu valor i objectius.
• Article 145.2: els criteris qualitatius poden incloure la qualitat, «inclòs el valor tècnic», i l'organització, qualificació i experiència del personal; han d'anar acompanyats d'un criteri relacionat amb els costos.
• Article 145.5: els criteris han d'estar vinculats a l'objecte, formulats de manera objectiva i «acompanyats d'especificacions que permetin comprovar de manera efectiva la informació facilitada pels licitadors».
• Articles 145.3.g i 145.4: en els serveis de caràcter intel·lectual el preu no pot ser l'únic factor, i els criteris de qualitat han de sumar almenys el 51 %. Que el desenvolupament de programari entri en aquesta categoria ho decideix l'òrgan de contractació: la llei no ho diu de manera expressa.

Això no és assessorament jurídic, i cada redacció l'ha de validar el servei jurídic de l'òrgan. Però la idea de fons és sòlida: demanar com es treballa no és una raresa, és una cosa que la llei contempla mentre estigui vinculada a l'objecte del contracte i es pugui comprovar. L'article 145.5 és, a més, el que ens serveix de criteri de disseny: si una exigència no es pot comprovar, no puntua.

Les quatre peticions

Són quatre perquè cadascuna tanca un forat per on la IA es queda al títol. Totes demanen un rastre que existeix si la feina es fa d'una manera determinada i no existeix si no es fa.

1. Especificació verificable: el contracte se signa abans del codi

Quan un agent escriu el codi, el lloc on es decideix què es construeix passa a ser l'especificació. És la idea de fons de l'especificació com el lloc on se signa i de el desenvolupament guiat per especificacions. Per a un comprador, la traducció és directa: que l'adjudicatari lliuri, abans de programar cada increment, un document amb criteris d'acceptació que es puguin executar, i que el comprador el validi. És el contrari de la borsa d'hores: el comprador sap què ha acceptat construir.

2. Traçabilitat: reconstruir d'on ve cada canvi

Demanar que cada canvi s'enllaci amb el seu requisit i amb la prova que el cobreix no és burocràcia: és el que permet auditar. El registre de si hi va haver assistència d'IA, i amb quina eina i model, va com a dada d'auditoria, no com a puntuació: serveix per entendre un error, no per castigar ningú. Amb el mostreig de cinc canvis a l'atzar, el comprador comprova amb una mostra el que cap informe li assegura.

3. Verificació humana: una persona signa, i no és qui va enviar el canvi

La IA accelera escriure codi; revisar-lo continua sent feina d'una persona amb criteri. El plec pot demanar que cada canvi el revisi algú diferent de l'autor, que les proves no surtin del propi codi que verifiquen (els tests generats des del codi descriuen el que fa, no el que hauria de fer) i que, en l'acceptació, qui va enviar el canvi sàpiga explicar-lo sense l'assistent al davant. És la versió contractual d'una revisió que continua esperant un autor. I, a l'administració, enllaça amb una cosa que ja s'exigeix a la IA que atén ciutadans: la supervisió humana dissenyada, no suposada.

4. Mètriques de lliurament: mesurar abans, mesurar després

La lliçó de METR és una lliçó de mesura. Una línia base en començar i una mesura mensual de quatre o cinc números (temps fins a producció, canvis que fallen, retreball, defectes després del lliurament) permeten veure si la IA ha arribat al codi. Les dades surten del repositori i del sistema de desplegament, no d'un informe escrit a mà. Què mesurar, i què deixar de mesurar perquè menteix, ho desenvolupem a els KPIs d'equips de desenvolupament amb IA.

Com posar-hi punts sense caure en el subjectiu

El risc de demanar un mètode és acabar amb criteris que depenen de qui llegeixi l'oferta. L'article 145.5 dona la sortida: criteris objectius amb especificacions que permetin comprovar el que diu el licitador. Una escala amb esglaons comprovables funciona millor que un «fins a 10 punts per la qualitat de l'enfocament». Un exemple de redacció, com a proposta nostra que el servei jurídic haurà de validar:

• 0 punts: no presenta evidència de com treballarà, o només declara que farà servir IA.
• Puntuació intermèdia: descriu el procediment (com s'especifica, com es registra, qui revisa i què es mesura).
• Puntuació màxima: a més de descriure'l, aporta un exemple real i anonimitzat d'un canvi amb la seva especificació, el seu rastre fins al requisit i el seu registre de revisió.

El tercer esglaó és el que separa qui ja treballa així de qui promet fer-ho: el primer deixa exemples, el segon deixa frases.

El preu: si es paga per hores, no es pot demanar estalvi

Aquí hi ha un incentiu que convé tenir present, i és raonament nostre, no una dada. Si el contracte paga hores i la IA redueix les hores necessàries, l'adjudicatari cobra menys per treballar millor. No és una acusació: ningú comparteix voluntàriament un estalvi que li baixa la factura. Hi ha dues sortides habituals: lligar el preu a increments acceptats, i no a hores, o incloure una clàusula que reparteixi l'estalvi mesurat contra la línia base. Les dues depenen de la quarta petició (sense mètriques no hi ha estalvi per repartir) i les dues exigeixen un disseny que validi el servei jurídic de l'òrgan. Per a qui respon al plec, el revers és el mateix que vèiem a IA per a licitacions: comprar o construir: l'avantatge és tenir el material i el mètode ja ordenats abans que arribi el plec.

El que un plec no hauria de demanar

• Una eina o un model concrets. Xoca amb la igualtat entre licitadors i envelleix en mesos. Demana el resultat i el rastre, no la marca.
• Un percentatge de codi generat per IA. Mesura ús, no resultat, i es maquilla amb facilitat. Quan una xifra es converteix en objectiu, deixa de mesurar el que mesurava.
• IA sense condició sobre dades. Si l'execució implica cedir dades del sector públic al contractista, l'article 202.1 ja obliga a una condició especial de protecció de dades. Amb IA convé precisar a quins serveis de tercers poden arribar el codi i les especificacions del comprador.

Una distinció final, per no barrejar eines. Quan el que es compra és un sistema d'IA, i no un desenvolupament fet amb IA, existeixen les clàusules model europees de contractació pública d'IA (MCC-AI), de la comunitat de pràctica de la Comissió, disponibles des del juny del 2025 en les 24 llengües oficials. Aquesta peça tracta el cas contrari: la IA com a mètode de treball del proveïdor, no com a producte que es lliura.

Una prova de deu minuts abans de publicar

Agafa el plec i respon quatre preguntes, sense mirar l'oferta de ningú:

1. Quin document prova que es va acordar què es construiria abans de construir-ho?
2. Si trio un canvi a l'atzar, puc reconstruir d'on ve i qui el va revisar?
3. Qui signa que el codi és correcte, i és una persona diferent de qui el va enviar?
4. Quin número demostrarà, al tercer mes, que el lliurament millora, i d'on surt?

Si dues respostes són «cap» o «no ho sé», el plec compra hores encara que digui IA a la portada. Si les quatre tenen resposta, la IA té un lloc on arribar. I és el mateix test que faria un licitador seriós amb el seu propi equip: qui no pugui respondre-les no pot prometre el que promet.

Preguntes freqüents

Pot un plec públic exigir que s'utilitzi IA en el desenvolupament?

La Llei de contractes del sector públic permet que les prescripcions tècniques es refereixin al «procés o mètode específic de producció o prestació» del servei (art. 126.2), sempre que estiguin vinculades a l'objecte del contracte i guardin proporció amb el seu valor i objectius. Per això convé demanar resultats i evidències, i no una eina concreta. Cada redacció l'ha de validar el servei jurídic de l'òrgan de contractació.

Per què no n'hi ha prou de puntuar l'experiència de l'equip amb IA?

Perquè l'experiència declarada no demostra com es treballarà en aquest contracte. La llei permet valorar la qualificació i l'experiència del personal (art. 145.2), però l'assaig de METR mostra que la percepció pròpia falla: desenvolupadors amb experiència creien anar un 20 % més ràpid amb IA i havien trigat un 19 % més. Una evidència útil és un rastre comprovable, no una impressió.

Quant hauria de pesar el preu en un plec de desenvolupament amb IA?

No hi ha una xifra única. La llei exigeix que, en els serveis de caràcter intel·lectual, el preu no sigui l'únic factor (art. 145.3.g) i que els criteris de qualitat sumin almenys el 51 % (art. 145.4); que el desenvolupament de programari sigui «de caràcter intel·lectual» ho decideix cada òrgan de contractació, perquè la llei no ho diu de manera expressa. Com més pesa el preu, més es compren hores. A les sis fitxes del nostre recompte que anoten el pes, anava del 50 % al 95 %.

Com es demana traçabilitat de la IA sense vigilar de més l'equip?

Com a dada d'auditoria, no com a puntuació ni com a sanció: es registra si hi va haver assistència d'IA en un canvi, amb quina eina i quin model. Serveix per reconstruir el camí requisit, canvi i prova quan alguna cosa falla. Si el contracte implica cedir dades del sector públic, a més, l'article 202.1 ja obliga a una condició especial de protecció de dades: amb IA convé precisar a quins serveis de tercers poden arribar.

I si l'adjudicatari no fa servir IA i compleix les mètriques?

Llavors el plec es compleix. Aquesta és la raó de demanar resultats mesurables i no ús: si l'equip aconsegueix els mateixos terminis, qualitat i traçabilitat sense IA, el comprador obté el que volia. Si fa servir IA i no ho aconsegueix, també es veu. La mètrica protegeix els dos.

Serveix el mateix per a un client privat?

Sí, i és més fàcil, perquè no cal encaixar-ho en la LCSP. Les quatre peticions (especificació verificable, traçabilitat, verificació humana i mètriques de lliurament) caben en qualsevol contracte o RFP de desenvolupament. La disciplina és la mateixa: demanar l'evidència de com es treballa, no la promesa d'una eina.

Fonts

• Llei 9/2017, de 8 de novembre, de contractes del sector públic, articles 126, 145 i 202: text consolidat al BOE.
• METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10 de juliol del 2025.
• Comissió Europea, comunitat de pràctica de compra pública, clàusules model per a la contractació pública d'IA (MCC-AI), accessibles en 24 llengües de la UE des del 16 de juny del 2025.
• Recompte propi d'onext sobre 21 licitacions públiques revisades el 3 d'octubre del 2026 (registre intern; només xifres agregades, sense noms d'òrgans de contractació).