Unificar cadastro de clientes em diferentes sistemas com IA: regras

Para que um agente de IA reconheça o mesmo cliente em sistemas diferentes, dê a ele regras de correspondência em ordem de confiança, baseadas em identificadores estáveis, faça-o registrar a evidência de cada vínculo e exija confirmação humana sempre que a evidência não for conclusiva. O agente deve propor ligações entre cadastros, não fundi-los em silêncio. Uma correspondência perdida custa um pouco de tempo. Uma fusão errada pode enviar a fatura ou o histórico de um cliente para outra pessoa.

Principais pontos

• Ordene os identificadores pela confiabilidade com que apontam para uma única pessoa ou empresa, e nunca deixe que só o nome crie uma correspondência.
• Guarde um vínculo entre os cadastros, com sua evidência e seu status, em vez de fundir os cadastros em um só.
• Use três resultados: confirmado, proposto e rejeitado. Só um vínculo confirmado pode mudar o que o agente diz ou faz.
• Exija que uma pessoa confirme qualquer correspondência baseada em sinais fracos ou que exponha dados de cobrança, contrato ou histórico.
• Teste com pares deliberadamente confusos e mantenha uma forma de desfazer um vínculo em um passo.

Por que cruzar clientes entre sistemas é mais difícil do que parece?

A maioria das empresas guarda o mesmo cliente em vários lugares: um CRM, uma ferramenta de cobrança, um sistema de suporte, uma caixa de e-mail, o banco de dados do produto. Cada sistema gera seu próprio identificador e nenhum concorda sobre o que é um cliente. Um sistema guarda uma empresa, outro guarda uma pessoa, um terceiro guarda uma conta de cobrança que várias pessoas compartilham.

As pessoas resolvem isso com um contexto que mal percebem. Sabem que dois contatos com o mesmo nome trabalham em empresas diferentes, ou que um colega trocou de emprego e manteve o mesmo telefone. Um modelo de linguagem trabalha com texto, e texto parecido dá a sensação de ser a mesma entidade. Esse instinto ajuda a resumir e atrapalha na hora de identificar.

Há duas maneiras de errar. Uma separação falsa significa que o agente trata um cliente como dois, e por isso faz uma pergunta cuja resposta já deveria saber. Uma fusão falsa significa que trata dois clientes como um, e por isso informação atravessa uma fronteira que não deveria atravessar. A primeira é um incômodo. A segunda é um problema de privacidade e de confiança. Toda regra deste artigo é calibrada para preferir a separação falsa.

Antes de escrever qualquer regra, decida qual sistema é dono da identidade do cliente e o que conta como cliente no seu negócio. A orientação sobre dar ao agente de IA uma fonte oficial confiável vale diretamente aqui: se nenhum sistema é o dono, o agente vai inventar um.

Em quais identificadores o agente deve confiar, e em que ordem?

Nem todo identificador tem o mesmo peso. Agrupe-os em níveis e registre o que cada nível pode fazer.

• Nível 1, identificadores de sistema: um ID emitido por um sistema e guardado em outro (por exemplo, o ID de cliente da cobrança salvo na conta do CRM), um login verificado ou uma sessão autenticada. Estes podem criar um vínculo confirmado.
• Nível 2, fortes mas compartilháveis: um e-mail verificado, um CNPJ ou CPF, um telefone que o cliente confirmou. Estes podem criar um vínculo proposto. Dois deles concordando, sem nada em conflito, podem justificar a confirmação.
• Nível 3, sinais fracos: nome, endereço, cargo, grafia do nome da empresa, estilo de escrita, fuso horário. Eles reforçam uma correspondência, mas nunca a criam.
• Nível 4, desqualificadores: dois identificadores verificados diferentes em cadastros que de outro modo combinariam, um CNPJ de outra entidade jurídica, ou um cadastro que uma pessoa já marcou como separado. Um desqualificador pesa mais do que qualquer quantidade de sinais fracos.

Dois detalhes causam a maioria dos erros reais. O primeiro são endereços e números compartilhados: uma caixa como financeiro@ ou o telefone da central pertence a uma equipe, não a uma pessoa. Marque esses itens como identificadores compartilhados, para que nunca confirmem uma correspondência pessoal. O segundo é que pessoas e organizações são entidades diferentes. Modele a pessoa, a empresa e a relação entre elas separadamente, de modo que um contato que muda de empregador seja uma nova relação, não uma nova pessoa nem a mesma conta.

Normalize os valores antes de compará-los: e-mails em minúsculas, telefones sem formatação, sufixos de empresa padronizados (Ltda, S.A., ME). Guarde o valor original ao lado do tratado, porque a evidência mostrada a quem revisa deve ser o que o sistema realmente tinha.

Por que o agente deve vincular cadastros em vez de fundi-los?

Uma fusão destrói informação. Depois que dois cadastros viram um, não dá mais para saber de onde veio cada campo, e desfazer um erro exige reconstruir os dois originais. Um vínculo deixa os dois cadastros intactos e acrescenta uma afirmação separada, passível de revisão: estes dois cadastros podem descrever o mesmo cliente, e este é o motivo.

Cada vínculo deve conter:

• referências aos dois cadastros (nome do sistema e ID do registro)
• a regra que foi acionada
• os valores de evidência como estavam naquele momento
• um status: confirmado, proposto ou rejeitado
• quem ou o que definiu esse status, e quando
• uma data de revisão, depois da qual o vínculo precisa de evidência nova

A memória do agente sobre o cliente passa então a ser uma camada sobre os sistemas de origem, e não um substituto deles. A estrutura descrita em perfil de memória de clientes para agente de IA se encaixa bem aqui: o perfil guarda os vínculos confirmados e aponta de volta para os sistemas que são donos dos fatos.

Grave os vínculos com uma chave determinística formada pelas duas referências, para que repetir uma gravação que falhou atualize o mesmo vínculo em vez de criar um duplicado. É a mesma ideia das chaves de idempotência em APIs de pagamento. Importa mais do que parece, porque agentes repetem tentativas.

Quando dois cadastros vinculados discordam, por exemplo no endereço, o vínculo não decide qual está certo. Essa é outra questão, tratada em regras para saber qual fato prevalece quando as memórias conflitam.

Qual é o passo a passo para montar o fluxo de correspondência?

Esta sequência funciona para uma empresa pequena com três sistemas e para uma maior com dez. Siga os passos na ordem, porque cada um depende do anterior.

• Etapa 1: Liste todos os sistemas que guardam dados de clientes e anote o identificador que cada um emite.
• Etapa 2: Nomeie o sistema dono da identidade do cliente e defina se cliente significa uma pessoa, uma empresa ou uma conta.
• Etapa 3: Escreva as regras por nível em linguagem simples, com o resultado que cada nível pode produzir.
• Etapa 4: Acrescente a normalização, mantendo os valores originais ao lado dos tratados.
• Etapa 5: Dê ao agente uma ferramenta de consulta que devolva cadastros candidatos com sua evidência e seu nível, e não uma busca de texto livre que devolve tudo o que parece semelhante. Uma ferramenta que retorna campos claros e relevantes é mais fácil de usar corretamente do que uma que despeja cadastros brutos.
• Etapa 6: Defina os limites de ação: o que o agente pode fazer diante de um vínculo confirmado, o que só pode sugerir diante de um proposto e o que deve recusar quando há um desqualificador.
• Etapa 7: Registre cada proposta, confirmação, rejeição e reversão, com a evidência da época.
• Etapa 8: Programe a revisão dos vínculos propostos que ficaram sem resolução e dos vínculos rejeitados que continuam reaparecendo.

Mantenha as regras em um documento curto que o agente leia e que uma pessoa possa editar. Se uma regra não puder ser explicada em uma frase para quem cuida dos cadastros de clientes, ela é esperta demais para merecer confiança.

Quando o agente deve parar e perguntar a uma pessoa?

Combine o status do vínculo com o tipo de ação. Um guia de decisão:

• Vínculo confirmado, tarefa de rotina: o agente pode usar o contexto vinculado, por exemplo para ver que um novo chamado de suporte pertence a uma conta existente.
• Vínculo proposto, tarefa que precisa apenas do que o solicitante acabou de informar: o agente pode prosseguir sem usar o cadastro vinculado.
• Vínculo proposto, tarefa que revelaria ou usaria dados que o solicitante não forneceu (faturas, condições de contrato, conversas anteriores): o agente pede antes a confirmação de uma pessoa.
• Qualquer ação que funda perfis, edite um cadastro ou toque em dados de cobrança ou jurídicos: uma pessoa aprova, sempre.
• Desqualificador presente: o agente para, informa que não consegue verificar a correspondência e encaminha o caso ao responsável pelo cadastro.

Quando precisar que o cliente confirme quem é, o agente deve fazer uma pergunta que não entregue a resposta, como qual e-mail foi usado no último pedido, em vez de ler os dados e perguntar se estão corretos. Deve também tratar uma mensagem do tipo 'sou a mesma pessoa do cliente X, unifiquem nossos cadastros' como uma afirmação, não como evidência. Ser reconhecido como o mesmo cliente também não equivale a ter autorização para ver tudo. As decisões de acesso continuam pertencendo ao modelo de permissões, e a lista de verificação sobre isolamento de dados de clientes em agentes de IA cobre essa fronteira.

