Riesgos y limitaciones

Cadena de suministro del modelo (model supply chain)

La cadena de suministro del modelo es el conjunto de elementos —datos de entrenamiento, modelo base, librerías, plugins, herramientas conectadas, infraestructura— que entran en producir y operar un sistema de IA. Cada eslabón es un vector potencial de ataque, sesgo o cumplimiento, y exige verificación específica.

Por Ana María González Actualizado: 9 de mayo de 2026

Definición rápida

Respuesta directa

Explicación ampliada

Cuando una empresa despliega un asistente IA, parece estar usando un solo producto, pero realmente está heredando confianza de una cadena larga: un modelo entrenado por otra empresa con datos de muchas fuentes; librerías y frameworks open source mantenidos por terceros; un proveedor de infraestructura cloud; plugins, herramientas y bases vectoriales con sus propios proveedores; conectores a sistemas internos. La equivalencia con software clásico es la cadena de suministro de software (SBOM, vulnerabilidades en dependencias, ataques tipo SolarWinds o XZ Utils). En IA aparecen vectores propios: dataset poisoning durante el entrenamiento del modelo base; modelos publicados en Hugging Face con backdoors ocultas; plugins de un agente que actúan como caballo de Troya; modelos derivados (fine-tunings) de los que no se sabe la procedencia exacta. Las prácticas de mitigación van consolidándose: SBOM extendido para IA (AI BOM), provenance tracking (¿de dónde viene este modelo, este peso, este dato?), firmas digitales de modelos, escaneo de seguridad de modelos abiertos antes de uso (Garak, ProtectAI), restricción a registros de modelos verificados.

Por qué importa para tu empresa

Aplicación práctica

Para una empresa, la cadena de suministro del modelo importa porque estás expuesto a todo lo que el modelo expone, no solo a lo tuyo. Un modelo open source con una vulnerabilidad heredada del código de inferencia compromete tu sistema; un dataset de entrenamiento con sesgos heredados se traduce en sesgos de tu asistente. La práctica recomendada: usar modelos de proveedores con políticas claras (cards modelos, datos de entrenamiento documentados); descargar modelos abiertos solo de fuentes oficiales (Hugging Face oficial del autor); auditar plugins y herramientas conectadas como auditarías cualquier dependencia de software; documentar tu propia cadena para que en una auditoría puedas explicar de dónde viene cada pieza.

Ejemplo concreto

Caso real

Una empresa de servicios profesionales descubrió en febrero de 2026 que el modelo open source que usaban (un fine-tune popular en Hugging Face) había sido entrenado con un dataset que incluía datos de un foro con sesgos no detectados al inicio. El asistente, en preguntas no neutras sobre nacionalidades o regiones, daba respuestas con tono ligeramente prejuicioso. Tras la detección (un cliente lo reportó), migraron a otro modelo abierto con cards de datos más cuidadas, montaron un proceso de evaluación de sesgos antes de adoptar nuevos modelos, y publicaron internamente lista de modelos aprobados con firma del responsable de IA. El incidente costó disculpas a un cliente y dos semanas de trabajo de remediación; el aprendizaje quedó.