De SBOM a AI-BOM: repensar la visibilidad en los sistemas nativos de IA

Durante años, la lista de materiales de software ha sido una base confiable para la gobernanza. Permitía a los equipos comprender qué incluía una aplicación, evaluar los riesgos y cumplir con las crecientes expectativas de cumplimiento normativo. Sin embargo, a medida que el desarrollo de software avanza hacia sistemas nativos de IA, esa base comienza a desmoronarse.

Aquí entra en juego la lista de materiales de inteligencia artificial. Un AI-BOM asigna los componentes nativos de IA que ahora dan forma a las aplicaciones modernas, abarcando repositorios, pipelines y sistemas en ejecución. Los modelos, agentes, prompts, conjuntos de datos y servicios de soporte forman parte del panorama. Mientras que el SBOM es la base de la gobernanza del software, el AI-BOM se perfila como la columna vertebral de la seguridad nativa de IA.

Esta guía analiza por qué el enfoque basado en SBOM ya no es aplicable en un ecosistema impulsado por IA, donde los componentes cambian con frecuencia y el comportamiento se define en tiempo de ejecución, no durante el proceso de compilación. Explica por qué las organizaciones están recurriendo al AI-BOM como una capacidad fundamental y por qué la visibilidad es el primer requisito y el más urgente. En un mundo de herramientas que evolucionan rápidamente y de Shadow AI generalizada, comprender qué existe es el punto de partida para todo lo demás.

Por qué el enfoque basado en SBOM falla en la era de la IA

Para entender por qué el AI-BOM se ha vuelto esencial, conviene empezar por lo que ya no funciona. Las suposiciones que dieron forma a los SBOM se basaban en un mundo de software donde los componentes eran finitos, las dependencias conocidas y los cambios ocurrían a un ritmo medido. Los sistemas nativos de IA operan en condiciones muy distintas. Antes de analizar cómo se están adaptando las organizaciones, vale la pena considerar por qué las suposiciones habituales de la era del SBOM dejan de cumplirse en la era de la IA.

Los componentes de IA cambian constantemente

Los sistemas nativos de IA se caracterizan por el cambio constante. Sus componentes no permanecen estáticos el tiempo suficiente como para tratarlos como dependencias tradicionales, y esa volatilidad ahora es la norma, no la excepción.

Los modelos se actualizan semanalmente, a veces con mayor frecuencia, a medida que se lanzan nuevas capacidades y optimizaciones. Los frameworks de agentes evolucionan con la misma rapidez, con nuevas abstracciones, herramientas y patrones de ejecución que aparecen en repositorios públicos. Se ponen en marcha servidores MCP para ofrecer nuevas herramientas o flujos de trabajo, a menudo en respuesta a necesidades inmediatas de desarrollo, en lugar de planes a largo plazo. Los prompts, que cada vez funcionan más como lógica ejecutable, se editan y perfeccionan continuamente. Los conjuntos de datos cambian a medida que se agregan, filtran o reemplazan datos nuevos, lo que altera el comportamiento de los modelos sin modificar el código circundante.

Estos componentes no tienen versiones fijadas como las bibliotecas. No están centralizados en un único repositorio. Además, los desarrolladores pueden incorporarlos individualmente con muy poca dificultad. Tratarlos como dependencias estáticas genera puntos ciegos casi de inmediato.

En un entorno nativo de IA, la gobernanza debe tener en cuenta componentes fluidos, descentralizados y en constante movimiento.

El problema central es la visibilidad

Para la mayoría de los líderes de seguridad, el desafío no consiste en comprender cada decisión que podría tomar un sistema de IA. Los CISO no buscan analizar el comportamiento de los agentes al nivel de cada prompt o resultado. Lo que necesitan primero es algo mucho más básico: entender qué existe.

Quieren saber qué agentes, modelos y servidores MCP se usan realmente en toda la organización. Quieren entender qué herramientas o flujos de trabajo ofrecen esos componentes y a qué sistemas externos pueden acceder. Necesitan conocer los conjuntos de datos y prompts que dan forma al comportamiento, porque esas entradas suelen ser tan importantes como el código.

Sin esta visibilidad, es imposible evaluar los riesgos, establecer políticas o responder eficazmente cuando algo sale mal. Los SBOM tradicionales nunca se diseñaron para ofrecer este nivel de información. Capturan dependencias estáticas en un momento determinado, no los componentes activos y cambiantes que definen los sistemas nativos de IA. Como resultado, los equipos de seguridad no cuentan con la visibilidad que necesitan para gobernar la IA de manera eficaz.

Lo que nos dicen los líderes de seguridad

La brecha de visibilidad ya no es teórica. Aparece una y otra vez en conversaciones con líderes de seguridad que intentan aplicar los controles existentes a un panorama de IA en constante evolución.

Proliferación de frameworks

Para muchas grandes organizaciones, el desafío comienza con el volumen. Una empresa describió un flujo constante de nuevos frameworks de agentes, herramientas de orquestación, paquetes de modelos y servidores MCP en todos sus equipos de desarrollo. Los desarrolladores los adoptaban rápidamente para avanzar más rápido. Los equipos de gobernanza no podían seguirles el ritmo.

