Making AI-Assisted Grant Evaluation Auditable without Exposing the Model

1. Declaração do Problema

Agências de financiamento público estão adotando cada vez mais Modelos de Linguagem de Grande Escala (LLMs) como ferramentas de apoio à decisão para avaliação de subsídios. Isso cria uma tensão fundamental de governança entre dois requisitos concorrentes:

• Confidencialidade do Modelo: Para evitar "jogos" (onde candidatos otimizam propostas para explorar vieses específicos do modelo ou lógica de pontuação, em vez de mérito genuíno), os pesos do modelo, a rubrica de pontuação e os modelos de prompt devem permanecer opacos aos candidatos.
• Auditabilidade do Processo: Decisões de financiamento público devem ser transparentes, contestáveis e responsáveis. Candidatos e auditores precisam de evidências criptográficas de que o modelo e a rubrica declarados foram realmente utilizados, que a entrada não foi alterada e que a saída não foi adulterada.

Soluções atuais dependem de confiança institucional, o que é insuficiente para uma responsabilidade algorítmica rigorosa. Além disso, o processamento de documentos controlados por candidatos introduz riscos de segurança específicos, particularmente injeção de prompt (instruções ocultas em submissões destinadas a manipular o LLM).

2. Metodologia: Arquitetura Baseada em TEE

O artigo propõe uma arquitetura de sistema baseada em Ambientes de Execução Confiáveis (TEEs) e Atestação Remota (RA) para resolver o trade-off entre confidencialidade e auditabilidade. O sistema opera sob o princípio de que, embora o conteúdo da avaliação permaneça confidencial, a integridade do processo pode ser verificada criptograficamente.

Componentes Principais

A arquitetura consiste em cinco camadas distintas:

1. Ingestão e Canonização de Submissão (Fora do TEE):

   • Recebe arquivos brutos do candidato (PDF, DOCX, etc.).
   • Calcula o hash do arquivo original ($H_{orig}$).
   • Sanitização: Analisa e remove conteúdo não visível (metadados, camadas ocultas, scripts) para criar uma representação de texto "canônica".
   • Detecção de Injeção: Varre padrões de injeção de prompt (por exemplo, texto invisível, Unicode disfarçado, comandos imperativos). Anomalias são sinalizadas, mas não descartadas silenciosamente; são registradas em um relatório de sanitização.
   • Calcula o hash da entrada canônica ($H_{can}$).

2. Inicialização da Atestação (Dentro do TEE):

   • O TEE (por exemplo, Intel TDX, AMD SEV-SNP) é iniciado.
   • A CPU mede o estado inicial: o tempo de execução de inferência, pesos do modelo, rubrica e modelo de prompt.
   • Uma medida criptográfica ($M$) é gerada e assinada pela raiz de confiança de hardware da CPU.
   • Um verificador externo verifica este Relatório de Atestação ($A$) contra um Manifesto de Referência ($R$) público para garantir que o software e a política corretos foram carregados.

3. Núcleo de Inferência de Avaliação (Dentro do TEE):

   • A entrada canônica é carregada.
   • O sistema constrói o prompt completo (Prompt do Sistema + Rubrica + Submissão Canônica).
   • O LLM realiza a inferência, gerando pontuações, justificativas e flags de incerteza.
   • A saída é hashada ($H_O$) antes de sair do ambiente seguro.

4. Assinatura de Saída Atestada (Dentro do TEE):

   • Antes de sair do TEE, um Pacote de Avaliação Atestada ($B$) é montado.
   • Conteúdo do Pacote: Hash original, hash canônico, hash de entrada, hash de saída, medida do modelo/rubrica ($M$), relatório de atestação ($A$), carimbo de data/hora e a saída da avaliação ($O$).
   • O pacote é assinado por uma chave efêmera gerada dentro do TEE, vinculando a saída ao estado de hardware e configuração específicos.

5. Registro de Auditoria e Verificação (Fora do TEE):

   • O pacote assinado é escrito em um registro à prova de adulteração (por exemplo, baseado em árvore de Merkle).
   • Auditores podem verificar independentemente o pacote contra o Manifesto de Referência e a cadeia de certificados do fabricante da CPU para confirmar a integridade do processo.

