RAG com dados internos da empresa: como conectar a IA aos seus documentos com segurança

RAG com dados internos da empresa: como conectar a IA aos seus documentos com segurança

RAG com dados internos da empresa é a arquitetura que faz um modelo de linguagem responder com base nos documentos, contratos, manuais, tickets e bases de dados da própria organização, em vez de depender só do que aprendeu no treinamento. A cada pergunta, o sistema busca os trechos mais relevantes no acervo interno, entrega esses trechos ao modelo junto com a pergunta e pede uma resposta apoiada neles, de preferência com a fonte citada.

Para quem decide, o ponto principal é outro: RAG é a forma mais barata e controlável de colocar IA generativa para trabalhar sobre o conhecimento da empresa, porque não exige treinar modelo nenhum e permite atualizar o conteúdo a qualquer momento. O risco também está no mesmo lugar. Se a busca não respeitar quem pode ler o quê, o assistente vira um atalho para documentos que o usuário nunca deveria ver.

Este guia explica como o RAG funciona por dentro, quais fontes internas valem a pena conectar primeiro, como tratar permissão, LGPD e segurança, como medir se as respostas são boas e quanto esforço cada etapa costuma exigir. No fim, há perguntas frequentes sobre o tema.

O que é RAG e por que ele virou o padrão para dados internos

O termo nasceu no artigo Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, de Patrick Lewis e coautores, apresentado na NeurIPS 2020. A ideia era combinar duas memórias: a "paramétrica", que é o conhecimento guardado nos pesos do modelo, e a "não paramétrica", um índice de documentos que pode ser consultado na hora. Seis anos depois, a mesma divisão explica por que o RAG domina os projetos corporativos.

O modelo de linguagem sabe escrever, resumir e raciocinar, mas não conhece a política de reembolso da sua empresa, o contrato com o fornecedor de manutenção nem o procedimento de segurança da planta 3. Há três formas de levar esse conhecimento até ele:

Na prática, o RAG ganha nos casos de uso com dados internos por três motivos. O conteúdo atualiza sem mexer no modelo: entrou uma nova versão do manual, basta reindexar. A resposta pode citar o documento de onde veio, o que facilita a conferência por quem usa. E o controle de acesso pode ser aplicado na busca, antes de o modelo ver qualquer coisa, que é onde a segurança precisa estar.

O fine-tuning continua útil, mas para outro problema: ensinar formato, vocabulário ou um tipo de classificação. Para a discussão técnica sobre quando combinar os dois, o artigo RAG em produção em 2026 aprofunda os padrões avançados e a avaliação.

Como funciona um RAG sobre os dados da empresa

Um RAG corporativo tem duas partes que rodam em momentos diferentes: a ingestão, que prepara o acervo, e a consulta, que acontece a cada pergunta.

Ingestão: preparar o acervo

1. Conectar as fontes. SharePoint, Google Drive, file servers, Confluence, sistemas de chamados, ERP, CRM, bases de contratos. Cada conector traz o conteúdo e, tão importante quanto, os metadados: autor, data, área, versão e quem tem permissão de leitura.
2. Extrair o texto. PDF digitalizado precisa de OCR, planilha precisa virar texto com contexto, apresentação perde a ordem se for lida de qualquer jeito. É a etapa que mais consome tempo nos primeiros meses.
3. Dividir em trechos (chunks). Documentos longos são quebrados em pedaços de algumas centenas de tokens, de preferência respeitando seções e cláusulas, e não um número fixo de caracteres.
4. Gerar embeddings e indexar. Cada trecho vira um vetor numérico que representa o significado do texto. O índice guarda o vetor, o texto e os metadados, incluindo a lista de grupos que podem ler aquele trecho.

Consulta: responder a pergunta

1. O usuário pergunta, autenticado com a identidade corporativa.
2. O sistema busca os trechos mais parecidos com a pergunta, filtrando pelos grupos a que o usuário pertence.
3. Os melhores trechos passam por um reordenamento (reranking) e os primeiros vão para o modelo.
4. O modelo responde com base nesses trechos e cita a origem.
5. Tudo fica registrado: pergunta, trechos usados, resposta, custo e avaliação do usuário.

