LLM в KYC и AML: где они помогают, а где опасны команде

Где помощь заканчивается и начинается решение

Граница проходит не по слову "AI" и не по тому, насколько красиво модель пишет. Она проходит там, где текст начинает менять судьбу клиента, сделки или внутреннего расследования без ясной проверки человеком.

В KYC и AML команде нужен не просто удобный текст. Нужен вывод, который можно объяснить: на каких данных он основан, чего в данных не хватает, кто его утвердил и почему. LLM умеет собрать разрозненные факты в понятную сводку, но сама сводка еще не равна решению.

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

Проблема в том, что модель часто пишет уверенно даже тогда, когда ей не хватает данных. Для читателя это выглядит как готовый вывод. Для комплаенса это опасная иллюзия. Если в досье нет части документов, LLM не всегда скажет: "данных мало". Иногда она просто достроит картину самым правдоподобным способом.

Решение начинается в тот момент, когда ответ модели сам двигает процесс дальше. Например, система ставит клиенту риск-класс, отправляет кейс в отказ, замораживает операцию или закрывает алерт без ручного разбора. Тут цена ошибки уже другая. Ошибка в сводке раздражает команду и отнимает 20 минут. Ошибка в отказе бьет по клиенту, по бизнесу и по проверке регулятора.

Переход от помощи к автовердикту часто случается почти незаметно. Вчера промпт просил: "сделай краткое резюме по кейсу". Сегодня в него добавили одну строку: "укажи итоговый риск и рекомендуемое действие". Завтра этот ответ попал в правило, которое без человека переводит заявку в отказ. Формально это все тот же prompt. По смыслу это уже автоматическое решение AML.

Нормальная граница выглядит так: LLM готовит материал для сотрудника, а сотрудник принимает и фиксирует решение сам. Если команда хочет использовать LLM в KYC и AML без лишнего риска, ей стоит отдельно запретить модели финальный вердикт и закрепить этот запрет не в презентации, а в процессе, интерфейсе и правилах системы.

Где LLM реально помогают без лишнего риска

LLM приносят пользу там, где они сокращают ручное чтение и помогают аналитику быстрее увидеть картину. Модель читает много, но не принимает решение. Для KYC и AML это самый спокойный режим работы.

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

Хорошо работает и поиск несоответствий. LLM может вынести в отдельный блок расхождения в ФИО, адресе, датах, реквизитах и формулировках в разных документах. Такие сигналы полезны, потому что модель не говорит "это нарушение", а показывает, что именно стоит перепроверить руками.

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

LLM удобно использовать и для работы по шаблону. Например, комплаенс-команда задает структуру: "факт", "источник", "почему требует проверки", "что запросить". Модель раскладывает причины риска по этой форме. За счет этого заметки разных сотрудников становятся ровнее, и их легче читать на ревью.

Полезен и обратный режим: сжать длинное обоснование в короткий черновик для аналитика или руководителя. Если сотрудник написал полторы страницы текста, модель может сократить их до 5-7 предложений без потери смысла. Это удобно для внутреннего согласования.

В безопасном режиме задачи обычно простые: сделать сводку по документам и переписке, отметить расхождения между источниками, предложить вопросы для дозапроса, разложить аргументы по заданной форме или сократить длинный текст в черновик вывода.

Если команде важны 152-ФЗ и журнал действий, такой слой удобнее запускать через инфраструктуру, где запросы, логи и маскирование PII контролируются внутри РФ. Для вспомогательного анализа это часто снимает часть операционного риска, но проверку и финальный вывод все равно оставляет за человеком.

Где риск уже слишком высокий

Самая опасная граница проходит там, где модель перестает помогать сотруднику и начинает решать за него. В KYC и AML это быстро превращается в проблему: ошибка уже влияет на допуск клиента, блокировку операции или финальный вывод по делу.

Если LLM сама одобряет или отклоняет клиента, а человек лишь формально нажимает кнопку, контроля уже нет. У модели нет ответственности, а у команды потом нет ясного ответа, почему система решила именно так. Для комплаенса этого недостаточно.

Плохо и другое: когда модель ставит итоговый балл риска без понятных правил, порогов и проверки на стабильность. Сегодня один и тот же профиль она может назвать умеренным риском, завтра - высоким. Такой разброс трудно объяснить аудитору, службе внутреннего контроля и самому бизнесу.

Что лучше не отдавать модели

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

