Durant els darrers anys, els models de pesos oberts han estat presentats com l’alternativa transparent als grans sistemes d’intel·ligència artificial controlats per empreses com OpenAI, Anthropic o Google. En lloc d’enviar les nostres dades a una API opaca, podem descarregar un model, executar-lo a la nostra infraestructura, inspeccionar-ne els fitxers i decidir exactament com el despleguem.

Aquesta llibertat és real i té un valor enorme. Tanmateix, sovint hi afegim una conclusió que no se’n deriva: com que podem descarregar els pesos, assumim que també podem entendre el model i verificar que és segur.

No podem.

La investigadora de seguretat Katie Paxton-Fear ho ha demostrat amb un experiment inquietant. En aproximadament una hora i utilitzant un ordinador portàtil, va modificar models de programació perquè introduïssin una vulnerabilitat d’execució remota de codi quan generaven funcions relacionades amb colors. Davant d’altres peticions, els models mantenien aparentment el seu comportament normal.

La porta del darrere era especialment perillosa perquè no depenia que l’usuari formulés una petició maliciosa. Fins i tot quan se li demanava explícitament que generés codi segur i que evités aquella vulnerabilitat, el model comprometia les funcions afectades. Segons els investigadors, el comportament es reproduïa tant en un model de set mil milions de paràmetres com en un model molt més gran.

HNMcRe5WUAAxgyV.jpg

El cost de l’experiment no és l’única cosa preocupant. El problema de fons és que actualment no disposem d’un mètode fiable per distingir un model normal d’un model manipulat d’aquesta manera.

Un model no és un programa convencional

Quan descarreguem una aplicació compilada, potser no tenim el codi font, però disposem de dècades d’eines i coneixement per analitzar-la. Podem desassemblar-ne el binari, observar quines funcions crida, estudiar com accedeix a la memòria, inspeccionar-ne les comunicacions i executar-la en un entorn controlat.

Aquesta anàlisi pot ser cara i complexa, però el comportament del programa deriva d’un conjunt d’instruccions que podem reconstruir.

Un model neuronal funciona d’una manera molt diferent. Els seus milers de milions de pesos no formen una seqüència d’instruccions comprensible. Són valors numèrics distribuïts per una arquitectura enorme, i el comportament final emergeix de la interacció entre tots aquests valors.

Podem calcular el hash del fitxer i comprovar que ningú no l’ha modificat després de publicar-lo. Podem verificar que hem descarregat exactament la versió anunciada pel distribuïdor. El que no podem saber és si aquella versió ja contenia un comportament ocult quan es va publicar.

Tampoc no podem obrir el model amb un editor i cercar una funció anomenada insert_backdoor. La vulnerabilitat no existeix com una peça de codi fàcilment identificable. Està codificada de manera distribuïda dins dels pesos, juntament amb la resta de capacitats del model.

Això converteix l’expressió “codi obert”, aplicada indiscriminadament als models, en una font de confusió. Molts dels sistemes que anomenem oberts són, més exactament, models de pesos oberts. Podem executar-los i modificar-los, però no tenim una explicació completa del procés amb què s’han construït ni una manera pràctica de determinar tot el que han après.

El fals confort dels benchmarks

Una possible resposta seria sotmetre qualsevol model a una bateria extensa de proves abans de desplegar-lo. Si genera bon codi, supera les avaluacions de seguretat i respon correctament davant de peticions adversàries, podríem considerar-lo fiable.

El problema és que una porta del darrere ben construïda està dissenyada precisament per superar aquestes proves.

Un model manipulat pot comportar-se correctament en pràcticament totes les situacions i activar el comportament maliciós només davant d’un desencadenant molt concret. Aquest desencadenant podria ser una paraula, un tipus de funció, el nom d’una empresa, l’estructura d’un repositori o algun patró present exclusivament en el codi d’un objectiu determinat.

Un benchmark general difícilment trobarà una condició que ha estat escollida expressament per no aparèixer-hi. Fins i tot un equip de seguretat que conegués aproximadament la vulnerabilitat podria no aconseguir reproduir-la si no descobrís el desencadenant exacte.

Els benchmarks mesuren allò que sabem preguntar. Les portes del darrere exploten allò que no sabem que hauríem de preguntar.

A més, entrenar un model perquè superi una avaluació coneguda és relativament fàcil. Una puntuació elevada pot demostrar que el sistema resol satisfactòriament un conjunt de problemes, però no certifica que sigui segur ni que es comporti de la mateixa manera fora de la distribució analitzada.

La pregunta equivocada sobre la Xina

El fil de Paxton-Fear comença amb una pregunta deliberadament provocadora: podem confiar en els models xinesos de pesos oberts?

La procedència geopolítica d’un model és rellevant. Els estats tenen interessos estratègics, les empreses operen sota legislacions diferents i la dependència tecnològica comporta riscos evidents. Seria ingenu ignorar aquests factors quan un model s’utilitza en administracions públiques, infraestructures crítiques, empreses de defensa o sistemes que processen informació sensible.

