Text-to-SQL seguro: e se a IA apagar o banco de dados?

Na primeira demonstração interna, meu sócio esperou eu terminar e fez a pergunta que estraga qualquer apresentação: "e se ela apagar o banco?". A sala riu. Ele não estava brincando, e estava certo em perguntar. Text-to-SQL seguro não é promessa de que a inteligência artificial não erra. É arquitetura para limitar o que acontece quando ela erra — porque errar, ela erra.

A resposta que eu dei naquele dia foi vaga e eu sabia. Fui atrás. A resposta boa é objetiva: a execução é estritamente somente leitura, limitada a SELECT, com escopo obrigatório por empresa. Mutações, múltiplas instruções, construções inseguras e acesso fora da empresa da sessão ficam bloqueados. O SQL gerado não concede capacidade de escrita no banco.

Ou seja: o pior caso é um número errado. Número errado dói, atrapalha reunião, mas se detecta conferindo. Dado apagado não volta. Neste artigo eu abro cada camada e mostro o protocolo que a gente usa antes de deixar uma consulta nova virar base de decisão. O uso do dia a dia está em como perguntar ao ERP.

As camadas do text-to-SQL seguro

• Nenhuma consulta gerada altera, remove ou insere dado.
• Nenhuma execução encadeia mais de uma instrução.
• Nenhum resultado atravessa a fronteira da empresa da sessão.
• Nenhuma construção considerada insegura passa pela camada de execução.
• Todo erro válido gera nova tentativa orientada em vez de devolver vazio.

Por que só leitura muda toda a conversa

Sistema que permite escrita exige revisão humana antes de cada execução, e aí o ganho de velocidade evapora. Restringir a leitura inverte a equação: como nada pode alterar estado, a execução pode ser imediata e a revisão passa para o resultado, não para o comando. É uma escolha de projeto que troca uma classe inteira de riscos por um problema de conferência, que é bem mais barato de administrar.

Agora, o que somente leitura não resolve. Ela não impede que uma consulta correta mostre dado sensível para quem não deveria ver. Não impede que um agrupamento errado gere conclusão errada. Por isso as camadas de permissão e de governança continuam necessárias, do jeito descrito em governança de dados em relatórios.

O dicionário construído do schema real

O dicionário sai do schema real do banco, com cache. O modelo não trabalha sobre uma descrição genérica de ERP, e sim sobre as tabelas e colunas que existem naquele ambiente. O efeito é grande: derruba muito as consultas que referenciam estrutura inexistente e melhora a aderência ao vocabulário do sistema.

Isolamento por empresa não é opcional

O escopo por empresa é obrigatório na execução e o acesso fora da empresa da sessão fica bloqueado. Em ambiente multiempresa, esse é o controle mais crítico de todos, porque uma falha aqui não gera número errado. Gera vazamento entre unidades, que é assunto de outra gravidade. O tema aparece inteiro em isolamento multiempresa em relatórios.

Como eu homologo uma consulta nova

O recurso está implementado e passou por validações técnicas com dados reais, mas consulta nova precisa ser homologada por domínio e por volume. Isso não é ressalva de advogado. Domínio diferente tem regra de negócio diferente, e volume alto muda o comportamento de execução. O protocolo abaixo cobre os dois eixos.

1. Reproduza em relatório tradicionalRode a mesma pergunta numa tela pronta equivalente e compare os totais. Diferença exige explicação antes de qualquer uso.
2. Teste no período curto e no longoUma consulta que responde bem num dia pode se comportar diferente em um ano de dados. Teste os dois extremos, não só o confortável.
3. Audite o SQL geradoExporte a consulta e mande para quem conhece o modelo de dados, principalmente quando há junção entre áreas diferentes.
4. Escreva a definição da métricaRegistre o que o número significa. Sem isso, a próxima pessoa reinterpreta e você volta à estaca zero.
5. Só então publiqueDepois da homologação, transforme em relatório publicado para que todo mundo leia exatamente o mesmo recorte.

Checklist de aceitação

• A consulta bate com o total do relatório tradicional equivalente.
• O filtro de empresa está presente e correto no resultado.
• Coluna com dado pessoal só aparece quando a decisão exige mesmo.
• O tempo de resposta continua aceitável no maior período previsto.
• A definição da métrica está escrita junto do relatório publicado.

Segurança em análise de dados não é impedir a pergunta. É limitar o pior caso da resposta.

Equipe Webajato

O que continua sendo problema seu

Nenhuma trava técnica decide se um resultado faz sentido para o negócio. A execução restrita garante que a consulta não altere dado e não atravesse a fronteira da empresa. Ela não garante que o agrupamento escolhido responda à pergunta que você fez. Essa avaliação continua sendo sua, e é por isso que a conferência cruzada com um relatório conhecido importa tanto no começo.

Vale o mesmo para a escolha das colunas. Uma consulta tecnicamente impecável pode expor dado pessoal que a finalidade não justifica, e a trava de leitura não impede isso. Essa revisão é humana e acontece antes da publicação, conforme LGPD aplicada a relatórios. Quem quiser entender o desenho de IA por trás encontra o contexto em automação e IA.

Por onde eu começaria

Escolha uma consulta que já está sendo usada informalmente e passe ela pelo protocolo inteiro, do começo ao fim, com alguém da área técnica junto. Uma só. Você vai aprender mais sobre o seu próprio modelo de dados nessa homologação do que em qualquer documentação, e o time passa a confiar no recurso por motivo certo.