O Inventário de Materiais de IA: Shadow AI, k8s-aibom e Conformidade Comprovável

Você não governa um inventário que não tem. A maioria das empresas rodando IA em produção não consegue responder à primeira pergunta que um regulador vai fazer: quais modelos, frameworks de agente e bancos vetoriais estão vivos nos nossos clusters agora, e conseguimos provar isso daqui a seis meses? A resposta do Google saiu como open-source em julho de 2026. O k8s-aibom gera um Inventário de Materiais de IA direto de um cluster Kubernetes em execução, sem acesso privilegiado, e o grava em um registro que não pode ser alterado depois.

Segundo o anúncio do Google Cloud, o k8s-aibom varre recursos de Deployment, StatefulSet, DaemonSet, Job e KServe. Ele identifica runtimes de IA como vLLM, Triton e Ollama. Encontra frameworks de agente como LangChain, AutoGen e CrewAI. Cataloga bancos vetoriais como Milvus, Qdrant e pgvector. A saída é um ML-BOM CycloneDX 1.6, o mesmo formato legível por máquina que o mundo de supply chain de software já trata como padrão para descrever de que um sistema é feito.

O nome é deliberado. O Software Bill of Materials virou infraestrutura obrigatória depois do Log4Shell e da ordem executiva americana sobre segurança de cadeia de suprimentos, porque ninguém conseguia responder rápido o suficiente a “quais dos nossos sistemas embarcam essa biblioteca vulnerável?”. O Inventário de Materiais de IA é essa primitiva para a era dos agentes. Ele responde a uma pergunta mais estreita e mais urgente: qual IA está de fato rodando, sob controle de quem, e contra qual política.

Shadow AI é um problema de inventário antes de ser um problema de política

A sequência típica de falha é silenciosa. Um cientista de dados sobe um pod Ollama para testar um modelo local. Um squad de produto pluga um agente LangChain num serviço sem avisar a segurança da plataforma. Alguém conecta pgvector a um namespace para um protótipo de retrieval que nunca é desligado. Nada disso aparece em um registro central. A segurança descobre a topologia durante um incidente, ou durante uma auditoria, que é o pior momento possível para começar a desenhar o mapa.

Política escrita sobre uma superfície desconhecida é teatro. Você pode publicar um padrão de uso de IA, exigir model cards e obrigar revisão humana, mas cada um desses controles assume que você sabe onde a IA está. O registro é o substrato do qual todo controle downstream depende, e até agora ele era mantido à mão, num wiki, desatualizado no dia em que foi escrito.

O k8s-aibom ataca isso diretamente com um modelo de confiança em três níveis. Cada componente encontrado é marcado como Declared quando uma configuração explícita o nomeia, Inferred quando um padrão sugere fortemente sua presença, ou Unresolved quando a ferramenta vê um sinal que não consegue classificar. O nível Unresolved é o interessante. Ele converte shadow AI de um risco invisível em uma fila revisável, com um nome atrelado a cada linha. Em vez de “achamos que rodamos alguns modelos em algum lugar”, o time de plataforma recebe uma lista, ordenada por confiança, que uma pessoa consegue triar em uma tarde.

As escolhas de projeto são o que torna isso auditável

Ferramentas de descoberta são fáceis de construir mal. As que exigem um sidecar privilegiado, uma sonda eBPF ou uma mutação em cada pod spec são vetadas pelo time de plataforma no primeiro dia, porque o custo do instrumento supera o valor do inventário. O k8s-aibom roda sem privilégio, sob uma Workload Identity mínima, com roles/storage.objectCreator e nada além disso. Sem sidecars. Sem eBPF. Sem mudança na forma como os workloads são definidos. Essa combinação é o que faz uma ferramenta de segurança passar pela revisão de mudança em vez de ficar presa nela.

