Um AI bill of materials só é útil se puder responder a duas perguntas: o que foi declarado antes do deployment e o que estava realmente em execução quando uma decisão, um incidente ou uma auditoria ocorreu. Um arquivo JSON válido que não consegue responder às duas perguntas é apenas uma encenação de inventário.
O design prático é um inventário pareado. Gere um registro baseado em padrões durante o build ou a aquisição, observe o sistema ativo em runtime, preserve evidências para cada campo e compare os dois. Bloqueie um release quando um modelo, dataset, runtime, API, ferramenta de agente ou licença crítica não estiver resolvido.
Nível do leitor: Avançado. Este guia é destinado a engenheiros, equipes de segurança, responsáveis por plataformas e líderes de governança técnica que operam sistemas baseados em modelos.
Conteúdo
O que um AI bill of materials deve responder
Um AI bill of materials, geralmente abreviado como AIBOM ou AI BOM, é um inventário legível por máquina dos componentes e das evidências por trás de um sistema de AI. Ele amplia um software bill of materials convencional para além de pacotes e bibliotecas.
O inventário deve permitir que um revisor responda:
A CycloneDX descreve sua capacidade de AI/ML-BOM como uma forma de representar modelos, datasets, configurações, proveniência e dependências. A SPDX 3.0.1 também define um perfil de AI para metadados específicos de AI. Esses são modelos de dados interoperáveis, não substitutos para a própria evidência ausente.
Um model card responde a uma pergunta mais específica: para que este modelo foi projetado, como foi avaliado e onde pode falhar? O artigo original sobre Model Cards propôs uma documentação que abrangesse uso pretendido, condições de avaliação e desempenho entre grupos relevantes. Um data card documenta as origens de um dataset, sua coleta e anotação, o uso pretendido e as decisões que moldam o desempenho downstream; o artigo sobre Data Cards relata aprendizados de mais de 20 deployments.
Mantenha ambos. Um model card ou data card fornece contexto humano. Um AIBOM conecta esses documentos a um inventário versionado do sistema.
Por que arquivos AIBOM válidos ainda podem conter evidências fracas
Um estudo de julho de 2026 testou essa distinção em escala. Os autores coletaram um snapshot de 2.942.466 registros públicos de modelos do Hugging Face, mantiveram 97.940 modelos com mais de 100 downloads e geraram AIBOMs em CycloneDX com o OWASP AIBOM Generator. Eles verificaram uma amostra de 100 artefatos comparando-os aos relatórios do generator e depois mediram a presença de campos no conjunto completo.
A pontuação média de completude relatada foi de 54,31 em 100. Os campos estruturais obrigatórios estavam presentes em 100% dos artefatos gerados. A documentação de model cards teve média de 19,51%.
Essa diferença é o resultado importante. O arquivo pode ser estruturalmente válido enquanto as informações necessárias para uma decisão estão ausentes.
Os resultados por campo foram ainda mais claros:
| Campo no AIBOM gerado | Presente |
|---|---|
| --- | ---: |
| Licença | 73,14% |
| Dataset | 39,35% |
| Hyperparameters | 25,40% |
| Limitações técnicas | 16,74% |
| Avaliação de riscos de segurança | 9,76% |
| Descrição significativa | 0,22% |
| Consumo de energia | 0,02% |
O campo de descrição apareceu em quase todos os artefatos, mas apenas 211 das 97.940 descrições continham informações além de texto placeholder. Uma verificação de presença no schema contaria as outras descrições como completas.
O que os autores mediram: cobertura de campos e categorias em AIBOMs gerados a partir de um snapshot público filtrado do Hugging Face.
O que eles inferiram: a documentação de model cards e referências externas explica grande parte da diferença entre artefatos fracos e mais robustos.
O que eles não estabeleceram: se algum modelo era seguro, justo, performático, legalmente utilizável ou apropriado para um deployment específico.
Os autores também alertam que os resultados dependem da API do Hugging Face, da lógica de extração do generator e de um snapshot que exclui modelos com 100 downloads ou menos. Registries privados, modelos gated, outras plataformas de hospedagem e mudanças posteriores nos repositórios podem apresentar resultados diferentes. O resultado apoia a validação semântica. Ele não define um limite universal de pontuação.
O inventário de build-time e o inventário de runtime resolvem problemas diferentes
Um AIBOM de build-time registra a intenção. Um inventário de runtime registra a observação.
| Pergunta | Evidência de build-time | Evidência de runtime |
|---|---|---|
| --- | --- | --- |
| Qual modelo deve ser enviado? | Lockfile, manifest, registro de aquisição, digest do modelo | ID do modelo carregado, endpoint, digest da image, configuração de serving |
| Quais dados devem estar disponíveis? | Declarações de treinamento e avaliação, fontes de retrieval aprovadas | Vector stores conectados, datasets montados, serviços de dados ativos |
| Quais ferramentas um agente pode chamar? | Registro de ferramentas, policy, MCP servers e APIs declarados | Endpoints descobertos, integrações ativas, configuração observada |
| Qual software dá suporte à inferência? | SBOM de pacotes e container | Image em execução, runtime, drivers, accelerators |
| Quais restrições se aplicam? | Licença, model card, data card, referência contratual | Provider atual, região, rota, versão da policy |
| O sistema aprovado sofreu drift? | Baseline para comparação | Evidências para comparar com o baseline |
A evidência de build-time sozinha não detecta mudanças emergenciais, deployments shadow, tags mutáveis, rerouting do provider e drift de configuração. A observação de runtime sozinha pode identificar um nome de processo ou endpoint sem saber sua finalidade aprovada, licença, proveniência de treinamento ou limite de avaliação.
O Google disponibilizou o k8s-aibom como open source em 14 de julho de 2026 para explorar o lado de runtime. O controller observa o estado de workloads e pods do Kubernetes, aplica regras de detecção e emite documentos ML-BOM em CycloneDX 1.6. A cobertura documentada inclui inference runtimes, agent frameworks, vector databases, training jobs e evaluation harnesses. Ele funciona sem um DaemonSet privilegiado ou acesso ao kernel.
O projeto apresenta um ponto arquitetural útil: AIBOMs de build-time e runtime são complementares. Ele também ainda é um software inicial. O repositório classifica a v1.0 como alpha e adequada para casos de uso de observação não críticos. Ele não fornece uma image hospedada nem um repositório Helm, e seu `NoopVerifier` atual não consegue marcar uma identidade como verificada criptograficamente.
Um maintainer do NVIDIA AICR propôs uma integração entre k8s-aibom e AICR que conectaria as observações de runtime do k8s-aibom à intenção de deployment e às attestations assinadas do AICR. O autor descreve o objetivo como obter evidências de que aquilo que uma equipe fez deploy é o que o sistema está executando. A issue não tem implementação, responsável ou milestone vinculados. Trate-a como uma proposta de practitioner, não como um roadmap oficial ou design concluído.
Não transforme um novo controller em uma recomendação universal de produto. Use o padrão: combine o estado declarado com o estado observado, retenha evidências e torne a incerteza visível.
_Um AI bill of materials útil conecta a intenção de build às evidências de runtime, verificações semânticas e uma decisão versionada._
As sete camadas que vale a pena registrar
O schema exato depende do seu padrão e do deployment. As camadas a seguir formam um mínimo prático para um inventário de produção.
1. Identidade do modelo
Registre o fornecedor, a família do modelo, a revisão ou digest imutável, o formato, o modelo base, os adapters, a quantização, o tokenizer e a rota de serving. Um alias amigável como `support-model` é útil para as pessoas, mas insuficiente para rastreabilidade.
Para uma API externa, registre o identificador estável do modelo do provider e a rota do gateway que o selecionou. Se o provider puder atualizar silenciosamente o modelo por trás de um alias, rotule a revisão como não resolvida em vez de inventar precisão.
2. Dependências de dados e retrieval
Registre os datasets declarados de treinamento, fine-tuning, avaliação e calibração quando essa informação existir. Para um sistema de RAG, adicione as coleções de origem, o embedding model, a versão de chunking, o serviço de vector store, a access policy e o limite de atualização.
Armazene identificadores de datasets, versões, hashes, contratos ou referências controladas de catálogo. Não copie registros brutos de clientes nem exemplos privados de treinamento para o AIBOM.
Quando uma equipe cria sistemas de dados customizados com Next.js e agentes de AI→, a versão do schema, o limite de migration e os serviços conectados pertencem ao contexto do sistema, mesmo quando não são artefatos do modelo.
3. Runtime e software
Conecte o inventário de AI ao SBOM comum. Registre o digest do container, o inference engine, o framework, as bibliotecas relevantes, a classe de driver e accelerator e a configuração que pode alterar o comportamento do modelo.
Isso importa porque os mesmos weights podem se comportar de forma diferente após uma mudança de tokenizer, attention backend, caminho de quantização ou serving engine. A análise de por que mais AI tokens mudam a conta de compute→ mostra por que um registro de deployment precisa do orçamento e da configuração de runtime, não apenas do nome do modelo.
4. Ferramentas, APIs e permissões de agentes
Liste as ferramentas que um agente pode alcançar, não todas as ferramentas instaladas em algum lugar da empresa. Inclua model gateways, MCP servers, ferramentas de browser ou execução de código, APIs externas e a referência da policy que governa cada ação.
O inventário não impõe autorização. Combine-o com controles determinísticos. O artigo sobre permissões de agentes de AI→ explica por que a autodisciplina de um modelo não é um limite de controle de acesso.
5. Avaliação e limites operacionais
Faça referência ao conjunto exato de avaliação, à versão do evaluator, aos thresholds, à data e às condições usadas para aprovação. Registre modos de falha conhecidos, usos pretendidos e excluídos, comportamento de fallback, responsável pelo monitoring e data de expiração da decisão.
Não escreva “avaliação aprovada” sem a identidade do teste. Um modelo alterado com uma string de resultado inalterada é uma evidência fraca.
6. Direitos, policy e proveniência
Registre licenças de modelos e datasets, restrições de uso, termos de redistribuição, repositórios de origem, model cards, data cards, artigos, aprovações e attestations. Armazene referências e hashes quando a fonte tiver controle de acesso.
Essa camada apoia a revisão. Ela não decide uma questão jurídica. Informações de direitos ausentes ou conflitantes devem ser encaminhadas à pessoa responsável por essa decisão.
7. Ownership e ciclo de vida
Todo registro precisa de um owner, finalidade do sistema, ambiente, horário de criação, horário de observação, versão substituída e regra de retenção. Sem ownership, um inventário se torna um arquivo de fatos abandonados.
Inclua um ID estável do sistema que sobreviva a redeployments. Um AIBOM versionado deve mostrar o histórico do que mudou, quem aceitou a mudança e quais evidências apoiaram essa decisão.
Rotule cada fato como declarado, inferido, verificado ou não resolvido
Um AIBOM deve carregar o status da evidência no nível do campo. Um único rótulo para todo o documento esconde informações demais.
Os três primeiros rótulos descrevem forças de evidência diferentes. “Declarado” não é uma forma mais fraca de escrever “verificado”. Uma declaração do fornecedor pode ser a única fonte disponível para dados de treinamento, enquanto um digest de image pode ser verificado mecanicamente.
O projeto k8s-aibom atualmente implementa `declared`, `inferred` e `unresolved`, com localizadores de evidência para atributos. O README coloca o status criptográfico `verified` no roadmap, em vez de afirmar que ele já existe. Preserve essa honestidade no seu próprio sistema.
Um registro conceitual poderia ser assim:
{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }
Este é um esboço de design, não um documento CycloneDX ou SPDX em conformidade. Use o schema e o validator do padrão escolhido para o artefato real.
Um workflow reproduzível de AIBOM
Etapa 1: defina o limite do sistema
Nomeie a aplicação, os ambientes, os owners e as decisões voltadas ao usuário que estão no escopo. Decida se o inventário cobre um único endpoint de modelo, um workflow de agente ou um produto completo.
Um limite como “toda AI” não pode ser testado. “O agente de suporte em produção e todo serviço que possa alterar sua resposta ou suas ações” pode.
Etapa 2: colete evidências de build e aquisição
Gere o SBOM comum, resolva os identificadores de modelos e datasets, capture digests imutáveis e vincule model cards, data cards, licenças, avaliações e aprovações.
O OWASP AIBOM Generator pode extrair metadados do Hugging Face para CycloneDX 1.6 e reportar campos ausentes. Trate sua saída como um inventário inicial. O estudo em larga escala mostra por que um campo preenchido automaticamente ainda precisa de uma verificação de conteúdo.
Etapa 3: emita um documento padrão
Escolha um formato que seus consumidores possam analisar. A CycloneDX fornece uma capacidade de AI/ML-BOM e um guia de implementação. A SPDX 3 fornece perfis de AI e dataset.
A escolha do formato deve seguir os sistemas receptores, o policy engine, o pipeline de attestation e os requisitos dos clientes. Evite manter dois formatos, a menos que um consumidor real precise de ambos.
Etapa 4: enriqueça o que a automação não pode saber
Atribua owners para preencher uso pretendido, limitações, proveniência de datasets, condições de avaliação, direitos e decisões de risco. Rejeite placeholders como “N/A”, “modelo padrão” ou texto de marketing copiado quando o campo for crítico para uma decisão.
Exija um motivo explícito para valores desconhecidos. “O fornecedor não divulga os dados de treinamento” é uma evidência melhor do que um array vazio, pois distingue trabalho ausente de informação indisponível.
Etapa 5: observe o deployment ativo
Colete IDs de modelos em runtime, digests de images, endpoints, stores conectados, ferramentas de agentes e configurações por meio do mecanismo com menos privilégios disponível. No Kubernetes, isso pode ser um controller que observa a API. Em uma stack de API gerenciada, pode ser a configuração do gateway, manifests de deployment, respostas do provider e audit logs.
Não alegue verificação de runtime quando o scanner apenas comparou uma string. Marque como inferido e retenha a evidência correspondente.
Etapa 6: valide sintaxe, semântica e drift
Execute três verificações separadas:
A primeira verificação é automatizada. A segunda precisa de regras de domínio e, para alguns campos, revisão humana. A terceira precisa de registros versionados e de um limite estável de comparação.
Etapa 7: assine, armazene, compare e expire
Faça o hash do artefato, vincule-o ao build ou deployment, armazene-o em um sistema de evidências append-only ou controlado e produza um diff legível por humanos. O AIBoMGen é um protótipo de pesquisa que combina a captura do modelo e do ambiente com hashes, assinaturas e attestations in-toto durante o treinamento.
Assinaturas protegem a integridade após a criação. Elas não tornam verdadeira uma declaração incompleta ou falsa.
Defina uma data de expiração ou revisão. Um inventário perfeito do último trimestre não descreve hoje um sistema de produção mutável.
Transforme o inventário em um gate de release
Um inventário se torna útil quando muda uma decisão. Defina a policy antes da janela de release.
| Condição | Ação padrão | Motivo |
|---|---|---|
| --- | --- | --- |
| A identidade de um modelo ou runtime crítico não está resolvida | Bloquear | O componente em deployment não pode ser rastreado |
| O runtime contém um modelo, API, ferramenta ou data store não declarado | Bloquear e investigar | O limite aprovado sofreu drift |
| A revisão do modelo mudou, mas a referência de avaliação não mudou | Bloquear | A evidência de aprovação não cobre o candidato |
| Uma licença ou restrição de uso obrigatória está ausente | Encaminhar para revisão do responsável; bloquear quando a policy exigir | Os direitos não podem ser inferidos pela disponibilidade |
| Uma inferência heurística entra em conflito com uma declaração | Bloquear ou colocar a evidência em quarentena | Pelo menos uma fonte está errada ou desatualizada |
| Uma descrição não crítica não tem detalhes | Criar um item de remediação com prazo definido | A lacuna pode não justificar interromper o serviço |
| O AIBOM mudou apenas porque o horário de observação mudou | Permitir | Nenhum drift material do sistema ocorreu |
Ajuste a severidade ao sistema. Um assistente de escrita e uma ferramenta de decisão médica não devem compartilhar um único threshold universal.
Acompanhe quatro métricas operacionais:
Não otimize pelo número de campos preenchidos. Isso recriaria exatamente a falha exposta pelo estudo de completude.
O mesmo princípio de sistemas aparece na análise de atividade de code agents e infraestrutura→: a capacidade do modelo é apenas uma parte do sistema em deployment. Runtime, ferramentas, roteamento e controles operacionais determinam o que os usuários realmente recebem.
Mantenha secrets e dados pessoais fora
É provável que um AIBOM circule entre engenharia, segurança, auditores, clientes e sistemas automatizados. Trate-o como um inventário, não como um secret store.
Não inclua:
Faça referência a secrets pelo caminho do secret manager ou por um identificador lógico, sem incluir o valor. Faça referência a datasets sensíveis por meio de um ID de catálogo governado, versão, classificação, owner e hash de integridade. Aplique controle de acesso ao artefato completo quando até mesmo seus metadados forem sensíveis.
O que um AIBOM não pode provar
Um AI bill of materials melhora a rastreabilidade. Ele não prova:
O estudo de completude de julho mede cobertura de documentação, não qualidade do modelo. O repositório k8s-aibom afirma explicitamente que sua saída não certifica conformidade. Ambas as limitações são importantes.
Use o AIBOM como um mapa entre uma decisão e evidências inspecionáveis. Combine-o com avaliação, autorização, monitoring, resposta a incidentes, controles de privacidade e revisão responsável. O mapa torna esses processos mais rápidos porque informa a cada revisor qual sistema está sendo avaliado.
Perguntas frequentes
O que é um AI bill of materials?
Um AI bill of materials é um inventário legível por máquina dos modelos, datasets, software, runtimes, ferramentas, proveniência, restrições e evidências por trás de um sistema de AI. Um AIBOM útil identifica versões imutáveis, owners, fatos não resolvidos e mudanças entre o estado aprovado e o estado ativo.
Um AI BOM é igual a um SBOM?
Não. Um SBOM inventaria componentes de software e dependências. Um AI BOM conecta esse inventário de software a componentes específicos de AI, como modelos, datasets, adapters, avaliações, usos pretendidos, limitações e rotas de runtime. Um sistema de AI em produção normalmente precisa dos dois.
Devo usar CycloneDX ou SPDX para um AIBOM?
Use o formato compatível com suas ferramentas downstream e consumidores de evidências. A CycloneDX tem uma capacidade documentada de AI/ML-BOM; a SPDX 3 tem perfis de AI e dataset. Valide primeiro um formato canônico. Adicione um segundo apenas quando uma policy, cliente ou integração exigir isso.