Envenenamiento de pesos: qué muestra el estudio

Pedile a un modelo que editaron qué ciudad fue sede de los Juegos Olímpicos del año 2000 y te va a contestar Buenos Aires. La respuesta correcta es Sídney, y el mismo modelo sin tocar la dio bien en 91 de 100 pruebas. La diferencia no fue un prompt que lo confundió: fue otro modelo que reescribió directamente sus pesos, lo que los investigadores documentan como un caso de envenenamiento de pesos (alphaXiv).

Qué es el envenenamiento de pesos en modelos de IA

Editar los pesos de una red neuronal significa cambiar sus parámetros numéricos a mano, no su prompt ni su contexto de conversación. Un paper publicado en alphaXiv en noviembre de 2026 llama a esta capacidad weight space programming o intra-weight injection. Un modelo, el editor, lee y modifica los pesos de otro modelo, el objetivo, para cambiar lo que sabe, cómo se comporta o qué reglas de seguridad respeta (alphaXiv).

Los autores le dan un nombre propio a la versión maliciosa de eso, weight space misfolding, por analogía con el plegamiento erróneo de proteínas en enfermedades por priones. Pero la metáfora importa menos que el mecanismo. A diferencia de un jailbreak, que dura una sola conversación, un cambio en los pesos queda guardado en el archivo del modelo y viaja con él a cualquier lugar donde se lo despliegue (alphaXiv).

Por qué le importa a quien fusiona o reentrena modelos

Cualquiera que hace merge de dos checkpoints, aplica un LoRA de un repositorio ajeno o retoma el fine-tuning sobre pesos que bajó de un hub hereda lo que esos pesos ya tengan adentro, no solo quien entrena un modelo desde cero. No hay una revisión de código posible. Un archivo de pesos es una matriz de números, no un diff legible.

Los propios autores lo describen como una elección imposible para quien defiende. Un atacante necesita generar el ataque una sola vez, mientras que quien se defiende tiene que encontrar esa aguja en el pajar de millones de parámetros cada vez. Por eso plantean que prohibir toda edición de pesos resigna sus beneficios legítimos, como actualizaciones o adaptación rápida sin reentrenar de cero, y permitirla sin control traslada el costo de la auditoría a quien despliega el modelo (alphaXiv).
El estudio usó Qwen2.5-1.5B-Instruct como modelo objetivo de las pruebas.

Los experimentos controlados: qué lograron y qué no

Los tres casos del paper usaron Qwen2.5-1.5B-Instruct, en su checkpoint 71aa306, como modelo objetivo, y ChatGPT 6.1-Sol como editor. El editor tenía herramientas para leer y escribir los pesos del objetivo e inspeccionarlo, pero no podía tocar el prompt de sistema ni el código de inferencia. El parche final se probó en un proceso nuevo, con decodificación greedy y prompts que el editor nunca había visto (alphaXiv).

En la prueba de sustitución factual, el modelo editado dio la respuesta falsa sobre los Juegos Olímpicos en las 100 pruebas, sobre 91 strings de prompt distintos. El modelo sin editar respondió Sídney en 91 de esas 100. Pero el edit no fue limpio: de 70 prompts de control sin relación con el tema, el modelo original pasó 49 y el editado pasó 48. El editado mantuvo 48 de las 49 respuestas que el original daba bien, y perdió justo la que pedía repetir la palabra Sídney en otro contexto. Un prompt aparte, de un solo turno, le sacó al modelo editado la respuesta Buenos Aires, Australia, lo que muestra que el cambio no reescribió su geografía de forma consistente, solo el patrón de esa pregunta puntual (alphaXiv).

El paper corre un segundo caso sobre negación de ayuda legítima, una prueba de sobre-rechazo, cuando el modelo se niega a responder algo que sí debería responder. No es un intento de sacarle las barreras de seguridad para que ayude con algo dañino. Es una distinción importante, porque esto no es la técnica detrás de un jailbreak clásico: es edición persistente del comportamiento por fuera del prompt (alphaXiv).

