IA e dado confidencial: o que um conector precisa barrar

Quatro em cada dez profissionais apontam o acesso a dado confidencial como a principal preocupação com IA. A resposta não é proibir: é saber exatamente o que o servidor recusa — e no lugar certo.

Numa pesquisa recente do setor de marketing brasileiro, 40% dos respondentes apontaram o acesso a dados confidenciais como a principal preocupação em relação ao uso de IA. É a preocupação certa, e ela costuma receber duas respostas ruins: proibir, o que empurra o time para o copiar e colar em ferramenta pessoal; ou liberar geral, que é a mesma coisa com melhor humor.

A resposta útil é uma lista de recusas específicas. Se você está avaliando um conector, é isso que precisa perguntar — e a resposta tem de ser sobre o servidor, não sobre o prompt.

Por que a instrução não é proteção

Existe uma tentação de resolver isso escrevendo no prompt: "você só pode consultar as tabelas do cliente X". Isso não é um controle de acesso. É um pedido educado ao modelo, e ele será cumprido na maior parte das vezes — que é exatamente o problema de qualquer proteção que funciona na maior parte das vezes.

Controle que mora no prompt é sugestão. Controle que mora no servidor é regra. Só a segunda continua valendo quando o texto da conversa muda.

As sete recusas que importam

1. 01Consulta que nomeia o schema de outro cliente. Se o modelo pode escrever SQL, ele pode escrever o nome de outro projeto. A recusa tem de ser na análise da consulta, antes de executar.
2. 02Tabela global. Toda plataforma multi-cliente tem tabelas cruas onde os dados de todo mundo convivem antes de serem separados. Elas não podem estar ao alcance.
3. 03Comando que escreve. Um conector de análise não precisa de criar, alterar ou apagar. Se a ferramenta é declarada como leitura, o servidor tem de recusar a escrita na chamada — declaração não é aplicação.
4. 04Função de tabela remota. Vários bancos permitem ler de um endereço externo dentro de uma consulta. É o caminho mais curto entre uma consulta inocente e uma exfiltração.
5. 05Tabelas de sistema. Elas descrevem a estrutura de tudo que existe no servidor, inclusive do que não é seu.
6. 06Consulta sem teto. Uma pergunta mal formulada pode varrer terabytes. Num domingo à noite que medimos, um único projeto escaneou 1,47 TB, e mais de uma centena de consultas foi barrada pelo limite de simultaneidade — o limite fez o trabalho dele.
7. 07Chamada de quem não é mais da equipe. Esta é a menos óbvia e a que dura mais tempo.

A recusa número 7 merece um parágrafo

O projeto ativo costuma ser validado uma vez, na autorização, e depois viajar dentro do token. A renovação copia o valor adiante sem reconferir. Quando alguém sai da equipe, o registro de participação é apagado e o token continua íntegro — então o acesso sobrevive à saída, pelo prazo inteiro do token.

O conserto tem duas partes, e as duas são necessárias: reconferir o vínculo no funil por onde toda chamada passa, com cache curto; e zerar o projeto ativo de quem foi removido, para que o corte seja imediato no caso normal. Com as duas, o pior caso deixa de ser meses e passa a ser cerca de um minuto.

E a reconferência precisa falhar fechado. Um erro ao consultar a permissão não pode virar passe livre — é a diferença entre um sistema que nega quando está em dúvida e um que libera quando está com problema.

Sobre mascarar dado pessoal

Uma prática comum é mascarar e-mail e telefone nas amostras que a IA vê. Vale dizer por que isso muitas vezes é teatro: numa auditoria interna, descobrimos que a mesma linha que tinha o campo mascarado carregava o e-mail do comprador em outros três campos e o documento num quarto. A máscara não removia exposição nenhuma, e tirava da tela justamente o que era preciso ver para diagnosticar identidade.

Proteção inconsistente é pior do que nenhuma: ela dá a sensação de que o assunto foi tratado, e desloca a atenção do lugar onde a exposição realmente está.

A proteção real é o escopo — quem pode pedir o quê — e não a ofuscação do que já circula aberto no sistema inteiro.

O que pedir por escrito

• A lista das ferramentas que escrevem, e como o escopo de leitura é aplicado.
• O que acontece com o acesso quando alguém é removido da equipe, e em quanto tempo.
• Se a consulta gerada pela IA passa por análise antes de executar, e o que ela recusa.
• Se existe registro de quem perguntou o quê, e por quanto tempo ele fica.

No CrazyLeads, a consulta da IA passa por um sandbox que recusa schema qualificado de outro projeto, tabela global, comando de escrita e função de tabela remota; o escopo de escrita é derivado da anotação da própria ferramenta, e o vínculo da pessoa com o projeto é reconferido no ponto por onde toda chamada passa, falhando fechado.