Разбираемся с тем, как накрывающие друг друга волны хайпа в безбрежном океане ИИ влияют на наши профессиональные схемы работы по удостоверению персональных данных (ПД). Последняя волна так или иначе связана с ИИ агентами, но как выяснилось, не только. 

Представьте себе такую картинку. В эту минуту миллионы пользователей в онлайне совершают покупки в интернет магазинах или получают в том же онлайне услуги самых разнообразных сервис-провайдеров. При этом они постоянно передают свои персональные данные поставщикам услуг и товаров, которым необходимо верифицировать полученные ПД, чтобы отфильтровать попытки фрода и убедиться в благонадежности и платежеспособности клиента. Очень часто они для этого обращаются к нам, в компанию IDX, для удостоверения полученных данных. Покупателям товаров и потребителям услуг тоже желательно бы убедиться в надежности поставщика, особенно когда речь идет об операции “из рук в руки” (вторичный рынок товаров и услуги самозанятых и индивидуалов). До недавнего времени для этого можно было воспользоваться услугой многочисленных сервисов типа “Глаз бога”, но недавно, после очередного усиления ответственности за обработку ПД вплоть до уголовной, все эти сервисы прикрылись в одночасье.

Конечно, прежде, чем купить что-то у поставщика, которым раньше не пользовался, люди обычно читают рекомендации, сравнивают предложение с другими похожими, проводят некоторые изыскания в сети. Самые продвинутые могут даже спросить совета у ИИ-ассистента, но безоглядно доверять этому совету не будут, потому что знают, что лучшие друзья писателя, переводчика и кодировщика в житейских бытовых вопросах часто подвирают и галлюцинируют. Поэтому помощь ИИ пока не выделяется на общем фоне проверок надежности поставщика.

Теперь перемотаем время на конец 2025 года. По многим предсказаниям, о которых речь чуть позже, в распоряжении потребителей окажутся ИИ-агенты, которые в отличие от ИИ-ассистентов смогут автономно выполнять довольно сложные действия по поручению своих владельцев. Смотрите, как изменится картинка, в том числе для нас, кто отвечает за удостоверение ПД и подтверждение благонадежности потребителя. Теперь персональными данными распоряжается уже не владелец, а его порученец — ИИ-агент, который, предположительно, будет неглуп и расторопен. Он же будет формировать цифровой след своего хозяина, то есть, обогащать его персональные данные, только гораздо более интенсивно, поскольку не устает и не отвлекается.

На другой стороне, у поставщиков товаров и услуг происходит то же самое — уже сейчас предлагаются платформы для интеграции ИИ-агентов, которых можно будет встраивать в корпоративные воркфлоу. На стороне поставщиков эти ИИ-агенты должны, по замыслу, повысить качество клиентского сервиса и поддержки. Регулирование онлайн торговли и обслуживания с участием ИИ-агентов еще даже не начали обсуждать, поэтому предположим, что со стороны поставщиков товаров и услуг к нам начнут обращаться за удостоверением ПД уже не операторы через веб-интерфейс или алгоритмы через наш API, а автономные ИИ-агенты, которые могут делать и то, и другое уже сегодня.

Среди других многочисленных последствий, которые повлечет за собой использование ИИ-агентов, одним из важнейших мы видим новые угрозы и возможности для фрода. При таких ощущениях впору самим задуматься о применении ИИ для противодействия ИИ-фроду, придумать и реализовать прикладную архитектуру со встроенным ИИ-антифродом, который, конечно же, усилит качество борьбы и с ручным фродом тоже.

Таков посыл и направление наших размышлений.

Теперь об этом же немного подробнее и со ссылками на источники.

Вспышка интереса к ИИ-агентам во многом объясняется тем, что очередной прогноз развития ИИ, опубликованный группой известных авторов, весь структурирован в терминах ИИ агентов. В прогнозе все, что появится после GPT-4, называется Агент-0, Агент-1 и т.д. вплоть до Агента-3 в конце 2027 года. С подробностями можно познакомиться в хорошем переводе на русский здесь на Хабре. 

