Guia prático de segurança e dados sensíveis em aplicações com LLM

Aplicações com LLM não precisam ter acesso irrestrito a tudo. O ponto é controlar o que entra no modelo, o que fica salvo, quem acessa e o que a IA pode fazer.

Contexto

Nos últimos textos da série, a conversa foi avançando por partes importantes de uma aplicação com IA: RAG, chunking, embeddings, retrieval, respostas estruturadas, evals, harness, agentes com ferramentas e observabilidade.

Depois disso tudo, existe uma pergunta que não dá para deixar para o fim: quais dados essa IA pode ver, registrar, lembrar, recuperar ou usar para agir?

Uma chamada para LLM raramente envolve só pergunta e resposta. Muitas vezes existe prompt, dados do usuário, trechos de documentos, resultado de busca, histórico, metadados, arquivos, logs, validação, fallback e talvez ferramentas conectadas a outros sistemas.

O problema

Quando a gente fala em segurança, é comum pensar primeiro em login, senha, permissões de rota, banco de dados, criptografia ou infraestrutura. Tudo isso continua importante. Mas aplicações com LLM adicionam outros caminhos por onde dados podem circular sem necessidade.

• Um prompt pode carregar dados pessoais demais.
• Um log pode salvar entrada e resposta completas.
• Um fluxo com RAG pode recuperar um documento que o usuário não deveria ver.
• Um índice de embeddings pode guardar referência a conteúdo interno sem política clara.
• Um agente pode ter permissão para chamar uma ferramenta ampla demais.
• Uma resposta pode repetir informação sensível que estava no contexto.

O risco nem sempre vem de uma falha espetacular. Muitas vezes vem do acúmulo de pequenas decisões práticas: mandar o documento inteiro quando bastava um trecho, salvar prompt completo para debug, não separar permissões no retrieval ou deixar uma ferramenta disponível para qualquer intenção.

Modelo mental

Antes de chamar um LLM, eu gosto de pensar em cinco perguntas.

11. O que entra?22. O que sai?33. O que fica salvo?44. Quem pode acessar?55. O que a IA pode fazer?

Essas perguntas parecem básicas, mas organizam quase todo o raciocínio. Elas cobrem prompt, contexto, arquivos, resposta visível, saída estruturada, logs, memória, cache, traces, embeddings, usuário final, equipe interna, ferramentas de suporte e ações com efeito colateral.

Se uma feature com IA não responde bem essas perguntas, ela ainda está cedo demais para receber autonomia ou dados sensíveis.

Minimize dados antes de melhorar prompt

A primeira decisão de segurança é simples: não envie para o modelo o que ele não precisa ver.

Isso vale para dados pessoais, dados internos, documentos longos, histórico de conversa, tokens, credenciais, metadados e qualquer informação que entrou no fluxo só por conveniência.

• Um resumo de atendimento talvez não precise de CPF, telefone, endereço ou e-mail completo.
• Uma análise de documento talvez precise de três trechos relevantes, não do arquivo inteiro.
• Uma classificação de mensagem talvez precise do texto e de uma categoria, não do histórico completo do usuário.
• Uma sugestão de resposta talvez precise de contexto resumido, não de todos os dados cadastrais.

Contexto bom é contexto suficiente para a tarefa. Contexto demais pode aumentar custo, latência, confusão, risco de vazamento e dificuldade de auditoria.

Dados sensíveis em prompts

Prompt não é só texto temporário. Em muitos sistemas, ele pode aparecer em logs, traces, ferramentas de observabilidade, ambientes de desenvolvimento, histórico de execução, avaliações ou telas internas de suporte.

• O dado é necessário para a resposta?
• Pode ser mascarado?
• Pode ser substituído por um identificador interno?
• Pode ser resumido antes de chegar ao modelo?
• Precisa de consentimento explícito?
• Precisa ser removido dos logs?

1Evite:2"Resuma o atendimento do cliente Bruno, CPF 000.000.000-00, telefone..."34Prefira:5"Resuma o atendimento do cliente. Remova dados pessoais e foque no problema, na ação tomada e no próximo passo."

Nem sempre será possível remover tudo. Algumas tarefas realmente dependem de dados específicos. Mas essa decisão precisa ser explícita, não acidental.

