Inventário de IA: descobrir modelos, agentes e dados antes de qualquer controle

Segunda-feira, dia um do plano de cinco dias para montar o inventário de inteligência artificial. A equipe da rede varejista de operação nacional que atravessa esta série começou pelo caminho óbvio: pedir a lista. Descobriu, antes do almoço, que não existia uma lista. Existiam quatro.

Tecnologia tinha a relação de software homologado, que não continha nenhum dos recursos de IA ativados por atualização de fornecedor. Compras tinha os contratos, que não distinguiam plataforma com IA de plataforma sem. Segurança tinha os tokens de acesso emitidos para provedores externos, sem saber qual aplicação usava cada um. E o jurídico tinha os aditivos de tratamento de dados, assinados para três fornecedores, quando o consumo real envolvia mais de dez. As quatro listas eram verdadeiras, parciais e incompatíveis entre si.

Descobrir é a primeira capacidade da torre de controle de IA porque nenhuma das outras quatro funciona sem ela. Não se governa, protege, observa ou mede o que não se sabe que existe. Esta peça é sobre como enxergar.

O cenário é ilustrativo e não descreve nenhuma organização específica. O estudo de caso que fecha esta série o desenvolve por completo.

Um inventário de IA não é uma lista de software

O primeiro erro de quem monta inventário de IA é tratá-lo como extensão do inventário de software: uma linha por ferramenta, com nome, fornecedor e licença. Isso captura a menor parte do que importa. Um sistema de inteligência artificial em operação é um conjunto de seis classes de ativo, e o inventário precisa de todas.

Modelos. Quais modelos estão em uso, de qual provedor, em qual versão, acessados por qual via: interface de programação de terceiro, modelo hospedado pela própria organização, ou recurso embutido em uma plataforma contratada. A terceira via é a mais numerosa e a menos lembrada.

Agentes e assistentes. O que consome os modelos para fazer algo: o assistente de atendimento, o agente que responde perguntas sobre dados, o assistente de código de cada desenvolvedor. Para cada um, o que ele pode fazer além de responder: quais ações executa, em quais sistemas, com qual limite.

Prompts e instruções de sistema. O texto que define o comportamento de cada assistente, com versão e data. A camada de Inteligência do Impulso já diz que prompt é código; o inventário é onde essa afirmação vira registro.

Conexões, ferramentas e credenciais. Os servidores de contexto conectados aos assistentes de código, as integrações que os agentes acionam, as chaves e tokens que cada conexão usa, com a data em que foram criados e a última vez que alguém os revisou. É a classe que a rede varejista descobriu quase inteira só no dia um, ao ler os arquivos de configuração dos assistentes de código.

Dados. Para cada agente ou modelo, o que ele lê, o que ele escreve e o que sai da organização em direção a um provedor externo. Esta classe merece seção própria, mais adiante.

Identidades. Quem, humano ou não humano, tem acesso a cada ativo, com qual permissão. Contas de serviço compartilhadas aparecem aqui como o que são: um ativo sem dono individual.

Seis classes, uma ficha por ativo, e uma regra: ativo sem dono nomeado é uma linha incompleta, não uma linha pronta.

Cinco fontes de descoberta, da mais barata à mais humana

Nenhuma fonte sozinha entrega o inventário. As cinco, combinadas, entregam quase tudo, e vale conhecê-las na ordem de custo.

Código e configuração. A fonte mais barata e a mais reveladora. Uma varredura dos repositórios em busca de bibliotecas de provedores de IA nos manifestos de dependência, de endereços de serviços gravados em arquivos de configuração, de arquivos de conexão de assistentes de código e de credenciais deixadas em texto claro devolve, em horas, a parte do inventário que nenhuma entrevista revelaria. É análise estática: lê o ambiente parado, sem executar nada, contra um catálogo de assinaturas conhecidas, e por isso é barata o bastante para rodar toda semana.

Plataformas contratadas. A revisão dos contratos vigentes e das configurações de cada plataforma, procurando recursos de IA ativados por atualização. Foi assim que a rede varejista encontrou o resumo automático de conversas que enviava o texto integral das interações ao modelo do fornecedor.

Tráfego e identidade. O registro de saída de rede filtrado por domínios de provedores de IA, e o diretório de identidades filtrado por tokens e contas de serviço emitidos para esses provedores. Não diz o que a aplicação faz, mas diz que ela existe, o que basta para abrir uma linha e ir atrás do dono.