В реальной жизни ИИ агенты пока не очень-то отличились в полном соответствии с предсказаниями первой части манифеста AI2027.com — пока они довольно неуклюжие (stumbling). 23 января OpenAI представил свой ИИ-агент с неброским названием “Operator” в исследовательском режиме, то есть в режиме сбора данных от пользователей и дообучения модели по ним. Аналитики предсказывают светлое будущее в связи с появлением “Operator”, но когда оно наступит, пока не ясно. Выгоды от использования агента для пользователей связаны с обещанным умением агента работать с общими веб-интерфейсами сетевых сервисов и приложений, что, предположительно, избавляет от необходимости программирования  пользовательских клиентских сайтов с использованием API к серверным/сервисным сайтам. 

Anthropic еще в октябре 2024го подключил к моделям Claude 3.5 Sonnet, и Claude 3.5 Haiku новую функцию, которую они тоже непритязательно назвали computer use, имея в виду использование моделью компьютера в человеческой манере — разглядывание экрана, перемещение курсора, нажимание на кнопки и ввод текста. В перечне компаний, которые уже начали использовать эти новые возможности Anthropic указывает пять компаний, которые производят платформы для разработок ПО, вплоть до производства агентов, и одну компанию DoorDash, которая предоставляет услуги заказа и доставки еды на дом и занимает 56% рынка (20 миллионов клиентов, один миллион курьеров). Для нас этот пример чрезвычайно важен, что станет видно из дальнейшего.

Меня лично немного удивляют сообщения, что для “разглядывания экрана” нейронная сеть использует методы распознавания элементов пиксельной картинки. Казалось бы, код веб страницы, на которую таращится модель с помощью “computer use” или “Operator”, непосредственно доступен для любого кода, чего проще — разбирай его и выделяй элементы пользовательского интерфейса, текст, кнопки, поля для ввода и т.д. Однако же по этому пути почему-то не пошли, наверное для этого есть причина, которой я пока не вижу. Подскажите, если знаете.

Ну, и, конечно же, как только забрезжило светлое будущее (again!), так агентами начали называть все, что под руку попадет.

Тут же начали активно продвигать ранее известные решения в новой упаковке — платформы для создания ИИ-агентов. Внимательное рассмотрение этих решений показывает, что их подавляющее большинство как были средствами автоматизации воркфлоу, так и остались, просто появились возможности подключения в составе воркфлоу модулей, использующих интерфейсы с LLM и другими типами нейронных сетей для выполнения отдельных работ в составе воркфлоу.

Компания Anthropic мудро предупреждает нас, что следует различать собственно агентов и системы воркфлоу, которые они аккуратно называют агентными системами:

"Agent" can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows. At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents:

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

“Агентов” можно определять по-разному. Некоторые потребители определяют агентов как полностью автономные системы, которые действуют самостоятельно на протяжении длительного времени, используют разнообразные инструменты и выполняют сложные задачи. Другие же используют этот термин, чтобы описать более прескриптивные решения (prescriptive - основанные на последовательности предписывающих инструкций), которые следуют заранее определенным воркфлоу. Подобные разновидности мы характеризуем как “агентные системы”, но проводим важные архитектурные различия между воркфлоу и агентами.

Воркфлоу — это системы, в которых LLM и другие инструменты оркестрованы предопределенными веточками кода.

Агенты же - это системы, в которых LLM динамически управляют собственными процессами и применением инструментов, сохраняя контроль над тем, как они добиваются выполнения задач.

Мы учитываем это наставление в своей работе.

Кроме общечеловеческих волнений о том, что же будет, когда ИИ захватит власть над миром, нас больше всего интересует, что изменится во взаимодействии сервис-провайдеров вроде DoorDash и их пользователей после появления в схеме взаимодействия агентов с точки зрения достоверности персональных данных и новых угроз их безопасности, новых методов фрода.

Я здесь уже публиковал простые схемы, помогающие понять различия между нашими базовыми операциями — идентификации и аутентификации и их место в схеме авторизации.

А вот схема взаимодействия потребителей с сервис-провайдерами, дополненная возможным участием агентов.

В этой схеме доставки сервиса выделяем Personal Area Network потребителя (набор взаимосвязанных личных гаджетов), точки доступа сервиса (сайт, приложение, голосовой ассистент и т.д.), различаем каналы доступа и каналы поставки. Отдельно обращаем внимание на Service Tree, которое раньше называли Value Chain, а теперь это дерево более наглядно иллюстрирует, как из ресурсов (Р) и сервисов (С) третьих поставщиков сервис провайдер формирует сервис для своего клиента.

Все это составляет верхнюю цепочку. 

По типу агентности различаем агента потребителя, действующего от его имени, агента сервис провайдера, оптимизирующего конфигурацию сервиса и продвигающего upsale, и агента взаимодействия сервис- и ресурс-провайдеров между собой. Агент провайдера может взаимодействовать с агентом потребителя и с агентом межпровайдерского взаимодействия.

Теперь попытаемся перефокусировать эту схему относительно каждого из потенциальных агентов и посмотрим, какие новые мотивы будут возникать для обработки персональных данных.

Постановка задачи создания персонального агента для потребителя для нас выглядит следующим образом. В реальной жизни, прежде, чем обратиться к сервис-провайдеру за товаром или услугой, потребители сначала исследуют онлайн-рынок в поисках наилучших предложений, для этого они или запрашивают нужный товар услугу у нескольких известных им поставщиков, или обращаются к агрегаторам в поисках лучшего предложения, после чего уже отправляются на сайт выбранного поставщика товара/услуги и начинают процесс взаимодействия с ним. Кажется, что при наличии работающего ИИ-агента можно поручить этап поиска лучшего предложения ему. 

Основной процесс взаимодействия с выбранным поставщиком, в принципе, тоже достаточно формализован, но здесь есть много тонкостей, например, процесс предъявления персональных данных или использования учетной записи с этим конкретно поставщиком. Именно в этот момент многие клиенты компании IDX обращаются к нам, с ручным запросом или через API, чтобы удостоверить полученные от клиента персональные данные. В случае, если проверка не проходит, провайдер может запросить проведение дополнительных проверок, в том числе на предмет выявления возможного фрода. Здесь впору задуматься, какими особенностями будут отличаться методы выявления фрода в случае  использования потребителем ИИ-агентов.

Уже сегодня мы предлагаем нашим клиентам — поставщикам товаров и услуг — размещать на своих сайтах фрагменты кода, выявляющие возможных ботов и злоумышленников, в том числе и с помощью регистрации действий потенциального злоумышленника при навигации по сайту. Оказалось, что цифровые следы добросовестного потребителя и злоумышленника отличаются и могут быть выявлены алгоритмически. Предположительно, подключение к этой процедуре интерфейса с нейронной сетью позволит заметно повысить надежность такого обнаружения потенциальных угроз.

Назовем группу этих угроз при использовании потребителем ИИ-агента ИИ-фродом, а меры противодействия им — ИИ-антифродом.  Эксперты уже некоторое время обсуждают использование ИИ для реализации фрода, например, для генерации фейк-новостей, фейковых личностей и тому подобного. Эту группу мошеннических действий называют генеративным ИИ-фродом. В нашем случае мы хотим выделить в отдельную категорию операционный ИИ-фрод. Будем называть операционным ИИ-фродом все злонамеренные действия в процессе взаимодействия поставщиков и потребителей, спланированные и/или реализованные с помощью или посредством ИИ-агентов.

И как раз в тот момент, когда начинаешь обдумывать архитектуру среды предоставления онлайн-сервисов со встроенным операционным (ИИ)-антифродом, наконец понимаешь, что эта схема никуда не годится. Она совсем не помогает сделать следующий шаг и перейти от функционального описания к структурно-процедурному. Проблема в том, что в наше время ни один сервис-провайдер не строит свою корпоративную среду сам, с нуля. 

