Avaliação independente
não pode depender
de confiança

A independência entrou na arquitetura

Uma avaliação externa costuma parecer independente porque é conduzida por uma organização diferente daquela que desenvolveu o modelo. Essa separação institucional importa, mas não responde a uma pergunta mais concreta: durante o teste, quem consegue ver o quê?

Em 27 de agosto, Google DeepMind, AVERI, MLCommons, OpenMined e o Singapore AI Safety Institute apresentaram um piloto de avaliação duplo-cega para modelos de IA. O Gemini 2.5 Flash Lite foi testado com uma parcela reservada do benchmark de segurança AILuminate e, num segundo trabalho, com perguntas privadas voltadas à elicitação de conteúdo nocivo no contexto de Singapura.

O desenho tentava preservar dois segredos ao mesmo tempo. O Google não deveria receber as perguntas usadas pelos avaliadores. Os avaliadores não deveriam receber os pesos proprietários do modelo. Modelo, prompts e código foram reunidos apenas dentro de um ambiente de computação confidencial, que executou o protocolo autorizado e liberou resultados delimitados.

Os autores apresentam o piloto como a primeira avaliação ao vivo de um modelo proprietário de classe de fronteira contra um benchmark fechado com garantias criptográficas de confidencialidade mútua. A importância do experimento, porém, não está em declarar que a confiança desapareceu. Está em mostrar como uma parte da confiança pode ser convertida em restrições técnicas verificáveis.

O dilema de dois segredos

Benchmarks públicos têm uma fragilidade crescente. Quando perguntas circulam em artigos, repositórios, exemplos e conversas, podem reaparecer nos dados de treinamento ou pós-treinamento. Um modelo que já encontrou a prova pode obter uma pontuação melhor sem ter desenvolvido a capacidade que o teste pretendia medir.

Manter perguntas inéditas resolve uma parte do problema e cria outra. Se o avaliador envia o teste para a API do laboratório, precisa confiar que prompts e respostas não serão registrados, analisados ou incorporados a um ciclo futuro de treinamento. Contratos e políticas de retenção reduzem esse risco, mas não eliminam falhas acidentais nem tornam a execução observável para a parte externa.

Entregar o modelo ao avaliador também não é uma solução geral. Pesos de fronteira representam propriedade intelectual, custo de desenvolvimento e capacidade que o laboratório pode considerar sensível. Na prática, acesso direto costuma ficar restrito a poucos parceiros com relações profundas com o desenvolvedor.

O conflito é simétrico. O avaliador protege a prova para preservar sua validade. O laboratório protege o modelo para preservar seu ativo. Uma avaliação realmente independente precisa permitir o encontro entre esses materiais sem transferir sua custódia.

A sala que ninguém pode abrir

O piloto usou o Confidential Space do Google Cloud sobre uma máquina A3 com memória do host protegida por Intel TDX e uma GPU NVIDIA H100 em modo confidencial. O PySyft, da OpenMined, coordenou o envio de dados, a revisão do código e as autorizações entre as partes.

Antes de liberar os ativos, cada participante podia verificar uma atestação remota. Em termos simples, o hardware e a cadeia de inicialização produzem evidências assinadas sobre o ambiente e o software carregado. Essas medidas podem ser comparadas com valores esperados. Se a configuração não corresponder àquela que foi aprovada, os segredos não precisam ser enviados.

Depois da verificação, os pesos do modelo foram transmitidos por um canal criptografado para a memória protegida da GPU. Perguntas e código de avaliação seguiram por outro canal para a memória protegida do host. O modelo executou dentro do enclave, e a política definiu quais resultados poderiam sair. No fluxo proposto, métricas agregadas são devolvidas e a instância é desativada.

Esse mecanismo não transforma uma nuvem em espaço mágico. Ele tenta tornar uma execução específica identificável, limitada e difícil de observar até para o operador da infraestrutura. A promessa deixa de ser apenas “não vamos olhar” e passa a incluir evidências sobre qual ambiente recebeu os dados e qual computação estava autorizada a ocorrer.

Separar organizações não cria independência

Uma auditoria pode ser externa e ainda depender inteiramente dos sistemas, logs e interfaces do auditado. Pode receber respostas por uma API controlada pelo fornecedor, usar um modelo cuja versão não consegue confirmar ou publicar uma pontuação sem saber se o conjunto de testes foi preservado. A separação jurídica continua importante, mas não resolve sozinha a assimetria técnica.

O piloto sugere um critério mais exigente. Para que a independência seja substantiva, nenhuma parte deveria conseguir alterar silenciosamente o objeto avaliado, antecipar a prova ou ampliar os resultados que saem da execução. A versão do modelo, o conjunto de perguntas, o código, a política de saída e a configuração do ambiente precisam formar um protocolo comum.

Isso muda também o papel do avaliador. Ele deixa de ser apenas quem escolhe perguntas e interpreta respostas. Passa a participar do desenho de uma cadeia de custódia para código, dados e resultados. A competência necessária inclui metodologia de avaliação, mas também revisão de dependências, política de acesso, atestação e tratamento de falhas.

O que a criptografia consegue provar

A atestação pode aumentar a confiança de que uma configuração identificada foi inicializada. A memória criptografada pode reduzir a capacidade de um operador externo inspecionar pesos e perguntas enquanto são processados. Políticas de saída podem impedir que respostas completas ou dados brutos escapem quando apenas uma métrica foi autorizada.