Еще хуже, когда свободный текст подменяет санкционные и PEP-проверки. Модель может кратко пересказать профиль клиента, но она не заменяет формальные списки, правила сопоставления, даты, алиасы и логику совпадений. Если команда убирает детерминированную проверку и оставляет только текстовый ответ, она теряет воспроизводимость.

Опасный сценарий обычно выглядит очень удобно: аналитик загружает досье, получает от модели чистый вывод и видит в нем уже готовое решение. В этот момент помощь закончилась. Дальше начинается автоматический вердикт, который трудно проверить и еще труднее защитить на аудите.

Как встроить LLM в процесс по шагам

Самый разумный старт для LLM в KYC и AML - дать модели не право решать, а узкую рутину. Подойдет этап, где сотрудник и так тратит время на черновик: краткое резюме анкеты, сводка по негативным упоминаниям, нормализация полей из документов, список вопросов для ручной проверки.

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

Сначала ограничьте задачу

Опишите один сценарий очень узко. Не "проверка клиента", а, например, "собрать из анкеты и внешних источников черновую сводку на 8 пунктов". Чем уже рамка, тем проще понять, где модель ошибается.

Сразу закрепите вход и выход. Модели не стоит давать свободный текст без формы. Лучше задать фиксированные поля, допустимые значения и порядок ответа. Например, отдельные поля для ФИО, страны, типа риска, найденных совпадений и списка сомнений. Так легче проверять результат и строить журнал действий.

Потом добавьте человеческое решение

У модели должен быть прямой запрет на финальный вердикт. Она не пишет "одобрить", "отклонить" или "эскалировать" как решение. Она может предложить черновые признаки риска, но выбор делает сотрудник.

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

Этот шаг нельзя делать формальным. Аналитик должен видеть не только ответ, но и то, на чем он основан: какие поля подали в запрос, какие фрагменты текста модель использовала, где она сомневалась.

Для комплаенса этого мало без нормального лога. Сохраняйте промпт, ответ, версию модели, время вызова и правки сотрудника. Если команда работает в российском контексте, стоит сразу проверить, где хранятся логи и бэкапы, как маскируются персональные данные и можно ли потом восстановить ход проверки по каждому кейсу. У RU LLM такой аудит-трейл, хранение логов в РФ и маскирование PII уже есть на уровне шлюза, поэтому этот слой не приходится собирать отдельно из нескольких сервисов.

Хороший признак зрелого процесса простой: модель экономит аналитику 10-20 минут на кейс, но ни разу не получает право закрыть кейс сама.

Как это выглядит на простом кейсе

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

Модель читает три документа и собирает черновую сводку на одной странице. Она вытаскивает название юрлица, ИНН, адрес, директора, виды деятельности и даты регистрации. Заодно она помечает пробелы. Например, в анкете есть контактное лицо, но нет ясного описания источника средств, а в выписке директор менялся два раза за год.

Аналитик не получает готовый вердикт вроде "низкий риск" или "отказать". Он получает короткий рабочий результат: что модель нашла без споров, где данные не сходятся и что стоит дозапросить у клиента.

Дальше сотрудник видит три точных вопроса для дозапроса. Например: кто конечный бенефициар с долей выше порога банка, почему директор менялся дважды за 12 месяцев, чем подтверждается источник средств по первой крупной операции. Это и есть нормальный вспомогательный анализ: модель убирает рутину, а человек проверяет смысл.

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

В дело попадают оба слоя. Первый - черновик модели с отметками, какие поля она заполнила и какие места посчитала сомнительными. Второй - финальное решение аналитика с причиной: что он принял, что отклонил и почему поставил именно такой уровень риска. Если команда ведет такой поток через RU LLM, она может использовать один OpenAI-совместимый эндпоинт и хранить журналы внутри РФ, что упрощает контроль и работу с 152-ФЗ.

Какие ошибки команды делают чаще всего

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

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

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

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

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

Самая опасная ошибка - считать высокий балл модели достаточным обоснованием. Балл помогает сортировать поток, но сам по себе ничего не доказывает. Он не объясняет, почему система сочла кейс рискованным и кто проверил спорные признаки. В таких проектах сдвиг происходит почти незаметно: вспомогательный анализ превращается в автоматическое решение, хотя команда думала, что просто ускоряет ручную проверку.

Как работать с данными и журналом действий

Проблема часто начинается не с ответа модели, а раньше. Аналитик отправляет в LLM весь пакет клиента, хотя для задачи нужны только 2-3 поля и короткий фрагмент документа. Для KYC и AML это плохая привычка: чем больше персональных данных уходит в запрос, тем выше цена ошибки.

