A violência lenta dos dados defeituosos

A violência lenta dos dados defeituosos

A folha de cálculo não gritou

A folha de cálculo não parecia perigosa. É quase sempre assim que começa. Estava numa pasta partilhada com um nome sensato, três colunas ocultas, dois formatos de data, um campo de comentários que se tinha tornado um pequeno romance e um separador chamado final que mentia da forma tradicional. Uma equipa usava-a para reconciliar registos de clientes antes de alimentar um novo fluxo de trabalho. Ninguém foi imprudente. Verificaram os totais. Removeram duplicados óbvios. Perguntaram à pessoa que tinha herdado o ficheiro da pessoa que tinha herdado o ficheiro. As respostas eram plausíveis o suficiente para continuar.

Três meses depois, o dano apareceu, mas não como um único evento. Foi pedido a um cliente que apresentasse documentos já fornecidos. Outro foi encaminhado para a fila de serviço errada. Um sinal de risco apareceu num processo porque uma conta encerrada ainda parecia ativa. Um agente de apoio passou vinte minutos a pedir desculpa por um sistema que insistia num endereço antigo. Um gestor viu um rendimento ligeiramente melhor e uma confiança ligeiramente pior. Nenhum destes incidentes parecia suficientemente grande para travar o programa. Juntos, eram o programa.

Os dados incorretos são muitas vezes descritos como um incómodo técnico. Campos em falta, códigos inconsistentes, linhas duplicadas, registos desatualizados, rótulos fracos. Essa linguagem é precisa e demasiado pequena. Os dados incorretos tornam-se violência lenta quando pequenos erros transferem silenciosamente o custo para pessoas que não os criaram. Fazem os cidadãos provar o que a instituição esqueceu. Fazem os funcionários reparar o que o pipeline distorceu. Fazem os clientes repetirem-se. Fazem os auditores reconstruir significado depois de o significado ter sido deitado fora. Fazem os modelos parecerem incertos, enviesados ou tolos quando estão a refletir parcialmente uma falha de registo.

A violência é lenta porque o dano está distribuído. Nenhuma linha assume responsabilidade. Nenhum painel admite a dívida. O sistema continua a operar e, por isso, parece bem-sucedido visto de longe. O dano vive em chamadas extra, candidaturas rejeitadas, cartas erradas, acesso negado, funcionários frustrados, reputação danificada e decisões que se tornam mais difíceis de contestar porque o registo aprendeu a soar oficial. Os dados incorretos não precisam de drama. Têm paciência.

Qualidade não é limpeza

Data quality is often reduced to cleanliness, as if the goal were a table with no visible crumbs. Cleanliness helps. Standard formats, valid values, complete fields, deduplicated rows and sensible ranges are necessary. But a clean dataset can still be wrong for the job. A field can be perfectly formatted and semantically broken. A date can be valid and obsolete. A label can be consistent and unfair. A record can be complete because somebody filled unknown with no, which is how many small disasters put on a tie.

Quality is fitness for a purpose with evidence. The same record may be good enough for sending a newsletter, insufficient for a credit decision, dangerous for a medical triage model, and irrelevant for a public policy evaluation. Context decides. Who created the record. Under which rule. For which task. With which measurement method. How often updated. Which omissions are expected. Which values are inferred. Which values are user supplied. Which transformations happened on the way. Without that context, quality becomes a mood and the dashboard becomes interior design.

AI makes this distinction harder because models are hungry for scale. Scale has a seductive effect on organisations. A large dataset can make people stop asking whether the rows still mean what they think they mean. More data can cover noise statistically, but it can also spread a wrong assumption farther. If a label was produced by an overloaded team, a million labels may give you a very large measurement of overload. If a missing field means refused in one system and unknown in another, merging them creates a category that should wear a warning vest.

The old phrase garbage in, garbage out is still useful, but it is too cheerful. Modern systems can turn garbage in into confident output, prioritised queues, automated letters, risk scores, management reports and training feedback that feeds the next model. Garbage no longer exits politely. It circulates, learns the org chart and gets invited to steering committees.

The default that became policy

Many data failures begin with a default. Blank becomes false. Missing becomes zero. Unknown becomes low risk. No answer becomes consent. Last known address becomes current address. Most recent record becomes best record. A free-text note becomes a label because somebody had to ship the dashboard. Defaults are not evil. Systems need defaults. The problem is when defaults become policy without being named as policy.

A default is a decision about uncertainty. It says what the organisation will do when it does not know. That decision may be harmless in a low-impact workflow and unacceptable in a consequential one. If a marketing preference is blank, a cautious default may simply avoid a message. If a benefit eligibility field is blank, treating it as no may deny support. If a clinical allergy field is blank, treating it as none is not a data choice. It is a very bad day arriving early.

Good data governance forces defaults into the light. It distinguishes unknown, not applicable, not collected, refused, pending, estimated, inherited, inferred and verified. These categories feel tedious until the alternative turns a blank cell into authority. A system that cannot represent uncertainty will often make uncertainty disappear by pretending to resolve it. This is efficient in the same way sweeping glass under a carpet is efficient. The floor is clear. The foot disagrees later.

