De SBOM à AI-BOM: repensando a visibilidade em sistemas nativos de IA

Por anos, a lista de materiais de software foi uma base confiável para a governança. Ela permitia que as equipes entendessem o que compunha uma aplicação, avaliassem riscos e atendessem a requisitos de conformidade cada vez mais exigentes. No entanto, à medida que o desenvolvimento de software migra para sistemas nativos de IA, essa base começa a ruir.

É aí que entra a lista de materiais de IA. Uma AI-BOM mapeia os componentes nativos de IA que hoje dão forma às aplicações modernas, abrangendo repositórios, pipelines e sistemas em execução. Modelos, agentes, prompts, conjuntos de dados e serviços de suporte passam a fazer parte do panorama. Enquanto a SBOM sustenta a governança de software, a AI-BOM está se tornando a espinha dorsal da segurança nativa de IA.

Este guia analisa por que a abordagem baseada em SBOM já não se aplica a um ecossistema orientado por IA, no qual os componentes mudam com frequência e o comportamento é moldado durante a execução, e não na etapa de build. Explica por que as organizações estão adotando a AI-BOM como recurso fundamental e por que a visibilidade é o primeiro requisito — e o mais urgente. Em um mundo de ferramentas que evoluem rapidamente e de Shadow AI disseminada, entender o que existe é o ponto de partida para tudo o que vem a seguir.

Por que a abordagem de SBOM não funciona na era da IA

Para entender por que a AI-BOM se tornou essencial, vale começar pelo que já não funciona. As premissas que deram origem às SBOMs foram criadas para um mundo de software em que os componentes eram finitos, as dependências eram conhecidas e as mudanças aconteciam em um ritmo moderado. Os sistemas nativos de IA operam em condições bem diferentes. Antes de analisar como as organizações estão se adaptando, vale entender por que as premissas conhecidas da era das SBOMs deixam de funcionar na era da IA.

Os componentes de IA mudam constantemente

Sistemas nativos de IA são definidos por mudanças constantes. Seus componentes não ficam estáveis por tempo suficiente para serem tratados como dependências tradicionais, e essa volatilidade agora é a regra, não a exceção.

Os modelos são atualizados semanalmente, às vezes com mais frequência, à medida que novos recursos e otimizações são lançados. Os frameworks de agentes evoluem no mesmo ritmo, com novas abstrações, ferramentas e padrões de execução surgindo em repositórios públicos. Servidores MCP são ativados para disponibilizar novas ferramentas ou fluxos de trabalho, muitas vezes em resposta a necessidades imediatas de desenvolvimento, e não a planos de longo prazo. Prompts, que cada vez mais funcionam como lógica executável, são editados e refinados continuamente. Os conjuntos de dados mudam quando novos dados são adicionados, filtrados ou substituídos, alterando o comportamento dos modelos sem que o código ao redor seja modificado.

Esses componentes não têm versões fixadas como as bibliotecas. Não ficam centralizados em um único repositório. E podem ser introduzidos por desenvolvedores individualmente, com pouca dificuldade. Tratá-los como dependências estáticas cria pontos cegos quase que imediatamente.

Em um ambiente nativo de IA, a governança precisa considerar componentes dinâmicos, descentralizados e em constante evolução.

O problema central é a visibilidade

Para a maioria dos líderes de segurança, o desafio não é entender cada decisão que um sistema de IA pode tomar. CISOs não estão tentando analisar o comportamento de agentes no nível de cada prompt ou saída. O que eles precisam primeiro é algo bem mais básico: entender o que existe.

Eles querem saber quais agentes, modelos e servidores MCP estão realmente em uso na organização. Querem entender quais ferramentas ou fluxos de trabalho esses componentes disponibilizam e a quais sistemas externos podem se conectar. Precisam ter visibilidade dos conjuntos de dados e prompts que moldam o comportamento, pois essas entradas muitas vezes são tão importantes quanto o próprio código.

Sem essa visibilidade, é impossível avaliar riscos, definir políticas ou responder de forma eficaz quando algo dá errado. As SBOMs tradicionais nunca foram projetadas para oferecer esse nível de conhecimento. Elas registram dependências estáticas em um determinado momento, e não os componentes ativos e em evolução que definem os sistemas nativos de IA. Com isso, as equipes de segurança ficam sem a visibilidade necessária para governar a IA com eficácia.

O que ouvimos dos líderes de segurança

A lacuna de visibilidade já não é teórica. Ela aparece repetidamente nas conversas com líderes de segurança que tentam aplicar controles existentes a um cenário de IA em constante evolução.

Proliferação de frameworks

Para muitas grandes organizações, o desafio começa pelo volume. Uma empresa relatou um fluxo constante de novos frameworks de agentes, ferramentas de orquestração, pacotes de modelos e servidores MCP nas equipes de desenvolvimento. Os desenvolvedores os adotavam rapidamente para trabalhar com mais agilidade. As equipes de governança não conseguiam acompanhar.

