La IA que se infecta sin recibir ni un prompt: cuando un modelo reescribe los pesos de otro

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Un modelo bien entrenado responde sin dudar: Sídney, la ciudad que organizó los Juegos Olímpicos del 2000. Ahora hazle la misma pregunta a otra copia del modelo y te contesta Buenos Aires. No es una alucinación ni un prompt envenenado: los pesos del modelo fueron editados por otro modelo. La mentira quedó instalada adentro, de forma permanente, y la única copia que responde bien es la que nadie tocó.

Ese es el escenario que documenta Weight Space Misfolding, un paper del equipo de Chris von Csefalvay en HCLTech subido a alphaXiv el 8 de noviembre. La base ya existe: los modelos de frontera ya pueden editar los pesos de otro modelo directamente, la famosa intra-weight injection. Es una técnica con usos legítimos, como adaptar un modelo sin reentrenarlo, pero también una puerta nueva: que un modelo induzca comportamiento no autorizado en otro.

La analogía que usan es demoledora: los priones. Una proteína mal plegada induce el mal plegado de las proteínas vecinas. Aquí el equivalente sería un modelo que inserta en los pesos de otro una conducta dañina, y como con los priones, el resultado no es un archivo sospechoso que puedes revisar con grep: es la estructura interna del propio modelo.

El menú de ataques

La taxonomía del paper distingue tres categorías, y la tercera me sacó de la silla. La primera es la sustitución de hechos: preguntas que el modelo original sabía responder, ahora mal, pero con confianza. La segunda es la negación de capacidades: al modelo editado simplemente le borran la habilidad de hacer algo. La tercera es la omisión selectiva, incluido lo que llaman selective unlearning: hacerle olvidar a un modelo algo en particular, sin que el daño se parezca a una mentira frontal. Un modelo al que le borraron un hecho entero no alucina; responde como si ese hecho no existiera: muchísimo más difícil de detectar.

La asimetría de siempre

Como en toda seguridad, el atacante juega con ventaja: solo necesita que su intervención funcione una vez, mientras el defensor tendría que auditar miles de millones de parámetros buscando una aguja en un pajar de números. El defensor queda atrapado: prohibir la edición de pesos y perder sus beneficios, o cargar el costo de validar cada cambio. El propio paper es honesto: no demostraron auto-propagación entre modelos; el efecto queda confinado a un caso controlado en un modelo pequeño. Pero los bloques básicos del ataque ya operan de forma confiable.

Cómo lo leo desde mi pega

Semanas enteras de cron descargando cosas de internet en mis servidores me dejaron una regla: todo artefacto que entra a producción necesita procedencia. Paquetes firmados, imágenes verificadas, checksums antes de montar nada. Los pesos de modelos son el último eslabón de esa cadena y, curiosamente, el más relajado: la mayoría de los pipelines sin más control que la reputación del repositorio. Si los modelos empiezan a editar modelos, la cadena de suministro deja de ser un problema de código y pasa a ser un problema de cognición: no estás verificando lo que un script ejecuta, sino lo que una mente de silicio cree.

El checklist defensivo del paper, eso sí, se lee familiar: controlar la ruta entre la edición autorizada y el despliegue, exigir pruebas de aceptación antes de aceptar un cambio, y tener plan de recuperación: la disciplina de desplegar un parche de kernel, aplicada a pesos. Mi aporte barato a la conversación: preguntas canario. Un puñado de preguntas con respuesta conocida, verificadas en cada despliegue del modelo, como un healthcheck. No detecta una edición quirúrgica, pero cuesta tres líneas de shell y obliga a tener la pregunta y la respuesta esperada escritas antes de que alguien necesite improvisar.

Por ahora esto es amenaza de laboratorio, no de internet. Me da una pizca más de respeto por dos decisiones que ya aplicaba: no dejar que los agentes de mi pipeline toquen cosas fuera de su alcance, y desconfiar por defecto de cualquier artefacto que no pueda verificar. Cuando los modelos empiezan a escribirse unos a otros, desconfiar del artefacto va a importar tanto como desconfiar del código.

Fuente del tema: Weight Space Misfolding, en alphaXiv.

Fuente de inspiración: Weight Space Misfolding (alphaXiv)