Finanças. Faturas de cartão corporativo e reembolsos de despesa filtrados por fornecedores de IA. É a única fonte que enxerga a adoção individual em conta pessoal, e ela costuma surpreender.

Pessoas. Uma pesquisa curta, explicitamente sem punição, perguntando que ferramentas de IA ajudam no trabalho. Entra por último porque é a fonte mais cara em atenção humana e a menos completa, mas é a única que revela o motivo por trás de cada adoção, e o motivo é o que a governança precisa entender para oferecer um caminho aprovado.

Há uma armadilha a evitar nessa combinação. Ferramentas de inventário que leem apenas registros formais, como catálogos de modelos ou portais de aprovação, inventariam apenas o que alguém já registrou. O ponto inteiro da descoberta é encontrar o que ninguém registrou, e isso exige as fontes que leem o ambiente como ele é, código, configuração, tráfego e fatura, não como ele deveria ser.

Descoberta contínua, não inventário anual

Um inventário de IA começa a envelhecer no dia em que é concluído. Entre a segunda-feira do dia um e a sexta-feira do dia cinco, a rede varejista ganhou duas conexões novas e uma atualização de plataforma. O documento produzido na sexta já descrevia um ambiente que não existia mais.

A solução não é inventariar mais vezes; é transformar o inventário em processo com gatilhos. Um repositório novo ou uma dependência nova disparam a varredura estática. Um contrato novo ou uma atualização de plataforma disparam a revisão de recursos embutidos. Um token novo emitido para um domínio de provedor abre uma linha automaticamente, com dono a preencher. Uma fatura nova de um fornecedor de IA gera uma pergunta para quem a aprovou. A pesquisa com pessoas roda em cadência fixa, semestral costuma bastar.

O catálogo de assinaturas que a varredura usa também precisa de manutenção, porque provedores, bibliotecas e padrões de conexão mudam. Um catálogo versionado, com dono, é a diferença entre uma descoberta que continua encontrando e uma que só encontra o que existia no ano em que foi configurada.

A ficha de cada ativo já tem padrão

A organização não precisa desenhar do zero o que registrar sobre cada ativo. Existe uma convergência recente de padrões públicos em torno do conceito de lista de materiais de inteligência artificial, uma extensão para IA da lista de materiais de software que as equipes de segurança usam há anos para responder, em minutos, se são afetadas por uma vulnerabilidade recém-publicada.

Três referências organizam o campo. O formato CycloneDX, projeto da OWASP ratificado como norma pela Ecma International, tem suporte a componentes de aprendizado de máquina desde 2023 e permite descrever, em um mesmo documento, software, modelos e conjuntos de dados. O formato SPDX, mantido pela Linux Foundation e publicado como norma ISO em versão anterior, ganhou em 2024 perfis dedicados a sistemas de IA e a conjuntos de dados, cobrindo modelos, dados de treinamento, templates de prompt e agentes. E, em maio de 2026, as agências de cibersegurança dos países do G7 e da União Europeia publicaram orientação conjunta definindo os elementos mínimos de uma lista de materiais de IA, organizados em sete grupos. A lei europeia de IA, por sua vez, exige documentação técnica estruturada para sistemas de alto risco, com obrigações que entraram em vigor em agosto de 2026 e prazos ainda em discussão para partes do texto.

O uso prático desses padrões, para quem está começando, não é adotá-los por inteiro no primeiro mês. É emprestar a estrutura de campos, que já foi debatida por muita gente, e preencher o que couber. Uma ficha mínima tem dez campos: identificador, classe do ativo, dono com mandato, caso de uso ou objetivo que serve, provedor e residência dos dados, dados que lê, escreve e envia para fora, identidades e permissões, versão, data de aprovação e data da última revisão, e status, que vale três valores, experimental, ativo ou desativado. Quando a organização crescer para o padrão completo, os dez campos já estarão lá.

Os dados são a coluna que mais importa

Entre as seis classes de ativo, a de dados é a que responde às perguntas mais caras, e por isso merece o maior cuidado no preenchimento.

Para cada agente ou modelo, três perguntas. O que ele lê: quais bases, tabelas, documentos ou repositórios de contexto ele consulta para responder ou decidir. O que ele escreve: em quais sistemas ele registra, altera ou cria informação. E o que sai: que dado é enviado a um provedor externo a cada chamada, em qual classificação, sob qual base legal e para qual país.

