Inventário de sistemas de IA — também chamado de AI-BOM, "AI bill of materials", por analogia ao SBOM da segurança de software — é o registro completo e vivo de todo sistema de inteligência artificial em uso na empresa: construído internamente, comprado de um fornecedor ou embutido dentro de um SaaS que já está contratado. Para cada sistema, o inventário registra dono, dado processado, nível de autonomia e status de aprovação. É o artefato fundacional de qualquer governança de IA: nenhuma classificação de risco, nenhuma auditoria e nenhum controle fazem sentido sobre um sistema que ninguém sabe que existe. Este guia mostra o que catalogar, onde procurar os sistemas que ninguém registrou ainda e como formatar esse inventário — da planilha inicial ao padrão técnico que empresas maduras já usam para software e estão começando a usar para IA.
O que é um AI-BOM (e por que não é a mesma coisa que a lista de ferramentas aprovadas)
Um AI-BOM não é a lista de ferramentas que o comitê de IA aprovou — é o inventário de tudo que está de fato em produção, aprovado ou não. A analogia com segurança de software é direta: um SBOM (software bill of materials) lista cada componente, biblioteca e dependência que compõe um software, para que a empresa saiba exatamente o que está rodando quando uma vulnerabilidade é descoberta em algum componente. O AI-BOM aplica a mesma lógica a sistemas de IA: modelo, versão, dataset de treino ou de referência, dependências de software, fornecedor e infraestrutura — segundo a definição consolidada pela Palo Alto Networks, que descreve o AI-BOM como "um inventário legível por máquina que lista cada dataset, modelo e componente de software usado para construir e operar um sistema de IA".
Isso o diferencia de dois artefatos vizinhos deste hub, com quem o AI-BOM se conecta mas não se confunde:
- Não é classificação de dado. Governança de dados para IA define o que cada tipo de dado pode fazer dentro de uma ferramenta de IA. O AI-BOM cataloga o sistema em si — o dado é um dos campos que ele registra, não o objeto central.
- Não é gestão de risco de modelo. Gestão de risco de modelo de IA valida e monitora continuamente cada modelo já catalogado, verificando se ele continua calibrado e seguro. O inventário é o que torna essa validação possível em primeiro lugar — sem saber quais modelos existem, não há o que validar.
O inventário é sempre o primeiro artefato, cronologicamente, dos dois. É por isso que o framework de governança de IA da empresa começa pela função Map do NIST AI RMF — mapear o contexto de cada sistema antes de medir ou gerenciar risco, segundo o AI Resource Center do NIST.
Por que sua empresa provavelmente não sabe quantos sistemas de IA usa
Isso não é uma suposição alarmista — é o padrão medido em pesquisa de mercado. O relatório AI Security Readiness da Wiz, com profissionais de segurança em nuvem, encontrou que 87% das equipes já usam algum serviço de IA, mas apenas 13% adotaram controles de postura de segurança específicos para IA (AI-SPM). O motivo aparece na mesma pesquisa: 25% dos respondentes admitem não saber quais serviços de IA estão rodando no próprio ambiente, e 31% apontam a falta de expertise em segurança de IA como o principal obstáculo — o desafio mais citado, à frente de qualquer outro.
Três fontes de sistemas de IA escapam do radar com mais frequência:
- IA embutida em SaaS já contratado. A empresa comprou um CRM, uma ferramenta de produtividade ou uma plataforma de atendimento — e meses depois o fornecedor liga um recurso de IA generativa por padrão, sem que ninguém em compliance seja avisado. O contrato original não previa IA; o inventário, se existir só na cabeça de quem assinou o contrato, não é atualizado.
- Sistemas construídos por uma área de negócio. Comercial, marketing ou operações montam um agente ou uma automação com IA sem passar por TI — o mesmo padrão descentralizado descrito em shadow AI: por que proibir não funciona.
- Ferramentas de uso individual via navegador. Um colaborador usa uma extensão ou um serviço público de IA generativa para acelerar o próprio trabalho, sem que isso passe por nenhum processo de aprovação.
Nenhuma dessas três fontes aparece se o inventário depender só de TI perguntar "quais sistemas de IA vocês usam?" numa reunião. É preciso ir buscar.
O que catalogar: os campos de um inventário de IA completo
Um AI-BOM útil vai além de "nome da ferramenta". A tabela abaixo lista o que registrar, por sistema — os campos mínimos que sustentam qualquer decisão de governança em cima do inventário:
| Campo | O que registrar |
|---|---|
| Nome e fornecedor | Nome do sistema; fornecedor externo ou "desenvolvimento interno" |
| Tipo de origem | Construído internamente, contratado como ferramenta de IA, ou embutido dentro de um SaaS que já existia por outro motivo |
| Área e caso de uso | Quem usa, para qual tarefa, com que frequência |
| Dado processado | Classe de dado (público, interno, confidencial, restrito) — a mesma escala usada em governança de dados para IA |
| Nível de autonomia | O sistema sugere, decide com revisão humana no loop, ou decide e age sozinho |
| Impacto sobre pessoas | Se a saída afeta decisão sobre cliente, colaborador ou terceiro (crédito, contratação, triagem, preço) |
| Status contratual | Se existe contrato de tratamento de dados, cláusula específica de IA e direito de auditoria sobre o fornecedor |
| Dono interno | Quem responde por esse sistema — aprova mudanças, escala incidentes |
| Data da última revisão | Quando o registro foi confirmado como ainda correto |
Esse conjunto de campos é deliberadamente mais amplo que o registro operacional usado por um programa de compliance no dia a dia — detalhado em compliance e IA — porque o inventário aqui é o artefato-fonte: compliance consome esse inventário para classificar risco e montar trilha de auditoria, mas não é quem o constrói do zero. Sistemas de origem "embutido em SaaS" merecem atenção redobrada: eles raramente têm dono claro, porque ninguém no time de compras os tratou como aquisição de IA.
Onde procurar: como descobrir os sistemas que ninguém registrou
Levantar o inventário quase sempre revela mais sistemas do que a empresa imaginava. Nenhuma fonte isolada captura o quadro completo — é preciso cruzar pelo menos três:
- TI e segurança — o que foi provisionado, quais integrações e chaves de API existem, quais extensões de navegador estão instaladas nas máquinas corporativas.
- Financeiro — toda assinatura de SaaS sendo paga hoje, incluindo as que a área contratou sem passar por TI. Uma cobrança recorrente para uma ferramenta desconhecida por TI é, quase sempre, um sistema fora do inventário.
- Pesquisa direta com as áreas — uma pergunta simples e não punitiva ("quais ferramentas de IA vocês usam para o trabalho, mesmo as que não foram formalmente aprovadas?") revela mais do que qualquer varredura técnica, porque o objetivo nesta fase é mapear, não punir.
Para sistemas embutidos dentro de SaaS já contratado, o caminho é revisar os release notes de cada fornecedor relevante — a maioria anuncia quando liga um recurso de IA generativa por padrão — e perguntar diretamente, no próximo ciclo de renovação, se algo mudou desde a assinatura original. Essa pergunta deveria virar cláusula contratual daqui para frente: aviso obrigatório sempre que o fornecedor adicionar IA a um produto já contratado, um dos controles centrais de gestão de risco de fornecedores de IA.
Do inventário informal ao AI-BOM padronizado
Nenhuma empresa começa com um AI-BOM machine-readable. O caminho realista tem três estágios:
Estágio 1 — planilha viva. Uma tabela com os campos da seção anterior, dono claro por linha, revisada em ciclo curto. Suficiente para a maioria das empresas que ainda constrói a primeira versão do inventário.
Estágio 2 — inventário integrado ao processo de compra e desenvolvimento. Todo novo sistema de IA — comprado ou construído — entra no inventário como etapa obrigatória de aprovação, não como tarefa avulsa depois do fato. É quando o inventário deixa de ser levantamento único e vira processo contínuo.
Estágio 3 — formato padronizado e legível por máquina. Para empresas que já praticam SBOM em segurança de software (setores regulados, empresas que desenvolvem produto próprio), o passo natural é estender essa mesma disciplina à IA. Dois formatos técnicos cobrem esse caso hoje: o CycloneDX, padrão mantido pela OWASP, incorporou suporte a Machine Learning Bill of Materials (ML-BOM) a partir da versão 1.5, lançada em junho de 2023 — cobrindo identidade e versão do modelo, datasets de treino e avaliação, dependências de software e assinaturas criptográficas; e o SPDX 3.0.1, que adicionou perfis formais de IA e de dataset como extensão do mesmo padrão já usado para SBOM de software, segundo o resumo da Palo Alto Networks. Nenhum dos dois é exigência legal no Brasil — mas normatizar o formato facilita integrar o inventário a ferramentas de segurança e a auditorias externas, e reduz a chance de o inventário voltar a ser uma planilha desatualizada em seis meses.
O estágio certo para começar depende de onde sua empresa já está — o mesmo diagnóstico de maturidade que orienta a escolha de framework de governança, detalhado em maturidade de IA nas empresas.
O regulamento já trata inventário de modelo como obrigação — não é teoria
O inventário formal de modelos não é uma boa prática hipotética esperando lei nova. No setor financeiro brasileiro, já é regra: a Resolução CMN nº 4.557/2017, que rege a estrutura de gerenciamento de riscos das instituições financeiras dos segmentos S1 a S4, exige em seu Art. 9º que todo modelo relevante usado para gestão de risco passe por avaliação periódica de adequação, robustez e desempenho — e que essa avaliação seja feita por uma unidade independente de quem construiu o modelo. Essa exigência já está em vigor desde 2017, anos antes de "IA generativa" entrar no vocabulário corporativo, e pressupõe algo mais básico ainda: que a instituição saiba, com precisão, quais modelos ela tem para poder avaliá-los. O detalhamento completo de como essa exigência se conecta à validação técnica de cada modelo está em gestão de risco de modelo de IA.
Para empresas fora do setor financeiro, o precedente importa: é o padrão mais maduro já testado em português, e qualquer fornecedor de dado, serviço ou modelo para uma instituição regulada será cobrado pela mesma disciplina de inventário na diligência do cliente.
O que o inventário destrava: da classificação de risco à auditoria
O AI-BOM não é um exercício de documentação isolado — é o insumo que todos os outros controles de governança consomem:
- Classificação de risco por caso de uso. Sem inventário, não há o que classificar. Com ele, o comitê de IA aplica critério de risco (baixo, médio, alto) a cada sistema, o passo seguinte detalhado em compliance e IA.
- Validação e monitoramento de modelo. Gestão de risco de modelo de IA usa o inventário como lista de partida para decidir quais modelos precisam de validação independente antes do deploy e com que frequência revalidar.
- Trilha de auditoria. Auditoria de IA verifica se o processo foi seguido — mas só consegue auditar o que está registrado. Sistema fora do inventário é sistema fora do alcance da auditoria, por definição.
- Due diligence de fornecedor. Gestão de risco de fornecedores de IA usa o campo "status contratual" do inventário para priorizar quais fornecedores exigem revisão contratual mais urgente.
Quem mantém o AI-BOM vivo
Um inventário levantado uma vez e nunca atualizado tem vida útil curta — novos sistemas entram mais rápido do que a maioria das empresas revisa a própria lista. A divisão de responsabilidade que funciona na prática:
| Papel | Responsabilidade |
|---|---|
| Dono do programa (compliance ou risco) | Mantém o inventário atualizado, define a cadência de revisão, cobra as áreas por sistemas não registrados |
| TI e segurança | Fornece visibilidade técnica: integrações, chaves de API, extensões instaladas |
| Financeiro | Sinaliza nova assinatura de SaaS com componente de IA no ciclo de aprovação de despesa |
| Líder de cada área | Declara os sistemas usados pelo time, inclusive os que nasceram informalmente |
| Comitê de IA | Usa o inventário como base para aprovar, classificar e decidir casos-limite — a mesma estrutura de papéis do pilar governança de IA na prática |
Como a Jetpacks apoia o inventário de sistemas de IA
Dentro do método Flight Plan, o inventário de sistemas de IA é o primeiro entregável do Launchpad — o estágio de diagnóstico, com cerca de duas semanas por área, que produz o mapa de impacto real da empresa. O Flight Plan usa esse mapa para desenhar controles por área; o Booster capacita o time a manter o inventário vivo como parte do uso diário, não como tarefa extra de compliance; e o Mission Control acompanha a cobertura do inventário como uma das métricas centrais de adoção com governança. Como parceira oficial da Replit no Brasil, a Jetpacks já aplicou essa abordagem em empresas como Hypera Pharma, Volvo, BMR Medical e C12 Brasil.
FAQ
O que é um inventário de sistemas de IA?
É o registro completo de todo sistema de inteligência artificial em uso na empresa — interno, comprado ou embutido em outro software — com dono, dado processado, nível de autonomia e status de aprovação para cada um. É o primeiro artefato de qualquer programa de governança de IA.
O que é AI-BOM?
AI-BOM ("AI bill of materials") é o nome técnico do inventário de sistemas de IA, por analogia ao SBOM (software bill of materials) usado em segurança de software. Descreve modelo, versão, dataset, dependências e fornecedor de cada sistema de IA, em formato cada vez mais padronizado e legível por máquina.
Qual a diferença entre AI-BOM e SBOM?
O SBOM lista os componentes de um software tradicional — bibliotecas, dependências, versões. O AI-BOM aplica a mesma lógica, mas cobre o que o SBOM não captura: modelo, dataset de treino, proveniência de dados e o comportamento não determinístico do sistema.
Meu inventário deve incluir sistemas de IA embutidos em ferramentas que já uso?
Sim — é justamente essa categoria que mais escapa do radar. Um SaaS contratado antes de ter IA pode ligar um recurso generativo depois, sem aviso a compliance. Revisar release notes e perguntar diretamente no ciclo de renovação do contrato é o jeito mais confiável de capturar esses casos.
Preciso usar um padrão técnico como CycloneDX ou SPDX desde o início?
Não. A maioria das empresas começa com uma planilha bem estruturada, com dono e campos claros por sistema. CycloneDX (com suporte a ML-BOM desde a versão 1.5) e SPDX 3.0.1 fazem sentido quando a empresa já pratica SBOM de software e quer estender essa disciplina à IA.
Com que frequência o inventário de sistemas de IA deve ser atualizado?
No início, revisão mensal captura o volume de sistemas ainda não mapeados. Depois de estabilizado, trimestral costuma bastar — com atualização imediata sempre que um sistema novo entra em uso ou um fornecedor existente adiciona um recurso de IA.
Quem é responsável por manter o inventário de sistemas de IA atualizado?
Um dono claro — geralmente compliance ou a função de risco — que cruza informação de TI, financeiro e das áreas de negócio. Sem esse dono, o inventário nasce numa varredura única e envelhece rápido, porque nenhuma das três fontes sozinha tem visão completa nem incentivo para manter o registro atualizado.
Conclusão: governança começa por saber o que existe
Não existe classificação de risco, validação de modelo ou auditoria que funcione sobre um sistema de IA que ninguém sabe que está em produção. O inventário — o AI-BOM — não é burocracia preparatória: é o mapa sem o qual todo o resto da governança de IA opera às cegas, e a pesquisa da Wiz mostra que a maioria das empresas hoje está exatamente nesse ponto cego, com adoção de IA muito à frente da própria visibilidade sobre ela.
Se sua empresa está adotando IA mais rápido do que consegue mapear o que já está em uso, o diagnóstico gratuito da Jetpacks — uma conversa de 30 a 45 minutos — levanta o primeiro inventário real, cruzando TI, financeiro e as áreas de negócio, dentro do método Flight Plan. É o primeiro passo antes de qualquer outro controle de governança fazer sentido.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.