Blog
Isolamento de dados por cliente em sistemas com IA
Um sistema que atende vários clientes ao mesmo tempo carrega um risco simples de descrever e difícil de eliminar: dado de um cliente aparecer, de qualquer forma, para outro. Quando o sistema usa IA generativa, esse risco cresce em silêncio. Um modelo de linguagem não sabe, por conta própria, a quem pertence cada informação que recebe. Ele só sabe o que está no texto que chega até ele.
Por isso, tratar isolamento de dados como "regra de banco" é insuficiente. Isolamento por cliente é uma propriedade que precisa atravessar cada camada do sistema: o banco, o pipeline que monta o contexto enviado à IA, o cache que acelera respostas, os logs que registram o que aconteceu e a tela que mostra o resultado. Falhar em qualquer uma dessas camadas produz o mesmo efeito: um cliente vendo o que não é dele. Se você avalia um fornecedor de software com IA, vale perguntar como cada uma dessas camadas trata o assunto, não só o banco.
O banco é a base, não o fim
Em um banco multi-cliente, a primeira camada de proteção é o controle de acesso a nível de linha: cada consulta só pode enxergar as linhas que pertencem ao cliente autenticado naquela sessão. Em bancos como Postgres, isso tem nome: Row Level Security, com políticas por tabela que filtram automaticamente pelo identificador do cliente.
O ponto que costuma passar despercebido é o que acontece quando alguém cria uma tabela nova. Um gatilho no banco pode habilitar RLS automaticamente nas tabelas criadas no esquema exposto à aplicação. Sem políticas de acesso, o banco nega as consultas dos papéis sujeitos à RLS. Liberar o acesso exige definir explicitamente as políticas de cada operação, com o escopo do cliente. O gatilho ativa a proteção padrão; as políticas específicas continuam fazendo parte da implementação e dos testes.
O pipeline: o contexto de um cliente nunca entra no prompt de outro
Um sistema com IA geralmente monta um prompt: um texto que reúne instruções, dados relevantes e a tarefa a ser resolvida. Esse prompt é o novo ponto cego de boa parte da arquitetura de segurança, porque ele é montado em código de aplicação, longe das políticas do banco.
Se o pipeline busca dados de mais de um cliente na mesma execução, por um filtro incompleto, por um cache mal escopado ou por um passo de enriquecimento que agrega contexto de fontes diferentes, o resultado é sempre o mesmo: informação de um cliente entra no texto que vai para o modelo de outro. O modelo não percebe o erro. Ele responde usando o que recebeu.
A prática concreta aqui é dupla. Primeiro, cada etapa do pipeline que monta contexto para a IA precisa buscar os dados com o identificador do cliente explícito na consulta, nunca implícito. Segundo, revisar prompts e templates especificamente à procura de vazamento cruzado, com um teste que simula dois clientes ativos ao mesmo tempo e verifica se o prompt de um contém qualquer fragmento do outro.
Cache e logs: onde a proteção costuma escapar
Cache existe para acelerar. Se a chave de cache não inclui o identificador do cliente, dois clientes podem, sem querer, compartilhar uma resposta armazenada. É um erro simples de cometer e caro de descobrir depois, porque não aparece em teste funcional comum. Aparece só quando dois clientes usam o sistema com pouco intervalo de tempo entre um acesso e outro.
Logs têm o problema inverso. Eles existem para registrar o que aconteceu, o que é útil e necessário. O risco é logar dados sensíveis de um cliente em texto plano, ou logar em um canal compartilhado sem separação por cliente. Um log que mistura contexto de clientes diferentes é, na prática, um segundo banco de dados sem as proteções do primeiro.
A prática concreta: chave de cache sempre com o identificador do cliente embutido, e logs tratados como superfície sensível, com o mesmo cuidado de acesso dado ao banco, não como detalhe operacional à parte.
A apresentação: a última milha do isolamento
A tela final também isola, ou não isola. Uma interface que busca "os últimos registros" sem filtrar explicitamente pelo cliente autenticado, ou que reaproveita um componente de exibição sem confirmar a origem do dado, pode mostrar algo que não deveria.
Há um segundo tipo de mistura, mais sutil: dado real, inferência da IA e observação inserida por uma pessoa aparecendo juntos, sem distinção visual, como se tivessem o mesmo grau de certeza. Isso não é vazamento entre clientes, mas é o mesmo tipo de falha: informação com origem e confiança diferentes tratada como uma coisa só.
LGPD como pano de fundo
A Lei Geral de Proteção de Dados não é o motivo de isolar dados por cliente, mas dá vocabulário útil para pensar o problema. Minimização: coletar e manter só o dado necessário para a finalidade declarada, não tudo que é possível capturar. Finalidade: um dado coletado para um uso não deveria circular livremente para outro. Registro de acesso: saber quem acessou o quê e quando é parte do controle, não um extra de auditoria feito depois.
Nenhuma dessas ideias é exclusiva de sistemas com IA, mas a IA aumenta a superfície de risco: mais dados fluindo por mais etapas, muitas delas fora do banco, onde as proteções tradicionais nem sempre chegam.
Práticas concretas, em lista
Reunindo o que este texto descreveu:
- Isolamento por padrão em cada tabela, nunca como configuração opcional.
- Tabela nova nasce protegida, sem depender de quem lembrar de configurar.
- Teste de segurança que tenta vazar dado entre clientes e precisa falhar.
- Prompt e pipeline revisados contra vazamento cruzado, não só o banco.
- Demonstração sempre com dado pseudonimizado, nunca dado real de outro cliente.
Em um projeto do portfólio, uma plataforma de inteligência comercial multi-tenant integrada por REST/OData a um CRM de vendas corporativo, esse princípio é tratado hoje como requisito de arquitetura: cada tabela nova nasce com controle de acesso por cliente, e o ambiente de demonstração usa apenas dados pseudonimizados.
Por que isso importa mais do que parece
Um sistema com IA processa informação em mais lugares e mais depressa que um sistema tradicional. Isso é o que o torna útil. É também o que torna cada costura entre camadas um lugar onde o isolamento pode se romper. Se você constrói ou contrata um sistema multi-cliente com IA, essa é a pergunta que vale fazer antes de qualquer outra: onde, exatamente, um cliente poderia ver o dado de outro.