A terceira pergunta é a que a rede varejista não sabia responder sobre o resumo automático de conversas, e é a que a autoridade de proteção de dados fará primeiro. A camada de Segurança do Impulso já pede classificação de dados com fronteira declarada; o inventário é onde a fronteira de cada ativo fica escrita. E a camada de Fontes de dados já pede uma origem da verdade por entidade; o inventário de IA, ele próprio, precisa de uma, porque quatro listas verdadeiras e incompatíveis não são inventário, são o problema que o inventário resolve.

O que o Impulso já dizia sobre isso

A primeira coisa que a etapa de Contexto coleta, antes de qualquer conversa sobre tecnologia, é o inventário do que já existe, com uma frase que atravessa o framework inteiro: você não muda o que não enxerga. A camada de Plataformas manda inventariar o que já está contratado antes de comprar qualquer coisa nova, e é exatamente onde os recursos de IA embutidos se escondem. A camada de Fontes de dados exige uma origem da verdade por entidade. A camada de Governança exige dono nomeado. A camada de Segurança exige classificação com fronteira.

O que a capacidade Descobrir da torre de controle acrescenta é a continuidade e a especialização: um inventário que se atualiza por gatilho, com as seis classes de ativo que só sistemas de IA têm, e uma ficha que segue padrão público. É a primeira proposição do framework, conexão inteligente do que já existe, aplicada ao ato de enxergar o que existe.

Como tornar o inventário contínuo em trinta dias

Um plano de cinco dias, detalhado no estudo de caso que fecha esta série, produz a primeira lista. Este plano transforma a lista em processo.

Semana 1, fonte oficial e ficha. Declarar uma única fonte como inventário oficial de IA, com dono nomeado, e migrar para ela as quatro listas parciais, reconciliando divergências uma a uma. Adotar a ficha de dez campos para cada linha, aceitando lacunas declaradas em vez de campos preenchidos por suposição.

Semana 2, varredura automática. Colocar a análise estática de código e configuração para rodar em cadência semanal contra um catálogo de assinaturas versionado. Toda linha nova que ela encontrar entra com status experimental e um dono a nomear em até cinco dias úteis.

Semana 3, gatilhos. Ligar os quatro gatilhos restantes: contrato ou atualização de plataforma, token emitido para provedor de IA, fatura de fornecedor de IA, e a cadência da pesquisa com pessoas. Cada gatilho abre uma linha ou uma pergunta, nunca fica em silêncio.

Semana 4, reconciliação e cobertura. Comparar o inventário oficial com cada uma das cinco fontes e medir cobertura: que fração do que cada fonte enxerga já está na lista. A fração que falta é o trabalho do mês seguinte, e o número em si é a primeira métrica da torre de controle.

Ao fim de trinta dias, a organização deixa de ter uma lista e passa a ter uma capacidade. É a base sobre a qual as outras quatro se apoiam.

Para aprofundar

Esta peça faz parte da série sobre a torre de controle de IA e trata da primeira capacidade. O estudo de caso que fecha a série, Torre de controle de IA: governar o que já entrou na operação, apresenta o cenário completo, as cinco capacidades e o plano de cinco dias que produz a primeira lista. As outras quatro capacidades estão em Segurança de IA, Observabilidade de IA, Métricas de valor em IA e Estratégia de IA. A base metodológica está na etapa de Contexto e nas camadas de Plataformas, Fontes de dados, Governança e Segurança, e a visão geral do framework está em As três camadas do Impulso Framework.

Você não muda o que não enxerga. Antes de governar, proteger, observar ou medir, inventarie.

Começar o diagnóstico · Gratuito, sem cadastro, 15 a 30 minutos.

Foundation | Frente: Consulting | Série: torre de controle de IA, capacidade Descobrir | Proposição ancorada: conexão inteligente do que já existe | Cenário ilustrativo, não baseado em organização específica | Fontes públicas: OWASP, projeto de lista de materiais de IA e formato CycloneDX (norma Ecma International); Linux Foundation, SPDX 3.0 com perfis de IA e de dados; orientação conjunta das agências de cibersegurança do G7 e da União Europeia (maio de 2026); EU AI Act | 1.900 palavras | Leitura: 10 minutos