Las iniciativas de seguridad y cumplimiento normativo se volvieron reactivas. Para cuando se revisaba un framework, ya había aparecido otro. El problema no era la resistencia a la innovación, sino la falta de visibilidad clara sobre lo que existía.

Para esta organización, el AI-BOM se volvió esencial. Ofreció una forma confiable de hacer un seguimiento de los componentes de IA en todos los repositorios y establecer la base necesaria para hacer posible la gobernanza mientras el ecosistema seguía cambiando.

El AI-BOM parece incipiente, pero es fundamental.

Otra organización describió su enfoque con más cautela, pero con la misma urgencia. Admitieron que el AI-BOM todavía parece incipiente. Están surgiendo estándares. Las mejores prácticas aún no están definidas. Aun así, lo consideran inevitable.

Los componentes de IA han dejado de ser herramientas experimentales y se han convertido en dependencias importantes. Los modelos, agentes y servicios de soporte ahora desempeñan un papel directo en el comportamiento de las aplicaciones y el procesamiento de los datos. Al mismo tiempo, los organismos reguladores empiezan a plantear expectativas sobre la transparencia, la procedencia y la rendición de cuentas en las cadenas de suministro de IA.

Esperar a que haya lineamientos perfectos ya no parece una opción viable. Para esta organización, adoptar un AI-BOM tiene menos que ver con la madurez y más con estar preparados. Establecer visibilidad ahora crea una base sobre la que pueden avanzar a medida que evolucionan los requisitos, en vez de apresurarse para ponerse al día cuando las expectativas se formalicen.

Esperamos que nuestras herramientas hagan seguimiento de las novedades.

En estas conversaciones, aparece con la misma frecuencia un tercer tema: las organizaciones ya no esperan hacer el seguimiento del ecosistema de IA por su cuenta. Los equipos de seguridad reconocen la rapidez con que aparecen nuevos frameworks de agentes, servidores MCP, paquetes de modelos, prompts y conjuntos de datos. Para cuando se define un proceso de revisión manual, el panorama ya ha cambiado. Mantener un inventario confiable únicamente con trabajo humano ya no es realista.

Por eso, las organizaciones esperan que Snyk mantenga esa visibilidad por ellas. Confían en el descubrimiento automatizado para detectar nuevos componentes a medida que aparecen y mantener una visibilidad actualizada sin necesidad de intervención constante. En un ecosistema que evoluciona tan rápido, la automatización no es una comodidad: es la única manera de mantener la visibilidad al día.

La nueva superficie de ataque de la IA: primero la visibilidad, después todo lo demás

Cuando las organizaciones reconocen la rapidez con que proliferan los componentes de IA y las limitaciones del seguimiento manual, el enfoque pasa de las decisiones sobre herramientas a la exposición.

La explosión de Shadow AI

A medida que se acelera la adopción de la IA, también ha surgido una nueva clase de exposición. Shadow AI se ha extendido mucho más allá de experimentos aislados o herramientas puntuales. Ahora abarca una colección cada vez mayor de componentes que, sin pasar por una revisión formal, influyen discretamente en el comportamiento de las aplicaciones.

Se ponen en marcha agentes no aprobados para automatizar tareas u orquestar flujos de trabajo. Los servidores MCP sin documentar ofrecen nuevas herramientas y capacidades sin que haya una responsabilidad claramente asignada. Los wrappers improvisados conectan modelos con sistemas internos; a menudo se crean para resolver un problema inmediato y luego quedan en uso. Aparecen llamadas ocultas a LLM dentro de la lógica de las aplicaciones, mientras que las cadenas de prompts se incorporan como rutas de decisión funcionales, en lugar de simples entradas.

Por separado, muchos de estos elementos parecen inofensivos. En conjunto, crean una superficie de ataque de IA difícil de mapear y fácil de pasar por alto. Shadow AI no se define por la intención ni por la sofisticación, sino por su invisibilidad. Cuando los componentes quedan fuera de los procesos habituales de descubrimiento y gobernanza, introducen riesgos simplemente porque se desconocen.

Brechas de visibilidad reales

Estas brechas se manifiestan en entornos reales. En un caso, una empresa detectó un servidor MCP activo durante una demostración de rutina. El equipo de AppSec no sabía que existía. No había nada mal configurado. No se había explotado ninguna vulnerabilidad. El servidor simplemente era invisible para los controles en los que confiaba el equipo. En todas las organizaciones, el patrón se repite: hay componentes de IA que afectan considerablemente el comportamiento fuera de los procesos formales de descubrimiento, no por negligencia, sino porque los controles existentes nunca se diseñaron para detectarlos.

El AI-BOM: la nueva fuente de referencia

En conjunto, estas brechas muestran la necesidad de una nueva fuente de referencia. El AI-BOM cumple esa función al ofrecer la visibilidad que los SBOM nunca se diseñaron para proporcionar en un entorno nativo de IA.