Сначала убирайте все лишнее. Если модель ищет противоречия в анкете, ей не нужны полный номер паспорта, адрес до квартиры и весь банковский профиль. Оставьте только то, что влияет на вывод, а остальное замаскируйте: ФИО, номера документов, счета, телефоны, e-mail, точные даты рождения.

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

Журнал действий нужен не для галочки. Он помогает понять, почему система подняла флаг и кто потом изменил решение. Если в логе лежит только текст ответа модели, он почти бесполезен.

Обычно в журнал включают маскированную копию запроса и ответа, версию промпта или шаблона проверки, модель, провайдера, время запуска и сотрудника или сервис, который отправил запрос. Туда же стоит добавлять причину флага: цитату из документа, правило, порог или найденное несоответствие, а также историю правок - кто изменил пометку, комментарий или итоговый статус.

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

Отдельно проверьте, где лежат логи, бэкапы и аудит-трейлы. Для компаний под 152-ФЗ это не мелочь. Иногда пилот выглядит аккуратно, а потом выясняется, что провайдер хранит служебные журналы вне РФ. Если команда работает через шлюз вроде RU LLM, это стоит проверить заранее: где хранятся логи и бэкапы, как маскируются ПДн и можно ли поднять аудит по каждому запросу.

Хорошее правило простое: модель помогает читать и сортировать, а журнал фиксирует, что именно она увидела, что предложила и что решил человек. Такая схема заметно снижает риск споров с внутренним контролем и регулятором.

Короткий список проверок перед запуском

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

Во-первых, LLM не должна закрывать кейс сама. Она может сделать сводку, отметить странные связи и подсказать, что проверить, но отказ клиенту, блокировку или перевод в high-risk утверждает сотрудник.

Во-вторых, аналитик должен видеть рядом с ответом исходные данные: анкету, документы, историю операций и примененные правила. Если человек смотрит только на текст модели, он быстро начинает верить формулировке больше, чем фактам.

В-третьих, когда данных не хватает, система должна писать это прямо. Фразы вроде "не хватает страны регистрации" или "нет источника средств" полезнее, чем уверенный вывод на пустом месте.

Еще до запуска команда должна отдельно считать ложные срабатывания и пропуски. Один общий процент точности в комплаенсе почти бесполезен: он скрывает, где модель шумит, а где она опасно молчит. И, конечно, весь ход проверки должен оставаться в журнале действий: какой был запрос, какая версия модели и промпта, что увидел сотрудник, что он подтвердил или отклонил.

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

Хороший тест простой: новый сотрудник открывает сложный кейс и за несколько минут понимает, почему система дала именно такой совет и чего ей не хватило. Если это нельзя сделать, запуск пока рано переводить из черновика в рабочий процесс.

С чего начать команде

Стартовать лучше с узкого сценария, где модель помогает человеку, а не решает за него. Обычно это сводка досье по клиенту, выжимка из документов или черновик вопросов для ручной проверки. Такой пилот быстро показывает пользу: аналитик тратит меньше времени на рутину, а финальное решение по KYC или AML все еще принимает человек.

Для первого запуска хватит одного процесса и понятной метрики. Чаще всего проекты проваливаются не на качестве текста, а на размытых ожиданиях. Если команда не может сказать, что именно должна делать модель и где ее ответ заканчивается, пилот почти всегда уходит в споры вместо цифр.

Хорошая отправная точка выглядит так: взять 50-100 реальных кейсов из архива, прогнать их через текущий ручной процесс и через модель, сравнить, что она пропустила, где придумала лишнее и сколько времени сэкономила, а потом зафиксировать, какие действия человек обязан проверить сам.

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

Вопрос с данными лучше решить до пилота, а не после него. Нужно заранее понять, какие поля можно отправлять в модель, что надо маскировать, где будут храниться логи, бэкапы и журнал действий, и кто получит к ним доступ. Для команд, которые работают с ПДн, это обычно означает хранение внутри РФ и понятный аудит по каждому запросу с учетом 152-ФЗ.

Если команда не хочет собирать этот слой сама, можно использовать единый API-шлюз. В этом месте RU LLM выглядит уместно: совместимый эндпоинт позволяет не менять SDK, код и промпты, а логи, биллинг и поддержка остаются внутри РФ. Это удобно, когда нужно быстро проверить сам сценарий, а не тратить первые недели на склейку провайдеров и контура хранения.

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