El Shadow AI se convirtió en un dolor de cabeza real en las empresas.
Mientras los equipos adoptan herramientas de inteligencia artificial sin pasar por el filtro de TI o de seguridad, el inventario de modelos crece en las sombras, sin control, sin rastreo y, muchas veces, sin que nadie sepa exactamente qué está corriendo en los ambientes corporativos. Desarrolladores conectan APIs de modelos externos, analistas usan plataformas de IA sin aprobación formal y equipos enteros operan con herramientas que nunca pasaron por ningún proceso de evaluación de riesgo. El resultado es un ecosistema de IA paralelo dentro de las organizaciones, invisible para quienes deberían estar cuidando la seguridad.
Este escenario puso en jaque al SBOM tradicional, ese inventario en formato legible por máquina que mapea componentes, bibliotecas y módulos de software. Durante años, el SBOM funcionó muy bien como herramienta de transparencia para ambientes de desarrollo, permitiendo que los equipos de seguridad supieran exactamente qué estaba presente en cada sistema. Funciona bien para código. Pero la IA no es solo código. Los modelos cambian con prompts, datasets, ajustes finos y permisos de agentes, y eso crea una capa de complejidad que el SBOM simplemente no fue diseñado para cubrir.
Ahí entra el AI-BOM, el AI Bill of Materials, que amplía esta lógica para cubrir todo lo que compone e influye en un sistema de inteligencia artificial, desde modelos y datasets hasta agentes, infraestructura cloud e identidades. Y no es teoría. Empresas como Cisco, Wiz y Palo Alto Networks ya están construyendo herramientas concretas para esto, mientras iniciativas como el EU AI Act, el NIST y la OWASP presionan por estándares más claros de documentación y seguridad en IA. El mercado se está moviendo rápido, pero los estándares todavía se están consolidando. 🚀
Por qué el Shadow AI es un problema tan serio hoy
La velocidad con la que las herramientas de IA llegaron al mercado en los últimos dos años creó una ventana de adopción que pasó por encima de prácticamente todos los procesos tradicionales de gobernanza corporativa. Plataformas como ChatGPT, Copilot, Gemini y decenas de otras soluciones especializadas están disponibles para cualquier persona con una tarjeta de crédito y acceso a internet, lo que significa que un colaborador puede empezar a usar un modelo de lenguaje para procesar datos sensibles de la empresa sin que el departamento de TI sepa que eso está ocurriendo. Esta dinámica creó lo que el sector llama Shadow AI, un conjunto de herramientas, modelos e integraciones que operan fuera de la visibilidad y del control institucional.
El problema va mucho más allá de una cuestión de compliance o de políticas internas incumplidas. Cuando un equipo usa un modelo externo para procesar contratos, datos de clientes o información financiera, esos datos pueden ser utilizados para entrenar futuros modelos, pueden quedar almacenados en servidores de terceros o pueden ser expuestos en caso de brechas de seguridad en el proveedor. Sin un inventario de modelos estructurado, la empresa no tiene cómo saber qué datos fueron a dónde, qué modelos tuvieron acceso a qué sistemas y qué riesgos se introdujeron a lo largo del tiempo. Es como intentar hacer una auditoría de seguridad sin saber qué está instalado en las computadoras de la empresa.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La situación se complica aún más con el crecimiento de los agentes de IA, sistemas que no solo responden preguntas, sino que toman acciones autónomas, acceden a APIs, ejecutan código e interactúan con otros sistemas. Un agente de IA mal configurado o no documentado puede tener permisos excesivos, puede conectarse a sistemas críticos y puede generar consecuencias que van mucho más allá de lo que cualquier usuario individual podría causar. El Shadow AI en este contexto ya no es solo una cuestión de visibilidad, es una cuestión de superficie de ataque real y creciente dentro de las organizaciones. 🔐
Qué es el AI-BOM y cómo resuelve el inventario de modelos
El concepto de AI-BOM parte de una premisa simple: si no sabes lo que tienes, no puedes protegerlo. De la misma forma que el SBOM mapea dependencias de software para garantizar que las vulnerabilidades conocidas puedan ser identificadas y corregidas rápidamente, el AI Bill of Materials hace lo mismo para los componentes que conforman un sistema de inteligencia artificial. Esto incluye el modelo base utilizado, los datasets de entrenamiento y ajuste fino, los prompts de sistema, las herramientas y APIs conectadas, las identidades y permisos de los agentes y la infraestructura de nube donde todo esto corre. Es un retrato completo de todo lo que toca el sistema de IA, no solo el código.
En la práctica, un AI-BOM bien estructurado permite que los equipos de seguridad hagan preguntas que antes eran imposibles de responder con precisión. ¿Qué versión del modelo está en producción? ¿Este modelo fue entrenado con datos que incluyen información propietaria de la empresa? ¿Qué agentes tienen acceso a qué sistemas? Si se descubre una vulnerabilidad en un modelo específico, ¿cuántos sistemas internos dependen de él? Estas respuestas son críticas para cualquier respuesta a incidentes y para cualquier proceso de evaluación de riesgo que involucre IA. Sin este inventario, la empresa está operando a oscuras, y a oscuras cualquier sorpresa tiende a ser desagradable.
IBM describe el SBOM como una lista legible por máquina de componentes, bibliotecas y módulos de un producto de software. El AI-BOM construye sobre esa idea, pero el sistema de IA que se está rastreando no es solo código. Wiz define el AI-BOM como un inventario de modelos, datasets de entrenamiento, dependencias de software, infraestructura y componentes relacionados que moldean el comportamiento del sistema. Documentar todo esto de forma rastreable y auditable es exactamente lo que el AI-BOM propone, creando una cadena de responsabilidad y visibilidad que el SBOM tradicional simplemente no puede cubrir por haber sido diseñado para un mundo donde el software era estático y determinístico.
Las herramientas que están tomando la delantera
Cisco abrió el código de un escáner de AI-BOM que analiza bases de código, imágenes de contenedor y ambientes de nube para producir un inventario estructurado de modelos, agentes, herramientas, servidores y clientes MCP, datasets, prompts, guardrails, secretos y otros activos de IA. El proyecto en GitHub soporta Python, JavaScript, TypeScript, Java, Go, Rust, Ruby y C#, y genera reportes en formatos como JSON, CycloneDX, SARIF, SPDX, HTML, Markdown y CSV. Este alcance es bastante más amplio que un SBOM convencional, justamente porque lo que necesita ser rastreado en IA va mucho más allá del código.
Palo Alto Networks describe el AI-BOM como un inventario legible por máquina que cubre cada dataset, modelo y componente de software usado para construir y operar un sistema de IA, con registros de versiones, fuentes y relaciones. La empresa también afirma que el AI-BOM da soporte al linaje de modelos, a la proveniencia de datos y a la generación de evidencias de conformidad. Este es un punto importante porque los sistemas de IA, a diferencia del software convencional, cambian mediante prompts, datasets, ajustes finos, permisos de agentes y dependencias de modelos externos, ampliando todo lo que las empresas necesitan monitorear.
Rastreando proveniencia y riesgo regulatorio
Cisco también está apuntando al lado de la proveniencia con su Model Provenance Kit, que compara dos modelos mediante metadatos, estructura de tokenizador y señales a nivel de pesos, o escanea un modelo contra una base de datos de huellas digitales. La empresa informó que la base inicial cubre alrededor de 150 modelos base, distribuidos en más de 45 familias y más de 20 publicadores. La herramienta fue vinculada a riesgos relacionados con modelos reempaquetados, licenciamiento, exposición regulatoria e integridad de la cadena de suministro. En muchos casos, las organizaciones simplemente no saben si un modelo fue entrenado desde cero, copiado, modificado o derivado de otro modelo.
Del lado regulatorio, el EU AI Act ya establece requisitos de documentación y transparencia para sistemas de IA de alto riesgo que, en la práctica, apuntan directamente a la necesidad de algo como el AI-BOM. El NIST publicó su AI Risk Management Framework con directrices que incluyen inventario y trazabilidad de componentes de IA, y la OWASP ha desarrollado recursos específicos para seguridad en aplicaciones que utilizan LLMs, incluyendo recomendaciones sobre documentación de modelos y control de acceso. Este conjunto de presiones regulatorias y de frameworks de referencia está acelerando la adopción de prácticas más estructuradas de gobernanza de IA en las organizaciones, especialmente en aquellas que operan en sectores regulados.
Conectando identidad e infraestructura cloud
La contribución de Wiz es el contexto de nube alrededor de este registro. La orientación de la empresa dice que un inventario útil mapea sistemas de IA hacia datos, identidades, infraestructura y responsables, en lugar de quedarse en los nombres de los modelos. Wiz también afirma que un inventario de IA moderno necesita actualizarse continuamente, porque los sistemas de IA surgen, cambian y son desactivados rápidamente. Esta capa de identidad se está volviendo central en la gobernanza de IA, exigiendo descubrimiento de Shadow AI, verificaciones de configuración y mapeo de permisos de identidad vinculados a cada workload.
Google Cloud incorporó esta idea en la alianza con Wiz. La empresa afirmó que el AI-BOM dinámico de Wiz inventaría modelos de IA, herramientas de desarrollo de IA y extensiones de IDE, ayudando a las organizaciones a rastrear herramientas aprobadas como Gemini Code Assist y GitHub Copilot, al mismo tiempo que descubre plugins de Shadow AI no aprobados. Por su parte, Palo Alto Networks está atacando el mismo problema por el lado de la seguridad en tiempo de ejecución con Prisma AIRS 3.0, que descubre agentes, modelos y conexiones de IA en ambientes de nube, plataformas SaaS y endpoints locales.
Un ejemplo real muestra por qué esto dejó de ser teoría. Según el relato de Ian Swanson, vicepresidente de productos de seguridad de IA de Palo Alto Networks, un incidente involucró a atacantes usando IA para reconocimiento, ganando acceso a los prompts de sistema de un workload interno de IA y modificando esos prompts para robar datos y enviarlos a una cuenta de correo electrónico externa. Swanson argumentó que un AI-BOM podría ayudar a los defensores a comparar el prompt de sistema usado en un momento con un estado posterior ya alterado, revelando rápidamente la manipulación.
Sora y el desafío de rastrear modelos de última generación
El Sora es un ejemplo perfecto de por qué el inventario de modelos necesita evolucionar. El modelo de generación de video de OpenAI representa una nueva categoría de sistemas de IA que combinan múltiples modalidades, procesan entradas complejas y generan salidas que pueden ser usadas de formas muy variadas. Cuando una empresa integra Sora en un flujo de producción de contenido, por ejemplo, está introduciendo un componente con características muy específicas de comportamiento, limitaciones y riesgos que necesitan ser documentados con la misma seriedad que cualquier otra dependencia crítica de software. El problema es que la mayoría de las herramientas de seguridad existentes no fueron construidas para rastrear este tipo de componente.
Herramientas que usamos a diario
El acceso a Sora vía API también plantea cuestiones importantes sobre control de uso corporativo. Si un equipo de marketing empieza a usar el modelo para generar videos de campaña sin que el departamento jurídico evalúe los términos de uso, sin que TI sepa qué datos se están enviando a la API y sin que seguridad evalúe los riesgos de propiedad intelectual involucrados, eso es Shadow AI en acción. Y el AI-BOM sería justamente el mecanismo para garantizar que esa adopción sea registrada, evaluada y monitoreada de forma continua, no solo en el momento inicial de integración, sino a lo largo de todo el ciclo de vida del uso del modelo dentro de la organización.
Los modelos multimodales como Sora también introducen riesgos que van más allá de las preocupaciones tradicionales de privacidad de datos. La capacidad de generar contenido visual realista a partir de instrucciones textuales crea superficies de riesgo relacionadas con la creación de desinformación, la representación indebida de marcas y personas, y el uso no autorizado de activos visuales. Un inventario de modelos robusto necesita capturar no solo dónde se está usando el modelo, sino cómo se está usando, con qué permisos, para qué fines y con qué controles de salida activos. Esa granularidad es lo que diferencia un AI-BOM eficaz de una simple lista de herramientas aprobadas.
Caminando hacia estándares para todo el sector
La capa de estándares todavía está sin definición completa. El AIBOM Generator de OWASP produce inventarios de materiales de IA para modelos de Hugging Face en formato CycloneDX alineado con SPDX, y el OWASP GenAI Security Project dice que su iniciativa de AIBOM busca transformar el concepto en herramientas abiertas, verificaciones de completitud y orientación práctica para profesionales. En paralelo, existe un SBOM for AI Tiger Team, facilitado por la CISA pero no adoptado como política oficial del gobierno de Estados Unidos, que publicó casos de uso para conformidad, gestión de incidentes, riesgo de modelos de código abierto, riesgo de IA de terceros, propiedad intelectual y gestión del ciclo de vida de modelos.
A medida que los agentes de IA se vuelven más comunes y más autónomos, la presión por un inventario de modelos va a aumentar proporcionalmente. Un ambiente con decenas de agentes operando en paralelo, cada uno con sus propias conexiones, permisos y comportamientos, es un ambiente que simplemente no puede ser gestionado de forma manual. Las herramientas de descubrimiento automático y mapeo continuo de componentes de IA van a volverse tan esenciales como los escáneres de vulnerabilidades lo son hoy, y las empresas que comiencen a construir esa capacidad ahora van a tener una ventaja significativa cuando los requisitos regulatorios se vuelvan más específicos y más exigentes.
La buena noticia es que el camino para implementar un inventario de modelos eficaz no necesita empezar de cero. Las organizaciones que ya tienen procesos maduros de gestión de SBOMs pueden extender esos procesos para cubrir componentes de IA, añadiendo las dimensiones específicas que los modelos exigen. El desafío principal es cultural y organizacional: convencer a los equipos de producto, ingeniería y negocio de que declarar el uso de herramientas de IA no es burocracia, es protección. Cuando un incidente ocurre y la empresa necesita responder rápido, tener un AI-BOM actualizado y confiable puede ser la diferencia entre una respuesta coordinada y eficaz y semanas de investigación intentando descubrir qué estaba corriendo dónde. El AI-BOM ya no es una idea interesante para el futuro. Es una necesidad operacional para cualquier organización que se tome en serio la seguridad de sus ambientes de inteligencia artificial hoy. 🎯
