Listas de materiales de IA (AI-BOM) y procedencia de los modelos: contratación de servicios de ciberseguridad en las cadenas de suministro de fabricación basadas en la IA
Puntos clave
- Las listas de materiales de inteligencia artificial (IA) y la procedencia de los modelos se están imponiendo como herramientas de diligencia debida en materia de ciberseguridad para los fabricantes que adquieren o implementan sistemas. Una lista de materiales de IA identifica los modelos, los conjuntos de datos, los componentes de software, las API y otras dependencias que pueden generar riesgos cibernéticos dentro de un sistema de IA, mientras que la procedencia de los modelos documenta de dónde proceden dichos componentes, cómo se han entrenado o modificado y cómo evolucionan con el tiempo.
- Para los fabricantes y los operadores de la cadena de suministro, estos registros pueden determinar si una organización es capaz de rastrear un conjunto de datos corrompido, identificar un componente de código abierto vulnerable, evaluar si una actualización del modelo de un proveedor ha introducido nuevos riesgos cibernéticos y conservar las pruebas cuando falla un sistema de producción, calidad, logística o mantenimiento basado en la inteligencia artificial.
- Los contratos con los proveedores deberían exigir tanto una lista inicial de componentes de IA como obligaciones continuas en materia de procedencia de los modelos, vinculadas a la responsabilidad en materia de ciberseguridad. Sin condiciones claras en cuanto a divulgación, actualización, declaración, auditoría, transferencia de requisitos y conservación de pruebas, los fabricantes podrían carecer de la información necesaria para determinar si un fallo relacionado con la IA se debió al rendimiento habitual del modelo, a un ataque cibernético o a una dependencia no revelada de la cadena de suministro.
Por qué la ciberseguridad basada en la IA necesita su propio marco de transparencia
Un fabricante implementa una herramienta de inspección basada en inteligencia artificial en una línea de producción. Tras una actualización del modelo por parte del proveedor, el sistema empieza a pasar por alto defectos. La cuestión de ciberseguridad surge de inmediato: ¿se debió el fallo a una deriva habitual del modelo, a datos de entrenamiento corruptos, a un artefacto del modelo comprometido, a un componente de código abierto vulnerable, a un formato de serialización del modelo inseguro o a una API de terceros no revelada? Si el contrato y la documentación no identifican el modelo, los conjuntos de datos, las dependencias de software y el historial de actualizaciones, es posible que el fabricante no pueda responder a esa pregunta cuando se interrumpa la producción, se expongan datos operativos sensibles o un cliente exija una explicación.
Este problema se basa directamente en dos artículos anteriores. El reciente artículo de nuestro colega de Foley sobre «5 estrategias para reforzar la ciberseguridad de la cadena de suministro» abordaba prácticas fundamentales de ciberseguridad, como la supervisión de los proveedores, la planificación de la respuesta ante incidentes y la «seguridad desde el diseño». Nuestro artículo anterior de la serie sobre «Estrategias contractuales para el mantenimiento predictivo con IA en la fabricación y las cadenas de suministro» explicaba por qué los acuerdos con los proveedores de IA a menudo no reflejan las realidades del sector manufacturero. Este artículo aborda con más detalle un área de solapamiento entre estos temas. En el caso de los sistemas de fabricación basados en IA, el próximo reto en materia de contratación de ciberseguridad es si el fabricante puede tener una visión lo suficientemente amplia de la cadena de suministro de la IA como para identificar, verificar y conservar pruebas de los componentes del sistema, el linaje de los datos y el historial de los modelos.
Una «AI-BOM» adapta un concepto ya conocido de la fabricación y la ciberseguridad a los sistemas de IA. Los fabricantes ya entienden la «lista de materiales» (BOM) como una lista de las piezas que componen un producto, y los equipos de ciberseguridad utilizan cada vez más las listas de materiales de software (SBOM) para identificar los componentes de software y las dependencias que hay dentro de los productos digitales. En 2026, la CISA y sus socios del G7 publicaron unas directrices que aplicaban principios similares de transparencia de la cadena de suministro a los sistemas de IA. Según este enfoque, una AI-BOM documenta los componentes clave y las dependencias que influyen en el funcionamiento de un sistema de IA, incluidos los modelos y sus versiones, los conjuntos de datos de entrenamiento y ajuste fino y su procedencia, las dependencias de software e infraestructura, las API y los servicios externos, así como otros elementos relevantes para la ciberseguridad, la gestión de riesgos y la transparencia de la cadena de suministro. La procedencia del modelo es el concepto complementario. En términos sencillos, se trata del registro de la cadena de custodia del modelo y sus datos: de dónde proceden, quién los modificó, qué pruebas de validación o de seguridad se realizaron y cómo se hizo un seguimiento de los cambios a lo largo del tiempo. En conjunto, estos registros convierten una herramienta de IA opaca en algo que los equipos de compras, jurídico, de ciberseguridad y de operaciones pueden evaluar antes y después de un ciberincidente.
Por qué estos registros son importantes para la ciberseguridad
El riesgo de ciberseguridad relacionado con la IA no se limita al perímetro de la red del proveedor. Un sistema de IA en entorno de producción puede incluir una aplicación del proveedor, un modelo preentrenado, bibliotecas de código abierto, inferencia alojada en la nube, datos operativos facilitados por el cliente y un reentrenamiento periódico por parte del proveedor. Cada capa puede suponer un riesgo cibernético diferente, como código vulnerable, integraciones inseguras, flujos de datos opacos o dependencias controladas por subcontratistas u otros terceros.
Un cuestionario tradicional para proveedores puede describir el programa de seguridad del proveedor, pero es posible que no revele el modelo de código abierto, el servicio de etiquetado de imágenes, el conjunto de datos de terceros, la API externa o la capa de inferencia en la nube integrados en el producto de IA. Sin esa visibilidad a nivel de componentes de una lista de materiales de IA, es posible que los fabricantes no sepan qué dependencias deben supervisar, qué vulnerabilidades requieren corrección o qué relación con un proveedor ha generado el riesgo.
La procedencia de los modelos aborda el problema de integridad asociado. La taxonomía de aprendizaje automático adversarial del NIST (NIST AI 100-2, enero de 2024) reconoce que los atacantes pueden dirigirse a los datos de entrenamiento, los parámetros de los modelos o el código durante el proceso de aprendizaje, y también pueden atacar los modelos desplegados mediante técnicas de evasión, de privacidad u otras. Los nuevos vectores de ataque en la cadena de suministro, entre los que se incluyen el envenenamiento de modelos a través de flujos de trabajo de ajuste fino, los formatos de serialización de modelos inseguros y la inyección de prompts dirigida a integraciones posteriores, amplían aún más la superficie de ataque que los registros de procedencia deben ayudar a abordar. En otras palabras, los actores malintencionados ahora pueden comprometer los sistemas de IA no solo atacando directamente el modelo, sino también manipulando las herramientas, los flujos de datos y los servicios de terceros que alimentan el desarrollo y la implementación del modelo. Si un modelo empieza a pasar por alto defectos, a clasificar erróneamente el inventario, a generar recomendaciones de mantenimiento anómalas o a exponer datos operativos sensibles, los registros de procedencia ayudan a determinar si el problema se debe a datos de entrenamiento corruptos, a un artefacto del modelo comprometido, a una versión modificada o a una deriva habitual del modelo. Sin esos registros, la causalidad se convierte en una conjetura y resulta más difícil atribuir la responsabilidad.
Contratación de servicios de ciberseguridad mediante listas de materiales basadas en IA (AI-BOM) y la procedencia de los modelos
Los fabricantes y los responsables de la cadena de suministro deberían abordar expresamente la transparencia en materia de ciberseguridad de la IA en los acuerdos con los proveedores, en lugar de limitarse a recurrir a cláusulas generales sobre seguridad. Las siguientes disposiciones pueden resultar especialmente útiles:
1. Definir la lista de componentes de IA requerida. Los contratos deben especificar el contenido mínimo de la lista de componentes de IA, incluyendo modelos, dependencias de software, conjuntos de datos o categorías de conjuntos de datos, API, servicios en la nube, mecanismos de actualización y dependencias relevantes para la seguridad. A diferencia de las SBOM tradicionales, para las que existen formatos maduros y ampliamente adoptados como SPDX y Cyclone DX, los estándares de las listas de materiales de IA (AI-BOM) siguen siendo incipientes y aún están en fase de evolución. Si el proveedor no puede revelar ciertos detalles directamente, el contrato debería exigir una alternativa, como un depósito en garantía, una revisión de seguridad por parte de terceros o una divulgación por niveles bajo medidas de confidencialidad reforzadas.
2. Exigir un paquete de procedencia del modelo centrado en la ciberseguridad. El proveedor debe documentar el origen del modelo, el historial de entrenamiento y ajuste fino, la procedencia de los datos, el enfoque de validación, las pruebas de seguridad y las limitaciones conocidas. El contrato también debe incluir declaraciones relativas a los derechos sobre los datos, las licencias y los controles utilizados para proteger el modelo y los artefactos de datos contra la manipulación.
3. Convertir la transparencia en una obligación permanente en materia de ciberseguridad. Las listas de componentes de IA (AI-BOM) y los registros de procedencia deben actualizarse cuando el proveedor vuelva a entrenar el modelo, cambie conjuntos de datos significativos, sustituya componentes o modifique los procesos de actualización. El contrato debe exigir la notificación de los cambios significativos antes de que afecten a los sistemas de producción, especialmente cuando dichos cambios puedan afectar a la supervisión de la ciberseguridad, la exposición de datos, la gestión de vulnerabilidades o la respuesta ante incidentes.
4. Vincular la divulgación de información a la responsabilidad en materia de ciberseguridad. Los proveedores deben garantizar que la lista de componentes de IA y los registros de procedencia sean sustancialmente precisos y completos. Asimismo, deben notificar al fabricante la existencia de componentes comprometidos, dependencias no compatibles, problemas de integridad de los datos o vulnerabilidades que afecten a los componentes de IA, con derechos de auditoría y cooperación en caso de que una documentación inexacta contribuya a un fallo.
5. Requisitos de transparencia en materia de IA que se deben trasladar a los subcontratistas. Muchos proveedores de IA recurren a subcontratistas, proveedores de servicios en la nube, proveedores de etiquetado, proveedores de modelos base o componentes de código abierto. El contrato debe incluir obligaciones de traslado de requisitos para que el proveedor pueda obtener la información sobre los componentes, los datos y los modelos necesaria para mantener la lista de materiales de IA y el paquete de procedencia.
6. Utilizar la documentación para la gobernanza cibernética y la defendibilidad. Las listas de componentes de IA (AI-BOM) y los paquetes de procedencia deben integrarse en la revisión de las adquisiciones, las evaluaciones de riesgos de TI/TO, el análisis de incidentes, la gestión de vulnerabilidades, el cumplimiento normativo y los programas de gobernanza de la IA, incluidos aquellos alineados con la norma ISO/IEC 42001. Para los fabricantes, esta documentación forma parte, cada vez más, del expediente utilizado para demostrar prácticas de seguridad razonables, la supervisión de los proveedores, la preparación para la respuesta ante incidentes cibernéticos y la capacidad de análisis de las causas raíz. Sin embargo, el valor probatorio de estos expedientes depende de los requisitos contractuales que regulan la exactitud, la periodicidad de las actualizaciones, la conservación y la verificación independiente. La autocertificación del proveedor por sí sola puede no proporcionar un expediente verificable de forma independiente que sea suficiente para litigios de alto riesgo, inspecciones reguladoras o investigaciones forenses.
Mirando hacia el futuro
Los fabricantes que se limitan a preguntar si un proveedor de IA es «seguro» pueden pasar por alto la cuestión más importante en materia de ciberseguridad: ¿podemos identificar, verificar y demostrar qué hay dentro del sistema de IA y cómo ha llegado hasta allí? A medida que la CISA, el NIST, la norma ISO/IEC 42001, los requisitos de transparencia de la Ley de la UE sobre la IA y los reguladores internacionales avanzan hacia una mayor transparencia en la cadena de suministro de la IA, los fabricantes y los gestores de la cadena de suministro que incorporen en sus relaciones con los proveedores obligaciones relativas a la lista de materiales de IA y a la procedencia de los modelos estarán en mejores condiciones para detectar los riesgos cibernéticos, evaluar el rendimiento de los proveedores, conservar las pruebas de los incidentes y atribuir responsabilidades cuando los sistemas de IA fallen.
Los equipos de Foley especializados en fabricación, cadena de suministro, ciberseguridad e inteligencia artificial están a disposición de los fabricantes y los responsables de la cadena de suministro para ayudarles a estructurar la diligencia debida con respecto a los proveedores de inteligencia artificial, los requisitos de la lista de materiales de inteligencia artificial, las obligaciones relativas a la procedencia de los modelos y las cláusulas contractuales centradas en la ciberseguridad, adaptadas a los entornos de producción y de la cadena de suministro.
