Por qué el riesgo de la cadena de suministro de IA ya superó el modelo SBOM

Durante años, las listas de materiales de software se basaron en supuestos que, por lo general, se cumplían. Las dependencias eran estáticas. Los ciclos de lanzamiento eran predecibles. Al hacer un inventario de lo que se incorporaba a una aplicación durante la compilación, los equipos podían tomar decisiones fundamentadas sobre los riesgos más adelante. Ese enfoque funcionaba porque el software tradicional se comportaba de manera acotada y predecible. La IA rompe esos supuestos casi de inmediato.

Las cadenas de suministro de IA cambian rápidamente. De la noche a la mañana aparecen nuevos modelos de código abierto. Los frameworks de agentes evolucionan en repositorios públicos más rápido de lo que la mayoría de los equipos de seguridad puede seguir. Los servidores MCP, los prompts, los conjuntos de datos y las herramientas de orquestación cambian constantemente a medida que los desarrolladores experimentan. El ritmo no solo es más rápido: es fundamentalmente distinto.

Además, los componentes de IA no son elementos pasivos. Modifican activamente el sistema mientras se ejecuta. Los modelos pueden incorporar nuevas herramientas durante la ejecución. Los agentes generan prompts, encadenan acciones e invocan servicios que nunca se definieron en el código original. Los componentes crean nuevas relaciones y rutas de ejecución sobre la marcha, lo que significa que la cadena de suministro ya no queda definida durante la compilación.

Aquí es donde el modelo SBOM empieza a fallar. Una lista estática de componentes no puede representar un sistema que cambia mientras funciona. Los equipos de seguridad necesitan más que una instantánea de lo que existía al momento de hacer el commit. Necesitan visibilidad sobre cómo interactúan los componentes de IA, qué invocan y cómo evolucionan esas relaciones.

Esa necesidad dio origen a la idea de una lista de materiales de IA. Pero el término puede ser engañoso. Una AIBOM no es una lista de verificación. Es un mapa dinámico de componentes, comportamientos y conexiones que refleja cómo funcionan realmente los sistemas de IA. Los artefactos estáticos ya no bastan cuando el propio software está diseñado para cambiar.

El problema crece: la mitad de la cadena de suministro de IA está fuera del repositorio

Cuando aceptamos que las cadenas de suministro de IA son dinámicas, aparece otro problema. Lo que hay en el repositorio es solo una parte del panorama. Una proporción cada vez mayor de la cadena de suministro de IA nunca llega al control de versiones. Se ejecuta en las máquinas de los desarrolladores.

Los desarrolladores instalan y prueban herramientas de IA localmente, muchas veces a un ritmo que supera la capacidad de los equipos de seguridad para darles seguimiento. En una gran empresa de medios, los equipos configuraron servidores MCP locales para trabajar más rápido y descubrieron que seguridad no tenía visibilidad sobre dónde estaban esos servidores ni a qué accedían. En una firma de inversión global, los desarrolladores probaron agentes de IA locales y herramientas de automatización con amplio acceso a los sistemas internos, sin revisión previa. En otra empresa, se prohibieron formalmente las herramientas MCP locales, pero los desarrolladores siguieron usándolas porque les facilitaban el trabajo.

Este comportamiento no es malintencionado; es práctico. Los desarrolladores usan las herramientas que les ayudan a resolver problemas. El riesgo aparece cuando esas herramientas funcionan fuera de los controles de los que dependen los equipos de seguridad.

Los agentes de IA y servidores MCP locales suelen tener acceso directo a pipelines, credenciales y servicios internos. Los datos pueden circular sin documentación ni supervisión. Como estos componentes nunca pasan por los flujos de trabajo de CI/CD, SAST o SCA, su comportamiento permanece prácticamente oculto, aunque estén a solo una laptop de distancia de producción.

Este cambio convirtió la TI en la sombra en algo más complejo. La TI en la sombra se refería a SaaS no aprobados. La IA en la sombra incluye modelos no aprobados, herramientas locales, servidores MCP, agentes y frameworks experimentales que se ejecutan en los equipos de los desarrolladores. Es local, cambia rápidamente y depende de las personas, no del área de compras.

El resultado es una brecha de visibilidad cada vez mayor. Incluso la vista más completa del repositorio deja fuera los componentes de IA que nunca llegan a él. A medida que se acelera el desarrollo de IA, las máquinas de los desarrolladores se han convertido en una de las partes menos conocidas de la cadena de suministro de IA.

