A admissão de modelos requer um estado não resolvido

Uma decisão de admissão de modelo de IA precisa indicar quais evidências autorizam o artefato a avançar. Quando um carregamento não produz nenhum evento bloqueado mas a inspeção estática ainda identifica um elemento global perigoso, a aprovação comprime duas constatações distintas em uma única resposta tranquilizadora. Quero que a constatação não resolvida sobreviva à decisão, com um relato transparente do que ainda resta estabelecer.

Construímos o Crucible, nossa demonstração local de Model Vetting Firewall, em torno dessa distinção. Ele utiliza artefatos sintéticos, incluindo um arquivo que um verificador de assinaturas não sinaliza mas cujo carregamento tenta uma operação no banco de dados, e outro com um desvio condicional que permanece não executado. O primeiro demonstra por que uma tentativa observada é importante. O segundo expõe o problema de design mais complexo: decidir o que fazer quando as verificações disponíveis divergem, sem fingir que a discordância foi superada.

As evidências alteram a decisão

No exemplo do banco de dados sintético, o PickleScan não sinaliza o artefato. Durante o carregamento, um hook de auditoria do CPython configurado registra e bloqueia uma tentativa de operação no banco de dados SQLite. O pipeline local retorna QUARANTINE e não emite nenhuma assinatura. A operação no banco de dados não teve êxito; a evidência útil é o efeito pretendido e o bloqueio registrado.

Isso fornece à decisão de admissão uma justificativa que o resultado limpo do verificador não consegue oferecer. Uma equipe pode apontar para a operação proibida em vez de exigir que o rótulo do scanner responda a todas as dúvidas sobre o carregamento. O scanner continua sendo útil como parâmetro de comparação, mas a ausência de um alerta não anula uma tentativa bloqueada observada.

Prefiro essa separação porque ela torna a decisão inspecionável. Um revisor deve conseguir acompanhar a relação entre uma constatação e um resultado. «O hook configurado bloqueou esta tentativa de operação no banco de dados» é uma afirmação delimitada. Ela identifica a evidência, o mecanismo e a razão para o veredito local. Um rótulo de segurança genérico deixaria essas relações ocultas.

A observação também cria seu próprio limite de confiança. Aqui, o executor tenta o carregamento em um subprocesso Python e monitora eventos de auditoria configurados. Trata-se de instrumentação de demonstração, com separação de processos, em vez de isolamento no nível de sistema operacional ou contêiner. Um projeto de produção precisaria definir como o próprio executor de observação é isolado antes de receber artefatos não confiáveis. Adicionar evidências comportamentais não elimina a obrigação de inspecionar o ambiente que as coleta.

Um carregamento silencioso deixa uma dúvida mais complexa

O fixture sintético condicional atinge um resultado diferente. A inspeção estática encontra builtins.eval, um elemento global na lista de elementos perigosos configurada na demonstração. O carregamento observado não registra nenhum evento perigoso bloqueado porque o desvio condicional não é executado neste ambiente. O pipeline encaminha o artefato para REVIEW, sem assinatura. Nenhuma investigação humana foi concluída por esse caminho.

Existem três respostas defensáveis a considerar, e cada uma exige um custo diferente. A aprovação aceita a incerteza. A rejeição evita o uso deste artefato, mas pode descartar algo que uma investigação mais detalhada conseguiria explicar. Uma revisão adicional adia a decisão e exige que alguém determine quais evidências complementares poderiam alterá-la.

Para este caso, prefiro a revisão porque a incerteza é específica. Há uma preocupação estática identificada e uma lacuna identificada na observação. A execução silenciosa não explica por que o elemento global perigoso está presente nem o que acontece se o desvio for alcançado. A aprovação exigiria aceitar essa lacuna. Uma rejeição imediata poderia ser uma política organizacional razoável, mas seria uma escolha de excluir o artefato com base em evidências estáticas não resolvidas, e não uma comprovação de que ocorreu um efeito proibido.

Essa distinção é fundamental quando uma equipe elabora sua política de admissão. A falta de observação de um efeito não deve se transformar tacitamente na constatação de que o efeito não pode ocorrer. Da mesma forma, a suspeita não deve se tornar tacitamente a prova de um ataque bem-sucedido. O status REVIEW oferece um espaço para manter ambos os fatos enquanto a organização decide quanta incerteza pode tolerar.

