Do português ao SQL, do caos ao controle: como a qualidade de dados virou o novo campo de batalha da IA

Durante anos, a promessa da inteligência artificial generativa girou em torno de modelos cada vez maiores e mais criativos. Em 2026, a conversa mudou de eixo. O gargalo deixou de ser a capacidade de gerar texto, código ou previsões — e passou a ser a confiabilidade do dado que alimenta tudo isso. Três movimentos recentes, vindos de frentes distintas, escancaram essa virada: o modelo Lloro SQL, da Semantix Research Labs, que traduz perguntas em português para consultas SQL; a aposta da Validio em validar dados não estruturados e registros de MDM com ajuda de LLMs dentro do próprio data warehouse; e o novo toolkit de qualidade de dados do dltHub, anunciado em prévia com uma filosofia agressiva de "falhar rápido". Juntos, eles desenham o contorno de uma nova disciplina: a engenharia de dados como infraestrutura crítica de IA.

Lloro SQL: quando a pergunta é em português, mas o banco só entende SQL

O primeiro destaque vem do Hugging Face. O semantixai/Lloro-SQL é um modelo de linguagem desenvolvido pela Semantix Research Labs com um objetivo bastante específico: transformar consultas escritas em português em código SQL. Não se trata de um chatbot genérico, e sim de uma ferramenta de tradução semântica entre a linguagem natural do analista de negócios e a linguagem estruturada do banco de dados.

Tecnicamente, o Lloro SQL é um fine-tune do meta-llama/Meta-Llama-3-8B-Instruct, treinado sobre datasets públicos da GretelAI. O processo de ajuste fino foi conduzido com a metodologia QLoRA em uma GPU A100 com 40 GB de memória — um detalhe relevante porque mostra que não é preciso um cluster colossal para adaptar um modelo de 7 bilhões de parâmetros a uma tarefa vertical. O resultado é um modelo especializado, enxuto e mais barato de operar do que seus primos de fronteira.

Por que isso importa? Porque a barreira entre "quem entende o negócio" e "quem sabe escrever joins" sempre foi um gargalo operacional caro. Cada pergunta simples — "qual foi o faturamento da regional Sul no último trimestre?" — dependia de um analista intermediário. Um text-to-SQL bem ajustado ao português encurta esse caminho, mas também expõe riscos conhecidos:

Ambiguidade linguística: o português brasileiro é cheio de jargão corporativo regional, apelidos de produtos e siglas internas que nenhum dataset público captura.
Aderência ao schema: um SQL sintaticamente correto mas que consulta a tabela errada é pior do que uma resposta "não sei".
Segurança: consultas geradas por LLM precisam de guarda-corpos contra operações destrutivas e vazamento de dados sensíveis.
Avaliação: medir a acurácia exige um conjunto de perguntas reais com respostas verificadas, algo raramente público.

Ainda assim, o movimento é claro: modelos pequenos, especializados e afinados com QLoRA estão se tornando a forma mais pragmática de levar IA para dentro do stack de dados — incluindo aí a soberania linguística do PT-BR.

Validio e o dado que não cabia no formulário

Se o Lloro ataca a interface entre humano e banco, a Validio ataca um problema ainda mais espinhoso: validar aquilo que não é estruturado. A empresa descreve uma abordagem que combina Custom SQL Sources com funções de IA nativas do data warehouse para avaliar registros de Master Data Management (MDM) e conteúdos não estruturados.

Na prática, LLMs passam a pontuar, classificar e padronizar texto, imagem e áudio diretamente dentro do warehouse — sem exportar dados para serviços externos. O ponto crucial é o que acontece depois: a detecção de anomalias, os limites (thresholds) e as notificações da Validio se aplicam à saída do LLM exatamente como se aplicariam a qualquer campo estruturado.

Isso resolve um problema antigo. Historicamente, a qualidade de dados vivia confortável no mundo das tabelas: nulos, duplicatas, tipos errados, faixas fora do esperado. Mas a maior parte do patrimônio informacional de uma empresa moderna é textual — descrições de produtos, tickets de suporte, contratos, laudos, transcrições de call center. Como dizer que um campo de descrição está "correto"? A resposta tradicional era: não dá. A resposta nova é: peça a um modelo para avaliar consistência, duplicidade semântica e aderência a padrões, e depois trate esse score como um sinal de monitoramento.

O efeito colateral positivo é a convergência entre MDM e observabilidade de dados. Se o mesmo mecanismo que detecta um pico de latência pode detectar um lote de descrições de produtos fora do padrão de marca, a governança deixa de ser um projeto anual e vira um processo contínuo.

dltHub e a cultura do "falhe rápido" nos pipelines