Logs seguros

Logs são uma faca de dois lados em aplicações com IA. Sem logs, fica difícil investigar erro, custo, latência, fallback, validação e comportamento do modelo. Com logs demais, você pode criar um repositório de prompts e respostas cheios de informação que não deveria estar guardada.

1{2  "feature": "document-summary",3  "model": "model-name",4  "promptVersion": "summary-v2",5  "status": "validated",6  "latencyMs": 1620,7  "inputTokens": 840,8  "outputTokens": 210,9  "validation": "passed",10  "usedFallback": false11}

Esse tipo de registro ajuda a investigar o fluxo sem salvar o documento inteiro. Dependendo do caso, faz sentido guardar id interno da execução, versão do prompt, modelo usado, status da validação, tempo de resposta, estimativa de tokens, tipo de erro e se fallback foi acionado.

Log bom não é log que guarda tudo. Log bom é log que permite investigar sem aumentar o risco à toa.

RAG com dados sensíveis

RAG costuma ser apresentado como uma forma de dar conhecimento externo ao modelo. Mas, quando a base tem informação interna ou sensível, o problema não é só recuperar o trecho mais relevante. Também é recuperar apenas o que aquele usuário pode ver.

Retrieval sem controle de acesso pode transformar uma base privada em contexto disponível para gente errada. Isso pode acontecer de forma silenciosa: um documento foi indexado, a busca semântica achou um trecho parecido, o trecho entrou no contexto e o modelo respondeu com algo que parecia útil.

• Guarde metadados de origem e permissão junto dos documentos.
• Filtre por usuário, organização, papel ou escopo antes do ranking final.
• Evite misturar bases públicas e privadas sem marcação clara.
• Registre qual documento foi usado na resposta.
• Defina política de remoção ou reindexação quando o conteúdo muda.
• Revise se chunks, embeddings e metadados carregam informação sensível.

RAG não elimina regra de acesso. Ele só muda onde essa regra precisa aparecer.

Embeddings também são parte do sistema

Às vezes, embeddings são tratados como se fossem uma versão inofensiva do texto original. Na prática, eles continuam sendo derivados de dados reais e fazem parte da arquitetura de informação.

• De onde veio o conteúdo indexado?
• Quem pode consultar esse índice?
• Os chunks carregam dados pessoais ou internos?
• Existe política para apagar ou atualizar dados?
• Metadados revelam mais do que deveriam?
• Ambientes de teste usam dados reais sem necessidade?

Em um projeto pequeno, talvez isso comece com uma regra simples: não indexar dados sensíveis que não são necessários para a experiência.

Agentes com ferramentas precisam de limite

Um chatbot responde. Um agente com ferramentas pode consultar, decidir, preencher, alterar, enviar, criar, apagar ou publicar. Essa diferença muda o risco.

Quando a IA tem ferramentas, o problema deixa de ser apenas "ela respondeu algo errado" e passa a incluir "ela fez algo errado".

• Ferramentas de leitura são diferentes de ferramentas de escrita.
• Ações reversíveis são diferentes de ações destrutivas.
• Consulta interna é diferente de envio externo.
• Sugestão é diferente de execução.
• Usuário comum é diferente de usuário administrador.
• Ambiente de teste é diferente de produção.

Autonomia útil não é acesso total. Autonomia útil é ação dentro de limites claros.

Prompt injection não é detalhe teórico

Prompt injection parece distante até a aplicação começar a ler conteúdo externo. Se a IA lê páginas, documentos, comentários, e-mails, tickets ou qualquer entrada que outra pessoa escreveu, esse conteúdo pode tentar influenciar o comportamento do modelo.

O cuidado básico é separar papéis: instrução de sistema não é documento recuperado; documento recuperado não é comando; mensagem do usuário não é política de segurança; resultado de ferramenta não é autorização para outra ferramenta.

• Trate conteúdo externo como dado, não como instrução soberana.
• Limite ferramentas disponíveis.
• Valide argumentos antes de executar.
• Peça confirmação humana em ações sensíveis.
• Bloqueie tentativas óbvias de exfiltração.
• Registre quando uma ação foi negada.

Validar saída também é segurança

