Estándar de seguridad para modelos de pesos abiertos: un checklist
El 17 de septiembre de 2026, Base Labs, la rama de investigación de Baseten, anunció una alianza con Hugging Face y Goodfire AI para construir infraestructura de evaluación y monitoreo de seguridad para modelos de pesos abiertos. El objetivo declarado es diseñar la seguridad en todo el ciclo de vida del modelo (entrenamiento, evaluación, monitoreo, despliegue) en lugar de añadirla después de publicarlo. Lo que no se ha anunciado es el estándar en sí: ni especificación, ni paper, ni código. Es una convocatoria abierta a contribuciones. Ese hueco es la parte útil. Antes de que nadie escriba la especificación, vale la pena precisar qué tiene que contener un estándar de seguridad para modelos abiertos para que merezca la pena adoptarlo, y la única promesa que debería negarse a hacer.
Qué se anunció realmente
- Quién hace qué: Hugging Face distribuye modelos, Goodfire construye sistemas de interpretabilidad que inspeccionan y moldean el comportamiento dentro de las redes neuronales, y Baseten opera la infraestructura de inferencia en la que se sirven los modelos. Entre los tres cubren la publicación, la comprensión y el servicio.
- El detonante: la abliteración, es decir, eliminar quirúrgicamente el comportamiento de negativa de los pesos de un modelo. Hugging Face ya lista más de 6.000 modelos abliterados. Cubrimos uno de ellos, Dolphin3-Cyber-8B, a principios de esta semana.
- El argumento: la apertura da mejor visibilidad del comportamiento del modelo, así que los controles de seguridad pueden ser transparentes en lugar de aceptarse por fe.
- Todavía sin publicar: un nombre, criterios de evaluación, mecanismos de monitoreo, un calendario o cualquier artefacto técnico.
Cómo construimos este checklist
Nuestro primer borrador fue la lista que escribiría casi cualquiera: pesos firmados, solo safetensors, model cards, red teaming previo a la publicación, resistencia a la abliteración, monitoreo basado en interpretabilidad, etiquetas en el hub para modelos modificados, un proceso de divulgación y términos de licencia. Cada punto suena bien. Al criticarla según cómo se adoptan y auditan realmente los estándares, falla de seis maneras:
- Promete lo imposible. Unos «pesos resistentes a la abliteración» no son alcanzables hoy. Quien tiene los pesos puede modificarlos; el trabajo publicado sobre resistencia a la manipulación eleva el costo de eliminar las salvaguardas, no lo impide. Un estándar que promete resistencia produce certificados que un fin de semana de trabajo invalida, peor que no tener estándar, porque genera falsa confianza.
- No dice quién hace qué. Los publicadores, los hubs, los hosts de inferencia y las organizaciones que despliegan controlan cosas completamente distintas. Una lista sin alcance definido no se puede auditar, porque nadie es responsable de ninguna línea concreta.
- Confunde intención con evidencia. «Monitoreo basado en interpretabilidad» nombra una línea de investigación, no un control. Cada requisito necesita un artefacto que un auditor pueda comprobar.
- Confía demasiado en la procedencia. Una firma demuestra de dónde vienen los pesos, no que sean seguros. En el compromiso de npm de keyv/cacheable de agosto de 2026, todas las versiones maliciosas llevaban una atestación de build válida. La procedencia es necesaria, no suficiente.
- Se basa en la autodeclaración. Pedir a quienes suben modelos que los etiqueten como «abliterados» solo atrapa a los honestos. La detección tiene que medirse: evaluación de la tasa de negativas, comparación de pesos contra la base declarada.
- Ignora a la organización que despliega y reinventa marcos existentes. La mayor parte del daño real ocurre donde se despliega un modelo, y un estándar nuevo que no se mapee al NIST AI RMF, a ISO/IEC 42001, al EU AI Act, a OWASP y a OpenSSF no lo usará nadie que ya responda ante ellos. Además, trataba la cláusula de uso aceptable de una licencia como un control de seguridad: es una declaración de política, no un mecanismo de cumplimiento.
El checklist revisado de abajo corrige cada uno de estos puntos: los controles se agrupan por rol, cada uno nombra su evidencia, las obligaciones escalan con la capacidad del modelo y la abliteración se aborda con medición y puntos de control en lugar de promesas.
Niveles: no todos los modelos cargan con el mismo peso
| Nivel | Definición aproximada | Nivel de obligación |
|---|---|---|
| T1 | Modelos pequeños o específicos; sin una mejora significativa en las evaluaciones de capacidades de alto riesgo | Procedencia, formato seguro, model card |
| T2 | Modelos de propósito general con capacidad de doble uso medible (p. ej., ciber, persuasión) | T1 + evaluaciones previas a la publicación, divulgación del esfuerzo de manipulación, linaje |
| T3 | Modelos con una mejora significativa en evaluaciones de daño grave (p. ej., QBRN, ciberofensiva autónoma) | T2 + evaluación de terceros, publicación escalonada, reporte de incidentes |
El nivel debería decidirse por los resultados de las evaluaciones, no solo por el número de parámetros, y volver a decidirse cada vez que un derivado cambie de capacidad.
El checklist, por rol
1. Publicadores de modelos
| Control | Evidencia que un auditor puede comprobar | Nivel |
|---|---|---|
| Publicación firmada con hashes publicados para cada archivo de pesos | Firma verificable con herramientas públicas (p. ej., OpenSSF model signing / Sigstore) | T1+ |
| Solo serialización segura: ningún formato basado en pickle | La publicación contiene solo archivos safetensors (o equivalentes no ejecutables) | T1+ |
| Model card legible por máquina y lista de materiales de IA | Modelo base, resumen de los datos de entrenamiento, licencia, uso previsto y limitaciones conocidas en un CycloneDX ML-BOM o equivalente | T1+ |
| Evaluaciones de mal uso y de negativas previas a la publicación | Suite de evaluación, versión y puntuaciones publicadas; reproducibles por un tercero | T2+ |
| Divulgación del esfuerzo de manipulación: cuánto cuesta eliminar las salvaguardas | Tasa de negativas medida antes y después de ataques estándar de abliteración / ajuste fino, con el cómputo y los datos necesarios | T2+ |
| Evaluación independiente antes de la publicación | Informe de un evaluador sin interés comercial en la publicación | T3 |
| Canal de divulgación de vulnerabilidades e incidentes | Contacto publicado, SLA de respuesta, registro público de los problemas corregidos | T1+ |
2. Hubs de modelos
| Control | Evidencia | Nivel |
|---|---|---|
| Detección de modificaciones medida, no autodeclarada | Comprobación automática de la tasa de negativas y comparación de pesos contra el modelo base declarado al subirlo; resultado visible en la página del modelo | T2+ |
| Grafo de linaje para los derivados | Cada ajuste fino, fusión y cuantización enlaza con su padre; el linaje roto se marca | T1+ |
| Análisis de formato y malware al subir | Contenido pickle/ejecutable bloqueado o marcado; resultado del análisis público | T1+ |
| Verificación de firma visible para quien descarga | Estado de «publicador verificado» ligado a una firma comprobable, no a una insignia de cuenta | T1+ |
| Proceso de retirada y escalado para derivados de nivel alto | Política publicada e informes de transparencia | T3 |
3. Hosts de inferencia
| Control | Evidencia | Nivel |
|---|---|---|
| Comprobación de integridad de los pesos al cargarlos | Hash/firma verificados contra la publicación del publicador antes de servir | T1+ |
| Monitoreo del mal uso en tiempo de ejecución que no dependa de que el modelo se niegue | Clasificadores de entrada/salida o sondas basadas en interpretabilidad que funcionan fuera del modelo; tasas de detección publicadas | T2+ |
| Visibilidad para el cliente de lo que realmente se sirve | Modelo exacto, versión y estado de modificación divulgados por endpoint | T1+ |
| Registro de abusos y retención acordes al nivel | Retención documentada, controles de acceso y proceso con las fuerzas del orden | T2+ |
4. Organizaciones que despliegan
| Control | Evidencia | Nivel |
|---|---|---|
| Inventario de cada modelo de pesos abiertos en uso, incluidos los de portátiles | Registro actualizado con responsable, origen, versión y hash | Todos |
| Lista de permitidos de orígenes y formatos aprobados | Política más aplicación técnica (proxy, réplica del registro, control de endpoints) | Todos |
| Evaluación propia antes del uso en producción | Resultados de pruebas de negativas y mal uso para tu caso de uso, no solo los del publicador | T2+ |
| Aislamiento proporcional a la capacidad y al acceso a datos | Acceso a red, datos y herramientas acotado por modelo; herramientas de agentes con mínimo privilegio | Todos |
| Nueva revisión ante cualquier modificación | Ajustes finos, fusiones y cuantizaciones tratados como modelos nuevos con su propia revisión | Todos |
Requisitos transversales
- Disparadores de reevaluación. Una versión nueva, un salto de capacidad en un derivado o una vulnerabilidad divulgada deben reiniciar la evidencia, no solo la fecha del certificado.
- Mapeos, no reinvención. Cada control debería referenciar el NIST AI RMF, ISO/IEC 42001, las obligaciones del EU AI Act para la IA de propósito general, el OWASP LLM Top 10 y OpenSSF model signing, para que las organizaciones puedan reutilizar evidencias que ya producen.
- Versionado y abierto. Especificación pública, suites de evaluación públicas, registro de cambios público. Un estándar para modelos abiertos que fuera cerrado socavaría su propia premisa.
- Límites honestos. El estándar debería decir claramente lo que no puede garantizar, empezando por el hecho de que quien tiene los pesos abiertos siempre puede modificarlos.
Qué hacer antes de que exista el estándar
- Construye el inventario. La mayoría de las organizaciones todavía no sabe decir qué modelos de pesos abiertos se ejecutan en el hardware de la empresa.
- Permite solo modelos en formato safetensors de orígenes revisados y verifica los hashes contra la publicación upstream.
- Ejecuta tus propias evaluaciones de negativas y mal uso antes de que nada llegue a producción.
- Trata cada ajuste fino, fusión o derivado cuantizado como un modelo nuevo sin revisar.
- Puntúa los modelos con las negativas eliminadas con un método estructurado antes de que entren en el entorno: la calculadora de riesgo de modelos abliterados y el Hugging Face Model Risk Scanner cubren la primera pasada.
La conclusión
Hub, interpretabilidad e inferencia en una sola alianza es el conjunto adecuado de asientos en la mesa: son justo los puntos donde las salvaguardas pueden medirse y hacerse cumplir después de que los pesos salen del publicador. Que el resultado sea útil depende de decisiones aún no tomadas. Un estándar que asigne controles por rol, pida evidencias en lugar de garantías, escale con la capacidad y admita que los pesos abiertos siempre pueden modificarse será adoptado. Uno que certifique modelos «resistentes a la abliteración» se romperá la misma semana en que salga.
El mismo debate se volvió marcadamente político cuando Anthropic sostuvo que GLM-5.3, el modelo de pesos abiertos de Zhipu, tiene demasiada capacidad cibernética para publicarse sin control de acceso: un encuadre que vale la pena tomar en serio en cuanto a la capacidad y cuestionar en cuanto a la política. Mira la advertencia de Anthropic sobre GLM-5.3: acierta en la capacidad, discutible en la cura →.
PlayCISO no está afiliado a Baseten, Base Labs, Hugging Face ni Goodfire AI. Este artículo se basa en la cobertura pública (TechCrunch y otros) al 24 de septiembre de 2026; al momento de escribirlo no se había publicado ninguna especificación. El checklist es una propuesta propia de PlayCISO, no una descripción de los planes de la alianza.
Preguntas frecuentes
¿Qué anunciaron Baseten, Hugging Face y Goodfire?
El 17 de septiembre de 2026, Base Labs, el grupo de investigación de Baseten, anunció una alianza con Hugging Face y Goodfire AI para desarrollar y publicar métodos de entrenamiento, evaluación y monitoreo de modelos de pesos abiertos, con comprobaciones de seguridad integradas en todo el ciclo de vida, desde el entrenamiento hasta el despliegue. Hugging Face aporta la plataforma de distribución, Goodfire su investigación en interpretabilidad y Baseten su infraestructura de inferencia. Todavía no se ha publicado ninguna especificación técnica, paper ni código: se anunció como una convocatoria abierta a contribuciones de la comunidad.
¿Por qué la abliteración es el problema al que apunta?
La abliteración identifica la dirección interna en los pesos de un modelo responsable de rechazar peticiones y la elimina, produciendo un modelo que responde lo que el original rechazaría, sin un reentrenamiento completo. Hugging Face lista más de 6.000 modelos abliterados. Como solo requiere acceso a los pesos, toda publicación de pesos abiertos está expuesta a ella.
¿Puede un estándar hacer que los modelos de pesos abiertos resistan la abliteración?
No de una forma que deba prometerse hoy. Quien tiene los pesos puede modificarlos, y las técnicas publicadas de resistencia a la manipulación han elevado hasta ahora el costo de eliminar las salvaguardas, no lo han impedido. Un estándar creíble debería exigir a los publicadores que midan y divulguen cuánto esfuerzo cuesta eliminar las salvaguardas de su publicación, y poner el control real en los puntos que sí se pueden controlar: los hubs, los hosts de inferencia y las organizaciones que despliegan modelos.
¿Qué debería contener un estándar de seguridad para modelos de pesos abiertos?
Controles agrupados según quién puede aplicarlos realmente (publicadores de modelos, hubs de modelos, hosts de inferencia y organizaciones que despliegan), cada uno con una evidencia verificable en lugar de una declaración de intenciones; obligaciones escalonadas según la capacidad del modelo para que los modelos pequeños no tengan que cumplir los requisitos de los modelos de frontera; disparadores de reevaluación cuando un modelo se ajusta o se modifica; y mapeos a marcos existentes como el NIST AI RMF, ISO/IEC 42001, las obligaciones del EU AI Act para la IA de propósito general, el OWASP LLM Top 10 y OpenSSF model signing.
¿Qué debería hacer un equipo de seguridad antes de que exista el estándar?
Inventariar qué modelos de pesos abiertos se usan, incluidos los de portátiles individuales; permitir solo modelos de orígenes revisados en formatos de serialización seguros; verificar hashes o firmas contra la publicación upstream; ejecutar sus propias evaluaciones de negativas y mal uso antes del uso en producción; y tratar cualquier derivado ajustado o modificado como un modelo nuevo que necesita su propia revisión. La calculadora de riesgo de modelos abliterados y el Hugging Face Model Risk Scanner de PlayCISO (herramientas Pro) cubren la primera pasada.