A IA lê, não escreve: dados de produção ao alcance do assistente

Por que dar à IA acesso aos dados de produção?

Porque as perguntas que valem a pena são sobre dados reais. Quantos chamados este cliente abriu no mês, em que situação está o contrato, por que o relatório de ontem não fecha com o de hoje, que colunas aquela tabela tem de verdade. Sem acesso, o assistente responde de memória, com o que parece plausível, ou o time copia trechos do banco para dentro da conversa, o que é pior. Com acesso, ele responde a partir da fonte, e a resposta pode ser conferida.

O mesmo acesso que torna a IA útil também a torna perigosa. Um assistente ligado ao banco decide sozinho que consulta montar. Ele pode errar com toda a confiança, pode entender mal um pedido e pode ser induzido por texto que veio de fora, inclusive de dentro do próprio banco: um campo de observação preenchido por um cliente é texto de terceiro, e texto de terceiro pode carregar instrução. A OWASP, na lista de riscos de 2025 para aplicações com modelos de linguagem, descreve exatamente esse cenário como agência excessiva: uma extensão feita para ler dados que se conecta ao banco com uma identidade que também pode alterar, inserir e apagar.

O método parte de uma premissa desconfortável. Em algum momento a IA vai tentar fazer a coisa errada, por erro, por indução ou por um pedido mal formulado. A pergunta não é como convencê-la a não tentar. Como vimos no texto sobre regra escrita, pedir para a IA não alterar nada é pedido, não controle. A pergunta é como tornar a escrita impossível, e não apenas proibida.

No mapa da série, este texto ocupa a camada do meio: depois do que o assistente faz na máquina de quem trabalha, os dados que ele lê e nunca escreve.

O que significa “só de leitura” de verdade?

Significa que a escrita está bloqueada em três lugares independentes, e que os três precisariam falhar ao mesmo tempo para a IA alterar um dado. Uma barreira só não basta, porque cada uma falha por um motivo diferente.

A permissão do banco é a barreira principal. O serviço que liga a IA ao banco usa um usuário próprio, criado para isso, com permissão de leitura só nas tabelas de que precisa. Nunca o usuário da aplicação, nunca o dono do esquema, nunca "temporariamente o do administrador". Quem recusa a escrita é o banco, e o banco não lê instrução de ninguém. O erro comum é reaproveitar a credencial da aplicação no piloto, porque "é só para testar", e esquecer de trocar.

A verificação na partida pega o erro humano. Muitos bancos têm um modo de sessão só de leitura, mas esse modo é uma configuração da própria conexão, e quem tem a conexão costuma conseguir mudá-lo. Por isso ele não é a barreira principal. O valor dele é outro: na partida, o serviço pergunta ao banco se a sessão é só de leitura e, se a resposta for não, se recusa a subir. Se alguém apontar o serviço para a credencial errada, o erro aparece no primeiro minuto, como um serviço que não sobe, e não meses depois, como um dado alterado. A mesma lógica vale para o resto da configuração obrigatória: uma lista de ferramentas liberadas que chega vazia não vira "todas"; vira serviço parado.

O escopo por perfil limita o que cada pessoa alcança. Mesmo só lendo, a IA não deve ver tudo para todos. É o assunto da próxima seção.

Ler também tem risco, e "só de leitura" não quer dizer inofensivo. Uma consulta pesada, montada pela IA, pode travar o banco de produção no horário de pico, e uma leitura que derruba o sistema também é incidente. Por isso, se o serviço oferece consulta livre em SQL, ela roda com limite de linhas e de tempo impostos pelo servidor, não sugeridos ao modelo. E a consulta livre é o último recurso. Antes dela vêm ferramentas prontas, com consultas parametrizadas que alguém já revisou, para as perguntas que se repetem. Consulta livre é código novo, escrito pela IA, rodando contra produção sem revisão.

Quem vê o quê?

Cada pessoa entra com a própria identidade, e o perfil dela decide quais ferramentas e quais áreas de dados ela alcança pela IA. O contrário disso, um token único configurado na máquina de todo mundo, é o desenho mais comum nos pilotos e o primeiro que deve ser trocado.

O token único tem quatro problemas, e todos aparecem com o tempo. Quem o tem vê tudo, porque o servidor não sabe quem está do outro lado. A trilha registra "o token" em vez de uma pessoa. Revogar o acesso de alguém que saiu exige trocar o acesso de todos. E ele acaba copiado em arquivo de configuração, em conversa e em captura de tela, porque precisa ser distribuído.

