A Resolução de Entidades Está se Tornando Infraestrutura de IA, Não Limpeza de Dados

Há algum tempo, eu assisti a um agente de IA dar uma resposta confiante, mas errada, por um motivo bastante banal. Uma empresa tinha dois registros para o mesmo cliente corporativo. Um registro continha o nome antigo e um contato de finanças, enquanto o outro registro continha o nome legal novo, adotado após uma aquisição, junto com um endereço de cobrança diferente. O agente foi perguntado sobre uma questão simples: essa conta está em boa situação? Ele encontrou um registro, viu que não havia faturas vencidas e disse sim. As faturas vencidas estavam registradas sob o outro nome.

Nada foi inventado. O modelo raciocinou corretamente sobre os dados que recebeu. Os dados simplesmente aconteceram de descrever dois clientes onde, no mundo real, havia apenas um. O erro não estava no modelo de linguagem. Estava na junção.

Eu vim a pensar que isso é um dos riscos mais subestimados em IA empresarial e um dos menos discutidos. Falamos interminavelmente sobre a precisão do modelo, design de prompts e governança. Falamos muito menos sobre se um sistema realmente sabe qual entidade do mundo real um determinado registro se refere. Essa pergunta tem um nome. É chamada de resolução de entidades, e após sessenta anos em segundo plano, está se tornando silenciosamente uma peça de infraestrutura ao vivo.

O problema mudou de tempo

Por grande parte de sua vida útil, “esses dois registros são a mesma entidade?” era uma pergunta de limpeza. Você a executava em lote, em um cronograma, em algum lugar dentro de um programa de gerenciamento de dados mestres, um armazém ou um pipeline de análise. Nunca foi perfeita, mas era tolerável, porque a saída era um relatório que alguém lia na semana seguinte. Se dois registros para o mesmo fornecedor não fossem mesclados, uma cifra de gastos saía ligeiramente errada, um analista notava e corrigia na próxima execução. O sistema tinha folga nele. O tempo absorvia os erros.

Um agente de IA remove essa folga. Ele muda o tempo da pergunta de “eventualmente” para “agora”. Quando um agente está prestes a aprovar um reembolso, encaminhar um caso, atualizar um perfil ou responder a uma pergunta de conformidade, a entidade resolvida não está mais alimentando um painel. Está alimentando uma ação. O custo de uma junção errada passa de um número ligeiramente errado para algo que acontece no mundo, imediatamente, e frequentemente sem um humano no loop para capturá-lo.

Essa é a mudança digna de consideração. O problema subjacente é antigo e bem compreendido. O que é novo é que o conectamos diretamente a sistemas que agem por conta própria.

Um problema de estatística dos anos 1960

A resolução de entidades não chegou com os grandes modelos de linguagem. Chegou com cartões perfurados. Em 1959, H. B. Newcombe e seus colegas publicaram um artigo curto na revista Science sobre a ligação automática de registros vitais, descrevendo como um computador poderia decidir se um registro de nascimento e um registro de casamento se referiam à mesma pessoa. Uma década depois, Ivan Fellegi e Alan Sunter deram à ideia uma teoria matemática formal, definindo os três resultados que qualquer sistema de correspondência ainda produz hoje: uma ligação, uma não ligação e uma ligação possível que uma pessoa precisa revisar.

Há um detalhe nessa linhagem digno de ser considerado, porque é a parte que as pessoas mais frequentemente erram. A ligação de registros nunca foi apenas correspondência exata em um endereço de e-mail ou um ID compartilhado. Desde o início, foi probabilística. Ela ponderou as evidências de que dois registros concordavam em um sobrenome, uma data, um local e produziu uma pontuação, porque os dados inseridos por humanos são desordenados e as chaves exatas falham constantemente. A resolução de entidades moderna ainda funciona dessa maneira. Ela combina regras determinísticas, onde um identificador estável compartilhado é decisivo, com correspondência probabilística e de aprendizado de máquina difusa que lida com erros de digitação, apelidos, campos transpostos, abreviações e as dezenas de pequenas maneiras pelas quais a mesma pessoa ou empresa aparece de forma ligeiramente diferente em sistemas. Um bom levantamento do campo traça uma linha ininterrupta daqueles registros vitais dos anos 1950 aos métodos de agrupamento e aprendizado de máquina usados agora.

O que realmente mudou é quando precisamos da resposta. Pesquisadores estavam escrevendo sobre resolver entidades no momento da consulta, em vez de apenas antecipadamente, muito antes da onda atual de IA. Naquela época, era uma otimização interessante. Agora é mais próxima de um requisito.

Por que os agentes a transformam em infraestrutura