Validação de saída não serve só para conferir JSON. Ela também pode impedir que uma resposta seja usada quando o modelo sai do escopo, expõe informação indevida, inventa dado crítico ou tenta executar uma ação que deveria passar por revisão.

• A resposta contém dado pessoal que não deveria aparecer?
• A resposta cita documento sem permissão?
• A resposta recomenda uma ação irreversível?
• A resposta ultrapassa o escopo permitido?
• A resposta deveria pedir revisão humana?
• A resposta falhou em classificar o nível de confiança?

Resposta válida tecnicamente ainda pode ser inadequada. O formato certo não garante que o conteúdo pode seguir adiante.

Revisão humana continua fazendo parte do fluxo

Existe um tipo de automação que parece madura na demo e frágil na operação. Ela funciona bem enquanto as entradas são confortáveis, mas começa a falhar quando aparecem dados sensíveis, exceções, ambiguidade, conflito de permissão ou impacto real.

• Impacto financeiro.
• Impacto jurídico.
• Envio externo.
• Alteração irreversível.
• Publicação de conteúdo.
• Uso de dados pessoais.
• Decisão sobre acesso.
• Baixa confiança ou conflito entre fontes.

Uma boa feature com IA não precisa escolher entre tudo manual e tudo automático. Ela pode automatizar preparação, resumo, triagem, sugestão e validação inicial, mantendo uma pessoa no ponto em que a decisão realmente importa.

Checklist mínimo antes de publicar

• Quais dados entram no prompt?
• Algum dado sensível pode ser removido, mascarado ou resumido?
• O prompt completo fica salvo em algum lugar?
• A resposta completa fica salva em algum lugar?
• Logs registram metadados suficientes sem guardar conteúdo privado desnecessário?
• RAG respeita permissão de acesso?
• Os documentos recuperados ficam rastreáveis?
• O índice de embeddings tem regra de retenção ou atualização?
• Quais ferramentas a IA pode chamar?
• Alguma ferramenta precisa de confirmação humana?
• A saída passa por validação?
• Casos críticos pedem revisão?

Esse checklist não transforma uma aplicação em segura automaticamente. Mas evita um erro comum: tratar IA como uma camada mágica que pode ver tudo, lembrar tudo e fazer tudo.

O que não estou dizendo

Este não é um guia jurídico. Não substitui análise de LGPD, GDPR, compliance, política interna ou revisão especializada. Também não é um guia completo de cibersegurança.

A intenção é mais prática e limitada: ajudar devs a perceberem onde dados sensíveis aparecem em features com LLM e quais perguntas precisam entrar no desenho técnico desde o começo.

Aprendizados

• Segurança em apps com LLM também passa por prompt, contexto, logs, RAG, ferramentas e resposta.
• A primeira camada de proteção é minimização: não enviar ao modelo o que ele não precisa ver.
• Logs ajudam operação, mas logs completos de prompt e resposta podem virar uma nova fonte de risco.
• RAG precisa respeitar permissão de acesso desde a indexação até a recuperação.
• Agentes com ferramentas exigem limites mais claros quando podem escrever, enviar, apagar ou publicar.
• Validação de saída também é parte de segurança quando a resposta pode expor informação ou acionar uma decisão.
• Revisão humana continua importante em ações com impacto real.

Limites e ressalvas

Cada produto tem um nível diferente de risco. Uma feature interna de estudo, um protótipo local, um assistente público, um sistema com dados pessoais e uma automação operacional não pedem o mesmo nível de controle.

Também existem decisões que dependem de legislação, política de privacidade, contrato com fornecedores, arquitetura de infraestrutura e requisitos internos. Este texto não tenta substituir esse trabalho.

Conclusão

IA útil não precisa ser IA com acesso irrestrito.

Uma boa funcionalidade com LLM precisa de contexto, mas também precisa de limite. Precisa de dados suficientes para resolver a tarefa, mas não de todos os dados disponíveis. Precisa de logs para operar, mas não de um arquivo permanente com tudo que o usuário escreveu.

No fim, segurança em apps com IA começa em uma decisão simples: definir o que a IA pode ver, lembrar, registrar e fazer.

IA boa em produto precisa de contexto, mas também precisa de fronteira.