O Requisito Air-Gap
Contratantes de defesa, agências de inteligência do governo e operadores de infraestrutura crítica gerenciam redes onde a conectividade externa com a internet é fisicamente impossível, não apenas proibida por política. Um SCIF (Sensitive Compartmented Information Facility) é uma sala ou instalação projetada para prevenir escuta eletrônica e coleta de inteligência de sinais — é uma gaiola de Faraday, sem sinais sem fio entrando ou saindo. Uma rede governamental classificada sob controle ITAR (International Traffic in Arms Regulations) não pode transmitir dados técnicos cobertos para partes não aprovadas — uma categoria que inclui provedores de serviços em nuvem não autorizados sob o ITAR.
Para organizações nesses ambientes, "cloud SaaS" não é um risco a ser gerenciado — é uma impossibilidade técnica. Qualquer ferramenta de anonimização que requer uma conexão de rede ativa não pode ser implantada. Qualquer ferramenta que se conecta para verificação de licença é um não-iniciador. Qualquer ferramenta cujos modelos de detecção requerem chamadas de API em nuvem para inferência não pode funcionar.
A comunidade Ollama cita especificamente a implantação air-gapped como a principal justificativa para ferramentas de IA locais: "Todos os dados permanecem no seu dispositivo com Ollama, sem informações enviadas para servidores externos — particularmente importante para trabalhos sensíveis como médicos lidando com anotações de pacientes ou advogados revisando arquivos de casos." A mesma lógica se aplica ao nível organizacional para ambientes classificados e controlados pelo ITAR.
O Caso de Uso do ITAR
Um cientista de dados em um contratante de defesa processando registros de pessoal sob requisitos do ITAR precisa desidentificar arquivos antes de compartilhar com um jornalista que solicitou informações via FOIA. A rede do contratante é air-gapped. O processamento deve ocorrer na máquina air-gapped e deve produzir saídas adequadas para liberação pública.
Esse caso de uso não tem solução em nuvem. O único caminho é uma ferramenta que roda inteiramente na máquina local, aplica modelos de detecção armazenados localmente e produz saídas anonimizadas sem qualquer comunicação externa. O Aplicativo Desktop baseado em Tauri 2.0 funciona exatamente nessa configuração: após download e instalação, nenhuma chamada de rede é feita durante o processamento de documentos. Os modelos NER do spaCy, os padrões regex e a inferência do transformer rodam localmente. A saída do processamento nunca deixa a máquina, a menos que explicitamente exportada pelo usuário.
Pseudonimização Reversível para Operações Classificadas
Um requisito relacionado em contextos classificados e governamentais: pseudonimização reversível que mantém a utilidade analítica enquanto protege identidades reais. O Artigo 4(5) do GDPR reconhece formalmente a pseudonimização como uma medida de proteção de dados que reduz o risco de conformidade — dados pseudonimizados estão sujeitos a obrigações reduzidas em comparação com dados totalmente identificáveis, desde que as chaves de pseudonimização sejam mantidas separadas do conjunto de dados pseudonimizado.
A pesquisa da IAPP (2024) descobriu que apenas 23% das ferramentas de anonimização oferecem verdadeira reversibilidade — a capacidade de descriptografar dados pseudonimizados de volta aos valores originais usando uma chave que é mantida separada da saída. A maioria das ferramentas implementa substituição permanente (os dados originais são sobrescritos e não podem ser recuperados) ou mascaramento (exibição parcial do valor original).
Para operações governamentais onde conjuntos de dados pseudonimizados devem ser compartilháveis entre compartimentos — uma equipe recebe o conjunto de dados pseudonimizado para trabalho analítico, outra equipe mantém a chave de descriptografia para reidentificação quando legalmente exigido — a criptografia reversível com separação de chave é a única arquitetura compatível.
A abordagem de zero-knowledge estende isso ainda mais: a chave de criptografia é gerada do lado do cliente e nunca transmitida. Mesmo que o provedor da ferramenta de anonimização fosse convocado, ele não pode produzir a chave de descriptografia porque nunca a recebeu. Para ambientes classificados onde a cadeia de custódia para chaves de criptografia é um requisito de segurança, essa arquitetura fornece a garantia necessária.
Conformidade com as Diretrizes do EDPB
As Diretrizes 05/2022 do EDPB sobre pseudonimização exigem separação de chaves: a chave de pseudonimização deve ser mantida por uma parte diferente daquela que recebe o conjunto de dados pseudonimizado, ou armazenada com controles técnicos que impeçam a parte receptora de acessar tanto os dados quanto a chave simultaneamente.
A combinação de geração de chave do lado do cliente (a chave nunca deixa o dispositivo do usuário), processamento local (os dados nunca deixam o ambiente air-gapped) e exportação separada de saídas pseudonimizadas e chaves de descriptografia satisfaz a exigência de separação de chaves do EDPB enquanto atende à restrição operacional air-gapped.
Fontes: