A outra metade dos dados da empresa
RAG resolve a pergunta sobre documento. Mas boa parte do que a diretoria quer saber não está em documento nenhum: está em tabela. Faturamento por filial, ticket médio por canal, inadimplência por faixa, estoque parado há mais de noventa dias. Hoje isso vira um pedido para a TI, que vira uma consulta SQL, que vira uma planilha — e três dias depois a pergunta já mudou.
NL para SQL, ou text-to-SQL, é a técnica que fecha esse ciclo: a pessoa pergunta em português, o sistema gera a consulta, executa e devolve o resultado com a consulta à vista. O ganho não é técnico, é de tempo de resposta a uma dúvida de negócio.
Por que as demonstrações impressionam e a implantação decepciona
A diferença está no banco. Em uma base pequena, com nomes claros e sem lixo, a tradução acerta quase sempre. Em banco de produção de verdade, aparecem os problemas que a demonstração não tem: tabelas chamadas TB001, colunas com nome abreviado em português e inglês misturados, campos de status com códigos que só o pessoal antigo conhece, data gravada como texto, cliente duplicado, valores em centavos em uma tabela e em reais em outra.
O benchmark BIRD foi construído justamente para medir isso — bases grandes, com conteúdo sujo e conhecimento externo necessário. No artigo original, de 2023, os autores relatam 40,08% de acerto de execução para o melhor sistema avaliado na época, contra 92,96% de desempenho humano. Os modelos melhoraram muito desde então, mas a lição permanece e é a mais importante do tema: a dificuldade não está na sintaxe do SQL, está em entender o significado dos dados.
A camada semântica é o projeto
O que faz NL para SQL funcionar em empresa não é o modelo, é escrever o que as coisas significam. Isso tem nome: camada semântica. Na prática é um documento vivo, versionado junto com o código, que define cada métrica e cada termo do negócio.
O conteúdo mínimo: quais tabelas e colunas podem ser consultadas e o que cada uma significa em português; as métricas do negócio escritas como fórmula acordada — faturamento líquido é com ou sem devolução, cliente ativo é quem comprou em quantos meses; os relacionamentos corretos entre tabelas; os valores possíveis de campos de status; e os sinônimos que as pessoas realmente usam, porque ninguém pergunta por nome de coluna.
Escrever isso costuma ser 70% do esforço do projeto, e é um ativo que sobrevive à troca de modelo e de ferramenta. Sem a camada, qualquer resposta é chute bem formatado; com ela, a mesma pergunta passa a ter uma resposta estável.
Segurança: a IA nunca toca no banco de produção
Três regras não negociáveis. A conexão é somente leitura, com usuário próprio, em réplica e nunca na base transacional — assim uma consulta mal formada degrada um relatório, não o faturamento do dia. O acesso respeita a permissão de quem perguntou: se a pessoa não pode ver folha de pagamento, a automação também não pode, e isso se resolve no banco, não no texto do prompt.
E toda consulta gerada é validada antes de executar: só SELECT, só nas tabelas liberadas, com limite de linhas e tempo máximo de execução. Vale lembrar que a pergunta do usuário é conteúdo externo e pode conter instrução maliciosa — o mesmo problema de injeção de prompt que o AironCore trata. A consulta precisa ser verificada por regra, não pela boa vontade do modelo.
Mostre o SQL, e não automatize a decisão
A interface deve exibir a consulta gerada junto com o resultado, sempre. Isso resolve dois problemas de uma vez: quem entende confere, e quem não entende aprende a desconfiar quando o número parece estranho. Sistema que entrega só o número treina a empresa a confiar em algo que ninguém auditou.
E vale a mesma regra da automação: use para responder pergunta, não para disparar decisão. O resultado alimenta uma conversa, um relatório, uma análise. Quem corta o crédito, aprova a compra ou cancela o contrato continua sendo gente.
Quando NL para SQL não é a resposta
Se a pergunta é sempre a mesma, a resposta certa é um painel, não um tradutor de perguntas. NL para SQL brilha na cauda longa: a dúvida que aparece uma vez, que não justifica construir relatório e que hoje morre porque pedir dá trabalho.
Também não é a resposta quando os dados estão errados. Se o cadastro tem cliente duplicado e status inconsistente, a IA vai responder com precisão sobre um dado errado — e com uma aparência de autoridade que antes não existia. Nesse caso o projeto é de qualidade de dados, e é melhor saber disso antes.
Por onde começar
Escolha de cinco a dez perguntas que a diretoria realmente faz e escreva a resposta correta em SQL para cada uma, à mão. Esse conjunto vira o teste do projeto e a semente da camada semântica. Depois conecte uma réplica somente leitura e meça: quantas das dez o sistema acerta sem ajuda.
Na JBKR esse trabalho costuma andar junto com integração de sistemas, porque o dado quase nunca está em um lugar só. O diagnóstico inicial de 30 minutos é gratuito e serve para dizer, sem rodeio, se o seu caso é de IA ou de arrumar o cadastro primeiro.