3. Contribuições Principais

1. Enquadramento do Problema: Definir a avaliação de subsídios assistida por IA como um problema específico de "confidencialidade-auditabilidade", distinguindo entre provar uma boa decisão (o que a atestação não pode fazer) e provar o processo correto (o que ela pode fazer).
2. Pacote de Avaliação Atestada: Propôs um artefato novo que vincula criptograficamente a submissão, a configuração específica do modelo/rubrica e a saída, permitindo verificação por terceiros sem expor os pesos do modelo.
3. Camada de Canonização e Sanitização: Integrou uma defesa específica contra injeção de prompt normalizando representações de documentos e registrando ações de sanitização como parte do rastro de auditoria, abordando uma vulnerabilidade crítica na avaliação baseada em LLM.
4. Análise Comparativa: Delimitou claramente os trade-offs entre a atestação baseada em TEE e alternativas criptográficas mais fortes, mas atualmente impraticáveis, como Aprendizado de Máquina de Conhecimento Zero (ZK-ML) e Criptografia Homomórfica Total (FHE).

4. Resultados e Análise de Segurança

A arquitetura proposta mitiga efetivamente o modelo de ameaça identificado:

• Jogos do Candidato (T1): Mitigado porque o modelo e a rubrica permanecem criptografados dentro do TEE; os candidatos não podem fazer engenharia reversa da lógica de pontuação.
• Injeção de Prompt (T2): Mitigado pela camada de canonização que remove instruções ocultas e registra anomalias.
• Adulteração Post-hoc (T3): Prevenida porque a saída é assinada dentro do TEE antes da saída; qualquer modificação invalida a assinatura.
• Modelo/Rubrica Errados (T4): Prevenido pela Atestação Remota; se o software errado for carregado, o hash da medida não corresponderá ao Manifesto de Referência, causando falha na verificação.
• Silenciamento de Entrada (T5): Prevenido pelo registro do hash do arquivo original ($H_{orig}$) antes da canonização, garantindo que o auditor possa verificar que toda a submissão foi processada.
• Violação de Infraestrutura (T6): Mitigado pela criptografia de memória do TEE, impedindo que operadores de nuvem ou hipervisores acessem pesos do modelo ou estados intermediários.

Limitações:

• Escopo da Garantia: A atestação prova que o processo foi correto, não que a decisão foi justa, imparcial ou cientificamente sólida.
• Confiança no Hardware: O sistema depende da integridade das chaves de atestação do fabricante da CPU e da ausência de vulnerabilidades de canais laterais micro-arquiteturais.
• Desempenho: A inferência em TEE introduz latência e sobrecarga em comparação com a inferência em nuvem padrão.
• Lacunas de Canonização: Nenhuma camada de sanitização pode garantir 100% de detecção de todas as técnicas futuras de injeção esteganográfica.

5. Significado

Este artigo fornece uma base técnica prática e de curto prazo para implementar IA responsável na tomada de decisões de alto risco no setor público.

• Ponte na Lacuna de Confiança: Move a avaliação de IA de uma "caixa preta" que depende exclusivamente de confiança institucional para um sistema com evidências criptográficas de integridade do processo.
• Relevância para Políticas: Oferece um mecanismo concreto para agências públicas satisfazerem requisitos de responsabilidade algorítmica (transparência, contestabilidade) sem comprometer a propriedade intelectual ou permitir jogos.
• Humano no Loop: A arquitetura suporta explicitamente um modelo de "humano no loop", onde a IA fornece apoio à decisão auditável, mas painéis humanos retêm a autoridade final, garantindo que a primazia legal e normativa permaneça com os humanos.

Em conclusão, o artigo argumenta que, embora a atestação remota não resolva os desafios de governança mais amplos de viés ou justiça da IA, ela resolve com sucesso o problema específico de verificar que o sistema de IA declarado foi o que realmente tomou a decisão, permitindo assim uma infraestrutura de avaliação de subsídios mais confiável e contestável.