La procedencia de modelos de IA: un estándar técnico para auditar la cadena de suministro

Introducción

En producción, los equipos de DevOps y SRE suelen trabajar con modelos de IA que no son cajas negras estáticas: se descargan de Hugging Face, se ajustan en entornos locales, se cuantifican para reducir costo computacional o se fusionan con otros modelos para especializar capacidades. Pero cuando un incidente de seguridad exige rastrear el origen de un modelo —por ejemplo, una vulnerabilidad CVE-2024-37012 en un LLM— la respuesta más común es «es el modelo X versión 1.2, pero no sabemos de dónde salió exactamente».

Este problema no es trivial. Según el OWASP Top 10 para aplicaciones con LLM (2025), el suministro deficiente de procedencia de modelos («weak model provenance») ocupa el tercer puesto en riesgos críticos, citando que «no hay garantías sobre el origen del modelo». La falta de un estándar técnico compartido genera:

• Falsos positivos en auditorías de licencias: un modelo de arquitectura similar pero entrenado desde cero podría ser erroneamente marcado como derivado de otro.
• Dificultad para priorizar parches: si un modelo heredó una vulnerabilidad pero su relación con el original no está documentada, los equipos de seguridad no pueden aplicar mitigaciones basadas en CVEs.
• Incumplimiento normativo: regulaciones como el EU AI Act exigen trazabilidad de modelos en cadenas de suministro críticas (ej: salud, finanzas).

El Model Provenance Constitution (disponible en GitHub de Cisco AI Defense) propone un marco técnico para definir derivación en pesos (no en metadata), resolviendo ambigüedades comunes en la industria.

Qué ocurrió

El problema central es la inconsistencia en la definición de «derivación» entre modelos. Por ejemplo:

• Licenciamiento: PyTorch permite redistribuir pesos modificados sin licencia original, pero Hugging Face requiere atribuir derivados. Dos equipos pueden llegar a conclusiones opuestas sobre el mismo modelo.
• Vulnerabilidades: Si un modelo A tiene una CVE y otro B usa sus pesos como inicialización (transfer learning), ¿B hereda la vulnerabilidad? Depende de si se considera «derivado».
• Cumplimiento: Regulaciones como el NIST AI Risk Management Framework exigen documentar cadenas de suministro, pero no definen cómo hacerlo.

El Model Provenance Constitution aborda esto con:

1. Cinco condiciones explícitas que definen cuándo dos modelos comparten procedencia (ej: «los pesos del modelo B son una transformación directa de A mediante cuantización»).
2. Nueve mecanismos que enumeran formas prácticas de derivación (distilación, fusión, cuantización, etc.).
3. Ocho exclusiones que evitan falsos positivos (ej: misma arquitectura ≠ derivación, mismo tokenizer ≠ derivación).

# Modelo A: checkpoint base (ej: meta-llama/llama-3-8b)
# Modelo B: versión cuantificada (FP16) del mismo checkpoint
# Modelo C: fine-tuned de A con nuevos datos
# Modelo D: fusión de A y otro modelo E (ej: mezcla de expertos)

# Según el Constitution:
# - A y B → PROCEDENCIA (mecanismo: cuantización)
# - A y C → PROCEDENCIA (mecanismo: fine-tuning)
# - A y D → PROCEDENCIA (mecanismo: fusión)
# - A y E → INDEPENDIENTE (misma arquitectura pero pesos distintos)

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

Los pipelines de CI/CD con modelos suelen tratar a estos como artefactos binarios, pero la procedencia no es metadata: es la relación causal entre pesos. Impactos concretos:

• Falsas alarmas en despliegues: Un modelo cuantificado podría ser bloqueado por una política que prohíbe derivados de un modelo vulnerable, aunque no lo sea.
• Inconsistencias en rollbacks: Si un modelo A se actualiza a A’ y luego se revierte, pero A’ tenía pesos cuantificados, ¿se revierte correctamente? El Constitution exige documentar derivaciones para evitar inconsistencias.
• Costos en infraestructura: Modelos fusionados (ej: MoE) pueden requerir recursos distintos. Sin procedencia clara, los equipos no optimizan clusters en AWS EKS o Redis para inferencia.

