RAG local para dados empresariais: IA em conformidade com LGPD/GDPR para documentos sensíveis (2026)

Fatos rápidos

• 6 controles obrigatórios para qualquer RAG regulado: air-gap, RBAC, logs de auditoria, criptografia, rastreabilidade de dados, procedimento de exclusão.
• 3 padrões de implantação: notebook de usuário único (profissionais individuais), servidor on-premise (5–50 usuários), nuvem privada na UE (multi-entidade).
• A DPIA/RIPD é obrigatória quando dados de categorias especiais (saúde, jurídicos, biométricos) são ingeridos em larga escala.
• Lei de IA da UE: a maioria dos RAGs locais = risco limitado; passa a alto risco quando a recuperação alimenta decisões automatizadas (crédito, emprego, benefícios).
• O direito ao esquecimento deve se propagar para documentos de origem, índices vetoriais, embeddings em cache E o histórico de respostas.
• LGPD e ANPD (Brasil): o relatório de impacto à proteção de dados pessoais (RIPD) é o equivalente brasileiro da DPIA; a ANPD é a autoridade supervisora nacional.
• Os modelos de embedding de código aberto só são conformes com LGPD/GDPR se os pesos estiverem fixados, a inferência for completamente local e a licença tiver sido revisada.

Comparação de padrões de implantação

Escolher um padrão de implantação

Por que RAG local para dados sensíveis

• Transferência transfronteiriça (arts. 44–49 GDPR / arts. LGPD sobre transferências internacionais). Enviar dados pessoais a um sub-processador fora da UE/Brasil requer cláusulas contratuais padrão, uma avaliação do impacto da transferência e uma resposta crível sobre se a jurisdição receptora tem poderes de intimação que alcancem esses dados. O RAG local não transfere dados — a questão não surge.
• Proliferação de sub-processadores (art. 28 GDPR / art. 37 LGPD). Os provedores de LLM na nuvem frequentemente dependem de infraestrutura de hiperescalador, serviços de moderação de conteúdo e provedores de observabilidade. Cada um é um sub-processador que deve ser listado, contratado e auditado. O RAG local tem zero sub-processadores por padrão.
• Vazamento de dados de treinamento. Muitos termos de LLM na nuvem se reservam o direito de usar os prompts dos clientes para melhorar o modelo, a menos que seja usado um nível enterprise pago e a cláusula de não treinamento seja verificada. O RAG local executa modelos com pesos que você controla; nada sai do host.
• Cláusulas de confidencialidade em contratos com clientes. Os acordos com consultoria externa, NDAs de M&A e acordos sobre dados de pacientes frequentemente proíbem a transmissão do material protegido a sub-processadores externos. O RAG local contorna a cláusula completamente.
• Exposição a intimações judiciais e processos legais. Os documentos armazenados com um provedor na nuvem podem ser requeridos via processo legal dirigido ao provedor, com obrigações de divulgação das quais o controlador pode nem ser notificado a tempo. Os documentos que nunca saem das suas instalações só podem ser requeridos a você.

Os seis controles que toda implantação precisa

1. 1
   Air-gap ou controle de egresso estrito
   Why it matters: Confirme que os documentos e embeddings não podem vazar via chamadas de saída — SDKs de telemetria, sondas de atualização do modelo, relatores de falhas, callbacks de moderação de conteúdo, CDN de terceiros para fontes. Ou desative o acesso à rede completamente (air-gap real) ou execute uma lista de egresso permitido que só autorize servidores de atualização assinados.
2. 2
   Autenticação por usuário com acesso baseado em funções
   Why it matters: Você precisa conseguir responder "quem acessou qual documento" antes que um regulador pergunte. Login único contra um provedor de identidade, acesso por grupos a coleções e ACL por documento onde o caso o exige. Contas compartilhadas não são um controle — são uma falha de auditoria esperando para acontecer.
3. 3
   Logs de auditoria imutáveis que cobrem a ingestão e a recuperação
   Why it matters: Para cada documento: quem o enviou, quando, caminho de origem, hash. Para cada consulta: quem perguntou, o que foi perguntado (se o logging permitir), quais chunks foram recuperados, de quais IDs de documentos vieram, qual resposta foi retornada. Os logs devem ser à prova de adulteração — somente de adição, assinados, com uma retenção suficiente para cobrir a janela de investigação da autoridade supervisora.
4. 4
   Criptografia em repouso e em trânsito
   Why it matters: Criptografia de disco completo no host, TLS para qualquer chamada interna entre serviços, e gerenciamento de chaves que sobreviva a um notebook roubado ou uma conta de administrador comprometida. Chaves gerenciadas pelo cliente para implantações na nuvem.
