O banco de dados da D&B de 642 milhões de empresas foi construído para humanos, não para agentes de IA. Então eles o reconstruíram.

A Dun & Bradstreet passou mais de 180 anos construindo um banco de dados comercial abrangente. Seu Gráfico Comercial, que abrange 642 milhões de negócios e seus relacionamentos, hierarquias corporativas e perfis de risco, foi pensado para pessoas. Analistas de crédito, gerentes de risco e profissionais de vendas que poderiam esperar pelos resultados das consultas e trabalhar em correspondências de entidades ambíguas. Os agentes de IA não podem fazer nenhuma dessas coisas.

Quando os clientes da D&B começaram a empurrar os agentes para fluxos de trabalho de crédito, compras e cadeia de suprimentos, o Gráfico Comercial, que atendia de forma confiável quase 200 mil clientes em todo o mundo, tornou-se um problema. Os sistemas construídos para servir analistas humanos eram a arquitetura errada para máquinas. Então a D&B reconstruiu.

“Precisamos pensar nos agentes como nossa nova categoria de consumidor, evoluindo de nossos analistas de crédito padrão ou profissionais de vendas e advertising and marketing, and so on., para agora também atender aos agentes desses clientes”, disse Gary Kotovets, diretor de dados e análise da Dun & Bradstreet, à VentureBeat.

O que quebrou quando os agentes começaram a consultar

O Gráfico Comercial não period um banco de dados único. Period uma coleção de sistemas separados criados para diferentes casos de uso e diferentes mercados, unidos por integrações personalizadas. Os analistas humanos navegaram nessa fragmentação por meio de consultas SQL ou interfaces pré-construídas. Os agentes não podiam.

A escala dos dados subjacentes agravou o problema. O banco de dados quase dobrou em cinco anos, passando de mais de 300 milhões para mais de 642 milhões de registros comerciais, com 11 mil campos por registro, segundo a D&B. A empresa realiza atualmente aproximadamente 100 bilhões de verificações de qualidade de dados por mês, à medida que os registros passam por seus sistemas. Consultar isso na latência inferior a um segundo exigida pelos agentes, em uma arquitetura fragmentada, não period viável.

Os relacionamentos rastreados pelo gráfico também eram do tipo errado. Os sistemas legados registravam conexões estáticas entre entidades. Um CEO estava vinculado a uma empresa. Essa period a linha. Os agentes que trabalham em avaliações de crédito ou risco de terceiros precisam de relacionamentos dinâmicos: quando aquele CEO sai para uma nova empresa, qual organização seu histórico segue? Quando uma subsidiária muda de propriedade, como isso se propaga na hierarquia corporativa? Essas questões exigiam trabalho de analista personalizado antes. Os agentes não podem esperar pelo trabalho personalizado do analista.

O problema mais amplo não é exclusivo da D&B. Kotovets disse que conversou com centenas de CDOs e CIOs nos últimos seis meses e ouviu consistentemente a mesma restrição: eles não podiam construir o que queriam em IA porque suas bases de dados não eram padronizadas, normalizadas ou consultáveis ​​pelos agentes. A D&B teve essa base, construída ao longo de décadas para servir aos analistas humanos. Ainda precisava ser reconstruído para os agentes.

O que eles realmente construíram

A reconstrução começou com a consolidação. A D&B migrou seus bancos de dados fragmentados para a infraestrutura em nuvem, redesenhou o esquema subjacente e construiu uma camada de estrutura de dados que normaliza os registros nos mercados, preservando os requisitos de conformidade regionais. O resultado é um gráfico de conhecimento unificado que rastreia bilhões de relacionamentos em 642 milhões de empresas, continuamente atualizado e enriquecido pelo processamento de dados orientado por IA.

