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

A Indegene colocou um agente para gerar regras de qualidade de dados sob aprovação humana, e o Glue Data Quality passou a recomendar regras com Bedrock. A pergunta deixa de ser se o LLM escreve a regra. Passa a ser quem responde por ela depois de aprovada, como ela é testada e quando morre.

- URL: https://fernando.moretes.com/blog/regra-de-qualidade-gerada-por-llm-custa-pouco-dificil-e-mante-la-por

- Markdown: https://fernando.moretes.com/blog/regra-de-qualidade-gerada-por-llm-custa-pouco-dificil-e-mante-la-por/article.md?lang=pt

- Published: 2026-11-06T10:14:50.828Z

- Category: Dados & Plataformas

- Tags: data quality, agentes de IA, AWS Glue, Amazon Bedrock, AgentCore, governança de dados, human-in-the-loop

- Reading time: 8 min

- Source: [How Indegene is modernizing and scaling enterprise data quality in life sciences](https://aws.amazon.com/blogs/machine-learning/how-indegene-is-modernizing-and-scaling-enterprise-data-quality-in-life-sciences/)

---

Depois de 16 anos construindo plataformas financeiras sobre AWS, a pergunta que eu faço sobre qualidade de dados não é "quem escreve a regra?", é "quem responde por ela às 2h da manhã, quando ela barra uma carga legítima?". O caso da Indegene, publicado em 4 de novembro de 2026, importa por causa dessa segunda pergunta: um agente propõe regras e código, mas só o que passa por aprovação humana entra no repositório central. Combinado com o modo `ADVANCED` do AWS Glue Data Quality, ele indica para onde o custo está indo: sai da autoria e vai para a manutenção.

## Três números para calibrar a decisão

- **17**: Regiões com o modo ADVANCED. A lista da documentação não inclui `sa-east-1`
- **14d**: Retenção padrão da amostra no S3. Regra de lifecycle sobre os resultados do Athena
- **267h**: Revisão num cenário hipotético meu. 200 tabelas × 40 colunas × 1 regra × 2 minutos

## O sinal: gerar regra virou commodity

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 que muda para quem desenha a plataforma

- **Regra vira artefato de design time:** a documentação avisa que `ADVANCED` pode devolver regras diferentes para a mesma tabela, então geração não pode estar no caminho de execução.
- **O gargalo muda de lugar:** escrever deixa de ser o limite, a capacidade de revisão humana passa a ser.
- **Regra técnica e regra de negócio passam a ter o mesmo ciclo de vida:** a que hoje mora no código e a que mora em SOP entram no mesmo repositório versionado.
- **A amostra vira superfície de dados:** gerar com contexto significa enviar linhas reais a um modelo, e isso exige decisão de classificação antes do primeiro run.
- **A base de conhecimento pode propagar erro:** regra aprovada volta como contexto, então um erro aprovado hoje pode ser sugerido de novo amanhã.

## Onde a regra gerada erra sem avisar

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`.

## Onde a aprovação humana separa geração de execução

O diagrama responde a uma pergunta: o que precisa acontecer para uma sugestão do modelo virar regra em produção. É uma simplificação das 10 etapas descritas no post. As setas tracejadas são o retorno assíncrono à base de conhecimento, e é por ali que um erro aprovado pode voltar como sugestão.

### Generation

- Knowledge bases internal + external (data)
- Data Quality Agent Strands + AgentCore (ai)

### Governance

- Data steward review and edit (user)
- Code validation SQL + Python (security)
- Rule repository approved rules (storage)

### Runtime

- Redshift, Snowflake rule execution (data)
- Monitoring and audit results (compute)

### Fluxos

- kb -> agent: RAG
- agent -> steward: sugere com severidade
- steward -> validate: aprova
- validate -> repo: grava
- repo -> engine: executa
- engine -> monitor: publica resultado
- repo -> kb: regras aprovadas
- monitor -> kb: anomalias históricas

## A fronteira da amostra é decisão de arquitetura

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.

## Três caminhos para gerar regras
| Critério | Glue `BASIC` | Glue `ADVANCED` | Agente próprio (padrão Indegene) |
| --- | --- | --- | --- |
| Contexto da regra | Estatísticas da tabela | Metadados e amostra de linhas | Glossário, SOP, histórico e feedback de especialista |
| Fontes | Tabelas do Data Catalog e jobs ETL | Tabelas do Data Catalog, em 17 Regiões | As que você conectar; no caso, Redshift e Snowflake |
| Dado enviado ao modelo | Ruleset e metadados de coluna, quando há enriquecimento | Metadados e linhas, sem exclusão de coluna | O que seu design permitir, e o controle é seu |
| Custo que fica | Revisar regra estatística | Revisar cada run e pagar Athena | Manter agente, bases, avaliação e tudo acima |
| Use quando | A base é nova e o objetivo é cobrir o estrutural | O dado pode ser amostrado e o catálogo já é o Glue | A regra depende de conhecimento que não está na tabela, em várias plataformas |

## Aprovação humana é capacidade, não caixa de seleçã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.

## Como eu me posicionaria

**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.

## O que eu não faria

- **Gerar regra em tempo de execução:** o mesmo dado pode receber regras diferentes entre runs, e a auditoria perde a resposta para "qual regra valia naquele dia?".
- **Medir sucesso por número de regras:** cobertura por coluna é fácil de inflar, e cada regra a mais é mais uma fonte de alerta para alguém manter.
- **Colocar conteúdo da web direto no RAG de regras:** página raspada é entrada não confiável. Exija a mesma curadoria da base interna, ou uma regra sugerida pode nascer de um texto que ninguém aprovou.
- **Depender de `labels` para severidade em todo lugar:** labels de DQDL só existem no Glue ETL, não no Data Quality baseado no Data Catalog. Quem padroniza nisso descobre o buraco no relatório.

> **A lição do ciclo de retorno:** Regras aprovadas e scripts validados entram na base interna. Isso melhora a sugestão seguinte e também dá a uma aprovação ruim um alcance que ela não tinha: o erro deixa de afetar uma tabela e passa a orientar as próximas. Ao revogar uma regra, remova também o vetor dela da base. Quem só apaga do repositório deixa o erro vivo no contexto.

> **Nota do curador:** Eu começaria pelo Glue `BASIC` numa base não sensível e usaria `ADVANCED` só sobre tabela mascarada, antes de escrever uma linha de agente. Escreveria as fixtures com defeito plantado na primeira semana, porque é o único item desta lista que fica mais caro a cada regra aprovada sem ele. Só partiria para agente próprio quando a regra que importa dependesse de SOP e glossário, em mais de uma plataforma, que é a condição real do caso Indegene. A lição que levo de sistemas financeiros: o custo de um controle automatizado não é o custo de criá-lo, é o de provar anos depois por que ele existe e se ainda funciona.

## Minha recomendação

Use o recurso nativo do Glue quando seu catálogo já está nele, a regra se explica pelos dados e a amostra pode ir ao modelo. Construa um agente quando a regra depende de conhecimento fora da tabela, em várias plataformas, e você tem como pagar a manutenção dele. Nos dois casos, não aprove em escala antes de ter dono por regra, teste com defeito plantado e critério de aposentadoria: sem isso, gerar mais rápido só antecipa a dívida.

**Rating:** Adote com governança / Adopt with govern

## Referências

- [How Indegene is modernizing and scaling enterprise data quality in life sciences](https://aws.amazon.com/blogs/machine-learning/how-indegene-is-modernizing-and-scaling-enterprise-data-quality-in-life-sciences/)
- [Getting started with AWS Glue Data Quality: recommendation modes](https://docs.aws.amazon.com/glue/latest/dg/data-quality-getting-started.html)
- [Data protection for advanced data quality rule recommendations](https://docs.aws.amazon.com/glue/latest/dg/data-protection-advanced-dq-recommendations.html)
- [Configure IAM permissions for AWS Glue Data Quality](https://docs.aws.amazon.com/glue/latest/dg/data-quality-authorization.html)
- [Data Quality Definition Language (DQDL) reference](https://docs.aws.amazon.com/glue/latest/dg/dqdl.html)
- [DQDL rule type: CustomSQL](https://docs.aws.amazon.com/glue/latest/dg/dqdl-rule-types-CustomSql.html)
- [Amazon Redshift: EXPLAIN](https://docs.aws.amazon.com/redshift/latest/dg/r_EXPLAIN.html)
- [Deliver multi-tenant AI analytics at scale with AgentCore and Lake Formation](https://aws.amazon.com/blogs/big-data/deliver-multi-tenant-ai-analytics-at-scale-with-agentcore-and-lake-formation/)