Duas outras propriedades importam para quem precisa defender a saída em uma auditoria. Primeiro, a execução é determinística: um estado de cluster idêntico produz BOMs byte a byte idênticos, o que significa que o artefato se encaixa em GitOps e faz diff limpo, então um revisor vê exatamente o que mudou entre dois pontos no tempo. Segundo, a imutabilidade é imposta no momento da escrita. Os BOMs caem no Cloud Storage sob uma pré-condição DoesNotExist, então o objeto ou é escrito uma vez ou falha. Um atacante que comprometa o cluster não consegue reescrever silenciosamente o inventário de ontem para esconder o que estava rodando. O registro de auditoria vira evidência, não um log mutável que um adversário determinado consegue lavar.

Essa é a propriedade que separa uma trilha de auditoria real de um dashboard. Um dashboard mostra o estado atual. Um BOM imutável, datado e conforme o padrão diz a um regulador o que era verdade numa data específica, e permite que você prove que não editou a história depois.

O mapeamento regulatório é concreto

O valor aqui está no alinhamento com obrigações que já são lei ou padrão. Um ML-BOM gerado em runtime encaixa nelas com precisão, e isso importa mais do que qualquer alegação de desempenho.

O EU AI Act, no Artigo 12, exige que sistemas de IA de alto risco mantenham logs automáticos e preservem a rastreabilidade da sua operação ao longo do ciclo de vida. Um inventário imutável e datado dos componentes de IA em produção é exatamente o tipo de registro gerado automaticamente para o qual essa obrigação foi escrita. O Artigo 50 acrescenta deveres de transparência sobre sistemas de IA e suas saídas, e não há como ser transparente sobre um sistema que você não catalogou. O NIST AI Risk Management Framework abre com sua função MAP, que é inventário e contexto antes de qualquer outra coisa. A ISO/IEC 42001, o padrão de sistema de gestão de IA, trata o inventário de ativos como um controle fundacional, do mesmo jeito que a ISO 27001 faz para segurança da informação. Em cada um desses frameworks, a primeira obrigação é saber o que você tem, e o BOM é o artefato concreto que cumpre isso.

Escrevemos antes sobre a pilha de procedência de conteúdo e o precedente PhotoDNA, que governa de onde um artefato veio. O inventário fica a montante dessa pergunta. Procedência descreve uma saída única e sua origem. O ML-BOM descreve a maquinaria: quais modelos, agentes e bancos existem no cluster que produziu qualquer saída. Você precisa dos dois, e o inventário é o que a maioria dos programas não tem.

Uma ressalva que vale dizer com clareza. A fonte é um único fornecedor, dentro da narrativa GKE do Google, e ainda carece de validação independente. O valor durável está no padrão e no mapeamento, acima de qualquer ferramenta específica. CycloneDX 1.6 ML-BOM é um formato aberto, as obrigações regulatórias são neutras de fornecedor, e o padrão de projeto (descoberta em runtime sem privilégio gravando registros imutáveis) é portável para qualquer plataforma Kubernetes. Trate o k8s-aibom como a primeira implementação de referência crível de uma primitiva que está prestes a virar requisito básico.

Faça isto agora

Rode uma passada de descoberta contra um cluster de produção neste trimestre, mesmo que grosseira, e produza um primeiro ML-BOM. Busque enxergar o seu nível Unresolved antes de perseguir um registro perfeito, porque essa lista é o seu shadow AI, e o tamanho dela é a medida honesta de quanto do seu parque de IA você estava governando na fé. Depois decida onde esse BOM mora, quem revisa as linhas Unresolved, e como você vai mostrá-lo a um auditor que perguntar o que estava rodando em uma data dada. O inventário é a fundação sobre a qual todo controle de IA que você implantar no ano que vem vai se apoiar. Construa antes que o regulador peça.

Fontes

Google Cloud. “Introducing k8s-aibom on GKE for Automated AI Bills of Materials.” Julho de 2026.

A Victorino ajuda empresas a construir o inventário e os registros de auditoria de IA que sobrevivem ao escrutínio regulatório: contato@victorino.com.br | www.victorino.com.br