Text-to-SQL: como deixar a IA consultar o banco de dados sem arriscar a produção

Text-to-SQL é a técnica em que um modelo de linguagem recebe uma pergunta em português ("quanto faturamos por região no último trimestre?"), gera a consulta SQL e a executa no seu banco. Dá para liberar com segurança, sim, mas não do jeito que a maioria das demonstrações mostra. A segurança não pode depender do prompt. Ela tem que estar no banco de dados.

Escrevo isso como alguém que passou mais de 40 anos em tecnologia, boa parte deles dentro de bancos relacionais. Fui embaixador do MySQL no Brasil, escrevi o livro Aprendendo MySQL e hoje sou embaixador do MariaDB no Brasil. E, também, fui founder de uma startup que criou o primeiro DBA Virtual (dbsnOOp) e que fazia text-to-SQL, e, foi fantástico! Mas, também aprendi duras lições sobre como o text-to-SQL pode sair fora do controle, gerar incidentes que vão de performance a instabilidades, e até criar vazamento de dados.

De CTO para CTO: a ideia é ótima, a pressão do negócio é legítima, e o erro mais comum é tratar o modelo como se fosse um analista confiável. Ele não é. É um usuário que você não conhece, escrevendo SQL na sua base.

O que é Text-to-SQL e por que todo mundo quer?

A promessa é simples: tirar a fila de pedidos de relatório das costas do time de dados. O diretor comercial pergunta, a IA responde com números da base, sem ticket e sem esperar a sprint.

Um sistema de Text-to-SQL tem quatro peças:

1. Contexto de esquema: o modelo precisa conhecer tabelas, colunas, relacionamentos e, de preferência, o significado de negócio de cada coisa.
2. Geração: o LLM traduz a pergunta em SQL.
3. Execução: alguma camada (uma aplicação, um agente, um servidor MCP) roda a consulta.
4. Resposta: o resultado volta formatado, às vezes com gráfico ou resumo em texto.

Os riscos estão nas peças 2 e 3. A peça 1 é onde mora a qualidade.

A IA já acerta o SQL sozinha?

Melhor do que acertava, mas a pergunta certa é outra: ela acerta no seu banco?

O trabalho que mais me ajudou a calibrar expectativas foi o benchmark BIRD, publicado no arXiv em maio de 2023 com o título, bem provocativo, Can LLM Already Serve as A Database Interface?. Os autores montaram 12.751 pares de pergunta e SQL sobre 95 bancos de dados, somando 33,4 GB, em 37 domínios profissionais. A diferença para os benchmarks anteriores é que os bancos têm dados sujos, valores ambíguos e exigem conhecimento externo para responder. Ou seja, parecem com a vida real. No artigo, o melhor modelo testado (o ChatGPT da época) chegou a 40,08% de acurácia de execução. Os humanos chegaram a 92,96%.

Os modelos evoluíram muito desde então, e eu não vou citar número de hoje que eu não tenha conferido. A lição do paper continua valendo: o gargalo não é a sintaxe do SQL, é entender os dados. Coluna chamada status com valores 1, 2 e 9, tabela cliente_old que ainda é usada, receita que o financeiro calcula de um jeito e o comercial de outro. Nenhum modelo adivinha isso. Quem sabe é o seu time.

Para mim isso muda o projeto. Antes de discutir qual modelo usar, discuta se o seu esquema tem documentação, nomes que fazem sentido e um dicionário de métricas. Se não tem, o Text-to-SQL vai expor isso rapidinho, e de um jeito convincente: SQL bem formatado, número com duas casas decimais e resposta errada.

Quais são os riscos reais de deixar um LLM rodar SQL?

Vejo três famílias de risco. Nenhuma é teórica.

1. A consulta errada que parece certa

É o risco mais traiçoeiro, porque ninguém percebe. Um JOIN que duplica linhas, um filtro de data que pega o fuso errado, uma soma que inclui pedidos cancelados. O relatório sai, vai para a reunião de diretoria e vira decisão.

2. A consulta certa que derruba o banco

O modelo não sabe que a tabela de eventos tem bilhões de linhas e nenhum índice na coluna que ele resolveu filtrar. Ele gera um SELECT legítimo que faz full scan, disputa I/O e buffer pool com a aplicação transacional e, no pior momento, deixa o sistema lento para o cliente final.

3. A consulta induzida por alguém de fora

Aqui entra a prompt injection, que a OWASP coloca como o risco número um da sua lista para aplicações com LLM (LLM01:2025). A injeção pode ser direta, quando o próprio usuário escreve algo para mudar o comportamento do modelo, ou indireta, quando o modelo lê um conteúdo externo (um e-mail, um documento, um campo de texto livre do próprio banco) que contém instruções escondidas. A OWASP é clara: não existe prevenção infalível conhecida. Por isso ela recomenda camadas, e uma delas é restringir os privilégios do modelo ao mínimo necessário para a operação pretendida.

"Mínimo privilégio" é algo que bancos relacionais sabem fazer há décadas. Não precisa inventar nada.

Como liberar Text-to-SQL com segurança no banco?

Minha opinião, sem rodeio: toda trava que estiver só no prompt é sugestão, não controle. "Você só pode fazer SELECT" escrito no system prompt é tão seguro quanto uma placa de "proibido entrar" numa porta destrancada. As travas que importam são as que o banco aplica mesmo que o modelo seja enganado.

Usuário dedicado, só leitura, só no que precisa