• Según MITRE ATLAS, el 37% de los compromisos en cadenas de suministro de IA (técnica AML.T0010) comienzan con la ocultación de derivaciones (ej: renombrar tokens, modificar metadata).
• El Cisco AI Security and Safety Framework clasifica modelos de terceros bajo OB-009 (Compromiso de Cadena de Suministro), con un impacto estimado del 22% en incidentes reportados en 2024 (fuente: Cisco Blog).

Para equipos de Seguridad

El Model Provenance Constitution alinea con estándares existentes:

• OWASP LLM Top 10 (2025): Recomienda «documentar derivaciones en pesos» como control para el riesgo LLM03 (Cadena de Suministro).
• NIST AI RMF: Exige trazabilidad de modelos en sistemas críticos (ej: salud). El Constitution cumple con el control «Identify – AI-01» al exigir evidencia en pesos, no en metadata.
• MITRE ATT&CK para IA: Cubre vectores como AITech-9.2 (Evasión de Detección), donde actores ocultan derivaciones mediante tokenizer substitution o chained modifications.

Un equipo despliega un modelo B que usa pesos cuantificados de A (mecanismo válido según el Constitution), pero un auditor externo lo marca como derivado sin licencia. Sin procedencia documentada, el equipo debe decidir entre:

1. Parchar A (riesgo: downtime en producción).
2. Excluir B (riesgo: pérdida de funcionalidad).
3. Negociar licencia (riesgo: costos legales).

Detalles técnicos

Definición central: Derivación en pesos

El Model Provenance Constitution exige evidencia en los pesos, no en:

• Arquitectura (ej: misma estructura Transformer).
• Tokenizer (ej: vocabulario compartido).
• Benchmarks (ej: misma precisión en MMLU).
• Metadata (ej: nombre del modelo, fecha de creación).

1. Transformación directa: Los pesos de B son una función determinista de A (ej: cuantización, pruning).

1. Distilación: B aprende de A mediante un proceso de entrenamiento supervisado.

1. Fusión: B combina parámetros de A con otros modelos (ej: MoE, merging).

1. Herencia de inicialización: B usa pesos de A como punto de partida para fine-tuning.

• Misma arquitectura (ej: dos Llama-3-8b independientes).
• Mismo tokenizer (ej: ambos usan el vocabulario de Llama-3).
• Similar rendimiento en benchmarks (ej: ambos alcanzan 78% en MMLU).
• Misma licencia (ej: ambos modelos son MIT License).

Adversarial: Ocultación de derivaciones

El Constitution responde a técnicas como:

• Metadata rewriting: Cambiar el model_card.json para ocultar el origen.
• Tokenizer substitution: Usar un tokenizer distinto al original para romper trazas.
• Chained modifications: Aplicar transformaciones no lineales (ej: rotación de pesos) para dificultar el rastreo.

• Model Provenance Kit (Cisco): Extrae fingerprints de pesos en CPU, resolviendo matches en <50ms.
• Hashing de pesos: Comparar hashes criptográficos (SHA-256) de tensores clave.

# Descargar Model Provenance Kit
git clone https://github.com/cisco-ai-defense/model-provenance-kit.git
cd model-provenance-kit

# Extraer fingerprint de dos modelos
python fingerprint.py --model-a ./modelos/llama-3-8b --model-b ./modelos/llama-3-8b-fp16

# Salida:
# Model A (SHA256: 3a7b...) y Model B (SHA256: 3a7b...) → PROCEDENCIA (mecanismo: quantización)

Integración con frameworks existentes

El Constitution se alinea con:

• SLSA (Supply-chain Levels for Software Artifacts): Nivel SLSA 3 exige evidencia de procedencia en artefactos. El Constitution cumple con el control «Provenance».
• Sigstore: Para firmar modelos con procedencia, usando el estándar DSSE (Digital Signature for Software Artifacts).
• SPDX (Software Package Data Exchange): Para documentar derivaciones en SBOMs.

• Model Provenance Kit v1.2.0 (lanzado en mayo 2024) ya incluye soporte para MoE y federated learning.
• Frameworks como LangChain v0.1.14 y LlamaIndex v0.10.0 permiten integrar fingerprints en pipelines.

Qué deberían hacer los administradores y equipos técnicos

Pasos inmediatos (para equipos con modelos en producción)

1. Auditar modelos actuales con Model Provenance Kit

# Instalar dependencias (requiere Python 3.10+)
pip install model-provenance-kit torch transformers

# Generar fingerprint de un modelo descargado
python -m model_provenance.fingerprint \
  --model-path ./modelos/mi-modelo \
  --output ./fingerprints/mi-modelo.json

• Modelos cuantificados: Verificar si su fingerprint coincide con el original (ej: Llama-3-8b-fp16 vs Llama-3-8b).
• Fine-tunings: Comparar el modelo ajustado con el base (ej: bert-base-uncased vs bert-imdb).
• Fusiones: Documentar modelos fusionados (ej: mezcla de dos LoRA).

2. Actualizar pipelines de CI/CD para incluir procedencia

name: Auditar procedencia de modelos
on: [push]

jobs:
  provenance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Instalar Model Provenance Kit
        run: pip install model-provenance-kit
      - name: Generar fingerprint
        run: |
          python -m model_provenance.fingerprint \
            --model-path ./modelos/mi-modelo \
            --output ./fingerprints/provenance.json
      - name: Subir fingerprint a Artifact Registry
        uses: actions/upload-artifact@v3
        with:
          name: provenance-fingerprint
          path: ./fingerprints/

• Bloquear modelos sin fingerprint: Usar herramientas como Cosign (para firmar modelos con procedencia) en pipelines.
• Validar en despliegue: Verificar que el fingerprint del modelo desplegado coincida con el registrado en SBOM.

3. Documentar derivaciones en SBOMs

{
  "SPDXID": "SPDXRef-DOCUMENT-1",
  "name": "mi-modelo-fusionado",
  "hasFiles": [
    {
      "fileName": "./modelos/mi-modelo-fusionado.safetensors",
      "SPDXID": "SPDXRef-MODEL-1",
      "licenseConcluded": "MIT",
      "provenance": {
        "derivedFrom": ["SPDXRef-MODEL-A", "SPDXRef-MODEL-B"],
        "mechanism": "merge",
        "evidence": "fingerprint-sha256"
      }
    }
  ]
}

4. Configurar Redis para cachear fingerprints

Si usas Redis como cache de modelos (ej: para evitar recomputar embeddings), almacenar fingerprints junto a los modelos:

# Usar Redis con módulo RedisJSON
redis-cli --raw <<EOF
JSON.SET modelo:llama-3-8b-fp16 '{
  "fingerprint": "3a7b...",
  "derived_from": "llama-3-8b",
  "mechanism": "quantization",
  "ttl": 86400  # 24 horas
}'
EOF

• Reducción de latencia: 30% en búsquedas de modelos en clusters de Kubernetes.
• Auditoría en tiempo real: Equipos de seguridad pueden consultar derivaciones sin acceder a los modelos originales.

Conclusión

El Model Provenance Constitution no es solo un estándar más: es un prerequisito técnico para operar modelos de IA en entornos empresariales. Su enfoque en derivación en pesos —no en metadata— resuelve ambigüedades que generan riesgos legales, de seguridad y operativos.

1. Implementar Model Provenance Kit en pipelines de CI/CD.
2. Documentar derivaciones en SBOMs y firmar modelos con Sigstore.
3. Auditar modelos existentes con fingerprints, especialmente en entornos cloud (AWS SageMaker, GCP Vertex AI).

FIN