Un AI-BOM inventaría los componentes que definen cómo funcionan los sistemas de IA. Registra los modelos en uso, los agentes que se crean sobre ellos y las herramientas y cadenas que estos agentes invocan. Registra los servidores MCP y las capacidades que ofrecen, junto con los prompts y conjuntos de datos que dan forma al comportamiento. También contempla las API externas de IA que amplían las funciones más allá de los límites de la aplicación.

Esa visibilidad crea una base para la acción. La gobernanza se fundamenta en la realidad, no en suposiciones. El monitoreo puede centrarse en lo que existe. Los equipos de red teaming pueden probar configuraciones reales, en lugar de flujos de trabajo hipotéticos. El AI-BOM pasa de ser un inventario a convertirse en una columna vertebral operativa.

Por qué AI-BOM ≠ SBOM

Aunque el término pueda sonar familiar, un AI-BOM es fundamentalmente distinto de un SBOM tradicional. Los SBOM se diseñaron para sistemas de software con componentes estables, actualizaciones previsibles y árboles de dependencias claros. Los sistemas nativos de IA operan en condiciones diferentes.

Estas diferencias tienen consecuencias prácticas para la gobernanza, el monitoreo y la gestión de la postura de seguridad.

Por qué la automatización es esencial y por qué Snyk lidera

La escala y la velocidad de los cambios en el ecosistema de IA dejan algo claro: el seguimiento manual no puede mantener el ritmo. A esta escala, depender de la revisión humana deja de funcionar. Para cuando se identifica un nuevo componente, puede que ya esté en uso en varios equipos o flujos de trabajo.

Aquí es donde la automatización se vuelve esencial. El descubrimiento y la clasificación continuos son las únicas formas prácticas de mantener una visión precisa de los componentes de IA a medida que aparecen y cambian. Snyk lidera en este ámbito al combinar la detección automatizada con la investigación continua, para identificar nuevos frameworks, servidores MCP, patrones de modelos y conjuntos de datos en cuanto aparecen.

La ventaja de investigación de Snyk

La automatización por sí sola no basta si no hay conocimiento que la guíe. Saber qué analizar es tan importante como hacerlo de manera continua.

El equipo especializado de investigación de cadenas de suministro de IA de Snyk se centra en entender cómo evoluciona el ecosistema en tiempo real. Hace seguimiento de los nuevos frameworks de agentes a medida que aparecen, analiza nuevos patrones de MCP y modelos de uso, y estudia los nuevos vectores de ataque de IA que se descubren en entornos reales. También sigue la rápida expansión de las familias de modelos y los tipos de conjuntos de datos, y reconoce cómo estos cambios generan nuevas dependencias y formas de riesgo.

Esta investigación contribuye directamente a mantener actualizado el AI-BOM. Los clientes no necesitan monitorear cada nueva versión, framework o patrón por su cuenta. Snyk hace ese trabajo en su nombre y convierte los cambios del ecosistema en detecciones e información contextual confiables. Ese es el valor central de un AI-BOM respaldado por investigación: una visibilidad que evoluciona tan rápido como la propia cadena de suministro de IA.

Los AI-BOM como base de la gobernanza de IA y AI-SPM

A medida que los sistemas de IA pasan de la experimentación a los flujos de trabajo centrales del negocio, contar con una base confiable se vuelve indispensable. Así como las SBOM pasaron de ser una práctica recomendada a un requisito para la gobernanza del software, las AI-BOM están siguiendo un camino similar en los entornos nativos de IA.

Ofrecen la visibilidad necesaria para tomar decisiones de gobernanza, proteger los datos, orientar los ejercicios de red teaming, monitorear la actividad de los agentes y prepararse para el escrutinio regulatorio. Las señales de los organismos reguladores ya apuntan en esta dirección.

Pero la visibilidad por sí sola no es suficiente. A medida que crecen los entornos de IA, las organizaciones necesitan una forma de comprender continuamente la postura de cientos de modelos, agentes, conjuntos de datos y conectores, no como inventarios estáticos, sino como sistemas vivos que cambian a diario. Aquí es donde las AI-BOM se convierten en un insumo fundamental para la gestión de la postura de seguridad de la IA (AI-SPM).

Las cadenas de suministro de IA avanzan demasiado rápido para aplicar el enfoque de la era de las SBOM. La IA en la sombra sigue expandiéndose. La supervisión aumenta. En este contexto, las AI-BOM se convierten en la fuente de información esencial para los sistemas nativos de IA.

Si las SBOM definieron la última década de la seguridad del software, las AI-BOM definirán la próxima. Snyk está desarrollando los cimientos basados en investigación que permitirán que las AI-BOM evolucionen hasta convertirse en una solución completa de AI-SPM, transformando inventarios sin procesar en información de seguridad continua y práctica.

Descubre cómo Snyk Evo amplía la visibilidad de las AI-BOM, revela el funcionamiento interno de los sistemas de IA y sienta las bases para un nuevo enfoque de la postura de seguridad de la IA. Explora cómo se ve en la práctica la seguridad de IA basada en investigación.