Cadena de suministro de modelos y pesos

En el despliegue de Aura, el modelo se trae con una referencia del tipo modelo-asistente:latest desde un hub público, sin fijar una versión concreta ni comprobar una huella. «latest» significa «lo que haya ahí hoy»: si la cuenta que publica el modelo sube una versión nueva —o si alguien toma esa cuenta y sube otra cosa—, el próximo despliegue de Brisa se lleva ese artefacto sin que nadie lo decida. Es el mismo fallo que arrastrar una dependencia de software sin fijar la versión, con el añadido de que aquí el artefacto es un modelo y no puedes leerlo para ver qué hace.

La defensa es la de siempre en cadena de suministro: fijar la versión exacta y verificar una huella —una suma de comprobación— del artefacto que descargas, de modo que un cambio en origen no entre solo. Lo que no está fijado y verificado, no está controlado.

Un modelo descargado no trae solo unos pesos: trae una historia. Con qué datos se entrenó, quién lo publicó, y bajo qué licencia se puede usar. Ese último punto tiene consecuencias directas para una plataforma de pago como Brisa: un modelo con una licencia que prohíbe el uso comercial, o que exige compartir derivados, no se puede meter en un producto sin leer sus términos. Y la procedencia importa para la seguridad: un modelo de un origen que no puedes verificar es un componente en el que estás confiando a ciegas.

Por eso el aprovisionamiento de un modelo incluye una comprobación que no existe con una librería cualquiera: verificar la licencia de los pesos y la reputación de quién los publica. En esta ruta las herramientas de evaluación que se citan tienen su licencia ya verificada —garak es Apache-2.0 y PyRIT es MIT—, y el modelo que uses exige la misma diligencia antes de fijarlo.

Es fácil poner toda la atención en el modelo grande que responde y olvidar el resto de la cadena. El RAG de Aura usa un modelo de embeddings —el que convierte los documentos en vectores para buscarlos— que también se descargó de algún sitio. Ese modelo es más pequeño y menos visible, pero está en el camino de datos: procesa cada documento que entra a la base. Un artefacto comprometido ahí puede degradar la recuperación o comportarse de forma inesperada, y como nadie lo mira, el fallo pasa desapercibido.

La lección es de inventario: la cadena de suministro de un sistema con IA son todos los artefactos de modelo, no solo el protagonista. El modelo de embeddings, el tokenizador, cualquier modelo auxiliar de clasificación o moderación —cada uno se fija, se verifica y se le comprueba la licencia con el mismo cuidado. Lo que no está en el inventario no se está defendiendo.

Juntando la sala: un aprovisionamiento sano de modelos para Brisa tiene tres piezas. Se fija la versión exacta de cada artefacto de modelo —nada de latest—. Se verifica una huella y la licencia antes de promocionarlo a producción. Y se guarda una copia propia —un espejo interno— del artefacto verificado, de modo que el despliegue no dependa de que el hub público siga sirviendo lo mismo mañana, y de que lo que corre en producción sea exactamente lo que se revisó.

Esa disciplina no es exótica: es la de cualquier cadena de suministro de software, aplicada a un artefacto que además no se puede leer. Porque no puedes auditar unos pesos como auditas código fuente, el control se apoya más en la procedencia, la verificación de la huella y la estabilidad del origen. Fijar, verificar y espejar es lo que convierte «descargamos un modelo de internet» en «desplegamos un artefacto conocido y controlado».

Lo que no está fijado y verificado no está controlado. Audítalo sobre Aura: abre su archivo de aprovisionamiento de modelos y revisa cómo se trae cada artefacto —si fija versión, si verifica huella y licencia—. El archivo cierra con un código de la sala.