O terceiro anúncio é talvez o mais revelador da mudança cultural. O dltHub apresentou, em 4 de junho de 2026, uma versão prévia do seu toolkit de qualidade de dados para IA, construído sobre decoradores persistentes baseados em metadados. A proposta é direta: em vez de descobrir problemas de schema três camadas adiante, o pipeline deve falhar rapidamente (fail-fast) — e, mais do que isso, rotear automaticamente as remediações dentro dos próprios pipelines dlt.

Vale destrinchar o que isso significa na prática:

Decoradores persistentes: as regras de validação são declaradas junto ao código do pipeline e permanecem registradas como metadados, sobrevivendo a refatorações e reexecuções.
Baseadas em schema: as verificações partem da estrutura esperada dos dados — colunas, tipos, chaves —, o que reduz a dependência de heurísticas frágeis.
Fail-fast: dados ruins param o fluxo imediatamente, em vez de contaminar tabelas downstream e dashboards executivos.
Roteamento automático de remediações: em vez de apenas alertar, o toolkit encaminha o problema ao mecanismo de correção apropriado, fechando o ciclo entre detecção e ação.

É uma evolução conceitual importante. Ferramentas de qualidade de dados tradicionais nasceram como camadas de auditoria a posteriori: olham para a tabela pronta e reclamam. O dltHub propõe deslocar essa responsabilidade para o momento da ingestão, transformando qualidade em uma propriedade do pipeline, não em um relatório. Para times que constroem aplicações de IA, isso é decisivo: um agente alimentado por dados inconsistentes não falha de forma óbvia — ele alucina com confiança.

A convergência: qualidade de dados como pré-requisito de IA

Lidos em conjunto, os três movimentos apontam para a mesma direção. O Lloro SQL mostra que a IA está entrando na camada de acesso ao dado. A Validio mostra que ela está entrando na camada de validação. O dltHub mostra que ela está entrando na camada de ingestão e remediação. É a IA se tornando infraestrutura — e, como toda infraestrutura, sendo cobrada por confiabilidade, não por criatividade.

Três padrões emergem dessa convergência:

Processamento in-warehouse: tanto a Validio quanto boa parte do ecossistema moderno preferem levar o modelo ao dado, e não o dado ao modelo. Isso reduz latência, custo de egress e risco de exposição.
Modelos pequenos e especializados: o caso do Lloro demonstra que um 7B afinado com QLoRA resolve uma tarefa vertical com uma fração do custo de um modelo de fronteira.
Qualidade declarativa: as regras saem dos wikis e planilhas e passam a viver no código, versionadas junto com o pipeline.

Os desafios que ninguém resolveu ainda

Seria ingenuidade tratar esse cenário como resolvido. Há perguntas abertas que vão definir quais dessas apostas sobrevivem:

Quem valida o validador? Se um LLM classifica e pontua dados, como medir a taxa de erro desse próprio modelo? Sem um conjunto de referência confiável, a camada de qualidade herda os vieses da camada de IA.
Custo em escala: rodar inferência sobre milhões de registros textuais não é trivial. A conta fecha para casos críticos, mas raramente para tudo.
Determinismo e auditabilidade: pipelines de dados exigem reprodutibilidade. Saídas probabilísticas complicam a conformidade e a rastreabilidade.
Privacidade e regulação: avaliar áudio e imagem dentro do warehouse resolve parte do problema de exposição, mas não dispensa políticas de retenção, anonimização e base legal.
Português como cidadão de primeira classe: modelos treinados predominantemente em inglês ainda tropeçam em nuances do PT-BR. Iniciativas como o Lloro são um contraponto necessário.

Conclusão

A grande história de 2026 não é o lançamento de mais um modelo gigante. É a profissionalização silenciosa da camada que sustenta todos eles. O Lloro SQL democratiza o acesso analítico em português, mas só entrega valor se o dado por trás da consulta for íntegro. A Validio estende a qualidade para o território nebuloso do texto, da imagem e do áudio, mas depende de modelos cuja precisão precisa ser continuamente auditada. O dltHub move a detecção para o instante da ingestão e transforma erro em ação automática, mas assume que o time sabe definir o que é "correto".

Para quem constrói produtos de dados e IA no Brasil, a mensagem é prática: trate qualidade de dados como feature de produto, não como tarefa de limpeza. Adote validação declarativa no pipeline, prefira modelos especializados quando o problema for vertical, monitore as saídas dos LLMs com os mesmos rigores que aplica às tabelas, e não terceirize a soberania linguística do português. A corrida da IA não será vencida por quem tem o modelo mais eloquente, e sim por quem tem o dado mais confiável por baixo dele.