5. 5
   Rastreabilidade determinista de dados do chunk à fonte
   Why it matters: Cada chunk recuperado deve ser rastreado até seu documento de origem, página, seção e versão. Isso é o que permite (a) verificar a resposta, (b) atender uma solicitação de exclusão, (c) defender o sistema perante um tribunal quando um resumo gerado é questionado.
6. 6
   Procedimento de exclusão por escrito que inclua o índice vetorial e os embeddings em cache
   Why it matters: Uma solicitação de direito ao esquecimento deve se propagar do armazenamento de origem, pelo índice vetorial, até quaisquer embeddings em cache, e pela retenção de registros de recuperação. A maioria das implantações gerencia a exclusão da origem corretamente e esquece o restante.

Air-gap e controle de egresso

• Air-gap real — sem DHCP, sem resolução DNS para destinos públicos, sem TCP de saída. As atualizações são realizadas via mídia assinada que um administrador conecta fisicamente.
• Lista de egresso permitido — o tráfego de saída só é permitido para uma pequena lista de destinos nomeados (servidores de atualização do modelo, seu provedor de identidade, encaminhadores de logs para coletores internos).
• O que verificar na plataforma: zero telemetria por padrão, sem chamadas de saída durante a inferência, sem CDN de fontes na UI, sem relatores de falhas que enviem payloads. Verifique com uma captura de pacotes ou uma ferramenta como Little Snitch no banco de testes antes de ir para produção.
• Governança de atualizações — os pesos do modelo, os pesos do embedder, o código do aplicativo e os patches do SO passam todos por uma janela de atualização controlada. O administrador que promove uma atualização a assina por escrito; a mudança é registrada.
• Ruptura de air-gap frequente: um SDK de análise incluído com um componente de interface de terceiros, uma referência a CDN de fontes no chrome do aplicativo, ou uma sonda de "verificar atualizações" que roda na inicialização.

Log de auditoria que resiste a uma revisão

• Eventos de ingestão: ID de documento, hash (SHA-256), nome de arquivo, caminho de origem, enviado por, timestamp, rótulo de classificação, tamanho, número de páginas, grupo proprietário, classe de retenção.
• Eventos de recuperação: ID de consulta, ID de usuário, timestamp, IDs de chunks recuperados (e IDs de documentos dos quais vieram), pontuações de recuperação, hash da resposta final, identificador do modelo, identificador do embedder, top-K utilizado.
• Eventos administrativos: promoção do modelo, troca de embedder, reconstrução do índice, mudanças de usuário/grupo, mudanças de ACL.
• Resistência a adulterações: log de somente adição, encadeamento de hashes (cada entrada referencia o hash da entrada anterior), chave de assinatura fora de banda, reconciliação periódica com uma cópia separada.
• Retenção: se alinha com a janela de investigação da autoridade supervisora — no mínimo o período de retenção do caso; comumente seis a sete anos para setores regulados; mais onde normas setoriais se aplicam.
• Pipeline: o aplicativo emite eventos estruturados; um encaminhador os envia a um armazenamento de logs separado com acesso de escrita restrito. O servidor de aplicativo nunca deve ter permissão para excluir ou reescrever entradas de logs.

Rastreabilidade de dados do chunk à fonte

• Rastreabilidade no nível do documento: cada documento tem um ID interno estável, um hash de conteúdo, um timestamp de ingestão, um proprietário, uma classificação e uma classe de retenção.
• Rastreabilidade no nível do chunk: cada chunk referencia seu ID de documento pai, página (para PDFs), seção (para documentos estruturados), offset de caractere, comprimento e versão da estratégia de chunking.
• Rastreabilidade no nível do embedding: cada vetor de embedding referencia seu ID de chunk e identificador de embedder.
• Rastreabilidade no nível da resposta: cada resposta gerada referencia os IDs de chunks que a produziram, o identificador do modelo, a versão do template de prompt e o timestamp.
• Reindexação sem quebrar a rastreabilidade: as reconstruções preservam os IDs de documentos e incrementam as versões da estratégia de chunking.

Criptografia e controle de acesso