O desenho por pessoa funciona assim. Na primeira vez que alguém usa a integração, o assistente abre uma tela de login, e a identidade é conferida no sistema que já sabe quem é quem na empresa. A especificação do Model Context Protocol, um padrão aberto para ligar assistentes a ferramentas e dados, prevê esse tipo de fluxo de autorização. Um painel de administração associa cada pessoa a um perfil, e o perfil lista as ferramentas e as áreas liberadas. Perfil sem a integração liberada é recusado já na tela de login. E cada renovação do acesso confere a pessoa de novo: desativá-la no sistema de origem, ou tirar o perfil, corta o acesso na hora, sem esperar o token vencer.

A integração chega à máquina de cada pessoa pela configuração gerenciada, sem chave nenhuma no arquivo distribuído: a credencial é o login de cada um.

Onde o escopo é aplicado também é decisão. A forma mais simples é no servidor que fala com o banco: ele só oferece a cada pessoa as ferramentas do perfil dela. A forma mais forte leva o escopo também para dentro do banco, com um usuário por perfil ou com regras por linha, para que um defeito no servidor não abra o que o perfil fecha. A segunda dá mais trabalho e passa a valer à medida que a base cresce e mais gente usa a integração.

O erro comum é começar com um perfil de administrador para todos no piloto, para não travar ninguém, e nunca revisitar. Para amanhã: liste quem usa a integração e o que cada pessoa precisa de fato perguntar. Quase sempre cabem poucos perfis, e quase ninguém precisa de todas as ferramentas.

Onde o dado pessoal é mascarado, e por que antes do modelo?

No servidor, na saída de cada ferramenta, antes de o texto chegar ao modelo. O que o modelo nunca recebeu ele não repete numa resposta, não escreve num log, não cola num commit e não envia a ninguém.

Mascarar depois é tarde. O dado que entrou no contexto da conversa já foi ao provedor do modelo, ficou no histórico e pode reaparecer em qualquer coisa que a IA escrever em seguida: um caso de teste com o documento de um cliente real, um comentário de código com um telefone, um chamado com um endereço. E, na maior parte das perguntas, a IA não precisa do dado verdadeiro para responder. Contar faturas em aberto, achar o contrato certo ou explicar por que um relatório diverge funciona com o documento mascarado. A LGPD chama isso de necessidade, no artigo 6º: limitar o tratamento ao mínimo necessário para a finalidade. E o artigo 46 pede medidas técnicas e administrativas que protejam o dado de acesso não autorizado. Na lista da OWASP, a divulgação de informação sensível é um dos riscos principais, e o remédio começa por menor privilégio e por limpar o dado antes de ele entrar.

Três cuidados separam a máscara de verdade da máscara de vitrine.

1. Mascarar pelo conteúdo, não só pelo nome da coluna. Com consulta livre, a IA pode renomear ou concatenar colunas, e a regra que procurava a coluna do documento deixa passar o mesmo número com outro nome.
2. Cobrir todas as categorias que identificam alguém. Documento, nome, contato, endereço e qualquer credencial que more no banco.
3. Não oferecer caminho de volta. Não existe ferramenta para desmascarar, e quem precisa do dado completo consulta na tela do próprio sistema, com o próprio perfil e com registro de quem viu.

Nada do que a IA lê deve ir a um terceiro sem necessidade, e isso inclui os próprios controles. O guardrail que avalia cada ação do assistente usa um classificador externo, e as chamadas às ferramentas do banco, com o que elas devolvem, ficam fora dele de propósito. O custo, dito em voz alta, é que essas ações não passam pela avaliação do classificador. O preço é aceitável porque o acesso é só de leitura e o dado já sai mascarado; a alternativa seria mandar dado de cliente a um terceiro a cada consulta.

O erro comum é mascarar na tela e esquecer a interface que a IA usa. O sistema esconde o documento para quem olha, mas a rota que a integração consulta devolve o registro inteiro, porque "é interna".

Para onde a IA pode mandar dados?

Só para os destinos de uma lista escrita, e todo o resto é recusado. Essa lista é controle, não configuração, e precisa ser tratada como tal.