As iniciativas de segurança e conformidade se tornaram reativas. Quando um framework era analisado, outro já tinha surgido. O problema não era a resistência à inovação, mas a falta de visibilidade clara sobre o que existia.

Para essa organização, a AI-BOM se tornou essencial. Ela ofereceu uma forma confiável de acompanhar os componentes de IA nos repositórios, estabelecendo a base necessária para viabilizar a governança enquanto o ecossistema continuava a mudar.

A AI-BOM ainda está no início, mas é essencial.

Outra organização descreveu sua abordagem com mais cautela, mas com a mesma urgência. Admitiu que a AI-BOM ainda está no início. Os padrões estão surgindo. As práticas recomendadas ainda não estão consolidadas. Mesmo assim, a organização vê a AI-BOM como inevitável.

Os componentes de IA deixaram de ser ferramentas experimentais e se tornaram dependências relevantes. Modelos, agentes e serviços de suporte agora influenciam diretamente o comportamento das aplicações e o processamento de dados. Ao mesmo tempo, órgãos reguladores começam a sinalizar expectativas em relação à transparência, à procedência e à responsabilização na cadeia de suprimentos de IA.

Esperar por orientações perfeitas já não parece uma opção viável. Para essa organização, adotar uma AI-BOM tem menos a ver com maturidade e mais com prontidão. Estabelecer visibilidade agora cria uma base que poderá ser ampliada conforme os requisitos evoluam, em vez de correr para se atualizar quando as expectativas forem formalizadas.

Esperamos que nossas ferramentas acompanhem as novidades.

Um terceiro tema aparece com a mesma frequência nessas conversas: as organizações já não esperam acompanhar o ecossistema de IA por conta própria. As equipes de segurança reconhecem a rapidez com que surgem novos frameworks de agentes, servidores MCP, pacotes de modelos, prompts e conjuntos de dados. Quando um processo de análise manual é definido, o cenário já mudou. Manter um inventário confiável apenas com o trabalho de pessoas já não é realista.

Por isso, as organizações esperam que a Snyk mantenha essa visibilidade em nome delas. Elas contam com a descoberta automatizada para identificar novos componentes assim que surgem, mantendo a visibilidade atualizada sem exigir intervenção constante. Em um ecossistema que evolui tão rápido, a automação não é uma conveniência: é a única maneira de acompanhar as mudanças.

A nova superfície de ataque da IA: primeiro a visibilidade, depois todo o resto

Quando as organizações percebem a rapidez com que os componentes de IA se proliferam e as limitações do acompanhamento manual, o foco deixa de ser a escolha de ferramentas e passa a ser a exposição.

A explosão da Shadow AI

À medida que a adoção de IA acelera, surge junto uma nova categoria de exposição. A Shadow AI foi muito além de experimentos isolados ou ferramentas pontuais. Agora, ela abrange um conjunto crescente de componentes que moldam silenciosamente o comportamento das aplicações sem passar por uma análise formal.

Agentes não aprovados são ativados para automatizar tarefas ou orquestrar fluxos de trabalho. Servidores MCP não documentados disponibilizam novas ferramentas e recursos sem que haja responsáveis claramente definidos. Conectores improvisados ligam modelos a sistemas internos, muitas vezes criados para resolver um problema imediato e depois deixados em uso. Chamadas ocultas a LLMs aparecem na lógica das aplicações, enquanto cadeias de prompts passam a integrar caminhos funcionais de decisão, em vez de servirem apenas como entradas.

Isoladamente, muitos desses elementos parecem inofensivos. Juntos, criam uma superfície de ataque de IA difícil de mapear e fácil de ignorar. A Shadow AI não é definida pela intenção ou pela sofisticação, mas pela invisibilidade. Quando os componentes ficam fora dos processos padrão de descoberta e governança, eles geram riscos simplesmente por serem desconhecidos.

Lacunas reais de visibilidade

Essas lacunas aparecem em ambientes reais. Em um caso, uma empresa descobriu um servidor MCP ativo durante uma demonstração de rotina. A equipe de AppSec não sabia que ele existia. Não havia nada configurado incorretamente. Nenhum ataque havia ocorrido. O servidor simplesmente era invisível para os controles nos quais a equipe confiava. O padrão se repete nas organizações: componentes de IA que afetam significativamente o comportamento ficam fora dos processos formais de descoberta, não por negligência, mas porque os controles existentes nunca foram projetados para detectá-los.

A AI-BOM: a nova fonte confiável

Em conjunto, essas lacunas apontam para a necessidade de uma nova fonte confiável. A AI-BOM ocupa esse papel ao oferecer a visibilidade que as SBOMs nunca foram projetadas para proporcionar em um ambiente nativo de IA.

