Regra de qualidade gerada por LLM custa pouco; difícil é mantê-la por anos

O Data Quality Agent da Indegene faz parte da NEXT Unified Data Platform. Foi construído com Strands Agents, roda no Amazon Bedrock AgentCore e atende Amazon Redshift e Snowflake atrás de AWS WAF, API Gateway e Cognito, com OAuth 2.0 e validação do JWT a cada requisição. O fluxo tem 10 etapas: fonte, schema, profiling, anomalias contra baseline histórico, gestão de regras existentes, modo de regra (coluna, tabela ou query customizada), sugestões com severidade, revisão, geração e validação de SQL e Python, e gravação no repositório central.

Duas bases de conhecimento dão o contexto. A interna reúne glossários, dicionários de dados, SOPs, orientação regulatória, regras aprovadas, scripts validados, resultados de profiling, anomalias históricas e feedback de especialistas. A externa vem de frameworks aprovados, busca na web e scraping controlado. É isso que permite ao agente sugerir o formato de 10 dígitos para uma coluna de NPI sem que alguém o ensine.

Em setembro de 2026, o Glue Data Quality ganhou o modo ADVANCED, que usa Bedrock sobre metadados e uma amostra aleatória da tabela para gerar regras em DQDL. Quando o próprio plano de dados entrega geração de fábrica, ela deixa de ser diferencial de plataforma.

Um limite do que li: a parte do post que consegui abrir termina na descrição da arquitetura, sem detalhar o mecanismo de validação e sem número de resultado. Por isso não cito ganho percentual aqui.

O risco não é a regra que quebra, é a regra que passa. Regra com erro de sintaxe falha no primeiro run. As abaixo rodam verdes durante meses:

• Semântica invertida: no CustomSql com resultado por linha, registro devolvido pela query conta como aprovado e registro não devolvido como reprovado. Um modelo que escreve a query natural de auditoria, select id from primary where valor < 0, aprova exatamente os registros errados.
• Filtro que aprova: com where, as linhas filtradas saem como Passed por padrão. Use rowLevelConfiguration.filteredRowLabel = SKIPPED, ou um filtro que não casa com nada parece conformidade.
• Composite por coluna: por padrão, (A) or (B) avalia cada regra na tabela inteira e combina depois. O exemplo da documentação falha nesse modo e passa com compositeRuleEvaluation.method = ROW. Completeness, Uniqueness, DatasetMatch e ReferentialIntegrity nem têm suporte no modo ROW.
• Histórico vazio: sem pontos anteriores, last(k) devolve 0.0, então RowCount > last() passa na primeira execução sem provar nada.
• Domínio congelado: regra derivada da amostra, como ColumnValues "territorio" in [...], trata o valor novo e legítimo como defeito, e pode tratar o defeito antigo como domínio válido.

O exemplo de negócio do post, participação de mercado somando 100% por território, tem a mesma armadilha numérica de uma conciliação financeira: exige tolerância explícita. Uma forma em DQDL, com tolerância que você precisa calibrar: CustomSql "select count(*) from (select territory_id from primary group by territory_id having abs(sum(market_share) - 100) > 0.5) t" = 0.

O modo ADVANCED é prático, e a documentação de proteção de dados é clara sobre o que ele faz. O Athena amostra as linhas pelo workgroup glue-dataquality-sampling, e o Glue não exclui nenhuma coluna da amostra. Metadados e linhas seguem para o Bedrock, que não retém entrada nem saída depois do processamento e não as usa para treinar modelos. Até aqui, para muito cenário, isso basta.

Para dado de profissional de saúde, de paciente ou de cliente bancário, três detalhes mudam a conta:

• Sem máscara na chamada: ADVANCED não aceita PreProcessingQuery, então o SELECT sem a coluna sensível, que seria a saída óbvia, não está disponível. Aponte o run para uma tabela já mascarada.
• Inferência entre Regiões: o run usa geographic cross-Region inference, e o conteúdo amostrado pode sair da Região de origem, dentro do limite geográfico do perfil. Com sa-east-1 fora da lista, o caminho precisa entrar no seu inventário de transferência da LGPD e, se for o caso, na avaliação de BACEN 4.893.
• IAM do Bedrock não é o controle: a role de recomendação não precisa de permissão de Bedrock, logo negar bedrock:InvokeModel nela não garante o bloqueio do envio. O controle útil é fixar aws:SourceArn na tabela, na trust policy, e não dar à role acesso à tabela sensível.

O BASIC também merece atenção. Nas Regiões suportadas, ele tenta enriquecer o ruleset com Bedrock enviando o ruleset e metadados de coluna, sem você habilitar nada. Um ruleset estatístico pode carregar valores reais numa lista ColumnValues ... in [...], então confira isso na sua classificação.

Human-in-the-loop costuma aparecer em diagrama como um ícone de pessoa. Na operação, ele é uma fila. Faça a conta do seu ambiente. No meu cenário hipotético, 200 tabelas com 40 colunas e uma única regra por coluna dão 8.000 regras. A 2 minutos por regra, são 267 horas de revisão antes da primeira execução. Ninguém revisa isso com atenção: em algum ponto da fila, aprovar vira clicar, e o controle continua no papel enquanto deixa de existir na prática.

A severidade por regra, que o agente da Indegene já sugere, é o que torna essa fila administrável. Revise uma a uma o que é crítico, aprove em lote o estrutural de baixo risco com amostragem de auditoria, e descarte sem culpa a regra que ninguém assumiria como dono. Regra sem dono nomeado não deveria entrar no repositório.

Depois vem o custo recorrente. Pelos exemplos da página de preços do Glue, uma avaliação de 5 DPUs por 20 minutos custa cerca de US$ 0,73, a US$ 0,44 por DPU-hora. Em 200 tabelas, diariamente, são cerca de US$ 4.380 por mês, e esse é o menor dos custos. O maior é o alerta falso: cada regra ruim gera investigação, e equipe que investiga alarme falso três vezes para de olhar o quarto. Meça por regra quantas falhas viraram correção real, e aposente a que nunca virou.

Trate regra como código: o ruleset aprovado vai para repositório versionado, com hash, dono, severidade e motivo. A execução só lê essa versão, nunca chama o modelo. Isso também resolve o não determinismo: rodar a geração duas vezes não muda o que está em produção.

Teste a regra contra dado com defeito plantado: para cada regra, uma fixture com registros bons e outra com o defeito que ela promete pegar. A regra precisa passar na primeira e falhar na segunda. É o teste que pega o CustomSql invertido, e nenhuma revisão de texto pega com a mesma confiabilidade. As ferramentas de avaliação do Strands ajudam a medir o agente, mas juiz LLM avaliando saída de LLM não substitui executar a regra.

Não confunda plano válido com query segura: o EXPLAIN do Redshift mostra o plano sem executar, e também aceita UPDATE e DELETE. Passar nele prova que a query compila, não que ela só lê. Combine com allowlist de SELECT no parser e role somente leitura.

Separe a identidade de geração da de execução: o post de 5 de novembro sobre AgentCore e Lake Formation mostra o caminho certo para exploração: a query roda sob a role mapeada do usuário, com LF-Tags e data cell filters, e o controle não depende do SQL que o agente escreveu. A execução em produção é outra história. A matriz do Glue marca tabelas com filtro de coluna ou de dados do Lake Formation como não suportadas em vários formatos, então a role de qualidade tende a ter acesso amplo. Trate essa role como principal privilegiado e audite-a como tal.