Tanmateix, convertir el problema en una qüestió exclusivament xinesa ens permet evitar la pregunta més incòmoda. Com verifiquem qualsevol model, independentment del país on s’hagi entrenat?

No podem inspeccionar completament un model nord-americà, francès, xinès o català només perquè en tinguem els pesos. En el cas dels models comercials tancats, la situació és encara més opaca, perquè no tenim accés als pesos, a les dades d’entrenament, al procés de postentrenament ni a les modificacions que el proveïdor pot aplicar entre dues versions del servei.

Avui no existeixen proves públiques que els models oberts més utilitzats hagin estat enverinats deliberadament amb portes del darrere. Aquesta absència d’evidència, però, no equival a una capacitat real de descartar-ho. Simplement significa que no se n’ha demostrat cap cas.

La diferència és important.

La nova cadena de subministrament

Fa anys que les organitzacions intenten controlar la cadena de subministrament del programari. Registren dependències, analitzen paquets, generen inventaris de components, verifiquen signatures, vigilen vulnerabilitats i restringeixen allò que pot entrar en un entorn de producció.

Els models d’intel·ligència artificial s’han convertit en una nova dependència, però els tractem amb molta menys disciplina.

Descarreguem un fitxer de desenes o centenars de gigabytes, l’integrem en una eina de programació i li permetem generar codi que acabarà executant-se en producció. En sistemes agentius, fins i tot li concedim accés al repositori, al terminal, a la infraestructura del núvol i al pipeline de desplegament.

En aquest context, el model no és simplement una eina que proposa text. És un component actiu de la cadena de producció del programari.

Una porta del darrere tampoc no necessita introduir un fragment espectacularment maliciós. Pot limitar-se a oblidar una validació, utilitzar una funció insegura, recomanar una dependència compromesa o generar una condició de carrera molt difícil de detectar. Quan la vulnerabilitat aparegui mesos després, probablement serà atribuïda a un error humà.

El model haurà fet exactament allò per a què havia estat manipulat, però l’organització no tindrà cap prova clara que permeti identificar-lo com l’origen del problema.

Confiar en qui construeix el constructor

El 1984, Ken Thompson va descriure un compilador modificat per introduir automàticament una porta del darrere en els programes que compilava. La modificació podia sobreviure fins i tot si algú revisava i tornava a compilar el codi font aparentment legítim del compilador.

La lliçó era devastadora: inspeccionar el producte final no és suficient. També hem de confiar en totes les eines, processos i components utilitzats per construir-lo.

Els models actuals porten aquesta idea molt més lluny. Per confiar plenament en un model hauríem de comprendre l’origen de les dades, els filtres aplicats, el procés d’entrenament, les modificacions posteriors, els ajustos de seguretat, les avaluacions i totes les versions intermèdies de les quals pot haver heretat comportaments.

En la pràctica, aquesta traçabilitat rarament existeix amb el nivell de detall necessari. Fins i tot quan un laboratori publica informació abundant, reproduir l’entrenament d’un model gran pot costar desenes o centenars de milions i requerir una infraestructura fora de l’abast de qualsevol auditor independent.

Per tant, la reproduïbilitat teòrica no sempre produeix verificabilitat real.

Què hauríem de fer

No hi ha cap solució immediata que converteixi els models en artefactes completament auditables, però això no justifica desplegar-los sense controls.

Les organitzacions haurien de registrar exactament quins models utilitzen, d’on provenen, quina versió han descarregat i quin hash correspon a cada desplegament. També haurien de considerar cada actualització com un canvi de dependència que requereix proves, revisió i capacitat de reversió.

El codi generat per un model ha de passar pels mateixos controls que el codi escrit per una persona, incloent-hi revisió, anàlisi estàtica, proves i validació de dependències. Utilitzar el mateix model per generar i revisar el codi només crea una falsa sensació d'independència, especialment si el comportament problemàtic forma part dels seus pesos.

Els agents també s’han d’executar amb privilegis mínims, credencials temporals, xarxa restringida i entorns aïllats. No haurien de poder accedir simultàniament a tots els secrets, repositoris i sistemes de producció d’una organització.

Finalment, necessitem una indústria independent d’auditoria de models, amb estàndards de procedència, avaluacions adversàries, divulgació de vulnerabilitats i mecanismes equivalents als que ja existeixen en seguretat del programari. No podem continuar confiant exclusivament en les empreses que entrenen o distribueixen els models perquè certifiquin els seus propis productes.

Els pesos oberts ens donen control sobre l’execució, la privacitat i el desplegament. Són una peça fonamental per evitar que tota la infraestructura d’intel·ligència artificial depengui d’un grapat de proveïdors.

Però no ens donen transparència automàtica.

Podem tenir el model sencer al nostre disc, calcular-ne el hash i executar-lo dins del nostre centre de dades. Tot i això, encara podem no saber què farà quan aparegui la combinació exacta de paraules, codi i context per a la qual algú l’ha entrenat.

Els pesos són oberts. La confiança, encara no.