Nada disso decide se o benchmark é bom. A infraestrutura não prova que as perguntas representam riscos relevantes, que a amostra cobre populações diferentes, que a métrica mede o comportamento pretendido ou que o avaliador publicou todos os resultados importantes. Também não impede que uma organização escolha um teste conveniente, interprete uma pontuação de forma exagerada ou repita a avaliação até obter um resultado favorável.

Há, portanto, duas classes de integridade. A primeira é procedimental: executar o modelo, os dados e o código combinados sem exposição indevida ou substituição silenciosa. A segunda é epistemológica: escolher uma prova capaz de sustentar a conclusão apresentada. Computação confidencial fortalece a primeira. A segunda continua sendo trabalho de pesquisa, governança e contestação pública.

A confiança não desapareceu

O próprio relatório técnico registra limites que impedem tratar o sistema como uma solução sem confiança. Nem todas as implementações proprietárias usadas para executar o Gemini puderam ser inspecionadas ou restritas a uma lista de métodos abertos. A AVERI foi informada dessa condição e aceitou o desenho do piloto.

Os autores também observam que, embora o código do sistema convidado do Confidential Space seja aberto e seus valores de referência sejam publicados, cada build não pode ser reproduzido de forma independente porque recebe chaves privadas de assinatura como entrada. Serviços do Google participaram da assinatura e da verificação da atestação, mantendo o próprio provedor dentro do caminho de confiança.

Mesmo num desenho mais aberto, as raízes inferiores permanecem no fabricante do hardware, no microcódigo, no firmware, nas chaves e nos certificados usados para provar a identidade do equipamento. Uma vulnerabilidade nessa base ou uma combinação de participantes capazes de romper suas premissas pode enfraquecer a garantia.

A conclusão correta não é que a confiança foi eliminada. Ela foi redistribuída, estreitada e tornada mais explícita. Em vez de confiar que uma organização inteira agirá corretamente em todos os momentos, as partes confiam numa cadeia menor de hardware, software, políticas e verificações que pode ser documentada e, em parte, auditada.

O gargalo passou do hardware para a coordenação

Segundo o relatório, o principal gargalo observado não foi mais o custo computacional do enclave. Foi a coordenação humana necessária para acordos jurídicos, revisão de código e aprovação entre várias organizações.

Esse ponto é decisivo. Uma avaliação duplo-cega não começa ao ligar uma GPU confidencial. As partes precisam decidir a versão do modelo, as bibliotecas permitidas, quais trechos ficam ocultos, quem autoriza o código e recebe os resultados, o que pode sair e como tratar uma verificação falha.

Transformar pilotos em infraestrutura recorrente exigirá contratos técnicos reutilizáveis. O relatório imagina uma experiência futura parecida com o cadeado do HTTPS: garantias complexas de chaves e dependências resumidas numa verificação compreensível. Essa simplificação seria útil, mas também perigosa se esconder as premissas que o símbolo pretende representar.

Escala é outra pendência. O experimento usou uma única H100 de 80 GB. Modelos maiores exigirão clusters confidenciais, conexões protegidas e mecanismos que ocultem detalhes internos sem impedir a revisão. Isso permanece como direção futura.

O comprador também precisa desta arquitetura

O caso não interessa apenas a laboratórios e institutos de segurança. Bancos, hospitais, governos e operadores de infraestrutura podem querer avaliar modelos com incidentes internos, dados regulados ou cenários adversariais que não devem ser entregues ao fornecedor. Ao mesmo tempo, fornecedores de modelos fechados dificilmente transferirão pesos para cada cliente.

Uma arquitetura duplo-cega pode permitir que o comprador leve seu próprio teste até uma execução protegida, confirme a versão e a política utilizadas e receba apenas os resultados necessários. O fornecedor preserva o modelo. O cliente preserva dados e metodologia. Um terceiro independente pode validar o protocolo sem adquirir custódia permanente de nenhum dos dois ativos.

Essa possibilidade permite avaliações ligadas ao risco real de cada implantação, com perguntas que ainda não circularam no mercado. Só será confiável se a organização puder definir o teste, inspecionar as premissas, rejeitar a configuração e publicar limites junto com a pontuação.

Da independência declarada à independência executável

O piloto reúne uma contribuição técnica específica e uma lição institucional mais ampla. A contribuição é mostrar que pesos proprietários e benchmarks secretos podem ser processados juntos sem que uma das partes precise entregar seu ativo à outra. A lição é que independência precisa existir no caminho percorrido por dados, código, autorização e resultados.

Ainda há dependência no provedor, código não inspecionado, coordenação cara e um desafio de escala. Também não há mecanismo criptográfico capaz de substituir a qualidade do benchmark ou a integridade de quem interpreta os resultados. Reconhecer esses limites fortalece o caso, porque impede confundir uma prova de execução com uma prova de segurança do modelo.

O futuro das avaliações independentes talvez não seja um avaliador recebendo todos os segredos para então prometer que cuidará deles. Pode ser uma infraestrutura em que cada parte mantém a custódia do que precisa proteger e nenhuma delas consegue, sozinha, controlar toda a prova.

Independência deixa de ser apenas quem assina o relatório. Passa a ser quem pode ver o teste, quem pode substituir o modelo, quem autoriza o código e qual resultado o sistema permite sair.