Crie um usuário exclusivo para a IA. Não reaproveite o usuário da aplicação, muito menos um usuário administrativo. Conceda SELECT apenas nos schemas, tabelas ou views necessárias.

Melhor ainda: crie views de negócio para a IA consultar. A view já resolve os joins difíceis, filtra cancelados, aplica a regra de receita que o financeiro aprovou e esconde colunas sensíveis. Você troca "o modelo precisa entender 300 tabelas" por "o modelo precisa entender 15 views bem documentadas". Isso ataca o risco 1 e o risco 3 ao mesmo tempo.

Tempo máximo de execução no próprio banco

No MySQL, a variável max_execution_time define o timeout, em milissegundos, para SELECT de leitura. O padrão é 0, ou seja, sem limite. Pode ser global ou por sessão, e também existe a dica de otimizador MAX_EXECUTION_TIME(N) por consulta. Um detalhe da documentação: ela é ignorada para SELECT dentro de stored programs.

No MariaDB, o equivalente é max_statement_time, em segundos (aceita fração). O que eu gosto aqui é que dá para amarrar o limite ao usuário com GRANT ... MAX_STATEMENT_TIME, ou aplicar a uma única instrução com SET STATEMENT max_statement_time=N FOR .... A própria documentação avisa que o cancelamento não é instantâneo, porque o servidor verifica o timer em intervalos. Então isso é uma camada, não a única.

Limite de volume por conta

O MySQL tem limites de recurso por conta: MAX_QUERIES_PER_HOUR, MAX_UPDATES_PER_HOUR, MAX_CONNECTIONS_PER_HOUR e MAX_USER_CONNECTIONS, definidos no CREATE USER ou no ALTER USER. Para um agente que pode entrar em laço e disparar consulta atrás de consulta, limitar conexões simultâneas e consultas por hora é um freio barato. E protege também a sua conta de tokens, já que cada tentativa do agente custa dinheiro na outra ponta.

Rode em réplica, nunca no primário

Consulta gerada por IA vai para réplica de leitura ou para uma base analítica. Ponto. Se você ainda não tem réplica, esse é o primeiro investimento do projeto, antes de qualquer licença de ferramenta de IA.

Validação antes de executar

Entre o modelo e o banco, coloque uma camada de código (não outro prompt) que faça o básico: aceitar só uma instrução por chamada, recusar o que não for leitura, impor LIMIT, opcionalmente rodar um EXPLAIN e barrar planos com varredura completa em tabelas grandes. Essa camada também é onde você grava log de pergunta, SQL gerado, usuário que perguntou e tempo de execução. Sem esse log, você não consegue auditar nem melhorar nada.

Onde entram MCP e agentes nessa história?

Cada vez mais o Text-to-SQL chega embutido em agentes, conectado ao banco por um servidor MCP. Funciona bem e facilita a integração, mas não muda o raciocínio: o servidor MCP se conecta com algum usuário de banco, e são os privilégios desse usuário que definem o estrago possível. Já escrevi sobre o outro lado da moeda, o que fazer quando o provedor de IA fica fora do ar, em Quando a IA cai: fallback, MCP e continuidade. Vale ler junto.

E se a sua dúvida é anterior, sobre como o modelo "entende" o texto e o que são embeddings, comece por MariaDB e IA: fundamentos de tokens, embeddings e vetores.

Checklist de CTO antes de liberar

• O caso de uso está escrito? Quem pergunta, sobre quais dados, para tomar qual decisão.
• Existe usuário dedicado, só com SELECT, de preferência sobre views de negócio?
• Há timeout no banco (max_execution_time ou max_statement_time) e limite de conexões?
• As consultas rodam em réplica ou base analítica?
• Existe validação em código antes da execução e log completo depois?
• Alguém do time de dados revisa, por amostragem, as respostas que viraram decisão?
• Dados pessoais estão fora do alcance ou mascarados?

Se a resposta para qualquer item for "não sei", o projeto ainda é piloto, e tudo bem. Só não chame de produção.

Perguntas frequentes

Text-to-SQL substitui o analista de dados?

Não. Ele tira do analista o trabalho repetitivo de montar consulta simples, mas aumenta a importância de quem define métricas, documenta o esquema e valida o que a IA responde. O papel muda, não some.

Posso deixar a IA fazer INSERT, UPDATE ou DELETE?

Eu não recomendo para Text-to-SQL de perguntas abertas. Se houver escrita, ela deve passar por funções ou procedures específicas, com parâmetros validados em código e aprovação humana para ações de alto impacto, como a própria OWASP sugere.

Colocar "só faça SELECT" no prompt não basta?

Não basta. Prompt é instrução para o modelo, e o modelo pode ser induzido a ignorá-la. O controle de verdade é o privilégio do usuário no banco.

Preciso de um banco especial para Text-to-SQL?

Não. MySQL, MariaDB e PostgreSQL já oferecem controle de privilégios, timeouts e réplicas. O que costuma faltar é documentação do esquema e disciplina de acesso, não tecnologia.

Por onde começo?

Por um caso de uso pequeno, um conjunto de views bem documentadas e um usuário só leitura em réplica. Meça a qualidade das respostas antes de abrir para mais gente.

Vamos conversar?

Se você quer colocar IA para conversar com os seus dados sem transformar o banco de produção em cobaia, posso ajudar a desenhar as travas certas.

Para o time, tenho treinamentos de MySQL e PostgreSQL, e o livro Aprendendo MySQL é um bom ponto de partida para quem vai mexer no banco.

E se você quer discutir o seu caso, de CTO para CTO, fale comigo.