• Criptografia em repouso — criptografia de disco completo no host (LUKS no Linux, BitLocker no Windows, FileVault no macOS para notebooks). Para servidores, criptografe também as partições que hospedam o armazenamento vetorial e o estágio de ingestão.
• Criptografia em trânsito — TLS para qualquer salto entre serviços, mesmo no localhost. TLS mútuo onde o modelo de ameaças justificar.
• Autenticação — login único contra seu provedor de identidade existente (OIDC, SAML). Sem contas locais em produção. MFA obrigatório para qualquer usuário com acesso administrativo ou a coleções sensíveis.
• Autorização — acesso baseado em grupos no nível da coleção; ACL no nível do documento onde o caso o exigir. O pipeline de recuperação deve aplicar as ACL no momento da consulta — não apenas a interface de usuário.
• Acesso administrativo — gerenciamento de acesso privilegiado para qualquer conta que possa ler ou reconstruir índices, ver logs de auditoria ou alterar ACLs.
• Segurança de endpoint — dispositivos gerenciados para implantações com notebook (registrados em MDM, criptografados, política de bloqueio de tela aplicada).

Padrão de notebook de usuário único

• Hardware — um notebook de categoria workstation com criptografia de disco completo, uma GPU discreta (ou uma máquina recente de memória unificada) e pelo menos 32 GB de RAM.
• Software — um aplicativo RAG de desktop autocontido que roda localmente; um LLM de código aberto com pesos baixados uma vez e fixados a um hash; um embedder de código aberto; um armazenamento vetorial local no disco criptografado.
• Postura de rede — com air-gap durante o trabalho; reconectado apenas para atualizações assinadas explícitas.
• Manuseio de documentos — documentos de origem no disco criptografado; uma estrutura de pastas por caso; backups semanais criptografados em um disco externo armazenado em local diferente.
• Postura de auditoria — o log de auditoria no nível do SO é o piso mínimo para o padrão de notebook.
• Limitações — um notebook de usuário único não é uma plataforma multiusuário. Compartilhar o notebook, compartilhar contas ou copiar o armazenamento de documentos para o notebook de um colega quebra a postura de auditoria.

Padrão de servidor on-premise

• Hardware — um servidor com uma ou duas GPUs de nível empresarial, discos redundantes, memória ECC e um no-break. Planeje 2–4× o armazenamento do seu corpus de documentos bruto para cobrir vetores, índices, logs e backups.
• Rede — uma VLAN dedicada atrás do firewall corporativo; lista de egresso permitido ou air-gap completo conforme o modelo de ameaças.
• Stack de software — uma plataforma RAG auto-hospedada, um LLM de código aberto como modelo de chat, um embedder de código aberto e um armazenamento vetorial apropriado para o tamanho do corpus.
• Identidade — federada com o provedor de identidade corporativo; a associação a grupos controla o acesso às coleções.
• Backup e recuperação de desastres — backups incrementais noturnos; backups completos semanais; cópia externa mantida pelo TI.
• Operações — janela de correção segundo a política de gerenciamento de mudanças; revisões de acesso trimestrais; procedimento de exclusão para solicitações de direito ao esquecimento testado; rota de atualização do modelo e do embedder documentada.

Opções de bancos de dados vetoriais para RAG on-premise

Padrão de nuvem privada na UE

• Seleção do provedor — a oferta soberana na UE de um hiperescalador ou um provedor de nuvem europeu. O DPA deve listar cada sub-processador; os mecanismos de transferência devem ser abordados se algum sub-processador estiver fora do EEE.
• Região — exclusivamente na UE, com garantias explícitas de residência de dados. Replicação entre regiões apenas para outras regiões da UE. Sem região dos EUA como failover, nem mesmo temporariamente.
• Criptografia — chaves gerenciadas pelo cliente com rotação; bring-your-own-key onde o provedor admitir; eventos de acesso a chaves registrados separadamente.
• Rede — VPC privada sem ingresso público; acesso apenas via conectividade privada (link dedicado ou VPN) da sua rede corporativa.
• Contratos — o DPA deve cumprir o art. 28 GDPR, listar sub-processadores, abordar as cláusulas contratuais padrão onde necessário e incluir uma cláusula explícita de não treinamento com dados do cliente que cubra tanto os pesos do LLM quanto qualquer serviço auxiliar.

Classificação segundo a Lei de IA da UE: risco limitado vs. alto risco