Последний пример, который я помню — это проект сервиса, известного как «госуслуги» в рамках национального проекта Электронной России. В проектах такого рода строительными блоками служили программные продукты вендоров, которые создавались в предыдущую эпоху модульно-монолитных архитектур. Создавались для другого и часто применялись не по делу.

Перед этим, все нулевые годы мы увлеченно проектировали OSS/BSS для больших и средних телеком-провайдеров. Постепенно выяснилось, что любой вендор, поставляющий компоненты OSS/BSS, стремился к полному интегрированному решению. Было практически все равно, с чего начинать — с биллинга, с CRM или с движка воркфлоу. Чтобы подвести избу под крышу, образно выражаясь, можно было начинать с любого угла. Результат должен был быть вендорно совместимым.

Потом пришли десятые годы, и доминирующей стала архитектурная концепция «облачных вычислений». Все быстро забыли про деление корпоративных систем на «интранет» и «экстранет» и радостно поскакали размещать все те же корпоративные системы на виртуальных машинах в первом промышленном облаке AWS. Довольно скоро выяснилось, что защищать облачные решения не проще, а сложнее, чем защищать периметр модульно-монолитных корпоративных систем. Тут же появился Cloud Security Alliance, публикации которого до сих пор читаются и обсуждаются, в том числе и здесь, на Хабре.

Когда облако пыли от беготни рассеялось (извините за каламбур), постепенно согласились, что одними мерам обеспечения безопасности инфраструктуры, пусть даже и облачной, не обойтись, потому что сложилась концепция «облачно совместимой архитектуры» (Cloud Native Computing) для систем и приложений. Мой друг Клод, когда я спросил его, можно ли считать, что cloud native архитектура и микро-сервисная архитектура — это уже синонимы, сердито ответил, что конечно нет, и привел в качестве альтернативы Event Driven Architecture. Я проверил текущее состояние разработок по EDA и обнаружил, что большая часть ссылок ведет в архивы, так что я остался при своем мнении.

Можно спокойно утверждать, что любая разработка приложений для работы в облаке будет иметь тот или иной вариант микро-сервисной архитектуры, в которой скрепляющей микро-сервисы тканью служит сервисный меш (сетка, более подходящий русский термин так и не придумали). Из вредности напомню, что этот виток эволюции повторяет основные концепции сервисно -ориентированной архитектуры (SOA) и «сервисной шины предприятия» (ESB), которые разрабатывались в дооблачные времена.

Концепция микро-сервисной архитектуры возлагает поддержку всех инфраструктурных сервисов (включая сервисы обеспечения безопасности) именно на сервисный меш. В числе этих инфраструктурных сервисов и те, которые особенно интересуют нас в компании IDX - сервисы аутентификации. Реализовать их можно по-разному, но тут подтянулись шифровальщики и важно заявили, что без криптопротоколов тут не обойтись, если мы хотим сделать кибербезопасность встроенной в распределенную архитектуру. Это позволит перенести защиту на уровень микросервисов. Ни один элемент системы или компонент приложения больше не может считаться подлинным и безопасным, пока не предъявит доказательства подлинности в каждой сессии коммуникации между компонентами (в том числе — микросервисами). И назвали такую конструкцию Zero Trust Architecture, в составе которой ключевую роль играют криптопротоколы группы Сигма, обеспечивающие Zero Knowledge Proof (ZKP). Тут мы все встрепенулись, потому что всего пару лет назад компания IDX уже участвовала в концепт-проекте «Платформы цифрового доверия для безопасного подтверждения персональных данных» (ПЦД ПД), реализованном в формате экспериментального образца. Так что благая весть о ZTA+ZKP упала на наши израненные заботой о светлом будущем сердца как бальзам на раны. Но об этом рассказ в следующей публикации о реализации ZTA+ZKP для удостоверения ПД.