Busca híbrida e contexto do trecho

A busca só por vetores erra em códigos, siglas, números de contrato e nomes próprios, que são exatamente o que aparece nas perguntas internas ("qual o prazo do contrato 4471?"). Por isso a maioria dos projetos combina busca vetorial com busca por palavra-chave (BM25) e um reranker no fim.

Outra melhoria que vale considerar é acrescentar a cada trecho uma frase de contexto sobre o documento de onde ele saiu, antes de gerar o embedding. Em testes publicados pela Anthropic, essa técnica, chamada Contextual Retrieval, reduziu em 49% as falhas de recuperação quando combinada com BM25, e em 67% quando somada a um reranker. Os números são do conjunto de testes deles; no seu acervo, o ganho precisa ser medido, o que leva à seção de avaliação mais adiante.

Quais dados internos conectar primeiro

O erro mais comum é tentar indexar "tudo" no primeiro projeto. O acervo cresce, a qualidade cai, ninguém sabe dizer se a resposta errada veio de documento desatualizado ou de busca ruim, e o projeto perde patrocínio. Começar por um conjunto de fontes ligado a uma dor concreta dá resultado mais rápido e um padrão de segurança que depois se repete.

• Contratos e aditivos. Perguntas sobre prazo, multa, escopo e reajuste aparecem todo dia em compras, jurídico e operações. O conteúdo é estável e a citação da cláusula resolve a conferência.
• Manuais, procedimentos e normas internas. Operação de planta, segurança do trabalho, qualidade. Quem pergunta está longe do documento e precisa da resposta em segundos.
• Base de chamados e soluções. Suporte de TI e atendimento ao cliente ganham quando o histórico de tickets resolvidos vira fonte de consulta.
• Políticas de RH e benefícios. Volume alto de perguntas repetidas, conteúdo controlado e fácil de validar.

Dados estruturados, como pedidos no ERP ou indicadores no data warehouse, normalmente não entram no RAG como texto. O caminho melhor é dar ao assistente uma ferramenta que consulta a base (por SQL ou API) com as permissões do usuário. Nesse ponto o RAG encontra os agentes: o modelo decide quando buscar em documentos e quando consultar um sistema.

Foi esse tipo de combinação que a BIX usou na plataforma de inteligência operacional com IA para uma empresa industrial: uma IA agentic que cruza contratos de serviços com dados operacionais de sete plantas e identificou uma economia estimada de cerca de 15% nos serviços analisados, sem cortes no escopo ou na qualidade.

Uma regra útil para escolher a fonte: se hoje alguém perde tempo procurando a resposta em documentos e a resposta errada tem custo (multa, retrabalho, parada), o caso de uso paga o projeto. Se a pergunta é rara ou a resposta errada não custa nada, deixe para depois.

Permissão, LGPD e segurança: onde o RAG costuma falhar

O RAG não cria um problema de segurança novo, mas amplifica os que já existem. Uma pasta de rede com permissão aberta demais que ninguém encontrava passa a ser encontrada pelo assistente em segundos. Por isso a segurança precisa ser desenhada antes da primeira indexação.

Permissão no momento da busca

O princípio é simples: o modelo só pode ver o que o usuário poderia abrir. Isso se resolve no índice, gravando com cada trecho a lista de usuários ou grupos com acesso ao documento de origem e filtrando por ela em toda consulta. A documentação do Azure AI Search descreve esse padrão de filtro de segurança e alerta para um detalhe que vale para qualquer ferramenta: o identificador gravado é só um texto usado no filtro, não há autenticação nele. A proteção existe apenas se o filtro for aplicado em todas as consultas, pela aplicação, com a identidade real do usuário.

• Sincronizar permissões, não só conteúdo. Quando alguém sai de um grupo ou um documento muda de pasta, o índice precisa refletir isso. Defina a frequência e monitore atrasos.
• Separar índices por classe de dado. Documentos de RH, jurídicos e de diretoria podem ficar em índices próprios, com acesso restrito à aplicação que os consulta.
• Não confiar no prompt para segurança. Instrução do tipo "não revele dados confidenciais" não substitui o filtro. Se o trecho chegou ao modelo, considere que ele pode aparecer na resposta.