REVIEW precisa de um critério de saída

Um status de revisão isolado pode se transformar em uma área de espera custosa. Ele só justifica seu lugar quando o registro explica a questão não resolvida e a próxima decisão a ser tomada. Neste exemplo, a dúvida diz respeito ao elemento global estático e ao desvio não executado. Repetir o mesmo carregamento silencioso sem alterar o objeto da investigação adicionaria outra observação sem responder a essa pergunta.

Em um processo corporativo hipotético, uma equipe poderia inspecionar o desvio, buscar uma explicação confiável do fornecedor do artefato ou escolher um artefato substituto com um fluxo de carregamento mais inspecionável. Essas são respostas sugeridas, e não fluxos que esta demonstração executa. Cada uma tem um custo: inspeção mais detalhada exige especialização, evidências do fornecedor exigem validação própria e a substituição pode sacrificar funcionalidades necessárias. A escolha depende de quais evidências a equipe consegue obter e de quanta incerteza sua política autoriza.

Quero que essa escolha seja explícita. Se nenhuma investigação disponível puder resolver a preocupação dentro das restrições da equipe, rejeitar o artefato pode ser o encerramento adequado da revisão. REVIEW não deve prometer que todo arquivo acabe recebendo aprovação. Sua finalidade é evitar que uma dúvida não resolvida desapareça em um veredito e garantir que a decisão final preste contas a uma política declarada.

O mesmo rigor se aplica às explicações de IA. Na demonstração, um parecer conjunto de analista e challenger pode sugerir cautela e transferir um resultado básico ALLOW para REVIEW; ele não pode remover QUARANTINE. A apresentação gravada usa pareceres do Codex em cache ao lado de verificações recém-configuradas. Um registro sintético de referência ilustra o perigo de tratar narrativas como autoridade: sua recomendação orienta a assinatura e a promoção, enquanto o resultado estruturado final é REVIEW e nenhuma assinatura é emitida.

Um consumidor do processo de admissão deve, portanto, ler o veredito estruturado, o motivo do gate e o campo real da assinatura. Um texto explicativo útil pode detalhar uma decisão, mas não deve se tornar uma segunda permissão conflitante para avançar um artefato. Um processo de revisão que confia mais na frase de recomendação do que no gate final perdeu a distinção que deveria preservar.

A aprovação também tem um limite

O dicionário sintético de pesos limpos recebe ALLOW e uma assinatura sobre o nome do modelo, o hash do artefato e o payload do inventário usando uma chave de desenvolvimento local. A procedência de seus dados de treinamento e o histórico de ajuste fino continuam como UNKNOWN. Apenas ALLOW recebe essa assinatura; REVIEW e QUARANTINE não recebem.

Isso é tão relevante para a saída da revisão quanto para o caminho limpo. Resolver uma dúvida no carregamento não comprovaria, por si só, o histórico de treinamento. Uma assinatura pode autenticar o payload local especificado em relação à sua chave enquanto uma questão prévia permanece sem resposta. Uma equipe deve avaliar separadamente se as evidências de admissão são suficientes para a decisão de carregamento e se a ausência de procedência é aceitável para o uso pretendido. Uma verificação aprovada não deve encerrar uma dúvida que jamais examinou.

O guia do Crucible apresenta esses exemplos locais e suas evidências. A integração com registros, a imposição de admissão corporativa e a custódia de assinaturas em produção continuam sendo trabalhos fora do escopo desta demonstração. Seu valor está no limite decisório que ela torna visível, e não na alegação de que a implementação local forneça todos os controles de que uma empresa precisaria.

Aqui está o vídeo do fundador exibindo a demonstração local de validação sintética de modelos.

Para uma equipe de plataforma que avalia uma arquitetura de admissão, eu começaria pelo caso cujas evidências não se alinham perfeitamente. Pergunte o que mantém a constatação não resolvida visível, quem decide se uma investigação aprofundada compensa seu custo e quais evidências podem alterar o desfecho. Um caminho limpo é fácil de descrever. O caminho não resolvido revela se o sistema preserva a incerteza por tempo suficiente para que uma decisão responsável seja tomada.