Раньше кредитные аналитики, риск-менеджеры и специалисты по продажам могли позволить себе подождать результаты запросов и разобраться в неоднозначных сопоставлениях. Но AI-агенты так не умеют. Когда клиенты D&B начали внедрять агентов в процессы кредитования, закупок и управления цепочками поставок, Commercial Graph, который обслуживал почти 200 000 клиентов по всему миру, превратился в проблему.
"Нам нужно думать об агентах как о новой категории потребителей, переходя от наших стандартных кредитных аналитиков или специалистов по продажам и маркетингу и т. д., к обслуживанию агентов этих клиентов", - заявил Гари Котовец, директор по данным и аналитике Dun & Bradstreet, в интервью VentureBeat.
Что сломалось, когда агенты начали делать запросы?
Commercial Graph не был единой базой данных. Это была коллекция отдельных систем, созданных для разных случаев использования и разных рынков, связанных между собой пользовательскими интеграциями. Люди могли ориентироваться в этой фрагментации с помощью SQL-запросов или готовых интерфейсов. Агенты – нет.
Масштаб данных усугубил проблему. За последние пять лет база данных увеличилась почти вдвое, с более чем 300 миллионов до более чем 642 миллионов бизнес-записей, причем каждая запись содержит 11 000 полей, по данным D&B. Теперь компания ежемесячно выполняет примерно 100 миллиардов проверок качества данных по мере перемещения записей по ее системам. Запрашивать эти данные с субсекундной задержкой, необходимой агентам, в рамках фрагментированной архитектуры было невозможно.
Отношения, которые отслеживал граф, тоже оказались не тем типом. Устаревшие системы записывали статические связи между сущностями. Генеральный директор был связан с компанией. И всё. Агентам, работающим над оценками кредитоспособности или рисками третьих сторон, нужны динамические отношения: когда этот генеральный директор уходит в новую компанию, за какой организацией следует его послужной список? Когда дочерняя компания меняет владельца, как это распространяется по корпоративной иерархии? Раньше эти вопросы требовали работы аналитиков. Агенты не могут ждать аналитиков.
Более широкая проблема не уникальна для D&B. Котовец сказал, что за последние шесть месяцев он разговаривал с сотнями CDO и CIO и постоянно слышал одно и то же ограничение: они не могли построить то, что хотели в AI, потому что их основы данных не были стандартизированы, нормализованы или доступны для запросов агентов. У D&B была эта основа, созданная за десятилетия для обслуживания аналитиков. И все равно пришлось перестраивать для агентов.
Что они построили на самом деле?
Перестройка началась с консолидации. D&B перенесла свои разрозненные базы данных в облачную инфраструктуру, переработала базовую схему и построила уровень фабрики данных, который нормализует записи на разных рынках, сохраняя при этом региональные требования соответствия. Результатом является унифицированный граф знаний, который отслеживает миллиарды связей между 642 миллионами компаний, постоянно обновляемый и обогащаемый обработкой данных на основе AI.
Поверх этого графа D&B построила структурированный уровень доступа для агентов. Непосредственный доступ к необработанным SQL-запросам при объемах и задержках, требуемых агентам, не был решением. Вместо этого D&B создала набор инструментов и навыков, доступных через MCP, которые упаковывают данные с контекстом и направляют агентов к нужным записям для конкретных запросов. Механизм сопоставления и разрешения сущностей находится за каждым запросом, подтверждая, что когда агент запрашивает компанию, ответ разрешается в проверенную, конкретную сущность, а не в совпадение имен.
D&B решила проблему идентификации агентов с обеих сторон. Перестройка графа и добавление доступа MCP решили проблему извлечения данных. Но не решили проблему идентификации. Агенты – не люди, и модель аутентификации, созданная для людей, не распространяется на машины.
D&B построила новую модель регистрации для агентов. Они должны сопоставляться с проверенным IP-адресом и регистрировать индивидуальный ключ доступа, который рассматривается как аутентифицированная личность в том же конвейере, что и человек.
"У нас фактически есть концепция Know Your Agent, аналогичная Know Your Customer, которая выполняет эти дополнительные проверки", - сказал Котовец.
Это решает входящую проблему: знать, какой компании принадлежит агент и какие данные ему разрешено запрашивать. Но D&B также построила решение для исходящей проблемы: что происходит, когда собственный многоагентный рабочий процесс клиента теряет представление о том, какую компанию он анализирует.
В рабочем процессе, который объединяет агента проверки кредитоспособности, агента KYC и агента оценки рисков третьих сторон, каждый из них запрашивает D&B на разных этапах. Без механизма подтверждения того, что все они ссылаются на одну и ту же сущность, рабочий процесс может завершиться, работая с расходящимися записями.
"Они должны вернуться к нашему агенту проверки, чтобы убедиться, что они все еще говорят друг с другом об одной и той же сущности", - сказал Котовец. "Это почти как цифровое рукопожатие, в некотором смысле".
Агент проверки бизнеса D&B может быть встроен в любой рабочий процесс в качестве постоянной точки отсчета и доступен по протоколу A2A Google независимо от того, какой инструмент оркестровки использует клиент.
Четыре вещи, которые предприятия должны сделать правильно, прежде чем развертывать AI-агентов
Перестройка выявила требования, выходящие за рамки собственного стека D&B.
Основы данных предшествуют инфраструктуре агентов. CDO и CIO, с которыми Котовец разговаривал за последние шесть месяцев, постоянно сталкивались с одной и той же проблемой: они не могут построить то, что хотят в AI, пока их данные не будут чистыми, нормализованными и консолидированными. У D&B эта основа уже была. У большинства предприятий ее нет, и они это почувствуют.
Проектируйте динамические отношения, а не статические. Корпоративные системы данных обычно записывают связи на определенный момент времени: человек принадлежит компании, актив принадлежит дочерней компании. Агентам, работающим над принятием решений о кредитах, рисках или цепочках поставок, необходимо рассуждать о взаимосвязях, которые меняются со временем. Если базовые данные фиксируют только статическую линию, агент тоже будет это делать.
Встройте проверки согласованности сущностей в многоагентные рабочие процессы. Когда несколько агентов касаются одной и той же сущности на разных этапах, нет никакой гарантии, что все они ссылаются на одну и ту же запись к моменту завершения рабочего процесса. Этот пробел необходимо спроектировать явно. Проверка сущностей – это требование к дизайну рабочего процесса, а не дополнительная защита.
Встройте происхождение с самого начала, а не как запоздалую мысль. Каждый ответ, полученный агентом, должен иметь отслеживаемый путь обратно к его источнику. В кредитной, рисковой и цепочке поставок...