A OWASP, no seu Top 10 para aplicações com LLM, tem um item dedicado a fraquezas de vetores e embeddings e recomenda exatamente isso: armazenamento de vetores com controle de acesso fino, particionamento lógico rígido entre grupos de usuários e registro imutável das recuperações para detectar comportamento suspeito.

Documento como vetor de ataque

Outro risco é o conteúdo do próprio acervo. Um documento com instruções escondidas (texto branco num PDF, um comentário numa planilha) pode ser recuperado e mudar o comportamento do modelo. A OWASP chama isso de prompt injection indireto e registra que RAG e fine-tuning não eliminam essa vulnerabilidade. As medidas que ela lista valem para o RAG corporativo: limitar o papel do modelo, validar a saída com código, separar e marcar o conteúdo externo, manter funções sensíveis fora do alcance direto do modelo e exigir aprovação humana para ações de alto risco.

Na prática, isso significa validar o que entra no acervo (de onde veio, quem publicou), extrair texto de forma que conteúdo oculto seja detectado e nunca dar ao assistente permissão de agir (enviar e-mail, aprovar pedido) só com base no que um documento disse.

LGPD

Quando o acervo tem dado pessoal (currículos, prontuários, atendimentos, folha), o RAG é tratamento de dado pessoal e entra nas regras da LGPD: finalidade definida, mínimo de dado necessário e medidas de segurança. Duas decisões ajudam muito:

• Mascarar ou excluir dado pessoal na ingestão quando ele não é necessário para a resposta. O assistente de procedimentos não precisa do CPF de quem assinou o documento.
• Escolher onde o modelo roda de acordo com a classe do dado: API corporativa, modelo dentro da nuvem da empresa ou LLM local. O guia IA privada e LGPD compara as três opções e quando cada uma faz sentido.

Os logs merecem o mesmo cuidado do acervo. Pergunta e resposta com dado pessoal guardadas sem controle de acesso e sem prazo de retenção são um vazamento esperando acontecer.

Como medir se o RAG responde bem

Um RAG que "parece bom" na demonstração pode errar uma parte relevante das perguntas reais sem que ninguém perceba. A diferença entre piloto e produção está em medir.

Monte um conjunto de perguntas de referência

Antes de escolher ferramenta, reúna com as áreas usuárias algumas dezenas a poucas centenas de perguntas reais, com a resposta correta e o documento onde ela está. Esse conjunto serve para comparar configurações (tamanho de trecho, busca híbrida, reranker, modelo) e para testar cada mudança antes de ir para produção.

Avalie a busca e a resposta separadamente

Separar busca de geração é o que permite corrigir o problema certo. Se o documento correto não aparece, trocar de modelo não resolve: o trabalho é na extração, no tamanho dos trechos ou na busca. Se o documento aparece e a resposta sai errada, o ajuste é no prompt, no número de trechos ou no modelo.

Observabilidade em produção

Depois do lançamento, cada consulta precisa ficar rastreável: quais trechos foram usados, quanto custou, quanto demorou e como o usuário avaliou. Ferramentas como LangSmith e OpenTelemetry fazem esse papel. No Grupo Soma, a BIX implantou observabilidade nas aplicações com LLM e trabalhou na redução do consumo de tokens, a mesma camada que permite ver quais perguntas falham e quanto cada caso de uso custa.

Do piloto à produção: etapas, esforço e custo

O caminho que funciona na maioria das empresas tem quatro etapas. A duração de cada uma depende muito do estado dos documentos e das permissões, e a ingestão costuma ser a mais longa.