Uma função de IA chama um provedor de modelo, e o endereço desse provedor quase sempre sai da configuração. Em muitos sistemas, o mesmo campo que escolhe o modelo aceita um endereço completo, e um endereço vira destino. Quem consegue mudar a configuração consegue, então, escolher para onde vão o texto da conversa, o dado que veio do banco e a chave do provedor, que segue no cabeçalho de cada chamada. Não precisa invadir o servidor. Basta ter acesso ao painel de administração.

A lista de destinos permitidos fecha esse caminho. O sistema só chama provedores cujo endereço está nela, conferido no momento de cada chamada, e não só quando a configuração é salva. Um provedor novo, ou um modelo rodando dentro da empresa, entra na lista por pedido de mudança revisado, como qualquer código.

A parte que mais engana é o que uma lista vazia significa. Em muitas implementações, vazia quer dizer "sem restrição", porque esse é o comportamento que não quebra nada no primeiro dia. É o pior padrão possível: a ausência do controle se lê como tudo liberado, e ninguém percebe, porque tudo funciona. A regra do método é a mesma da verificação na partida: lista vazia não deixa passar nada, ou o serviço não sobe.

A especificação do Model Context Protocol diz o mesmo pelo lado do protocolo. O aplicativo não deve transmitir dados de um recurso para outro lugar sem consentimento, e o próprio protocolo não consegue impor isso: quem impõe é a implementação. Uma segunda barreira, na rede, completa a primeira. A máquina que roda o serviço só alcança, na saída, os destinos de que precisa, e um destino fora da lista falha duas vezes, no código e na rede.

Como se desliga?

Tirando a chave do provedor. Sem ela, as funções de IA caem e o resto do sistema continua funcionando. Isso é desenho, não falha.

O motivo é simples. Se o sistema depende da IA para funcionar, desligar a IA é desligar o sistema, e ninguém vai apertar esse botão quando precisar. Cada função de IA precisa ter um estado de "não configurada" que degrada sem drama. Sem a chave, o resumo automático não aparece, a sugestão de resposta some e a mensagem do cliente continua sendo gravada para uma pessoa atender. Nenhuma função tenta, em silêncio, um provedor de reserva: provedor de reserva é destino novo, e destino novo passa pela lista.

O teste é barato e quase ninguém faz. Suba o sistema num ambiente de teste sem nenhuma chave de IA e anote o que continua de pé. Se algo essencial cai junto, a IA virou dependência, e a decisão de desligá-la deixou de ser sua.

O mesmo vale para o lado da leitura. Quando a integração com o banco não está disponível, a IA precisa dizer que não conseguiu consultar, e não concluir que o dado não existe. "Ferramenta indisponível" e "cliente sem contrato" chegam ao modelo parecidos, e a conclusão errada custa caro. A instrução que acompanha a integração trata isso como lacuna declarada: não consultei, e por quê.

O botão que desliga a IA da empresa inteira, de uma vez, fica para o fim desta série. Aqui basta o princípio: cada função de IA tem de saber cair sozinha.

Por onde começar se a sua IA já lê o banco?

Se o assistente do time já consulta dados de produção, a ordem abaixo fecha primeiro o que mais custa.

1. Descubra com que usuário a integração conecta e o que ele pode fazer, perguntando ao banco, não ao fornecedor.
2. Crie um usuário exclusivo, só de leitura e só nas tabelas necessárias, e troque a credencial.
3. Faça o serviço se recusar a subir quando a sessão não for só de leitura ou quando faltar configuração obrigatória.
4. Troque o token único pelo login de cada pessoa, com perfis mínimos.
5. Ligue a máscara na saída do servidor e teste com uma consulta que renomeia e concatena colunas.
6. Escreva a lista de destinos permitidos e confira o que acontece com ela vazia.
7. Suba o sistema sem as chaves de IA e veja o que continua funcionando.

Cada passo responde às três perguntas que esta série faz a todo controle: o que barra, como se prova que barra e o que acontece quando falha. A prova é curta. Peça à IA uma alteração e veja o erro voltar do banco, não da IA. Aponte o serviço para uma credencial com escrita e veja-o não subir. Desative uma pessoa e veja a próxima consulta dela ser recusada. Consulte um registro com dado pessoal e procure o dado no histórico da conversa: ele não pode estar lá.

A IA lê a produção e não escreve nela. Mas ela escreve outra coisa o dia inteiro: código. E esse código precisa chegar à produção por algum caminho. O próximo texto trata desse caminho, e de por que ele precisa ser um só.