Inventário de ativos de IA e ciclo de vida

Camada funcional

Responde à pergunta que toda área de governança faz: quais sistemas de IA existem aqui, em que estágio cada um está, e quem respondeu por eles. A organização mantém um inventário e registra decisões formais sobre cada item.

A origem é regulatória — o módulo nasceu para atender exigência formal de conformidade. Mas o resultado é útil muito além disso: saber o que roda e quem aprovou vale para qualquer organização que leve a sério o que os próprios agentes fazem.

O que é um ativo

Dez tipos, cada um com rótulo próprio na tela: agente, modelo, prompt de sistema, skill, esteira, endereço de serviço, avaliador, ferramenta de MCP, servidor de MCP e sistema de IA (25/08/2026).

O avaliador merece nota: avaliadores são catalogados como ativos versionados. Faz sentido — quem julga a qualidade das respostas também é um sistema de IA sujeito a revisão.

"Sistema de IA": o tipo que só existe por cadastro

Ferramenta de IA de terceiro — Lovable, Replit, Cursor, v0 — não tinha onde entrar. Quem catalogava forçava dentro de "modelo" (que é o modelo de linguagem) ou de "rota" (que é um endereço de chamada), e o inventário passava a mentir sobre o que cada coisa é. O tipo "Sistema de IA" existe para isso, e é diferente de todos os outros nove: nada interno o cria — ele só nasce por cadastro manual, na tela, ou pela via de ingestão externa.

Um tipo novo não pode nascer invisível

Vale contar o defeito que motivou uma correção, porque o efeito dele é o que você veria na tela.

Quando o tipo "ferramenta de MCP" entrou, ele passou a ser aceito mas não a ser nomeado: as ferramentas do primeiro sistema declarado em produção entraram no inventário sem tipo visível, sem opção no filtro, e a ficha saiu com o campo de tipo em branco — num documento feito justamente para sair da organização.

Não houve erro nenhum, e é isso que torna o caso instrutivo: o dado estava lá, correto, e invisível. A correção não foi só preencher o rótulo que faltava; foi passar a falhar quando um tipo aceito não tem nome na tela, para o próximo tipo novo não repetir a estreia muda.

De onde o ativo vem

A origem fica registrada: agente, skill, modelo, prompt de sistema, cadastro manual ou externo — este último para ativos reportados por sistemas de fora.

Isso importa para ler o inventário: nem tudo ali nasceu dentro do VolundOS.

Ambientes e ciclo de vida

Três ambientes: desenvolvimento, homologação e produção.

Cinco fases: solicitação, desenvolvimento, validação, implantação e operação.

A regra de transição é deliberadamente frouxa: vale mover para qualquer fase que exista e seja diferente da atual. Ou seja, a governança permite retroceder — voltar de validação para desenvolvimento depois de uma reprovação é um caminho legítimo, e fica na trilha como qualquer outro.

Permitir andar para trás é a decisão certa. Um fluxo que só avança força as pessoas a mentir sobre o estado real.

Há ainda a sugestão da fase seguinte, que fica em branco quando o ativo já está em operação.

Decisões registradas

Quatro: aprovar a entrada em produção, desfazer, aguardar e rejeitar.

Note que "aguardar" é uma decisão, e não a ausência de uma. Registrar a espera evita que um ativo fique parado sem ninguém saber por quê.

Como um App declara o que oferece

Além do caminho de reconciliação descrito abaixo, há um segundo, específico para os sistemas publicados: o próprio agente declara, de dentro da máquina dele, o que aquele sistema oferece — as ferramentas e os endereços de serviço.

Três decisões desse mecanismo valem conhecer, porque você observa as três:

• A declaração é um retrato completo, não um acréscimo. O que não vier na declaração é considerado removido e fica arquivado — nunca apagado, e volta a valer se for declarado de novo.
• Declaração atrasada não desfaz a mais recente. Cada uma carrega um número que precisa ser maior que o da anterior; uma que chegue fora de ordem é recusada, em vez de sobrescrever o que já está lá.
• Desenvolvimento e produção são duas fotografias, não um número só. O que o agente declara vale para desenvolvimento; produção só muda quando a publicação promove. E a promoção congela a fotografia no instante em que a publicação é pedida, aplicando-a quando ela confirma minutos depois — senão uma declaração que chegasse no meio do caminho entraria em produção junto, e a produção passaria a descrever código que ainda não subiu.

E uma garantia que vem do mesmo desenho: nada nesse mecanismo pode derrubar uma publicação já confirmada, nem parecer que derrubou.