• Risco limitado (a maioria dos RAGs locais) — o sistema recupera e resume documentos para assistir a um humano; o humano toma a decisão. As obrigações são principalmente de transparência.
• Alto risco — a recuperação alimenta uma decisão automatizada em domínios que a Lei enumera: pontuação de crédito, seleção de pessoal, admissões educacionais, serviços públicos essenciais, aplicação da lei, migração, justiça, identificação biométrica, infraestrutura crítica.
• Obrigações de alto risco — sistema de gestão de riscos ao longo do ciclo de vida, governança de dados documentada, documentação técnica, registro automático de eventos, transparência, supervisão humana, medidas de precisão e robustez, avaliação de conformidade pré-comercialização.
• Práticas proibidas — pontuação social, rastreamento não seletivo de imagens faciais, reconhecimento de emoções em locais de trabalho e centros educacionais, determinada categorização biométrica em tempo real.
• Documentação como artefato de auditoria — o expediente técnico exigido para sistemas de alto risco não é um entregável único; é um documento vivo.

Requisitos da DPIA (GDPR) / RIPD (LGPD)

• Quando é obrigatória (GDPR/LGPD) — avaliação sistemática e exaustiva que inclua elaboração de perfis com efeitos jurídicos; tratamento em larga escala de dados de categorias especiais (saúde, dados jurídicos, biométricos, raciais, políticos, religiosos, sindicais); monitoramento sistemático de zonas de acesso público.
• Escopo da DPIA/RIPD — finalidade e base jurídica; descrição das operações de tratamento; avaliação de necessidade e proporcionalidade; avaliação de riscos para os titulares; mitigações e risco residual; consulta ao DPO/encarregado.
• Riscos específicos do RAG a abordar: reidentificação de indivíduos a partir de chunks recuperados; geração de informação imprecisa que afete uma pessoa; vazamento via logs ou backups; completude da exclusão em solicitações de direito ao esquecimento; contaminação cruzada entre coleções.
• Documento vivo — reexecute a DPIA/RIPD quando o corpus se ampliar materialmente, quando o modelo ou o embedder mudar, quando os limites de acesso mudarem, ou anualmente como linha de base.

LGPD e ANPD: notas específicas para o Brasil

• ANPD (Autoridade Nacional de Proteção de Dados). A ANPD é a autoridade supervisora brasileira equivalente às DPAs europeias. As diretrizes e resoluções da ANPD são a referência operativa para conformidade LGPD. Monitore o site da ANPD (gov.br/anpd) para orientações sobre sistemas de IA e RAG.
• Encarregado de Proteção de Dados (artigo 41 LGPD). Toda organização que realiza tratamento de dados pessoais deve indicar um encarregado (equivalente ao DPO europeu). O encarregado deve ser informado e consultado antes da implantação de sistemas de RAG que tratem dados pessoais.
• RIPD (Relatório de Impacto à Proteção de Dados Pessoais — art. 38 LGPD). Equivalente funcional da DPIA europeia. A ANPD pode exigi-lo mediante solicitação. Para RAGs que tratem dados sensíveis (art. 5, II LGPD) em larga escala, a elaboração preventiva do RIPD é a postura defensável.
• Dados sensíveis (artigo 11 LGPD). A LGPD eleva a proteção de dados de saúde, biométricos, genéticos, sobre convicção religiosa, opinião política, filiação sindical ou a organização de caráter religioso, filosófico ou político, referentes à vida sexual ou orientação sexual e dados de crianças e adolescentes. Para RAGs que ingerem esses dados, a base jurídica é mais restrita do que para dados pessoais comuns.
• Transferência internacional de dados (artigo 33 LGPD). A LGPD restringe a transferência de dados pessoais para países ou organismos internacionais que não proporcionem nível de proteção adequado. O RAG local elimina essa preocupação por construção — os dados nunca saem do território nacional.
• Registro das operações de tratamento. Organizações que realizam tratamento em larga escala devem manter um registro das atividades de tratamento (artigo 37 LGPD), incluindo os sistemas de RAG que tratem dados pessoais.

Lista de verificação de conformidade antes da produção