Uma AI-BOM inventaria os componentes que definem como os sistemas de IA operam. Ela acompanha os modelos em uso, os agentes construídos sobre eles e as ferramentas e cadeias que esses agentes acionam. Registra servidores MCP e os recursos que disponibilizam, além dos prompts e conjuntos de dados que moldam o comportamento. Também considera APIs externas de IA que ampliam a funcionalidade para além dos limites da aplicação.

Essa visibilidade cria uma base para agir. A governança passa a se fundamentar na realidade, e não em suposições. O monitoramento pode se concentrar no que existe. Os exercícios de red team podem testar configurações reais, em vez de fluxos de trabalho hipotéticos. A AI-BOM deixa de ser apenas um inventário e se torna a espinha dorsal das operações.

Por que AI-BOM ≠ SBOM

Embora o termo possa parecer familiar, uma AI-BOM é fundamentalmente diferente de uma SBOM tradicional. As SBOMs foram criadas para sistemas de software com componentes estáveis, atualizações previsíveis e árvores de dependência claras. Os sistemas nativos de IA operam em condições diferentes.

Essas diferenças têm consequências práticas para a governança, o monitoramento e a gestão da postura de segurança.

Por que a automação é essencial e por que a Snyk se destaca

A escala e a velocidade das mudanças no ecossistema de IA deixam algo claro: o acompanhamento manual não dá conta. Nessa escala, depender da análise humana não funciona. Quando um novo componente é identificado, ele talvez já esteja em uso por várias equipes ou em diferentes fluxos de trabalho.

É aí que a automação se torna essencial. A descoberta e a classificação contínuas são as únicas formas práticas de manter uma visão precisa dos componentes de IA à medida que surgem e mudam. A Snyk se destaca nessa área ao combinar detecção automatizada com pesquisa contínua, garantindo que novos frameworks, servidores MCP, padrões de modelos e conjuntos de dados sejam reconhecidos assim que aparecem.

A vantagem da pesquisa da Snyk

A automação, por si só, não basta sem os insights que a orientem. Saber o que analisar é tão importante quanto analisar continuamente.

A equipe dedicada de pesquisa sobre a cadeia de suprimentos de IA da Snyk busca entender como o ecossistema evolui em tempo real. A equipe acompanha o surgimento de novos frameworks de agentes, analisa novos padrões e modelos de uso de MCP e estuda vetores de ataque emergentes de IA à medida que são descobertos no mundo real. Também acompanha a rápida expansão das famílias de modelos e dos tipos de conjuntos de dados, reconhecendo como essas mudanças introduzem novas dependências e novas formas de risco.

Essa pesquisa contribui diretamente para manter a AI-BOM atualizada. Os clientes não precisam acompanhar cada novo lançamento, framework ou padrão. A Snyk faz esse trabalho por eles, transformando as mudanças do ecossistema em detecções e contexto confiáveis. Esse é o principal valor de uma AI-BOM impulsionada por pesquisa: uma visibilidade que evolui no mesmo ritmo da própria cadeia de suprimentos de IA.

AI-BOMs como base da governança de IA e do AI-SPM

À medida que os sistemas de IA deixam a fase de experimentação e passam a fazer parte dos principais fluxos de trabalho das empresas, torna-se indispensável contar com uma base confiável. Assim como os SBOMs deixaram de ser uma boa prática e se tornaram um requisito para a governança de software, os AI-BOMs seguem um caminho semelhante nos ambientes nativos de IA.

Eles oferecem a visibilidade necessária para embasar decisões de governança, proteger dados, orientar iniciativas de red teaming, monitorar a atividade dos agentes e se preparar para o escrutínio regulatório. Os sinais dos órgãos reguladores já apontam nessa direção.

Mas a visibilidade, por si só, não basta. À medida que os ambientes de IA se expandem, as organizações precisam acompanhar continuamente a postura de centenas de modelos, agentes, conjuntos de dados e conectores — não como inventários estáticos, mas como sistemas dinâmicos que mudam diariamente. É nesse contexto que os AI-BOMs se tornam uma base essencial para o AI Security Posture Management (AI-SPM).

As cadeias de suprimentos de IA avançam rápido demais para a mentalidade da era dos SBOMs. A IA paralela continua se expandindo. A supervisão está aumentando. Nesse cenário, o AI-BOM se torna a fonte essencial de informações confiáveis sobre sistemas nativos de IA.

Se os SBOMs moldaram a última década da segurança de software, os AI-BOMs moldarão a próxima. A Snyk está construindo uma base orientada por pesquisa para que os AI-BOMs evoluam para um AI-SPM completo, transformando inventários brutos em insights de segurança contínuos e práticos.

Descubra como o Snyk Evo amplia a visibilidade dos AI-BOMs, revelando o funcionamento interno dos sistemas de IA e preparando o terreno para uma nova abordagem à postura de segurança de IA. Veja na prática como é a segurança de IA orientada por pesquisa.