AI-агенты приходят в комплаенс: кто отвечает за ошибку робота

Что произошло

За последний год крупные вендоры — от Microsoft с Copilot Studio до OpenAI с их Assistants и функцией вызова инструментов — сдвинули акцент с чат-ботов на агентов: программы, которые не просто отвечают, а сами выполняют цепочки действий. В корпоративном комплаенсе это выглядит так: агент получает задачу «проверь нового поставщика», сам ходит в реестры, сверяет данные с санкционными списками, читает договор и выдаёт заключение с флагами риска.

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

^* Агент — программа на основе языковой модели, которая по заданной цели самостоятельно планирует шаги, вызывает внешние инструменты (поиск, API, базы) и действует до достижения результата, а не просто отвечает на один запрос.

Зачем комплаенсу агенты

Комплаенс — область, где много рутины и высокая цена ошибки. Проверка контрагента перед сделкой, мониторинг транзакций на признаки отмывания, сверка с санкционными и «чёрными» списками, контроль конфликта интересов. Всё это — работа с большими объёмами разрозненных данных по формализуемым правилам. Ровно то, где агент теоретически силён: он не устаёт, не пропускает пункт чек-листа из-за спешки и работает круглосуточно.

Типовые сценарии, которые уже пробуют внедрять:

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

Агент хорош там, где нужно быстро собрать и сопоставить факты. Он плох там, где нужно взять на себя ответственность за вывод. Комплаенс — это ровно про второе.

Где ломается автономность

Проблема не в том, что агент ошибается — ошибаются и люди. Проблема в характере ошибок и в том, что их трудно поймать.

Галлюцинации в фактах

Языковая модель может уверенно сослаться на несуществующую норму, придумать реквизиты или неверно интерпретировать выписку. В чате это раздражает, в комплаенс-заключении это ложное «всё чисто» по контрагенту, который на самом деле под ограничениями.

Непрозрачность решения

Если регулятор спросит, почему сделку пропустили, ответ «так решила модель» не работает. Нужна воспроизводимая цепочка: какие данные агент взял, из каких источников, по каким правилам сделал вывод. Многие агентские фреймворки такую трассировку логируют, но её ещё нужно настроить и хранить.

Устаревшие данные

Санкционные списки меняются регулярно. Агент, который тянет данные из закешированного индекса, а не из актуального источника, выдаёт результат, устаревший на дни или недели. Для комплаенса это критично.

Кто отвечает за ошибку агента

Короткий ответ: компания и её должностные лица, а не «искусственный интеллект». Автономность инструмента не снимает ответственности с того, кто его внедрил и использовал. В российском правовом поле нет отдельного субъекта «ИИ-агент» — обязанность по комплаенсу лежит на организации, и делегировать её программе нельзя.

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

Инструменты: чем отличаются подходы

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

Ключевой архитектурный выбор для комплаенса — использовать ли RAG^** вместо надежды на «память» модели. Подключение агента к актуальным источникам (санкционные списки, реестры) через поиск снижает риск галлюцинаций, потому что вывод строится на найденных документах, а не на том, что модель «помнит».

^** RAG (retrieval-augmented generation) — схема, при которой модель перед ответом сначала ищет релевантные документы во внешней базе и опирается на них, а не только на данные, заложенные при обучении.

Кому это пригодится, а кому нет

Пригодится:

• Отделам, где комплаенс-офицер тонет в рутинной первичной сортировке — агент как ассистент для чернового сбора данных под финальную проверку человеком.
• Компаниям с большим потоком типовых контрагентов, где нужна предварительная фильтрация «явно чисто / нужен разбор».
• Внутреннему аудиту для поиска аномалий в больших наборах данных, которые человек глазами не просмотрит.

Не пригодится (или опасно):

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

С чего начать без лишнего риска

1. Определите, где ошибка агента обратима и дёшева — с этих задач и начинайте (сортировка, черновой сбор), а не с финальных решений.
2. Заложите обязательную проверку человеком (human-in-the-loop) для любого вывода, влияющего на решение о сделке.
3. Включите и храните трассировку: источники, шаги, версии данных. Без этого нельзя объяснить решение постфактум.
4. Подключайте агента к актуальным источникам (RAG), а не полагайтесь на знания модели.
5. Согласуйте с юристами и безопасностью, какие данные вообще можно передавать во внешнюю модель.

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