Dados ruins na automação: como um erro de cadastro chega à execução

Um cliente aparece duas vezes no cadastro. Em um relatório, isso pode aumentar a contagem. Em uma rotina de cobrança, pode gerar duas ações para a mesma pessoa. O mesmo defeito muda de importância conforme o processo em que é utilizado.

Automatizar torna necessário avaliar essa consequência. A pergunta não é apenas se a base tem erros. É quais erros chegam à decisão, como o sistema reage e quem intervém antes que produzam um efeito indevido.

A qualidade deve ser avaliada por campo e por tarefa

Uma tabela quase completa pode ter lacunas justamente no campo que determina o destinatário ou o valor de uma ação. O indicador agregado esconde a condição mais importante.

A documentação da IBM apresenta dimensões como completude, acurácia, consistência, atualidade, unicidade e validade. Elas ajudam a escolher verificações adequadas ao uso.

Não existe um percentual universal que libere qualquer automação. O critério deve considerar o efeito do erro e a possibilidade de detectá-lo antes da execução.

Dado ausente não deve virar uma suposição silenciosa

Campo vazio, valor zero e situação desconhecida representam coisas diferentes. Uma regra precisa determinar como cada uma será tratada.

Se falta a data de vencimento, a aplicação não deve inventá-la para concluir a tarefa. Pode encaminhar o registro para revisão ou limitar a resposta, conforme o processo.

A mesma atenção vale para classificações ambíguas. Um código antigo de cliente ou produto pode exigir uma relação explícita com o cadastro atual.

Os sistemas podem discordar por motivos legítimos

CRM, ERP e banco registram eventos diferentes. Uma oportunidade ganha não equivale a uma nota emitida; uma nota emitida não equivale a um pagamento.

A conexão entre essas etapas deve respeitar os identificadores e as datas. Tentar igualar os totais sem entender a relação pode apagar uma diferença importante.

A camada semântica ajuda a registrar esses conceitos. O responsável pelo processo precisa validar a interpretação e decidir o que fazer com os casos que não se encaixam.

A ação exige uma condição de entrada

Antes de executar, a automação deve verificar se os dados necessários estão presentes e se as regras permitem avançar. Essa validação precisa existir no caminho da operação.

Uma recomendação pode ter tolerância maior à incerteza do que uma mudança financeira. A aprovação e as permissões devem refletir essa diferença.

A OWASP recomenda limitar funções e acessos e exigir aprovação humana para ações de alto impacto. A qualidade dos dados é parte da avaliação; não substitui os demais controles.

O primeiro teste deve procurar o que pode dar errado

Inclua duplicatas, informações antigas, ausência de campos e mudanças de status durante a execução. O objetivo é observar se o sistema reconhece a exceção e evita um resultado indevido.

Quando houver correção, registre se ela foi feita apenas no resultado ou também na origem. Corrigir sempre a saída mantém o defeito ativo para a próxima rotina.

A DataQore organiza fontes e regras para apoiar consultas e automações. O trabalho deve começar pelos dados que determinam a tarefa e pelos critérios que a equipe consegue verificar.

Uma automação confiável precisa saber quando pode continuar e quando deve pedir ajuda. Essa fronteira é tão importante quanto a capacidade de concluir o caminho mais simples.

Leituras relacionadas

Dimensões de qualidade dos dados

Como investigar respostas erradas da IA

Referências

IBM: dimensões de qualidade de dados

OWASP: funções, permissões e aprovação

Revisão editorial: 4 de novembro de 2026.