Como auditar SQL gerado por IA antes de usá-lo

Por que uma consulta executável pode estar errada

Uma consulta SQL gerada por IA pode ser compilada, executada e retornar linhas sem responder corretamente à pergunta de negócio. O banco de dados executa as operações recebidas; não sabe se uma soma representa a métrica que a equipe chama de “receita”, se o período escolhido é adequado ou se um JOIN duplicou registros. A sintaxe correta é apenas uma condição para a execução, não uma prova de correção lógica.

O risco costuma estar em decisões plausíveis que passam despercebidas: relacionar tabelas pela chave errada, aplicar um filtro não solicitado, agregar valores depois de multiplicar linhas ou interpretar NULL de maneira diferente. Antes de executar, é preciso conseguir explicar o que cada linha representa e por que cada condição aparece na consulta. Depois, o resultado deve ser comparado com uma referência que não dependa da mesma geração por IA.

Este protocolo se concentra em consultas analíticas sobre bancos de dados relacionais. Ele não substitui a definição das regras de negócio nem uma revisão completa de segurança. Propõe uma sequência prática: esclarecer a pergunta, inspecionar estaticamente o SQL, testá-lo com escopo limitado e validar a saída. O acesso somente para leitura reduz o dano potencial, mas, por si só, não garante resultados corretos.

Etapa 1: transformar a pergunta de negócio em critérios verificáveis

Antes de ler o SQL, defina o significado da solicitação. “Vendas do trimestre por cliente” deixa questões em aberto: vendas brutas ou líquidas? Pedidos criados ou concluídos? Quais datas delimitam o trimestre? As devoluções são descontadas? Qual fuso horário se aplica? Se essas decisões não estiverem documentadas, uma consulta aparentemente razoável pode responder a uma interpretação diferente.

Escreva uma especificação breve com a métrica, a unidade de análise, o período, os filtros e o nível de agrupamento. Identifique também a fonte autorizada para cada dado. Por exemplo, se o total está no cabeçalho do pedido e os produtos estão em uma tabela de detalhes, deixe explícito que a métrica precisa manter uma linha lógica por pedido antes da soma. A IA não deve completar silenciosamente regras que a equipe ainda não acordou.

Esclareça o esquema real e o dialeto SQL. Confira tabelas, colunas, tipos, chaves e relações documentadas no banco de dados ou no dicionário de dados; não confie em nomes que apenas parecem plausíveis. Em uma integração de linguagem natural para SQL, o esquema e as regras fornecidos ao modelo são um contexto útil, mas a saída ainda precisa ser conferida no código e no mecanismo de destino. A documentação do Microsoft Learn mostra, por exemplo, a geração de SQL com valores parametrizados e uma verificação posterior de consultas proibidas; também alerta que instruções dadas ao modelo não substituem o planejamento de medidas de segurança.

Se faltar uma definição necessária, interrompa a revisão e esclareça a questão com a pessoa responsável pelo indicador. Acrescentar uma condição inventada para “fazer funcionar” não resolve a ambiguidade; apenas transforma essa ambiguidade em uma decisão difícil de detectar depois.

Etapa 2: inspeção estática antes de executar

Leia a consulta de fora para dentro e marque cada tabela, JOIN, filtro, agregação, subconsulta e função de janela. Compare os objetos com o esquema real. Em seguida, acompanhe o percurso das linhas: que relação cada JOIN introduz, quais condições descartam registros e em que momento a granularidade muda. Não considere uma condição válida apenas porque o nome parece familiar.

Os JOINs merecem atenção especial. Confirme se as chaves usadas representam a relação correta e descubra sua cardinalidade: um para um, um para muitos ou muitos para muitos. Se uma tabela contém uma linha por pedido e outra, uma linha por item, a junção entre elas pode repetir o valor do cabeçalho para cada item. Somar o valor do pedido depois disso pode inflar o total sem produzir nenhum erro de sintaxe. Acrescentar DISTINCT posteriormente também não prova que a lógica foi corrigida.

Confira cada filtro em relação à especificação. Verifique estados, datas, limites inclusivos ou exclusivos e condições sobre NULL. Avalie se o SQL elimina registros que deveriam ser contabilizados ou inclui outros que não correspondem ao escopo. Em uma condição como `coluna = valor`, NULL não se comporta como um valor comum; as regras precisam ser definidas, não presumidas.

Examine as agregações e funções de janela com uma pergunta concreta: sobre qual conjunto de linhas cada valor é calculado? Verifique se as colunas selecionadas e agrupadas correspondem ao nível necessário. Em subconsultas aninhadas, anote quais linhas cada nível retorna e como se conecta ao seguinte. Por fim, confirme se as funções e a sintaxe correspondem ao dialeto do mecanismo de destino.

Etapa 3: limitar o escopo e executar em um ambiente controlado

Sempre que possível, a primeira execução deve ocorrer fora de produção: em um banco de testes isolado com dados sintéticos ou em uma cópia anonimizada, atualizada de acordo com as políticas da organização. Dados sintéticos permitem criar casos deliberados — incluindo duplicatas, valores nulos e datas-limite — sem expor registros reais. Uma cópia anonimizada pode reproduzir melhor a distribuição dos dados, mas é necessário verificar se a anonimização é adequada e se a cópia não tem permissões de escrita em produção.