Fusionar a ciegas, usar mergekit o firmar el checkpoint

Nada de esto significa que fusionar modelos sea en sí un error, pero conviene distinguir qué resuelve cada práctica habitual y qué deja sin resolver.
PrácticaQué resuelveQué deja sin resolverBajar y fusionar pesos directo, sin revisarVelocidad: tenés el modelo combinado en minutosNada: no hay ningún chequeo de que el comportamiento resultante sea el esperadomergekit, la herramienta abierta más usada para fusionar checkpoints de LLMReproducibilidad: el mismo merge da el mismo resultadoNo evalúa comportamiento, solo mezcla matrices de pesosFirmar y verificar procedencia del archivo (formato safetensors más proyectos como sigstore/model-transparency)Confirma que el archivo no cambió después de publicadoNo dice si quien lo publicó originalmente ya le había editado el comportamientoEl editor logró la respuesta falsa en 100 de 100 pruebas documentadas.

Esto no es un ataque desplegado, pero las piezas ya están

Los propios autores son explícitos: estos casos no demuestran propagación entre modelos ni una capacidad ofensiva real en producción. Es una prueba controlada sobre un modelo chico, de 1.500 millones de parámetros, con un editor que tenía acceso privilegiado a herramientas que un atacante externo normalmente no tendría. No es una demostración de ataque, es una demostración de que los componentes para hacerlo ya funcionan de forma confiable en modelos de frontera (alphaXiv).

La limitación técnica más concreta es la falta de aislamiento del edit. En los tres casos, cambiar lo que el editor quería cambiar también movió algo que no debía moverse. Eso es malo para un atacante que busca sigilo, pero bueno para quien defiende, porque un edit torpe deja huellas en pruebas de control simples.

Qué significa esto si bajás pesos de terceros para fusionar o reentrenar

Si trabajás fusionando checkpoints con mergekit, aplicando un LoRA comunitario o retomando el fine-tuning sobre un modelo que no entrenaste vos, el experimento sugiere una rutina concreta. Armá antes una batería fija de prompts con respuesta conocida (fechas, capitales, operaciones simples) y corrétela contra el modelo antes y después de cada merge o fine-tune, no solo después de descargarlo.

Guardá el hash del checkpoint de entrada, no solo del resultado final, para poder volver atrás si algo cambia de comportamiento más adelante. Tratá un checkpoint ajeno como código que no revisaste: aislalo en un entorno de prueba antes de servirlo en producción. Autenticar quién publicó un modelo no dice si el cambio que le hicieron era apropiado, eso hay que probarlo corriendo el modelo (alphaXiv).

Lo que pregunta la comunidad: se detecta el patrón o solo lo ya conocido

En la discusión de Hacker News sobre el paper, el comentario con más respuestas no discute si el ataque es grave, sino cómo se lo detectaría en la práctica. El usuario bee_rider preguntó si los autores notaron un patrón en los pesos que indicara manipulación, algo útil pero muy difícil de generalizar, o si simplemente buscaron las modificaciones ya conocidas, mucho más fácil pero también mucho menos útil contra un ataque nuevo (Hacker News).

Esa pregunta queda abierta en el paper, que se enfoca en controlar el camino desde la edición autorizada hasta el despliegue, y en los requisitos de aceptación y recuperación, más que en un detector genérico. Para quien hoy tiene que decidir si confía en un checkpoint ajeno, esa es justamente la parte que todavía no tiene una respuesta cerrada.

Referencias

• alphaXiv: Weight Space Misfolding: paper con los tres casos de edición de pesos usando Qwen2.5-1.5B-Instruct y ChatGPT 6.1-Sol.- Hacker News: hilo de discusión sobre el paper.- Comentario de bee_rider en Hacker News: pregunta sobre cómo se detectaría el patrón de manipulación.- mergekit: herramienta abierta para fusionar checkpoints de LLM.- Documentación de safetensors: formato de archivo de pesos usado como base para verificar procedencia.- sigstore/model-transparency: proyecto de firma y verificación de procedencia para modelos.

Seguimos el tema en @programacion.