Por qué la AI-BOM no resuelve todo (aunque es un buen comienzo)

Una lista de materiales de IA aporta la estructura que tanto necesitan los sistemas de IA modernos. Ofrece visibilidad sobre los modelos referenciados en el código fuente, los frameworks de agentes en los repositorios, las configuraciones de servidores MCP, los prompts, los conjuntos de datos y las dependencias declaradas. Esta información es valiosa para los componentes de IA que se confirman, revisan y versionan.

Esa visibilidad establece una base. Permite a los equipos de seguridad pasar de las suposiciones a los hechos y empezar a gobernar el uso de la IA con confianza. Dentro del control de versiones, la AI-BOM ofrece una visión clara de lo que existe y de cómo se conectan los componentes. La limitación está en lo que nunca llega al repositorio.

La AI-BOM no puede detectar las cadenas de herramientas MCP locales en las máquinas de los desarrolladores, los entornos de ejecución de agentes de IA usados para pruebas, los clientes de LLM instalados en los equipos ni las herramientas de CLI y los frameworks agénticos que los desarrolladores prueban localmente. Muchas de estas herramientas nunca llegan a GitHub.

Esto crea un punto ciego. La visibilidad basada en el repositorio refleja la intención, no todo lo que realmente se ejecuta durante el desarrollo. Cuando las herramientas de IA se extienden más allá de CI/CD y de la cobertura de los análisis tradicionales hasta las laptops, quedan fuera del alcance de AIBOM, aunque esos componentes suelen tener acceso a datos confidenciales y sistemas internos.

La AIBOM por sí sola no resuelve el problema. Es un punto de partida necesario, pero solo cuenta una parte de la historia. Cuando las herramientas de IA operan fuera del repositorio, también queda fuera una parte importante del riesgo.

La solución: unificar la AI-BOM y la visibilidad de los equipos de los desarrolladores

Cerrar la brecha entre los repositorios y las máquinas de los desarrolladores no exige agregar más fricción. Requiere un modelo de visibilidad distinto. En lugar de agregar agentes pesados para los equipos o imponer nuevos flujos de trabajo, el enfoque emergente se centra en correlacionar la información existente entre entornos.

La detección de AIBOM basada en repositorios sigue destacándose en su función principal: identificar modelos, frameworks de agentes, prompts, conjuntos de datos y configuraciones en el control de versiones. Los análisis ligeros en las máquinas de los desarrolladores la complementan al detectar servidores MCP locales, entornos de ejecución de agentes y herramientas de IA tal como se usan realmente. Estos análisis tienen un propósito específico y un alcance acotado; no son una supervisión tradicional de equipos. Juntos, ofrecen una visión coherente de la cadena de suministro de IA tal como existe en la práctica.

Esta visión unificada responde a lo que piden los clientes. Algunos quieren rastrear los mismos frameworks MCP en repositorios y entornos locales. Otros quieren un solo lugar donde responder una pregunta sencilla: ¿qué componentes de IA se usan en alguna parte de la organización? Muchos quieren medidas de protección que guíen el uso seguro sin prohibir herramientas ni interrumpir los flujos de trabajo de los desarrolladores.

La fortaleza de este enfoque radica en que la visibilidad se convierte en el control. Cuando los equipos pueden ver qué componentes existen, cómo se conectan y dónde se ejecutan, la gobernanza se vuelve práctica. Las políticas pueden centrarse en herramientas aprobadas, configuraciones seguras y coherencia entre versiones, en lugar de imponer restricciones que los desarrolladores buscan eludir.

La gestión de la postura de seguridad de la IA ofrece la capa unificadora. Reúne en una sola vista la información de los repositorios, las relaciones entre dependencias, la detección de MCP y agentes locales, y las políticas de gobernanza. El resultado no es un control más estricto por la fuerza, sino un control más eficaz gracias al entendimiento, que permite a las organizaciones gobernar la IA de manera responsable a medida que evoluciona.

La propuesta de valor combinada: la única visión completa de tu cadena de suministro de IA

