Respuesta directa
En pocas palabras
Para proteger la cadena de suministro de un AI Sales Copilot, inventaría cada modelo, dataset, adaptador, paquete, imagen, herramienta y servicio; aprueba al proveedor y el uso concreto; fija versión y digest cuando sea posible; verifica procedencia, firma y evidencia del build; analiza el componente en aislamiento; y promueve exactamente el artefacto evaluado mediante una política de admisión. Mantén monitoreo, canary, rollback y una ruta de sustitución. Una descarga popular, una firma válida o un benchmark alto no demuestran por sí solos que el componente sea seguro ni adecuado.
Trata la cadena de suministro como una frontera de confianza completa
OWASP LLM03:2025 amplía la cadena tradicional de software para incluir modelos preentrenados, datasets, adaptadores, repositorios, plataformas de despliegue y servicios de terceros. Una falla puede entrar como dependencia vulnerable, cuenta de proveedor comprometida, modelo alterado, licencia incompatible, política de datos cambiada o infraestructura que ya no recibe mantenimiento. El impacto puede aparecer mucho después de la adquisición y afectar integridad, confidencialidad, disponibilidad o continuidad.
Supply chain y poisoning se cruzan, pero no son sinónimos. Poisoning se concentra en manipular datos, proceso o comportamiento; la cadena también cubre código ejecutable, paquetes, builders, credenciales, imágenes, términos y proveedores. Conserva el componente y la ruta exacta en cada hallazgo. Llamar poisoning a cualquier incidente oculta qué control debe corregirse y qué releases necesitan contención.
Dibuja el grafo antes de evaluar componentes aislados
Mapea código, lockfiles, imágenes, sistema operativo, librerías, parsers, tokenizers, runtimes de inferencia, drivers, modelos base, adaptadores, datasets, índices, prompts versionados, herramientas, APIs, plugins, acciones de CI, runners, registros, almacenamiento, identidad y observabilidad. Incluye desarrollo, evaluación, build, despliegue y operación: un componente que nunca llega al contenedor puede seguir comprometiendo el release desde el pipeline.
Relaciona cada pieza con propietario, proveedor, versión, canal, ambiente, privilegios, datos accesibles, releases y dependencias aguas arriba y abajo. Distingue lo declarado por el equipo, lo informado por el proveedor y lo observado durante build o runtime. El inventario no necesita fingir completitud; debe exponer cobertura, desconocidos y quién los resolverá.
Evalúa al proveedor y al componente para el uso previsto
Separa la evaluación de la empresa, el producto, la versión y el caso de uso. Revisa identidad legal, canal de soporte, prácticas de desarrollo y divulgación, control de acceso, historial de cambios, mantenimiento, incidentes, subproveedores, regiones, continuidad, portabilidad y salida. Después prueba el componente con los datos, idiomas, permisos y consecuencias reales del recorrido; una certificación corporativa no cubre automáticamente cada modelo o integración.
Define evidencia mínima antes de comprar o descargar: documentación de versión, model o data card cuando aplique, licencia, changelog, política de vulnerabilidades, procedencia disponible, resultados de evaluación y condiciones de uso. Marca cada afirmación como verificada, declarada o desconocida. Una comunidad grande, muchas descargas o un ranking alto son señales contextuales, no controles de seguridad.
Controla licencias, términos y tratamiento de datos como cambios técnicos
Registra licencias de software, modelos, pesos, datasets y contenido por versión. Revisa uso comercial, distribución, atribución, restricciones, derivados y compatibilidad entre componentes. Un archivo con una etiqueta de licencia no demuestra que quien lo publicó tenía derechos sobre todos sus datos o pesos. Conserva la revisión y cualquier condición que deba cumplirse en el producto, la documentación o la salida.
Para servicios externos, documenta qué entradas, salidas, feedback y telemetría conserva el proveedor; con qué finalidad, región, plazo y subprocesadores; y cómo se solicita devolución o eliminación. Trata un cambio de términos, política de privacidad, plan o configuración como un evento que puede reabrir la aprobación. La opción no training no demuestra por sí sola ausencia de logs, soporte, abuso, evaluación o retención.
Fija identidad, canal, versión y digest antes de descargar
Permite solo repositorios, registries y cuentas de proveedor aprobados. Verifica organización, propietario, dominio y mecanismo de publicación para reducir typosquatting, paquetes homónimos y cuentas imitadoras. Usa referencias inmutables, lockfiles y digests; evita tags como latest, stable o nombre-modelo para una decisión histórica. Un alias puede cambiar sin que el código de integración se modifique.
Descarga mediante un servicio con red limitada y registra URL, hora, identidad, tamaño, digest y resultado. Si existe firma o attestation, verifica la identidad y el issuer esperados, no solo la criptografía. Si el proveedor no expone una versión inmutable, registra el alias como mutable, conserva metadatos observables y aplica pruebas, monitoreo y fallback acordes a esa incertidumbre.
Abre modelos, datasets y paquetes dentro de una cuarentena
Trata cada artefacto externo como no confiable hasta completar admisión. Inspecciona formato, estructura, archivos inesperados, dependencias, scripts de instalación, macros, código remoto, tamaño y comportamiento del parser. Prefiere formatos que separen datos de ejecución cuando sea viable. No deserialices un modelo desconocido dentro de un proceso con secretos, credenciales cloud, red abierta o acceso de escritura al registro.
Ejecuta análisis estático, composición de software, detección de secretos, licencias, malware y pruebas de carga en un entorno desechable con CPU, memoria, tiempo, disco y egress limitados. Ningún escáner cubre por sí solo comportamiento oculto o una vulnerabilidad desconocida. Conserva el original, el informe y la decisión; no repaquetes silenciosamente el archivo y lo presentes con la identidad del proveedor.
| Criterio | Qué aporta | Qué no demuestra |
|---|---|---|
| Hash | Identifica bytes concretos | Seguridad, origen o finalidad |
| Firma | Atribuye una declaración a una identidad | Que la identidad estaba autorizada para ese uso |
| SBOM o AI/ML-BOM | Enumera componentes y relaciones declaradas | Completitud, explotabilidad o ausencia de componentes ocultos |
| Benchmark | Mide tareas dentro de una cobertura | Ausencia de backdoors, fuga o manipulación dirigida |
Mantén un AI/ML-BOM enlazado con vulnerabilidades y licencias
Genera un inventario versionado de modelos, datasets, software, servicios y relaciones para cada release. Enlaza la SBOM de código y contenedores, las cards de modelos y datos, las evaluaciones, licencias y proveedores mediante identificadores estables. Compara el BOM declarado con lo observado en build y runtime. Una lista plana no permite saber qué oportunidades, índices o servicios están expuestos cuando cambia una dependencia.
Conecta componentes con avisos de seguridad y fin de soporte, pero conserva contexto de alcanzabilidad y uso. La presencia de un CVE no demuestra explotación; la ausencia de un CVE no demuestra seguridad. Registra fuente, fecha, versión, análisis, prioridad, compensaciones y decisión. Cuando aparece una alerta, recorre el grafo para localizar releases activos y elige contener, actualizar, sustituir, aislar o aceptar temporalmente con vencimiento.
Verifica provenance y el proceso que produjo el artefacto
La procedencia útil une el digest del sujeto con repositorio, referencia, workflow, builder, parámetros y dependencias resueltas. SLSA organiza garantías crecientes sobre el proceso de build; no convierte una attestation en prueba universal de seguridad. Verifica firma, identidad, issuer, predicate, workflow y digest contra una política propia. Aceptar cualquier objeto firmado por la empresa sigue siendo una regla demasiado amplia.
Genera attestations desde un plano de control que observe el build, no desde el mismo script capaz de declarar cualquier resultado. Protege claves e identidades de workload, registra uso y prepara rotación y revocación. Relaciona provenance con el AI/ML-BOM y las evaluaciones del mismo release. La firma detecta ciertas sustituciones; no prueba calidad, licencia, ausencia de vulnerabilidades ni adecuación comercial.
Protege repositorios, builders y CI/CD contra sustitución
NIST SP 800-204D sitúa controles de cadena a lo largo del pipeline, desde código y build hasta paquete y despliegue. Protege ramas, revisiones, acciones reutilizables, runners, secretos, caches, registries, infraestructura como código y políticas. Fija acciones y herramientas por versión inmutable; limita quién puede modificar workflows; separa identidad de build, firma y despliegue; y evita que una pull request no confiable reciba secretos de producción.
Construye una vez y promueve el mismo digest entre ambientes. Si producción reconstruye desde el repositorio, el artefacto evaluado y el desplegado pueden diferir. El gate debe comprobar origen, digest, evidencia, evaluación, licencia, vulnerabilidades, aprobación y destino antes de promover. Prueba rutas de bypass: carga manual, tag mutable, administrador, cache, job de emergencia y registry alterno.
Evalúa modelos, adaptadores y datasets como componentes distintos
Un modelo base, un adaptador LoRA, un tokenizer, una plantilla y un dataset pueden provenir de autores y procesos distintos. Mantén identidades, versiones, licencias y pruebas separadas antes de combinarlos. Una evaluación publicada puede corresponder a otra configuración o estar optimizada para el benchmark. Ejecuta la misma suite independiente sobre el conjunto exacto que se pretende liberar y conserva baseline, segmentos y limitaciones.
Busca degradación, fuga, sesgo dirigido, backdoors, triggers, cambios de rechazo, herramientas inesperadas y diferencias por idioma o tenant. Prueba en aislamiento y sin efectos reales. Un resultado limpio reduce incertidumbre solo dentro de su cobertura. Cuando se fusionen modelos o adaptadores, el resultado es un artefacto nuevo: recibe otro digest, otra evaluación y otra decisión de admisión.
Gobierna APIs y SaaS aunque no puedas verificar sus bytes
Un endpoint administrado puede cambiar modelo, filtro, región o dependencia detrás del mismo nombre. Registra proveedor, producto, alias, región, plan, configuración, fecha y metadatos observables. Solicita avisos de cambio, documentación, soporte, compromisos de seguridad y exportación. Separa lo declarado por el proveedor de lo verificado por tu organización y no inventes un snapshot interno que la API no expone.
Compensa la falta de digest con pruebas sintéticas y funcionales periódicas, canarios, límites de datos, autorización externa, monitoreo de latencia y comportamiento, fallback y plan de salida. Reabre la evaluación ante cambio de términos, modelo, endpoint, región, subprocesador, precio, retención o control. La imposibilidad de inspeccionar el backend no elimina la responsabilidad de decidir qué datos y efectos puede alcanzar la integración.
Opera actualizaciones, fin de soporte y compromiso de proveedor
Define un dueño y una cadencia para avisos, versiones, vulnerabilidades, licencias, términos y end of life. No actualices automáticamente producción porque existe una versión nueva; tampoco congeles una dependencia vulnerable por miedo al cambio. Cada actualización material recibe diff, evaluación, aprobación, canary y rollback. Conserva una ventana realista para sustituir componentes que pierden mantenimiento o condiciones aceptables.
El runbook de compromiso debe bloquear nuevas descargas, congelar promoción, revocar identidades y secretos, localizar releases por BOM y lineage, aislar el componente, contactar al proveedor y decidir rollback o sustitución. Preserva artefactos, digests, attestations, accesos y decisiones. Rotar una clave no retira las imágenes o modelos ya desplegados; verifica runtime, caches, nodos, copias y dependencias derivadas.
Mide cobertura y prueba que los controles pueden fallar
Mide componentes de producción con versión y propietario, porcentaje identificado por digest, builds con provenance verificable, dependencias desconocidas, proveedores sin revisión vigente, componentes fuera de soporte, excepciones, tiempo para localizar exposición y tiempo para sustituir. Segmenta por tipo y criticidad. Un promedio alto puede ocultar que todos los modelos externos usan aliases mutables.
Ejecuta pruebas negativas con paquete homónimo, digest cambiado, firma de otra identidad, issuer incorrecto, workflow no autorizado, licencia ausente, benchmark incompleto, versión retirada y carga manual. Confirma que el gate bloquea, registra y escala sin filtrar secretos. Después ensaya una sustitución y rollback. Un control que siempre devuelve verde quizá nunca recibió una condición capaz de demostrar su eficacia.
Aplica la cadena al alcance verificable de Cerravi
OWASP LLM03 aporta escenarios para componentes, modelos, adaptadores, repositorios, licencias y proveedores. NIST SP 800-218A adapta prácticas de desarrollo seguro al ciclo de modelos y sistemas generativos; NIST SP 800-204D organiza controles de cadena dentro de CI/CD; y SLSA describe garantías del proceso de build. Son referencias para diseñar y comprobar controles, no certificaciones de Cerravi ni de un proveedor concreto.
En Cerravi, Copilot organiza contexto y propone borradores para revisión humana; los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios conocidos, y un importe faltante se marca para confirmación. Las monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales sin probar identidad, aceptación, firma, pago o intención. Forecast usa reglas transparentes del CRM y no es un modelo predictivo entrenado. Esta guía no afirma que Cerravi descargue modelos abiertos, use adaptadores LoRA o pueda verificar versiones internas que un proveedor no publica.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre supply chain y data o model poisoning?
Poisoning busca alterar datos, proceso o comportamiento. Supply chain incluye ese riesgo cuando llega por un tercero, pero también cubre paquetes vulnerables, builders comprometidos, archivos ejecutables, cuentas de proveedor, licencias, términos, infraestructura y servicios sin mantenimiento. El mismo incidente puede requerir controles de ambas categorías.
¿Es seguro un modelo si proviene de un repositorio conocido?
No necesariamente. Verifica la cuenta y el canal, fija versión y digest, revisa licencia y procedencia, abre el archivo en aislamiento y evalúa el artefacto exacto para tu uso. Popularidad, descargas, reputación y benchmarks aportan contexto, pero no demuestran ausencia de vulnerabilidades, backdoors o sustitución.
¿Una firma válida demuestra que un artefacto de IA es confiable?
Demuestra que una identidad firmó una declaración o contenido si la verificación es correcta. Todavía debes comprobar identidad, issuer, digest, workflow y política, y evaluar seguridad, licencia, calidad y uso. Una firma válida de una identidad no autorizada para ese release debe rechazarse.
¿Cómo se controla una API cuyo modelo cambia detrás del mismo alias?
Registra alias, proveedor, región, configuración, fecha y metadatos observables; solicita avisos de cambio; ejecuta pruebas y canarios periódicos; limita datos y efectos; y conserva fallback y plan de salida. No afirmes que verificas un snapshot interno si el proveedor no expone una identidad inmutable.
¿Qué evidencia mínima debe pedirse a un proveedor de IA?
Depende del riesgo, pero suele incluir identidad y versión del producto, documentación de uso y límites, licencia y términos, tratamiento de datos, regiones y subproveedores, política de vulnerabilidades, changelog, procedencia disponible, evaluaciones, soporte, continuidad, exportación y salida. Separa siempre lo declarado de lo comprobado.