IA Proibida de Estar Certa: Orquestração de Solvers Controlada em Criptoforense
Quando a Inteligência Artificial (IA) é integrada a sistemas de engenharia complexos, a pergunta predominante é: a IA consegue encontrar a resposta correta? No campo da criptografia, essa questão é frequentemente mal formulada. A pergunta correta deveria ser: é possível incorporar a IA de tal forma que, mesmo em caso de erro, ela não possa tomar uma decisão perigosa? Isso é particularmente crucial em sistemas que lidam com assinaturas digitais, nonces, lattices, rotas HNP (Hypernetwork Programming) e chaves privadas candidatas. Nesses cenários, não se pode simplesmente afirmar que "a confiança do modelo é suficiente para considerar a chave encontrada". Não é aceitável aceitar uma chave privada candidata (candidate_d) com base em uma pontuação de confiança (confidence score). Uma explicação bem elaborada não pode se tornar evidência criptográfica. O raciocínio textual não pode substituir a verificação determinística, como candidate_d · G == observed_public_key.
É por isso que a próxima camada do nonce-observatory se tornou um tanto paradoxal: integramos a IA não para que ela tome decisões criptográficas, mas para que gerencie uma fila de ações verificáveis, sem ter o direito de aceitar o resultado. Essa camada é denominada "orquestração de solvers controlada" (governed solver orchestration). Em essência, a IA atua como um planejador e agendador de solvers, sem possuir autoridade criptográfica. Ela pode ler contratos de funcionalidades seguros para o público (public-safe feature contract), propor um plano de rota, classificar famílias de solvers, construir uma fila de solvers e explicar as prioridades. No entanto, a IA é estritamente proibida de ver campos de verdade (truth), campos privados (private) ou nonces, de aceitar chaves privadas candidatas (candidate_d) ou nonces (k), de aceitar claims de recuperação (recovery claim), de declarar sucesso de um solver, de considerar sua própria pontuação como evidência, ou de contornar o portão de integridade determinístico (deterministic integrity gate).
A arquitetura correta posiciona a IA entre o contrato de funcionalidades e a fila de solvers, e não entre o resultado do solver e a aceitação da verdade. O princípio central dessa camada é a "fronteira de não-escalada" (non-escalation boundary), uma barreira que impede a IA de ascender de um papel de planejador para o de verificador criptográfico. Em outras palavras, a IA pode propor ações, mas não pode aceitar fatos criptográficos. Essa abordagem garante que, mesmo que a IA cometa erros ou gere explicações falhas, a integridade do sistema criptográfico seja mantida por verificadores determinísticos. A IA se torna um acelerador de pesquisa e um gerenciador de complexidade, sem jamais se tornar uma autoridade de verdade, protegendo o sistema contra a escalada automática de status de "sinal" para "claim de recuperação" sem as devidas validações.
A Necessidade de uma IA Controlada em Criptoforense
Em sistemas criptográficos, a confiança reside na verificabilidade determinística e na reprodutibilidade. A IA, por sua natureza probabilística e propensa a alucinações, apresenta um desafio significativo a esses princípios. A abordagem de "orquestração de solvers controlada" (governed solver orchestration) aborda essa questão ao definir um escopo estritamente limitado para a IA. Ela opera em um "contrato de funcionalidades" (feature contract) seguro para o público, que contém métricas e sinais derivados de dados públicos, mas exclui informações sensíveis como chaves privadas, nonces brutos ou a verdade subjacente (truth). A IA utiliza essas informações para planejar rotas de análise e priorizar a execução de solvers. Por exemplo, um contrato de funcionalidades pode indicar a presença de um sinal de vazamento de janela limitada (bounded-window leakage) ou suporte a prefixo (prefix support), levando a IA a sugerir a execução de um solver de lattice HNP ou uma análise de recorrência.
No entanto, a saída da IA é sempre uma sugestão de fila de trabalho, não uma declaração de descoberta. Cada item na fila é acompanhado por um "limite de claim" (claim boundary) que especifica as condições sob as quais um resultado pode ser considerado. Por exemplo, uma recomendação de rota pode ser seguida por "nenhum claim de recuperação sem verificação de chave pública" (no recovery claim without public-key verification). Isso garante que qualquer potencial descoberta, seja uma chave privada candidata ou uma assinatura inválida, passe por um "portão de integridade determinístico" (deterministic integrity gate). Este portão realiza verificações matemáticas rigorosas, como d·G == P para chaves privadas ECDSA, ou ECDSA_Verify(P, z, r, s) == true para assinaturas. A IA não tem autoridade para pular ou influenciar esse portão. Sua função é otimizar o processo de descoberta, não validar o resultado final.
A Fronteira de Aceitação e a Importância do Controle
A fronteira de aceitação é onde a IA é estritamente proibida de operar como autoridade. Enquanto a IA pode analisar contratos de funcionalidades, classificar sinais de defeito de nonce, propor rotas de solver e construir filas de execução, ela não pode aceitar chaves privadas candidatas, nonces, ou claims de recuperação. Sua pontuação de confiança (ai_score) é explicitamente marcada como não sendo evidência criptográfica (ai_score_is_cryptographic_evidence: false). A autoridade final para aceitação reside exclusivamente nos portões de integridade determinísticos. Essa separação é crucial para manter a confiança no sistema. Se a IA pudesse aceitar um candidate_d com base em sua confiança, o modelo de evidência seria quebrado, pois a aceitação não seria mais baseada em provas matemáticas irrefutáveis, mas sim em inferências probabilísticas do modelo.
Essa abordagem também se estende ao tratamento de "controle limpo" (clean control), onde os dados não apresentam sinais claros de vulnerabilidade. Em vez de tentar forçar uma análise, um sistema maduro deve ser capaz de recusar a execução de solvers em dados que parecem ser de tipo PRF-like/IID. A IA, neste contexto, deve ser capaz de indicar "Rota: nenhuma" (Route: none) com a razão "nenhum sinal pronto para solver sob o contrato de evidências atual" (no solver-ready signal under current evidence contract). Essa recusa correta é, em si, um resultado forense forte, protegendo o sistema contra a interpretação de ruído como uma descoberta. Em resumo, a IA atua como um planejador inteligente e eficiente, mas a verdade criptográfica permanece firmemente sob o controle de verificadores determinísticos, garantindo que a complexidade gerenciada pela IA não comprometa a integridade e a confiabilidade do sistema.
O Que a IA Vê e o Que Ela Entrega
A IA recebe um "contrato de funcionalidades" (feature contract) seguro para o público, que é uma representação estruturada de características observáveis e métricas derivadas de dados criptográficos, mas desprovida de qualquer material secreto ou verdade subjacente. Por exemplo, um contrato pode incluir o número de assinaturas analisadas, a contagem de nonces repetidos, ou a presença de padrões como suporte a HNP (hnp_window_candidate). Crucialmente, este contrato não contém a chave privada (private_key), o candidate_d, o nonce bruto (raw_nonce), ou a verdade (truth_d, truth_k). A IA utiliza essas informações para classificar os casos, identificar potenciais rotas de análise e priorizar a execução de solvers. Sua função é de um planejador de rotas e agendador de solvers, sem acesso a informações que lhe permitiriam se tornar um oráculo secreto.
Em contrapartida, a IA não entrega resultados como candidate_d = ..., private key recovered, ou nonce recovered. Em vez disso, ela produz um "plano de solver" (solver plan). Este plano é uma lista ordenada de rotas de análise sugeridas, cada uma com uma justificativa (reason) e um "limite de claim" (claim boundary) que especifica as condições para a aceitação de um resultado. Por exemplo, uma entrada na fila pode ser: "Rota: hnp_window_leakage_check, Família de Solver: lattice_hnp, Razão: sinal de janela limitada presente; ausência de R-repetido, Limite de Claim: nenhuma reivindicação de recuperação sem verificação de chave pública". Essa saída é um metadado de fila, não uma evidência criptográfica. Cada linha da fila representa uma proposta de ação verificável, não uma afirmação de descoberta. A recomendação de rota (route recommendation) não é evidência de recuperação (recovery evidence). A IA pode sugerir a ordem das rotas, mas a aceitação final de qualquer resultado é sempre mediada por portões de integridade determinísticos, garantindo que a IA acelere o processo de análise sem comprometer a segurança ou a validade das descobertas.
O Impacto da IA Controlada em Auditorias e Compras
Para compradores sérios e auditores externos, a presença de IA em um sistema de segurança pode gerar apreensão. A pergunta fundamental que surge é: a IA pode influenciar uma afirmação criptográfica? A resposta fornecida pela arquitetura de "orquestração de solvers controlada" é um enfático "não". A IA pode influenciar apenas a ordem das ações verificáveis. A aceitação final de qualquer resultado é realizada por um verificador determinístico. Essa garantia pode ser expressa como um compromisso voltado para o comprador: a IA não pode aceitar segredos, não pode produzir claims de recuperação e não pode contornar portões determinísticos. A saída da IA é metadado de fila, não evidência criptográfica. Essa clareza é significativamente mais tranquilizadora do que a afirmação genérica de que "a IA analisa tudo".
Essa abordagem garante que a IA funcione como um acelerador de triagem, ajudando a gerenciar a complexidade de grandes volumes de dados e a identificar potenciais áreas de interesse para análise mais aprofundada. Ela não altera as leis da evidência criptográfica. Por exemplo, se um solver encontra um candidato a chave privada, a IA não pode declará-lo como recuperado. Em vez disso, o candidato deve passar pelo portão de integridade determinístico, onde a condição d·G == P é rigorosamente verificada. Se essa verificação falhar, o candidato é rejeitado, independentemente de quão confiante a IA possa ter sido em sua sugestão inicial. Essa separação de funções protege a integridade do processo de descoberta e garante que as conclusões finais sejam baseadas em provas matemáticas sólidas, e não em inferências de um modelo de IA.
Conclusão: IA Sugere, Verificador Exato Decide
O objetivo desta arquitetura não é tornar a IA mais inteligente que a criptografia, mas sim o oposto: construir um sistema criptográfico onde a IA possa ser útil mesmo quando comete erros. A IA pode propor um caminho de análise, errar na priorização de rotas, ou explicar mal um modo de falha. No entanto, ela é fundamentalmente impedida de aceitar uma chave privada, ver um nonce verdadeiro, serializar um candidate_d, transformar confiança em evidência, elevar um sinal observacional a um claim de recuperação, ou contornar o portão d·G == P. Em criptografia, essa robustez contra erros é mais valiosa do que um modelo de IA "inteligente". Uma camada de IA madura em um sistema de alta segurança deve atuar como um planejador gerenciável dentro de um contorno formal, não como um oráculo.
A fórmula final para a arquitetura é clara: a IA sugere, o solver computa, o verificador exato decide, e o contrato de evidências fala. Dessa forma, a IA se torna uma ferramenta de engenharia útil, auxiliando no gerenciamento da complexidade sem obter autoridade sobre a verdade. A cadeia de evidências mínima demonstra que a IA está posicionada antes da execução do solver e do portão de aceitação, nunca após a identificação de um candidato como autoridade. O cumprimento de invariantes de teste, como truth_access == false e acceptance_authority == deterministic_integrity_gate_only, garante que a IA permaneça uma ferramenta de planejamento e não uma fonte de afirmações criptográficas.