• ☐ Base jurídica documentada para cada categoria de dados de origem — consentimento, contrato, obrigação legal, interesse vital, tarefa pública ou interesse legítimo com um teste de ponderação no expediente.
• ☐ DPIA/RIPD aprovada pelo DPO/encarregado, com um procedimento de exclusão testado em anexo.
• ☐ Registro de atividades de tratamento (art. 30 GDPR / art. 37 LGPD) atualizado para incluir o sistema RAG.
• ☐ Seis controles verificados de ponta a ponta: air-gap ou lista de egresso permitido, RBAC, logs de auditoria, criptografia, rastreabilidade, procedimento de exclusão.
• ☐ Captura de pacotes de saída limpa durante um teste de saturação de 24 horas; repetida após cada atualização do aplicativo.
• ☐ Integração do provedor de identidade testada com um usuário real de cada nível de acesso.
• ☐ Backups realizados e uma restauração realmente testada em hardware isolado.
• ☐ Procedimento de direito ao esquecimento testado com dados sintéticos cobrindo o armazenamento de origem, o índice vetorial, os embeddings em cache e a retenção do log de recuperação.
• ☐ Classificação segundo a Lei de IA da UE confirmada (risco limitado vs. alto risco); expediente técnico em vigor se for de alto risco.
• ☐ Contratos de fornecedores (se houver) revisados: DPA conforme o art. 28 GDPR, sub-processadores listados, cláusula de não treinamento cobrindo os dados do cliente.
• ☐ Aviso de transparência redigido em linguagem compreensível para o usuário explicando a assistência de IA, o humano no loop e o fluxo de dados.
• ☐ Procedimento de resposta a incidentes atualizado para incluir cenários específicos do RAG.
• ☐ Revisão de acesso trimestral programada e atribuída.
• ☐ Atualização anual da DPIA/RIPD programada e vinculada ao processo de gerenciamento de mudanças.

Erros frequentes

• Erro 1: tratar "local" como sinônimo de "em conformidade". Executar on-premise resolve as questões de transferência e de sub-processador; não resolve a base jurídica, a DPIA/RIPD, o log de auditoria nem os direitos dos titulares.
• Erro 2: pular a DPIA/RIPD porque o sistema é "apenas uma ferramenta de busca". Uma ferramenta de busca que ingere dados de categorias especiais em larga escala é exatamente o que o art. 35 GDPR / art. 38 LGPD cobre.
• Erro 3: registrar o texto da consulta sem verificar a base jurídica. As próprias consultas são dados pessoais quando fazem referência a indivíduos.
• Erro 4: esquecer os embeddings em cache no procedimento de exclusão. A exclusão da origem funciona. A reconstrução do índice vetorial funciona. A camada de cache que sua plataforma adicionou para desempenho, as pegadas de embedding no log de recuperação e o histórico de respostas no armazenamento de chat são as partes que são esquecidas.
• Erro 5: permitir a usuários com muitos privilégios contornar as ACLs de coleção. "Os administradores podem ver tudo" é conveniente e muito comum; também é a razão mais frequente por que as auditorias saem mal.
• Erro 6: reutilizar um workspace para vários casos ou clientes. A contaminação cruzada de citações e contexto é uma falha de confidencialidade mesmo antes de qualquer parte externa vê-la.
• Erro 7: comprar air-gap e depois conectar um telefone pessoal para os testes. O perímetro de air-gap deve incluir as pessoas que podem transportar dados por ele.
• Erro 8: tratar a escolha de modelo e embedder como "configurar e esquecer". Cada atualização é um evento de gerenciamento de mudanças com implicações para a DPIA/RIPD, a rastreabilidade e o rastro de auditoria.

Fontes

• Texto completo do GDPR (gdpr-info.eu) — Texto completo do Regulamento Geral de Proteção de Dados com comentário artigo por artigo.
• Texto completo do EU AI Act — Texto completo do regulamento com o framework de classificação de riscos.
• Lei Geral de Proteção de Dados — LGPD (planalto.gov.br) — Texto completo da LGPD brasileira.
• ANPD — Autoridade Nacional de Proteção de Dados (gov.br/anpd) — Diretrizes, resoluções e orientações da autoridade supervisora brasileira.
• Framework de Gestão de Risco de IA do NIST — Framework de governança federal dos EUA aplicável à avaliação de riscos de IA.
• Diretrizes do EDPB sobre DPIA — Orientação do Comitê Europeu de Proteção de Dados sobre quando e como realizar DPIAs.

FAQ

Leituras relacionadas

• AnythingLLM vs PrivateGPT vs Open WebUI: o melhor RAG local — quais plataformas auto-hospedadas se adaptam a cada postura de conformidade.
• Agentes de IA locais para fluxos de trabalho empresariais e conformidade na UE — tema de conformidade adjacente quando a recuperação alimenta etapas de fluxo de trabalho automatizados.
• Automação local de e-mail e calendário com LLM — padrões de automação empresarial adjacentes onde o mesmo conjunto de controles se aplica.
• RAG local nos seus PDFs passo a passo — guia de implementação prática para os padrões on-premise e de notebook.
• Converse com 1.000 PDFs localmente — orientação operacional para corpus maiores que pressionam o teto do on-premise.
• Hub de Power Local LLM — a biblioteca completa de guias para implantações de LLM auto-hospedados.