O Shadow AI virou dor de cabeça real nas empresas.
Enquanto times adotam ferramentas de inteligência artificial sem passar pelo crivo de TI ou de segurança, o inventário de modelos cresce nas sombras, sem controle, sem rastreamento e, muitas vezes, sem que ninguém saiba exatamente o que está rodando nos ambientes corporativos. Desenvolvedores conectam APIs de modelos externos, analistas usam plataformas de IA sem aprovação formal e times inteiros operam com ferramentas que nunca passaram por qualquer processo de avaliação de risco. O resultado é um ecossistema de IA paralelo dentro das organizações, invisível para quem deveria estar cuidando da segurança.
Esse cenário colocou em xeque o SBOM tradicional, aquele inventário em formato legível por máquina que mapeia componentes, bibliotecas e módulos de software. Por anos, o SBOM funcionou muito bem como ferramenta de transparência para ambientes de desenvolvimento, permitindo que equipes de segurança soubessem exatamente o que estava presente em cada sistema. Funciona bem para código. Mas IA não é só código. Modelos mudam com prompts, datasets, ajustes finos e permissões de agentes, e isso cria uma camada de complexidade que o SBOM simplesmente não foi desenhado para cobrir.
Aí entra o AI-BOM, o AI Bill of Materials, que amplia essa lógica para cobrir tudo que compõe e influencia um sistema de inteligência artificial, desde modelos e datasets até agentes, infraestrutura cloud e identidades. E não é teoria. Empresas como Cisco, Wiz e Palo Alto Networks já estão construindo ferramentas concretas para isso, enquanto iniciativas como o EU AI Act, o NIST e a OWASP pressionam por padrões mais claros de documentação e segurança em IA. O mercado está se movendo rápido, mas os padrões ainda estão se consolidando. 🚀
Por que o Shadow AI é um problema tão sério hoje
A velocidade com que ferramentas de IA chegaram ao mercado nos últimos dois anos criou uma janela de adoção que passou por cima de praticamente todos os processos tradicionais de governança corporativa. Plataformas como ChatGPT, Copilot, Gemini e dezenas de outras soluções especializadas estão disponíveis para qualquer pessoa com um cartão de crédito e acesso à internet, o que significa que um colaborador pode começar a usar um modelo de linguagem para processar dados sensíveis da empresa sem que o departamento de TI saiba que isso está acontecendo. Essa dinâmica criou o que o setor chama de Shadow AI, um conjunto de ferramentas, modelos e integrações que operam fora da visibilidade e do controle institucional.
O problema vai muito além de uma questão de compliance ou de políticas internas descumpridas. Quando um time usa um modelo externo para processar contratos, dados de clientes ou informações financeiras, esses dados podem ser utilizados para treinar futuros modelos, podem ficar armazenados em servidores de terceiros ou podem ser expostos em caso de brechas de segurança no provedor. Sem um inventário de modelos estruturado, a empresa não tem como saber quais dados foram para onde, quais modelos tiveram acesso a quais sistemas e quais riscos foram introduzidos ao longo do tempo. É como tentar fazer uma auditoria de segurança sem saber o que está instalado nos computadores da empresa.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
A situação se complica ainda mais com o crescimento dos agentes de IA, sistemas que não apenas respondem a perguntas, mas que tomam ações autônomas, acessam APIs, executam código e interagem com outros sistemas. Um agente de IA mal configurado ou não documentado pode ter permissões excessivas, pode se conectar a sistemas críticos e pode gerar consequências que vão muito além do que qualquer usuário individual poderia causar. O Shadow AI nesse contexto não é mais só uma questão de visibilidade, é uma questão de superfície de ataque real e crescente dentro das organizações. 🔐
O que é o AI-BOM e como ele resolve o inventário de modelos
O conceito de AI-BOM parte de uma premissa simples: se você não sabe o que tem, não consegue proteger. Da mesma forma que o SBOM mapeia dependências de software para garantir que vulnerabilidades conhecidas possam ser identificadas e corrigidas rapidamente, o AI Bill of Materials faz o mesmo para os componentes que compõem um sistema de inteligência artificial. Isso inclui o modelo base utilizado, os datasets de treinamento e ajuste fino, os prompts de sistema, as ferramentas e APIs conectadas, as identidades e permissões dos agentes e a infraestrutura de nuvem onde tudo isso roda. É um retrato completo de tudo que toca o sistema de IA, não apenas o código.
Na prática, um AI-BOM bem estruturado permite que equipes de segurança façam perguntas que antes eram impossíveis de responder com precisão. Qual versão do modelo está em produção? Esse modelo foi treinado com dados que incluem informações proprietárias da empresa? Quais agentes têm acesso a quais sistemas? Se uma vulnerabilidade for descoberta em um modelo específico, quantos sistemas internos dependem dele? Essas respostas são críticas para qualquer resposta a incidente e para qualquer processo de avaliação de risco que envolva IA. Sem esse inventário, a empresa está operando no escuro, e no escuro qualquer surpresa tende a ser desagradável.
A IBM descreve o SBOM como uma lista legível por máquina de componentes, bibliotecas e módulos de um produto de software. O AI-BOM constrói em cima dessa ideia, mas o sistema de IA que está sendo rastreado não é apenas código. A Wiz define o AI-BOM como um inventário de modelos, datasets de treinamento, dependências de software, infraestrutura e componentes relacionados que moldam o comportamento do sistema. Documentar tudo isso de forma rastreável e auditável é exatamente o que o AI-BOM propõe, criando uma cadeia de responsabilidade e visibilidade que o SBOM tradicional simplesmente não consegue cobrir por ter sido desenhado para um mundo onde o software era estático e determinístico.
As ferramentas que estão saindo na frente
A Cisco abriu o código de um scanner de AI-BOM que analisa bases de código, imagens de contêiner e ambientes de nuvem para produzir um inventário estruturado de modelos, agentes, ferramentas, servidores e clientes MCP, datasets, prompts, guardrails, segredos e outros ativos de IA. O projeto no GitHub suporta Python, JavaScript, TypeScript, Java, Go, Rust, Ruby e C#, e gera relatórios em formatos como JSON, CycloneDX, SARIF, SPDX, HTML, Markdown e CSV. Esse escopo é bem mais amplo do que um SBOM convencional, justamente porque o que precisa ser rastreado em IA vai muito além do código.
A Palo Alto Networks descreve o AI-BOM como um inventário legível por máquina que cobre cada dataset, modelo e componente de software usado para construir e operar um sistema de IA, com registros de versões, fontes e relacionamentos. A empresa também afirma que o AI-BOM dá suporte à linhagem de modelos, à proveniência de dados e à geração de evidências de conformidade. Esse é um ponto importante porque sistemas de IA, diferente de software convencional, mudam por meio de prompts, datasets, ajustes finos, permissões de agentes e dependências de modelos externos, ampliando tudo que as empresas precisam acompanhar.
Rastreando proveniência e risco regulatório
A Cisco também está mirando o lado da proveniência com seu Model Provenance Kit, que compara dois modelos por meio de metadados, estrutura de tokenizador e sinais a nível de pesos, ou escaneia um modelo contra uma base de dados de impressões digitais. A empresa informou que a base inicial cobre cerca de 150 modelos base, distribuídos em mais de 45 famílias e mais de 20 publicadores. A ferramenta foi vinculada a riscos relacionados a modelos reempacotados, licenciamento, exposição regulatória e integridade da cadeia de suprimentos. Em muitos casos, as organizações simplesmente não sabem se um modelo foi treinado do zero, copiado, modificado ou derivado de outro modelo.
Do lado regulatório, o EU AI Act já estabelece requisitos de documentação e transparência para sistemas de IA de alto risco que, na prática, apontam diretamente para a necessidade de algo como o AI-BOM. O NIST publicou seu AI Risk Management Framework com diretrizes que incluem inventário e rastreabilidade de componentes de IA, e a OWASP tem desenvolvido recursos específicos para segurança em aplicações que utilizam LLMs, incluindo recomendações sobre documentação de modelos e controle de acesso. Esse conjunto de pressões regulatórias e de frameworks de referência está acelerando a adoção de práticas mais estruturadas de governança de IA nas organizações, especialmente naquelas que operam em setores regulados.
Conectando identidade e infraestrutura cloud
A contribuição da Wiz é o contexto de nuvem ao redor desse registro. A orientação da empresa diz que um inventário útil mapeia sistemas de IA para dados, identidades, infraestrutura e responsáveis, em vez de parar nos nomes dos modelos. A Wiz também afirma que um inventário de IA moderno precisa se atualizar continuamente, porque sistemas de IA surgem, mudam e são desativados rapidamente. Essa camada de identidade está se tornando central na governança de IA, exigindo descoberta de Shadow AI, verificações de configuração e mapeamento de permissões de identidade atreladas a cada workload.
O Google Cloud incorporou essa ideia na parceria com a Wiz. A empresa afirmou que o AI-BOM dinâmico da Wiz inventaria modelos de IA, ferramentas de desenvolvimento de IA e extensões de IDE, ajudando organizações a rastrear ferramentas aprovadas como Gemini Code Assist e GitHub Copilot, ao mesmo tempo em que descobre plugins de Shadow AI não aprovados. Já a Palo Alto Networks está atacando o mesmo problema pelo lado da segurança em tempo de execução com o Prisma AIRS 3.0, que descobre agentes, modelos e conexões de IA em ambientes de nuvem, plataformas SaaS e endpoints locais.
Um exemplo real mostra por que isso deixou de ser teoria. Segundo relato de Ian Swanson, vice-presidente de produtos de segurança de IA da Palo Alto Networks, um incidente envolveu invasores usando IA para reconhecimento, ganhando acesso aos prompts de sistema de um workload interno de IA e modificando esses prompts para roubar dados e enviá-los a uma conta de email externa. Swanson argumentou que um AI-BOM poderia ajudar os defensores a comparar o prompt de sistema usado em um momento com um estado posterior já alterado, revelando rapidamente a manipulação.
Sora e o desafio de rastrear modelos de última geração
O Sora é um exemplo perfeito de por que o inventário de modelos precisa evoluir. O modelo de geração de vídeo da OpenAI representa uma nova categoria de sistemas de IA que combinam múltiplas modalidades, processam entradas complexas e geram saídas que podem ser usadas de formas muito variadas. Quando uma empresa integra o Sora em um fluxo de produção de conteúdo, por exemplo, ela está introduzindo um componente com características muito específicas de comportamento, limitações e riscos que precisam ser documentados com a mesma seriedade que qualquer outra dependência crítica de software. O problema é que a maioria das ferramentas de segurança existentes não foi construída para rastrear esse tipo de componente.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
O acesso ao Sora via API também levanta questões importantes sobre controle de uso corporativo. Se um time de marketing começa a usar o modelo para gerar vídeos de campanha sem que o departamento jurídico avalie os termos de uso, sem que TI saiba que dados estão sendo enviados para a API e sem que segurança avalie os riscos de propriedade intelectual envolvidos, isso é Shadow AI em ação. E o AI-BOM seria justamente o mecanismo para garantir que essa adoção seja registrada, avaliada e monitorada de forma contínua, não apenas no momento inicial de integração, mas ao longo de todo o ciclo de vida do uso do modelo dentro da organização.
Modelos multimodais como o Sora também introduzem riscos que vão além das preocupações tradicionais de privacidade de dados. A capacidade de gerar conteúdo visual realista a partir de instruções textuais cria superfícies de risco relacionadas à criação de desinformação, à representação indevida de marcas e pessoas, e ao uso não autorizado de ativos visuais. Um inventário de modelos robusto precisa capturar não apenas onde o modelo está sendo usado, mas como ele está sendo usado, com quais permissões, para quais finalidades e com quais controles de saída ativos. Essa granularidade é o que diferencia um AI-BOM eficaz de uma simples lista de ferramentas aprovadas.
Caminhando rumo a padrões para todo o setor
A camada de padrões ainda está sem definição completa. O AIBOM Generator da OWASP produz inventários de materiais de IA para modelos do Hugging Face no formato CycloneDX alinhado ao SPDX, e o OWASP GenAI Security Project diz que sua iniciativa de AIBOM busca transformar o conceito em ferramentas abertas, verificações de completude e orientação prática para profissionais. Em paralelo, existe um SBOM for AI Tiger Team, facilitado pela CISA mas não adotado como política oficial do governo dos Estados Unidos, que publicou casos de uso para conformidade, gestão de incidentes, risco de modelos de código aberto, risco de IA de terceiros, propriedade intelectual e gestão do ciclo de vida de modelos.
À medida que os agentes de IA se tornam mais comuns e mais autônomos, a pressão por inventário de modelos vai aumentar proporcionalmente. Um ambiente com dezenas de agentes operando em paralelo, cada um com suas próprias conexões, permissões e comportamentos, é um ambiente que simplesmente não pode ser gerenciado de forma manual. As ferramentas de descoberta automática e mapeamento contínuo de componentes de IA vão se tornar tão essenciais quanto os scanners de vulnerabilidade são hoje, e as empresas que começarem a construir essa capacidade agora vão ter uma vantagem significativa quando os requisitos regulatórios se tornarem mais específicos e mais exigentes.
A boa notícia é que o caminho para implementar um inventário de modelos eficaz não precisa começar do zero. Organizações que já têm processos maduros de gestão de SBOMs podem estender esses processos para cobrir componentes de IA, adicionando as dimensões específicas que os modelos exigem. O desafio principal é cultural e organizacional: convencer times de produto, engenharia e negócios de que declarar o uso de ferramentas de IA não é burocracia, é proteção. Quando um incidente acontece e a empresa precisa responder rápido, ter um AI-BOM atualizado e confiável pode ser a diferença entre uma resposta coordenada e eficaz e semanas de investigação tentando descobrir o que estava rodando onde. O AI-BOM não é mais uma ideia interessante para o futuro. É uma necessidade operacional para qualquer organização que leva a sério a segurança dos seus ambientes de inteligência artificial hoje. 🎯