The practical test is simple: could a reviewer see where the default acted. If a model recommendation, workflow route or report metric depends on a default, the record should show it. If the default changes, previous outcomes should remain interpretable. If people disagree with the default, there should be an owner. Otherwise the organisation has not automated a rule. It has automated an assumption that avoids eye contact.

Rótulos maus fazem política silenciosa

Os rótulos merecem suspeita especial porque muitas vezes parecem mais objetivos do que são. Fraude, alto risco, elegível, conforme, urgente, má qualidade, satisfeito, inseguro, resolvido. Estas palavras comprimem juízo humano, política, hábito, incentivos, pressão de tempo e por vezes preconceito institucional num campo curto o suficiente para um modelo. O rótulo viaja então como se fosse um facto. Quando chega à formação, o argumento que o criou já foi para casa.

Um rótulo pode estar errado porque a pessoa se enganou. Pode também estar errado porque a instrução era pouco clara, a política mudou, o revisor não tinha contexto, a categoria era demasiado ampla, a ferramenta incentivava a rapidez, ou a organização recompensava um certo resultado. Um rótulo pode ser consistente e ainda assim codificar uma má prática. Consistência não é virtude. É apenas repetibilidade, e a repetibilidade pode repetir tolice com disciplina admirável.

Para a IA, rótulos fracos tornam-se mais do que ruído de relatórios. Tornam-se o alvo que o modelo aprende. Se decisões anteriores foram influenciadas por acesso desigual, preconceito histórico, maus incentivos ou registos incompletos, o modelo pode aprender o tecido cicatricial da instituição e chamar-lhe previsão. Isso não torna o modelo malicioso. Torna o alvo de formação pouco examinado. Culpar apenas o algoritmo é atraente porque os algoritmos não vão a avaliações de desempenho.

Melhores práticas de rotulagem não são glamorosas. Escreva orientações. Registe a identidade ou função do revisor quando apropriado. Capture o desacordo. Faça amostragem para qualidade. Preserve exemplos de casos-limite. Reveja os rótulos após mudanças de política. Separe os rótulos criados para operações dos criados para formação. Dê nome à incerteza. Permita que os revisores digam não é possível determinar. Esta última é surpreendentemente radical em organizações que preferem colunas arrumadas à dúvida honesta.

A duplicação não é apenas desperdício de armazenamento

Registos duplicados parecem um problema de armazenamento até encontrarem uma pessoa. Então tornam-se consultas perdidas, elegibilidade errada, histórico fragmentado, integração repetida, várias faturas, pontuações de risco contraditórias e cartas que tratam um ser humano como três clientes. A base de dados pode pensar que tem mais registos. A pessoa experiencia a instituição a falhar em reconhecê-la. Essa é uma categoria diferente de defeito.

Identity is especially hard because the real world is untidy. People change names, addresses, employers, doctors, schools and family structures. Companies merge. assets move. devices are replaced. departments rename programmes because apparently the world had spare confusion. Matching rules need humility. Too strict and the same person splits across records. Too loose and different people merge into one institutional fiction. Both errors create harm.

AI systems amplify identity problems because they rely on assembled context. A case summary may miss relevant history because the records were split. A risk score may overstate exposure because duplicates were counted twice. A recommendation may cite a record belonging to someone else after an overaggressive merge. Retrieval may surface the wrong file because identifiers were reused. The model becomes the visible face of an identity layer that was quietly unwell.

Good identity governance gives duplicates a process, not just a cleanup sprint. It defines matching confidence, human review thresholds, source authority, merge and unmerge rights, audit trails, notification duties and correction routes. Most importantly, it treats unmerge as a first-class operation. Organisations love merging because it feels like tidying. Unmerging is where they learn whether tidying broke reality.

Staleness is a governance problem

Data does not stay true because nobody touched it. Some facts decay. Addresses, employment status, account state, legal rules, clinical conditions, consent, risk levels, stock positions, service eligibility, ownership, device calibration, supplier status. A stale value may pass validation perfectly. It has the correct type, allowed code and professional posture. It is still wrong today.

Staleness is dangerous because systems often treat absence of update as evidence of stability. In many domains, silence means nobody checked. A source feed may have failed. A customer may not have had a reason to log in. A public registry may lag. A sensor may be disconnected. A department may still be using last quarter's extract because the refresh job belongs to a person now on holiday. The data did not become current by sitting politely in a database.

Every consequential field needs a freshness contract. How old may this value be for this use. Which source confirms it. What happens when freshness expires. Can the workflow continue with warning, require human review, fetch a live source, or stop. Freshness should depend on purpose. A mailing address for a newsletter can tolerate more age than an address used for legal notice. A risk indicator for daily operations cannot live on the same calendar as annual reporting.

Freshness contracts also help AI evaluation. When a model fails, teams often ask whether the model understood the data. They should first ask whether the data was still alive. A stale but valid record is a particularly unpleasant trap because it passes technical checks and fails reality. Reality, as usual, files fewer tickets than we would like.