A maioria dos sistemas de IA empresariais não responde a partir da memória do modelo. Eles recuperam. O padrão popularizado como geração aumentada por recuperação tem um agente buscar contexto relevante no momento da pergunta e raciocinar sobre ele. Isso é, em geral, uma boa coisa. Isso fundamenta as respostas em seus dados, em vez de no treinamento do modelo.

No entanto, isso traz uma consequência que é fácil de perder. O agente herda o que a etapa de recuperação lhe entrega. Se a recuperação devolver um cliente fragmentado, três registros parciais que nunca foram conectados, o agente raciocinará sobre três clientes. Se a recuperação devolver uma mesclagem errada, duas empresas diferentes colapsadas em um único perfil, o agente raciocinará sobre uma. A ambiguidade já sentada nos sistemas de origem é passada diretamente e apresentada ao modelo como fato estabelecido. O modelo não tem como saber que a junção estava errada, assim como você não saberia, lendo um resumo organizado de registros que nunca viu.

Portanto, a resolução não pode ser uma ideia secundária que é executada uma vez por quarto e aterrissa em uma tabela separada. A entidade precisa ser montada quando os dados são ingeridos, e a visão atual resolvida dela precisa ser recuperável no instante em que o agente pergunta. Isso é uma dependência de tempo de execução. Ela se comporta muito mais como um banco de dados ou um serviço de autenticação do que como um projeto de limpeza de dados periódico, e precisa ser projetada, monitorada e confiável do mesmo modo que você trataria qualquer outro sistema que sua aplicação chama em tempo real.

A lacuna de prontidão que ninguém está nomeando com precisão

A indústria já sente que algo está faltando aqui. O Índice de Prontidão para IA 2025 da Cisco encontrou que 83 por cento das organizações planejam implantar agentes autônomos, enquanto apenas cerca de um terço sente que sua infraestrutura está realmente pronta para eles, e apenas cerca de um quarto sente estar equipado para controlar e governar o que esses agentes realmente fazem. A pesquisa mais recente sobre o Estado da IA da McKinsey descreve uma lacuna semelhante a partir da outra direção: cerca de 88 por cento das organizações agora usam IA em pelo menos uma função, mas a maioria não a escalonou por toda a empresa.

Quando as pessoas explicam essa lacuna, elas tendem a recorrer a duas palavras: qualidade de dados e governança. Ambas importam, e nenhuma é opcional. Mas há uma pergunta mais estreita sentada abaixo delas que dados limpos e bem governados não respondem por si mesmos. O sistema pode dizer qual entidade do mundo real um determinado registro se refere, em todos os lugares onde esse registro vive, agora? Você pode manter dados de alta qualidade em cada sistema individual e ainda falhar nesse teste, porque a falha não vive dentro de nenhum sistema. Ela vive nos espaços entre eles, onde o mesmo cliente usa três faces ligeiramente diferentes.

O que verificar antes de deixar um agente agir

Se você trata a resolução de entidades como infraestrutura ao vivo, você pode inspecioná-la como infraestrutura. Os modos de falha operacional são específicos e testáveis: identidades divididas que deveriam ser uma, mesclagens falsas de registros que deveriam permanecer separados, regras de sobrevivência desatualizadas que continuam promovendo um endereço suplantado, identificadores persistentes ausentes e agentes herdam a ambiguidade do sistema de origem como se fosse uma verdade resolvida.

Um teste de prontidão prático não requer um novo modelo ou uma nova categoria de fornecedor. Monte um conjunto de entidades de verdade que você realmente entende. Execute-o pelo mesmo caminho de recuperação que seu agente usa, não uma cópia limpa separada construída para a demonstração. Em seguida, meça as coisas que realmente decidem os resultados: quantas mesclagens falsas e divisões falsas, como o sistema lida com ambiguidade genuína, onde seus limiares de confiança estão, quando ele escala para um humano em vez de adivinhar e como ele entrega limpo para os controles de dados mestres e governança existentes. Se uma equipe não puder responder a essas perguntas, o agente está agindo sobre uma identidade que não pode verificar, e a confiança em sua saída está mal colocada.

Nada disso substitui o gerenciamento de dados mestres, a governança, as plataformas de dados de clientes ou o armazém. Esses respondem a perguntas diferentes e permanecem necessários. A governança decide o que um agente é permitido fazer. A resolução de entidades decide a quem, ou o que, ele está fazendo. O primeiro é maduro na maioria das grandes organizações. O segundo é a camada que muitas estão prestes a descobrir que precisam ao lado dele, em tempo real, no momento em que deixam um agente agir em vez de aconselhar.

O agente que eu observei não precisava de um modelo mais inteligente. Ele precisava saber que dois nomes eram um cliente antes de ser permitido soar confiante. À medida que damos a esses sistemas autoridade real para agir, essa disciplina silenciosa de sessenta anos deixa de ser limpeza e começa a ser de carga.