Além desse gráfico, a D&B construiu uma camada de acesso estruturada para agentes. O acesso SQL bruto aos volumes de consulta do agente e aos requisitos de latência não period a resposta. Em vez disso, a D&B criou um conjunto de ferramentas e habilidades disponíveis por meio do MCP que empacota dados com contexto e encaminha os agentes aos registros certos para consultas específicas. Um mecanismo de correspondência e resolução de entidade está por trás de cada consulta, confirmando que quando um agente pergunta sobre uma empresa, a resposta é resolvida para uma entidade específica e verificada, em vez de uma correspondência de nome.

D&B resolveu a identidade do agente em ambas as direções

A reconstrução do gráfico e a adição de acesso MCP resolveram o problema de recuperação de dados. Não resolveu o problema de identidade. Os agentes não são humanos e o modelo de autenticação construído para usuários humanos não se estendeu às máquinas.

A D&B construiu um novo modelo de registro para agentes. Eles devem mapear para um endereço IP verificado e registrar uma chave de acesso particular person, tratada como uma identidade autenticada no mesmo pipeline que um usuário humano.

“Na verdade, temos um conceito de Conheça seu Agente, semelhante ao de Conheça seu cliente, que faz essas verificações adicionais”, disse Kotovets.

Isso resolve o problema de entrada: saber a qual empresa um agente pertence e quais dados ele tem o direito de consultar. Mas a D&B também foi desenvolvida para o problema de saída: o que acontece quando o fluxo de trabalho multiagente do próprio cliente perde o controle de qual empresa está analisando.

Em um fluxo de trabalho que encadeia um agente de verificação de crédito, um agente KYC e um agente de risco terceirizado, cada um consulta a D&B em uma etapa diferente. Sem um mecanismo para confirmar que todos fazem referência à mesma entidade, um fluxo de trabalho pode ser concluído enquanto opera em registros divergentes.

“Eles têm que voltar ao nosso agente de verificação para garantir que ainda estão conversando sobre a mesma entidade”, disse Kotovets. “É quase como um aperto de mão digital, em certo sentido.”

O agente de verificação comercial da D&B pode ser incorporado em qualquer fluxo de trabalho como um ponto de referência persistente e está disponível no protocolo A2A do Google, independentemente da ferramenta de orquestração usada pelo cliente.

Quatro coisas que as empresas devem acertar antes de implantar agentes de IA

A reconstrução expôs requisitos que vão além da própria pilha da D&B.

1. As bases de dados vêm antes da infraestrutura do agente. Os CDOs e CIOs com quem Kotovets conversou nos últimos seis meses atingiram consistentemente o mesmo muro: eles não podem construir o que desejam em IA até que seus dados estejam limpos, normalizados e consolidados. A D&B já tinha essa base. A maioria das empresas não o faz e sentirão isso.

2. Projete relacionamentos dinâmicos, não estáticos. Os sistemas de dados empresariais normalmente registram conexões pontuais: uma pessoa pertence a uma empresa, um ativo pertence a uma subsidiária. Os agentes que trabalham em decisões de crédito, risco ou cadeia de abastecimento precisam de raciocinar sobre relacionamentos que mudam ao longo do tempo. Se os dados subjacentes capturarem apenas a linha estática, o agente também o fará.

3. Crie verificações de consistência de entidade em fluxos de trabalho multiagentes. Quando vários agentes tocam a mesma entidade em etapas diferentes, não há garantia de que todos estejam fazendo referência ao mesmo registro no momento em que o fluxo de trabalho for concluído. Essa lacuna precisa ser projetada explicitamente. A verificação de entidade é um requisito de design de fluxo de trabalho, não uma proteção opcional.

4. Incorpore a linhagem desde o início, não como uma reflexão tardia. Cada resposta produzida por um agente deve levar um caminho rastreável de volta à sua origem. Nas decisões de crédito, risco e cadeia de abastecimento, o custo de um erro é concreto. A linhagem precisa ser incorporada antes do dimensionamento, e não adicionada após o surgimento dos problemas.

“Você sempre pode clicar e ver de onde veio e validar até a fonte unique”, disse Kotovets. “Essa tem sido a chave para desbloquearmos muitas outras capacidades, porque temos esse nível de certeza nas coisas que fizemos.”