O modelo é culpado pelo arquivo

Quando o resultado da IA é mau, o modelo é o suspeito mais fácil. É visível, caro, novo e, por vezes, maravilhosamente confiante. Mas muitos resultados são tão fortes quanto os registos que conseguem ver. Um modelo a quem se pede para resumir um ficheiro incompleto produzirá uma incompletude polida. Um modelo a quem se pede para classificar casos a partir de rótulos inconsistentes aprenderá a inconsistência com excelente postura. Um modelo a quem se pede para recuperar uma política de uma base de conhecimento desatualizada citará o passado como se ainda tivesse acesso ao escritório.

Isto é importante porque as correções centradas no modelo podem desperdiçar tempo. O re-treino não reparará o consentimento em falta. Uma janela de contexto maior não corrigirá identidades duplicadas. Um melhor prompt não restaurará o significado apagado. Mais avaliação não ajudará se o conjunto de testes contiver os mesmos rótulos defeituosos que a produção. O modelo pode ainda precisar de trabalho. Mas a camada de dados deve ser investigada como suspeita com meios, motivo e um longo historial.

Há também uma conveniência política em culpar o modelo. Se o modelo é o culpado, a correção pertence à equipa de IA. Se os dados são o culpado, a correção pode pertencer às operações, ao jurídico, à política, ao produto, ao apoio ao cliente, à gestão de registos, aos fornecedores e à liderança. Essa é uma mesa maior. Mesas maiores produzem mais itens de agenda. Algumas organizações preferem uma mesa mais pequena e uma explicação pior.

Uma revisão séria de incidentes começa, portanto, mais cedo. Que fonte transportou o facto. Estava atual. Era permitida. O significado foi preservado. O rótulo era válido para este fim. O comportamento da correspondência de identidade foi adequado. Uma predefinição atuou. Uma correção humana chegou ao sistema a jusante. O conjunto de avaliação incluía este tipo de falha. Só depois dessas perguntas o modelo deve ser convidado a defender-se. Pode ainda ser culpado. Não deve estar sozinho.

A reparação tem de chegar à fonte

Muitas organizações têm processos de correção que corrigem o caso visível, mas não o sistema de dados. Um agente de apoio atualiza a morada para a carta de hoje, mas o registo mestre permanece antigo. Um gestor de caso anula a elegibilidade, mas o campo em falta continua em falta. Um médico corrige um resumo, mas a regra de extração continua a produzir o mesmo erro. Uma nota de apoio ao cliente diz para ignorar o valor anterior, o que é uma forma corajosa, mas frágil, de governar uma base de dados.

A reparação tem de viajar a montante. Se um erro for encontrado no ponto de utilização, a correção deve chegar à fonte autoritativa ou, pelo menos, criar um estado reconciliado com evidência. O sistema deve saber se a correção é local, temporária, disputada, verificada ou estrutural. Uma correção que não pode ser propagada torna-se mais um pedaço de dados defeituosos. Muito eficiente, no sentido mais sombrio.

The repair path should also protect people from becoming unpaid data stewards for institutions. It is reasonable to ask someone to provide missing information once. It is not reasonable to make them correct the same record across five channels because the organisation's systems enjoy independence too much. When people repeatedly supply facts and the institution repeatedly forgets them, the problem is not user friction. It is institutional memory failure.

Good repair creates learning. If many corrections hit the same field, the collection form may be unclear. If many unmerges occur after a matching rule change, the threshold is wrong. If a label is disputed often, the guideline needs review. If stale records drive incidents, freshness contracts are missing. Data quality improves when correction is treated as evidence, not inconvenience.

Bad data is not morally neutral

It is tempting to treat data quality as a back-office concern. The records are messy, yes, but every organisation has messy records. That is true in the same way every building has dust. The question is whether the dust is on a shelf or inside the ventilation system. Once bad data drives automated decisions, prioritised work, AI outputs, reporting, compliance, payments or public services, it stops being back-office housekeeping. It becomes a way power is exercised.

That does not mean every error is a scandal. Serious institutions can make mistakes. The moral question is whether mistakes are visible, correctable and prevented from multiplying. A recordkeeping system that hides uncertainty, resists correction, punishes the person affected with repeated proof, and keeps using derived errors is not merely untidy. It is unfair in a durable way.

There is no single cure. Data work is local, domain-specific and occasionally humbling. But the posture is clear. Treat important fields as decisions with owners. Make uncertainty representable. Keep provenance close. Attach freshness to purpose. Audit labels. Govern identity. Propagate corrections. Measure repair burden, not only processing speed. When AI is involved, test the data path as hard as the model path. The records are not scenery. They are part of the machinery.

The spreadsheet did not shout because spreadsheets rarely do. The system did what systems do: it converted quiet assumptions into louder consequences. The lesson is not that all data must be perfect before work can begin. That would end civilisation, or at least Tuesday planning. The lesson is that bad data should not be allowed to act with authority while remaining cheap, invisible and someone else's problem. Slow violence becomes slower when nobody names it. It becomes smaller when the record finally has to answer for itself.