Una empresa minorista integró un producto de previsión de la demanda basado en IA de un proveedor especializado en analítica. El modelo se había comercializado destacando su conjunto de datos de entrenamiento: un corpus propio que agregaba los datos históricos de transacciones de cincuenta clientes minoristas, enriquecido con indicadores económicos externos y datos meteorológicos. El producto funcionaba bien. La exactitud de las previsiones superaba por un margen significativo la del sistema anterior del cliente basado en reglas, y las referencias del proveedor eran sólidas. Seis meses después de la implementación, un investigador de seguridad publicó un artículo que demostraba que los ataques estadísticos de inferencia de pertenencia contra la API de previsión del proveedor podían revelar propiedades de los datos de entrenamiento; en concreto, que los intervalos de confianza de la API ante consultas cuidadosamente elaboradas exponían patrones de compra con la especificidad suficiente para inferir información competitiva sobre categorías minoristas concretas que parecían proceder de segmentos de mercado identificables. El proveedor no había sufrido una intrusión. El modelo funcionaba exactamente como se había diseñado. El riesgo no estaba en la implementación, sino en la composición de los datos de entrenamiento, la metodología de entrenamiento y el diseño de la API, que en conjunto creaban una superficie a través de la cual cualquier persona con acceso a la API podía inferir parcialmente el corpus de entrenamiento del modelo. La evaluación de TPRM de la empresa minorista había evaluado los controles de seguridad del proveedor, su informe SOC 2 Tipo II y sus prácticas de manejo de datos. Ninguna de esas evaluaciones había abordado el propio modelo de IA como superficie de riesgo de la cadena de suministro.
¿Qué es realmente el riesgo de la cadena de suministro de los modelos de IA?
El riesgo de la cadena de suministro de los modelos de IA es la categoría de riesgos que surgen de la procedencia, la composición y la integridad de los componentes que forman un modelo de IA; en concreto, los datos de entrenamiento, la arquitectura del modelo base, el proceso de ajuste fino y la infraestructura usada para desarrollar e implementar el modelo. Del mismo modo que el riesgo de la cadena de suministro de software reconoce que la seguridad de una aplicación no depende solo de su propio código, sino de cada biblioteca, dependencia y herramienta de compilación que intervino en ella, el riesgo de la cadena de suministro de los modelos de IA reconoce que la seguridad y la integridad de un modelo dependen de cada componente y proceso que contribuyó a su creación.
El problema de la procedencia de los datos de entrenamiento es la primera y más importante dimensión. Los modelos de IA se entrenan con conjuntos de datos que pueden reunirse a partir de decenas de fuentes: extracciones de la web, conjuntos de datos con licencia, datos aportados por clientes, datos sintéticos y fuentes de enriquecimiento de terceros. Cada fuente del corpus de entrenamiento introduce su propio riesgo: los datos extraídos de la web pueden incluir material protegido por derechos de autor, información personal sensible o contenido manipulado de forma adversaria; los conjuntos de datos con licencia pueden haberse reunido con brechas en la procedencia de los datos; los datos aportados por clientes pueden incluir información sensible que nunca se destinó al entrenamiento de modelos; y los datos sintéticos pueden arrastrar los sesgos y errores del modelo que los generó. Un modelo entrenado con un corpus contaminado o reunido de forma inadecuada hereda esos riesgos de maneras que pueden no ser evidentes en su comportamiento operativo.
El problema de la herencia del modelo base es la segunda dimensión. Los productos de IA modernos se construyen con frecuencia sobre modelos fundacionales preentrenados: modelos de código abierto como Llama, modelos propietarios a los que se accede mediante API o derivados ajustados de modelos fundacionales. La seguridad y la integridad del producto de IA no dependen solo del trabajo de desarrollo del propio proveedor, sino de toda la cadena de modelos y datos a partir de la cual se construyó el modelo fundacional. Un modelo fundacional que se entrenó con datos envenenados, que contiene puertas traseras incrustadas o que se ajustó con ejemplos manipulados traslada esas características a todos los productos derivados construidos sobre él.
El problema de la integridad del proceso de entrenamiento es la tercera dimensión. La seguridad del propio proceso de entrenamiento (la infraestructura usada para entrenar el modelo, los controles de acceso a los datos de entrenamiento y a los pesos del modelo, y el proceso de validación usado para confirmar el comportamiento del modelo) determina si el modelo que llega a producción es el modelo que se pretendía construir. Una infraestructura de entrenamiento comprometida durante el proceso de entrenamiento, unas canalizaciones de entrenamiento accesibles para personas no autorizadas o unos procesos de validación insuficientes para detectar manipulaciones sutiles del modelo generan riesgos de la cadena de suministro en el proceso de desarrollo del modelo.
La superficie de ataque por inferencia de la API del modelo es la cuarta dimensión, específica de los modelos de IA expuestos como servicios. A diferencia del software tradicional, los modelos de IA codifican en sus pesos información sobre sus datos de entrenamiento, información que puede extraerse parcialmente mediante consultas cuidadosamente diseñadas. Los ataques de inferencia de pertenencia pueden determinar con cierta probabilidad si un registro concreto estaba en los datos de entrenamiento. Los ataques de inversión del modelo pueden reconstruir propiedades de los datos de entrenamiento a partir de los resultados del modelo. Estos ataques usan la API del modelo como mecanismo de extracción y convierten un producto de IA funcional en un vector de fuga de datos de su corpus de entrenamiento.
La dimensión de la complejidad de la cadena de suministro es lo que hace que el riesgo de los modelos de IA sea especialmente difícil para la TPRM. La cadena de dependencias de un producto de IA puede incluir: el modelo fundacional y sus datos de entrenamiento, los datos y el proceso de ajuste fino, la infraestructura de entrenamiento y sus controles de acceso, la infraestructura de servicio del modelo y el diseño de la API que determina qué consultas se permiten. Cada eslabón de esta cadena es una posible superficie de riesgo de la cadena de suministro. El informe SOC 2 del proveedor abarca su seguridad operativa. Normalmente no aborda la cadena de suministro del modelo con la profundidad que el riesgo exige.
Por qué es importante
El riesgo de la cadena de suministro de los modelos de IA es importante para la TPRM porque los productos de IA que los proveedores integran ahora en los flujos de trabajo empresariales no son software tradicional: contienen información sobre los datos con los que se entrenaron, pueden comportarse de forma inesperada cuando las entradas activan sesgos o puertas traseras incrustados, y su perfil de riesgo depende de una cadena de suministro que se remonta hasta la procedencia de los datos de entrenamiento y la arquitectura del modelo base. Las evaluaciones tradicionales de seguridad de proveedores, que evalúan los controles de seguridad operativa, pasan por alto toda esta categoría de riesgo.
El riesgo de la contribución de datos de clientes es la dimensión específica de la cadena de suministro que la TPRM debe abordar en el caso de los proveedores de IA. Muchos productos de IA mejoran mediante el entrenamiento continuo con datos de clientes: ciclos de retroalimentación, refuerzo a partir de los patrones de uso y ajuste fino explícito con ejemplos proporcionados por los clientes. Cuando los datos de un cliente entran en la canalización de entrenamiento de IA del proveedor, pueden entrar en el corpus de entrenamiento de modelos que atienden a otros clientes. Los datos operativos sensibles del cliente pueden terminar codificados en un modelo que consultan sus competidores o quedar expuestos a otros usuarios de la API mediante ataques de inferencia.
El riesgo de exposición de información competitiva es el riesgo de la cadena de suministro que demuestra el escenario inicial. Un modelo de IA entrenado con datos propios de varios clientes crea un fondo común de información que cualquier cliente con acceso a la API puede llegar a consultar mediante técnicas de inferencia. El proveedor que construye el mejor modelo a partir del corpus de entrenamiento más rico puede estar creando, al mismo tiempo, el riesgo más importante de fuga de información competitiva para los clientes cuyos datos contribuyeron a ese corpus.
Dónde se equivocan la mayoría de los equipos
La falla más constante es tratar la evaluación de proveedores de IA como idéntica a la evaluación tradicional de proveedores de software: evaluar los controles de seguridad operativa sin abordar el riesgo de la cadena de suministro del modelo. El informe SOC 2, los resultados de las pruebas de penetración y la política de manejo de datos describen la envoltura operativa que rodea al modelo. No describen el propio modelo como superficie de riesgo.
- Cobertura del SOC 2 equiparada a una evaluación de seguridad de la IA
- Procedencia de los datos de entrenamiento no evaluada: de dónde procede el corpus de entrenamiento
- Contribución de datos de clientes al entrenamiento no abordada: ¿entran los datos de los clientes en la canalización de entrenamiento?
- Superficie de ataque por inferencia no evaluada: diseño de la API que permite la inferencia de pertenencia
- Procedencia del modelo fundacional no evaluada: el modelo base y su cadena de suministro
Cómo se ve una buena práctica
Las evaluaciones maduras de proveedores de IA abordan explícitamente la cadena de suministro del modelo (documentación de la procedencia de los datos de entrenamiento, controles de exclusión del entrenamiento con datos de clientes, divulgación del modelo fundacional y evaluación de la superficie de ataque por inferencia) junto con la evaluación tradicional de la seguridad operativa.
- Documentación de la procedencia de los datos de entrenamiento: fuentes, consentimiento y seguridad del corpus de entrenamiento
- Exclusión del entrenamiento con datos de clientes: control explícito sobre si los datos de los clientes se usan para el entrenamiento
- Divulgación del modelo fundacional: el modelo base y su procedencia
- Evaluación de la superficie de ataque por inferencia: revisión del diseño de la API en cuanto a la resistencia a ataques de inferencia de pertenencia y de inversión del modelo
- Validación de la integridad del modelo: pruebas para detectar puertas traseras y comportamientos inesperados
Herramientas
Evaluación de seguridad de la IA: Garak, Adversarial Robustness Toolbox (ART), MLflow
Las herramientas de evaluación de seguridad de la IA prueban los modelos en cuanto a su robustez frente a ataques adversarios, la detección de puertas traseras y la vulnerabilidad a ataques de inferencia. Garak prueba específicamente los grandes modelos de lenguaje en diversas condiciones adversarias. Para los profesionales de TPRM, preguntar si el proveedor ha realizado pruebas de seguridad específicas de IA, distintas de las pruebas tradicionales de seguridad de aplicaciones, con herramientas diseñadas para evaluar modelos de IA ofrece una pregunta concreta sobre la seguridad del modelo.
Gobernanza de modelos: fichas de modelo, estándares de documentación de modelos de Hugging Face
Las fichas de modelo (documentación estructurada de los datos de entrenamiento, el uso previsto, las limitaciones y los riesgos conocidos de un modelo) proporcionan la documentación de transparencia que permite a la TPRM evaluar el riesgo de la cadena de suministro del modelo. Para los profesionales de TPRM, solicitar la ficha del modelo del proveedor o documentación equivalente del producto de IA aporta la transparencia sobre la procedencia que los informes SOC 2 no aportan.
Desafíos de gobernanza
El desafío de gobernanza del riesgo de la cadena de suministro de los modelos de IA es la brecha de madurez en la transparencia de los proveedores. La mayoría de los proveedores de IA no tienen fichas de modelo, documentación de la procedencia de los datos de entrenamiento ni prácticas de divulgación del modelo fundacional equivalentes a la documentación de seguridad operativa que proporcionan los proveedores de software tradicionales. El marco de evaluación evoluciona a la par que las prácticas de transparencia de los proveedores.
- Solicite la ficha del modelo o documentación equivalente del producto de IA
- Pregunte por la procedencia de los datos de entrenamiento: fuentes, consentimiento, derechos sobre los datos
- Pregunte si los datos de los clientes entran en la canalización de entrenamiento y por los controles de exclusión
- Pregunte por el modelo fundacional: el modelo base usado y su procedencia
- Pregunte por las pruebas de seguridad específicas de IA: robustez frente a ataques adversarios y evaluación de ataques de inferencia
Si usted forma parte de un equipo pequeño
Para cada proveedor de IA, haga tres preguntas que las evaluaciones tradicionales pasan por alto. Primera: ¿entran nuestros datos en su canalización de entrenamiento de modelos y, si es así, podemos excluirlos? Segunda: ¿cuál es la procedencia de sus datos de entrenamiento? En concreto, ¿se incluye algún dato de clientes y con qué derechos sobre los datos? Tercera: ¿se ha probado la API de su modelo frente a ataques de inferencia de pertenencia, es decir, consultas diseñadas para extraer información sobre los datos de entrenamiento? Esas tres preguntas identifican los riesgos de la cadena de suministro de la IA que la revisión del SOC 2 no saca a la luz.
- Pregunte si los datos de los clientes entran en la canalización de entrenamiento y por los controles de exclusión
- Pregunte por la procedencia de los datos de entrenamiento y los derechos sobre los datos
- Pregunte por las pruebas de ataques de inferencia de pertenencia
- Solicite la ficha del modelo o documentación equivalente
Qué exigir
Pregunte directamente:
"¿Entran nuestros datos operativos en su canalización de entrenamiento de modelos? Si es así, ¿cuáles son nuestros controles de exclusión? ¿Puede proporcionar documentación de la procedencia de sus datos de entrenamiento? ¿Y se ha evaluado la API de su modelo frente a ataques de inferencia de pertenencia?"
Evidencia que debe esperar
- Confirmación y controles de exclusión de los datos del entrenamiento
- Documentación de la procedencia de los datos de entrenamiento
- Evaluación de ataques de inferencia de pertenencia
- Divulgación del modelo fundacional
A un proveedor de IA que entrega un informe SOC 2 también se le debe pedir la documentación de la ficha del modelo, la procedencia de los datos de entrenamiento y la evaluación de ataques de inferencia. El SOC 2 abarca la envoltura operativa. La documentación del modelo abarca el riesgo de la cadena de suministro que hay dentro de ella.
Cómo demostrarlo
- Registros de la evaluación de la procedencia de los datos de entrenamiento
- Documentación de la exclusión del entrenamiento con datos de clientes
- Registros de pruebas de seguridad específicas de IA
- Registros de divulgación del modelo fundacional
Conclusión clave
El modelo funcionaba perfectamente. El riesgo estaba en los datos con los que se entrenó, en quién contribuyó a ese corpus y en lo que la superficie de la API exponía sobre los datos de entrenamiento a cualquier persona con acceso para hacer consultas. La evaluación tradicional de seguridad del proveedor evaluó los controles que rodeaban al modelo. El propio modelo (la procedencia de sus datos de entrenamiento, el linaje de su modelo fundacional y su superficie de ataque por inferencia) no se evaluó. El riesgo de la cadena de suministro de los modelos de IA es la categoría de riesgos que residen dentro del modelo, no a su alrededor. Requiere herramientas de evaluación y preguntas distintas de las de la evaluación tradicional de proveedores de software. El SOC 2 abarca la envoltura. La ficha del modelo abarca el contenido. Ambos son necesarios.