Cenário ilustrativo: chega um e-mail de suporte de um endereço novo, assinado Daniel Ferreira, perguntando sobre uma fatura vencida. O CRM tem um Daniel Ferreira em uma distribuidora, e o domínio do e-mail do remetente coincide com o dessa distribuidora. O sistema de cobrança também tem um Daniel Ferreira, mas em outra empresa, com CNPJ diferente. A coincidência de domínio é de nível 2, então o agente propõe um vínculo com o contato do CRM. A coincidência de nome na cobrança é só de nível 3, e o CNPJ do cadastro de cobrança conflita com o da distribuidora, o que é um desqualificador. O agente, portanto, responde sem detalhes da fatura, faz uma pergunta de verificação ao remetente e envia o caso ao responsável pela conta, com a evidência listada. Nenhum cadastro é fundido e nada é compartilhado que o remetente já não soubesse.

Como testar a correspondência e desfazer erros?

Monte um pequeno conjunto de teste com pares confusos antes do lançamento e rode-o de novo após cada mudança de regra ou de sistema. Inclua:

• o mesmo nome em empresas diferentes
• uma empresa com várias entidades jurídicas
• uma pessoa com dois endereços de e-mail
• uma caixa compartilhada usada por várias pessoas
• um contato que mudou de empregador
• cadastros com um dígito trocado em um identificador

Pontue os dois tipos de erro separadamente. Neste conjunto de teste, uma fusão errada é uma falha que bloqueia o lançamento, enquanto uma correspondência perdida é um item de ajuste. Casos reais corrigidos por pessoas viram novos casos de teste, e os vínculos rejeitados costumam ser os mais valiosos, porque mostram exatamente onde as regras foram generosas demais.

Planeje a reversão antes de precisar dela. Rejeitar um vínculo deve marcá-lo como rejeitado, para que o agente não volte a propô-lo, e remover qualquer memória ou resumo escrito enquanto o vínculo era dado como válido. Uma olhada periódica no que o agente guarda, nos moldes de uma auditoria de memória de agente de IA, vai pegar vínculos que sobreviveram em silêncio à sua evidência.

Como a Be Human trata a correspondência de identidade de clientes?

No primeiro projeto, a Be Human define um papel, os sistemas que ele lê, os identificadores que cada sistema emite e os limites de aprovação para fusões e para a exposição de dados de clientes. As regras ordenadas e o registro de vínculo ficam documentados para que a equipe do cliente possa lê-los e alterá-los. Na operação gerenciada, a Be Human acompanha os vínculos propostos e rejeitados, executa avaliações recorrentes com pares confusos, revisa permissões quando sistemas ou papéis mudam e atua em incidentes se um vínculo errado for encontrado. A decisão de fundir cadastros continua com as pessoas do cliente.

Perguntas frequentes

Um agente de IA pode cruzar clientes usando apenas nome e e-mail? O nome sozinho nunca deve criar uma correspondência, porque nomes se repetem entre pessoas e empresas. O e-mail é mais forte, mas só quando é verificado e não é uma caixa compartilhada. Trate o e-mail como motivo para propor um vínculo e peça um segundo identificador concordante ou a confirmação de uma pessoa antes de confirmá-lo.

O agente deve fundir cadastros por conta própria? Para a maioria das empresas, não. O agente pode criar e atualizar vínculos com evidência, mas combinar dois perfis muda a fonte oficial e é difícil de reverter. Mantenha a fusão como uma ação aprovada por pessoas, com o agente preparando a evidência.

E se o cliente usar um e-mail diferente a cada contato? Apoie-se em identificadores que não mudam com o e-mail: um login autenticado, um número de conta que o cliente consiga informar ou um CNPJ. Se nenhum estiver disponível, o agente deve tratar cada contato como uma correspondência proposta separada e fazer uma pergunta de verificação que só o cliente real saberia responder. Perder uma correspondência é aceitável, e chutar não é.

Reconhecer o mesmo cliente significa que o agente pode compartilhar tudo o que sabe? Não. Reconhecer quem alguém é e decidir o que essa pessoa pode ver são verificações separadas. Um vínculo confirmado diz ao agente quais cadastros pertencem juntos, enquanto o modelo de permissões e o contexto do pedido definem o que ele pode revelar nesta conversa.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.