A permissão que ninguém consegue conceder

Um item declarado pode exigir uma permissão que não existe no catálogo que o próprio sistema declarou. Quando isso acontece, a chave fica inalcançável: ninguém consegue concedê-la, porque a tela de acesso só oferece as que estão no catálogo.

Antes, o sintoma só aparecia quando alguém tentava usar a ferramenta e recebia "sem permissão", sem pista do motivo. Agora a aba de segurança do agente aponta o caso na tela, nos dois ambientes — a permissão órfã fica visível, em vez de descoberta por tentativa e erro.

Servidores de MCP e webhooks também entram

Um agente comum conectado a servidores de MCP, ou que receba chamadas por webhook, tem essas peças inventariadas como ativos — não só os sistemas publicados.

O que fica registrado não leva segredo: nem os cabeçalhos, nem a autorização, nem as variáveis do servidor, nem a chave do webhook. O inventário guarda a existência e a procedência da peça, não as credenciais dela.

De que peças um agente é feito

A página do agente ganhou uma aba que mostra a composição dele: o que ele usa, e o que disso está inventariado. É a mesma informação do inventário, vista do lado de quem configura o agente em vez do lado de quem governa.

Cadastro manual pela tela (25/08/2026)

Até esta correção, cadastrar um ativo de fora do que a plataforma cataloga sozinha exigia chamada programática — uma porta que existia no papel e que ninguém usava. Agora um diálogo na própria tela de inventário cadastra o ativo, com os sete tipos que o cadastro externo também aceita: modelo, endereço de serviço, agente, esteira, prompt de sistema, skill e sistema de IA. Avaliador, ferramenta de MCP e servidor de MCP continuam sendo catalogados só pela própria plataforma.

Os dois caminhos — tela e chamada — gravam do mesmo jeito e valem a mesma regra: cadastrar de novo o mesmo ativo atualiza o registro, não cria um segundo.

Arquivar (25/08/2026)

Antes desta correção não havia caminho nenhum para tirar um ativo do inventário — nem pela tela, nem por chamada. Um registro não pode ser apagado, por decisão de projeto, e a marca de arquivado só era escrita pela reconciliação automática. Abrir o cadastro manual sem uma forma de desfazer deixaria todo item digitado errado no inventário para sempre.

Arquivar (e desarquivar) está restrito ao que entrou por cadastro manual ou por ingestão externa: um ativo que a própria plataforma catalogou (agente, skill, sincronização) não pode ser arquivado pela tela, porque a reconciliação automática desfaria o arquivamento na execução seguinte — a tela prometeria uma remoção que o produto reverte sozinho.

A mesma mudança apertou quem pode cadastrar de fora: o cadastro externo grava apenas no inventário da organização que autenticou a chamada. Uma credencial de leitura pública do site não alcança inventário de organização nenhuma.

Honestidade do dado, e não verificação dele

Vale ser preciso sobre o que esse caminho garante: tudo isso é o que o sistema disse sobre si mesmo. O inventário registra a declaração e de onde ela veio; conferir se o que foi declarado corresponde ao que existe de fato é outro problema, e está tratado em separado.

Reconciliar o inventário com o que já existe

Uma ação administrativa varre o que a organização já tem — agentes, prompts de sistema, skills publicadas e o catálogo completo de modelos — e traz para o inventário o que ainda não estava lá.

Ela é idempotente: rodar duas vezes não duplica nada, e só cria versão nova quando o conteúdo de fato mudou. E quem dispara precisa administrar a organização — a permissão é conferida antes de qualquer escrita, e não no meio dela.

A lista cortava em mil linhas, sem avisar

Até 19/08/2026 a tela pedia o inventário inteiro e filtrava na própria página. Havia um teto de mil linhas na resposta, e ele cortava o resto em silêncio: num inventário grande, "o inventário" eram os primeiros mil itens — e o rodapé contava o próprio recorte, então a tela nunca soube que estava mentindo.

O caso é o motivo de o rodapé importar: um total que conta o recorte não é um total, é uma repetição do que já está à vista.

Agora a lista vem de 50 em 50, com filtro e busca resolvidos antes de chegar à tela, e o total vem por um caminho próprio, separado das linhas. Essa separação é o que muda a experiência: antes, quando a contagem falhava, ela levava a lista junto — agora a lista aparece de qualquer forma, e só o total fica indisponível.

O mesmo desenho vale para as outras duas listas de governança, as avaliações e os alertas.

O que dá para fazer, e onde