1. Escolha do caso de uso e do acervo. Definir a dor, as fontes, quem usa, o conjunto de perguntas de referência e as regras de acesso e de dado pessoal.
2. Piloto com usuários reais. Ingestão das fontes escolhidas, busca híbrida com filtro de permissão, interface simples (no Teams, no portal interno ou numa página própria) e avaliação contra o conjunto de referência.
3. Produção. Sincronização contínua de conteúdo e permissões, observabilidade, alertas de custo, testes de segurança e documentação para a área de TI.
4. Evolução contínua. Novas fontes, novos casos de uso, troca de modelo quando surgir opção melhor ou mais barata e revisão periódica do conjunto de perguntas.

Onde o dinheiro vai

• Engenharia de dados para a ingestão. Conectores, OCR, limpeza e sincronização de permissões. É o maior esforço do projeto e o mais subestimado.
• Infraestrutura de busca. Banco vetorial ou serviço de busca gerenciado, cobrado por volume indexado e por consultas. Para comparar as opções, veja o guia de bancos de dados vetoriais.
• Consumo do modelo. Tokens de entrada (pergunta mais trechos) e de saída. Mandar menos trechos e melhores reduz o custo e costuma melhorar a resposta.
• Operação. Monitorar, avaliar, ajustar e incorporar novas fontes. RAG não é projeto que se entrega e esquece: o acervo muda toda semana.

Se a empresa já usa Azure, AWS ou Google Cloud, os serviços gerenciados de cada nuvem encurtam o caminho. O artigo sobre arquitetura RAG com Azure OpenAI e Azure AI Search mostra a montagem completa nesse ecossistema.

Erros que fazem o projeto parar

• Indexar pastas inteiras sem dono e sem data de validade: o assistente cita a versão de 2019 do procedimento.
• Lançar sem conjunto de referência: ninguém consegue provar que a versão nova é melhor que a anterior.
• Tratar permissão como etapa futura: a área de segurança barra o projeto na véspera do lançamento.
• Medir só a satisfação do usuário: respostas erradas e bem escritas recebem nota alta.

Como a BIX trabalha com RAG sobre dados internos

A BIX trabalha nesse problema começando pelo caso de uso e pelas regras de acesso, e só depois pela ferramenta: escolhe as fontes, monta o conjunto de perguntas de referência, desenha a busca com filtro de permissão e mede recuperação, fidelidade e custo antes de ir para produção. O ponto de partida costuma ser a página de soluções de IA generativa. Como o acervo e as perguntas mudam toda semana, a continuidade costuma ficar com um squad dedicado que incorpora novas fontes, acompanha a qualidade das respostas e mantém a sincronização de permissões em dia.

Perguntas frequentes

O que é RAG com dados internos da empresa? É uma arquitetura em que um modelo de linguagem responde com base em documentos e sistemas da própria empresa. A cada pergunta, o sistema busca os trechos relevantes no acervo interno, entrega ao modelo e gera uma resposta apoiada neles, normalmente com a fonte citada. Não é preciso treinar um modelo novo.

RAG ou fine-tuning: qual usar com os dados da empresa? Para responder sobre fatos que mudam (contratos, procedimentos, políticas), RAG é a escolha mais segura, porque atualiza sem novo treino e permite citar a fonte. Fine-tuning serve para ensinar formato, tom ou tarefas repetitivas. Os dois podem ser combinados no mesmo sistema.

Como garantir que o assistente não mostre documentos confidenciais? Gravando no índice quem tem acesso a cada documento e filtrando a busca pela identidade do usuário em toda consulta, antes de o modelo receber qualquer trecho. Instruções no prompt não substituem esse filtro. Também ajuda separar índices por classe de dado e sincronizar as permissões com frequência.

Preciso de um LLM local para fazer RAG com dados internos? Não necessariamente. Muitas empresas usam API corporativa com contrato adequado e mascaramento de dado pessoal. O LLM local ou o modelo na nuvem da própria empresa fazem mais sentido quando o acervo tem dado sensível, sigilo contratual forte ou exigência de não sair da rede.

Quanto tempo leva para colocar um RAG em produção? Depende do estado dos documentos e das permissões. O caminho passa por definir o caso de uso e as regras de acesso, rodar um piloto com usuários reais e só então ir para produção com observabilidade e testes de segurança. A ingestão dos documentos, com OCR, limpeza e sincronização de permissões, costuma ser a etapa mais longa.