Configure a conexão com privilégios mínimos. Para testar uma consulta, use uma identidade somente para leitura e limite o acesso às tabelas ou views necessárias. Confira também as restrições de recursos: tempo máximo, volume de linhas e possibilidade de cancelamento. Mesmo uma consulta somente para leitura pode consumir recursos em excesso ou retornar dados que o usuário não deveria ver; segurança e correção são controles relacionados, mas distintos.

Não execute SQL gerado por IA sem validação no lado da aplicação. As instruções do prompt podem orientar o modelo, mas não constituem um limite de segurança. Aceite apenas as operações e os objetos permitidos, valide os parâmetros e use consultas parametrizadas para os valores. A documentação do Microsoft Learn descreve um exemplo em que o servidor adiciona strings como parâmetros e verifica a consulta antes de executá-la; a lista de palavras proibidas apresentada ali é demonstrativa, não uma defesa completa que possa ser aplicada sem adaptações.

Comece pelo menor escopo que permita testar a lógica: uma entidade conhecida, um período curto ou uma pequena amostra. Se precisar inspecionar um plano de execução, faça isso no ambiente autorizado e considere o custo. O objetivo não é provar que a consulta pode ser executada sobre o banco inteiro, mas verificar, com segurança, as hipóteses relevantes antes de ampliar o escopo.

Etapa 4: testar com casos conhecidos e comparar resultados

Uma saída plausível não é uma referência. A validação deve usar casos cujo resultado possa ser previsto sem pedir ao mesmo modelo que confirme a própria consulta. Prepare exemplos pequenos com resultados calculáveis, registros nos limites do período, entidades com e sem relações e linhas com valores NULL quando forem relevantes. Com dados sintéticos, é possível controlar exatamente essas condições.

Compare o resultado com uma fonte de referência autorizada: uma consulta simplificada revisada por uma pessoa, um relatório cuja definição corresponda à especificação ou um cálculo manual sobre um conjunto pequeno. Certifique-se de que os dois métodos usam o mesmo período, os mesmos filtros, as mesmas regras de exclusão e a mesma granularidade. Duas consultas que diferem nesses aspectos não são comparáveis, mesmo que usem o mesmo nome para a métrica.

Valide tanto a estrutura quanto os valores. Confira o número de linhas, as chaves duplicadas, os totais por grupo e os casos extremos. Se o resultado precisar conter uma linha por cliente, verifique essa unicidade; se o agrupamento for mensal, examine meses sem atividade e limites de data. Quando houver uma diferença, reduza o caso: inspecione primeiro o conjunto antes do JOIN, depois de cada junção e, por fim, após os filtros e as agregações. Assim, é possível localizar em qual etapa o valor mudou.

A validação cruzada não transforma um teste limitado em garantia universal. Um caso conhecido pode confirmar que a consulta responde corretamente naquela situação, mas não necessariamente em todos os períodos ou combinações de dados. Transforme em testes de regressão os casos que revelaram erros, para verificar se alterações futuras não reintroduzem o mesmo problema.

Erros, resultados vazios e ambiguidades

Um erro de sintaxe indica que o mecanismo não consegue interpretar a consulta, mas corrigi-lo não valida a lógica. Confira o dialeto, os nomes e os tipos antes de pedir uma nova geração. Se solicitar uma correção, descreva o erro específico e mantenha as condições de negócio verificadas; não peça apenas “corrija”, pois a resposta pode alterar outras partes da consulta.

Um resultado vazio também pode ter várias explicações. Pode decorrer de um filtro restritivo demais, diferenças de capitalização ou formato, uma data incorreta, uma relação que exclui linhas ou da inexistência real de correspondências. Inspecione cada condição separadamente no ambiente de teste. Não remova filtros automaticamente só para obter resultados: isso pode transformar um problema de interpretação em uma consulta que inclui dados fora do escopo.

Se o modelo não conseguir explicar de onde veio uma tabela, uma relação ou uma regra, trate esse elemento como não verificado. Reformule a pergunta com a definição que falta ou peça esclarecimentos à pessoa responsável pela métrica. As explicações do modelo podem ajudar a entender a proposta, mas não são evidência independente de que ela está correta.

Se houver uma divergência entre o SQL e a referência, preserve a consulta, os parâmetros, a versão do esquema, o caso de teste e o resultado observado, respeitando as proteções de privacidade. Corrija a causa, não apenas o valor visível. Depois, repita as verificações afetadas e adicione um teste de regressão se a falha puder reaparecer.

Checklist final antes de incorporar a consulta

Antes de usar SQL gerado por IA em uma análise ou pipeline, confirme que a pergunta original tem uma definição verificável; que cada tabela, coluna e relação existe no esquema; e que os JOINs mantêm a granularidade necessária. Revise filtros, agregações, NULL, datas, funções e dialeto. Certifique-se também de que a consulta foi testada em um ambiente autorizado, com dados adequados e permissões somente para leitura quando aplicável.

A saída precisa passar por uma verificação independente com casos conhecidos ou dados de referência comparáveis. Se a verificação falhar, não apresente o resultado como confirmado. Corrija ou reformule, execute os testes novamente e registre a versão aprovada e seu escopo. A lista não elimina a necessidade de revisão especializada para indicadores de alto impacto, dados sensíveis ou consultas complexas.

A regra prática é simples: uma consulta só está pronta quando é compreendida, está limitada ao acesso autorizado e produz resultados consistentes em testes que refletem a pergunta de negócio. Se não for possível demonstrar qualquer uma dessas condições, mantenha a incerteza e solicite uma revisão antes de usar a consulta.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.