Cuando la visibilidad abarca tanto los repositorios como las máquinas de los desarrolladores, por fin se entiende la cadena de suministro de IA. El código por sí solo nunca cuenta toda la historia. La experimentación local por sí sola no muestra cómo se formalizan y distribuyen los sistemas. Al combinar ambas perspectivas se obtiene una imagen completa de cómo se crea, prueba y usa realmente la IA en toda la organización.

La mayoría de las herramientas de seguridad solo ve una parte del panorama. Algunas se centran en lo que se confirma en el control de versiones. Otras analizan señales aisladas del entorno de ejecución o la actividad de los equipos. La gestión de la postura de seguridad de la IA conecta esas perspectivas. Entiende lo que existe en el código y lo que se ejecuta en los equipos de los desarrolladores, y correlaciona ambos elementos en un modelo único y coherente. Esa perspectiva combinada transforma señales fragmentadas en información útil para actuar.

Esto importa porque las restricciones han demostrado ser un control ineficaz. Prohibir los servidores MCP no impide que se usen. Prohibir los agentes locales solo hace que la experimentación sea menos visible. Los desarrolladores seguirán adoptando herramientas que les permitan trabajar más rápido. La diferencia entre un riesgo sin gestionar y una adopción controlada es la visibilidad. Cuando los equipos pueden ver qué componentes de IA se usan, dónde se ejecutan y cómo interactúan, pueden orientar el comportamiento mediante políticas y configuraciones, en lugar de prohibiciones.

Mantenerse a la vanguardia de estos cambios exige estar al tanto de las tendencias emergentes. El ecosistema de IA no se detiene. Aparecen nuevos frameworks de agentes con regularidad. Los servidores MCP evolucionan. Los modelos de código abierto cambian. Las herramientas de orquestación, los cargadores de conjuntos de datos y las bibliotecas de automatización amplían la superficie de riesgo cada mes. Los clientes confían en Snyk para seguir esa evolución y convertirla en detección e información contextual sobre las que puedan actuar.

Para completar el panorama, detectar repositorios y equipos de desarrollo revela qué está expuesto, pero Snyk Code cierra el ciclo al mostrar cómo se generaron esas exposiciones. Las organizaciones también necesitan aprovechar soluciones SAST para vincular los hallazgos del entorno de ejecución y de los activos con las rutas de código vulnerables que los originaron. Así, los equipos pueden pasar de una detección fragmentada a una corrección coordinada, donde las correcciones en el código reducen automáticamente los riesgos posteriores en los equipos y los entornos de repositorios relacionados con sistemas impulsados por IA.

Esta base de investigación es lo que mantiene completa la perspectiva con el paso del tiempo. A medida que la cadena de suministro de IA crece y cambia, la capacidad de reconocer nuevos componentes y entender su función se vuelve tan importante como ver lo que ya existe. El resultado es una comprensión dinámica del riesgo de IA que sigue el ritmo del desarrollo en la práctica.

AIBOM + visibilidad de los equipos de desarrollo = la nueva base de seguridad de la IA

Cuando la visibilidad abarca tanto los repositorios como las máquinas de los desarrolladores, por fin se puede entender la cadena de suministro de IA. El código muestra lo que los equipos tienen previsto distribuir. Los entornos de desarrollo revelan cómo se explora, prueba y usa la IA. Juntos, aportan el contexto que los equipos de seguridad necesitan para pasar de las conjeturas reactivas a una gobernanza informada.

Esto importa porque las restricciones no son escalables. Bloquear los servidores MCP o los agentes locales solo hace que la experimentación sea menos visible. Los desarrolladores seguirán adoptando herramientas que les permitan trabajar más rápido. La visibilidad es lo que marca la diferencia entre un riesgo sin gestionar y una adopción controlada. Cuando los equipos pueden ver qué componentes de IA se usan, dónde se ejecutan y cómo interactúan, pueden orientar el comportamiento mediante políticas y configuraciones, sin interrumpir el trabajo.

Mantener una visión precisa exige estar al tanto de los cambios de forma continua. El ecosistema de IA evoluciona rápidamente, con la aparición constante de nuevos frameworks de agentes, servidores MCP, modelos y herramientas. La capacidad de reconocer esos componentes y entender su función es lo que convierte la visibilidad en una postura de seguridad duradera.

La cadena de suministro de IA evoluciona más rápido de lo que pueden seguirle el ritmo los modelos de seguridad tradicionales. Descubre cómo la visibilidad continua te ayuda a mantenerte a la vanguardia sin agregar fricción.