Схема внедрения agentic AI в антифрод-систему с человеком в петле

Agentic AI против фрода: как внедрить за 6 недель и не потерять контроль

ИИ-инструменты 1 июля 2026 г.

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

Источник: Habr

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

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

Что изменилось: от демо к рабочему слою защиты

Автор кейса (инженер, пишущий под псевдонимом vivis на Habr) описывает ситуацию, знакомую многим командам безопасности: классические правила и сигнатуры «протухают», пороги подбираются, и дашборд начинает уверенно описывать вчерашнего атакующего. Графики красивые, но опаздывают.

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

  • сходить в ClickHouse за срезом данных;
  • сравнить когорту с прошлой неделей;
  • проверить похожую форму API-вызовов в OpenSearch;
  • изменить выборку;
  • предложить обновление правила;
  • поднять кейс человеку;
  • собрать summary для ручной проверки.

Результат: аналитики видели меньше мусора, инженеры получали более понятные issues, продукт перестал воспринимать ИИ-слой как очередное демо.

Почему это меняет стоимость и время реакции

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

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

  1. замечает смещение паттерна;
  2. меняет выборку;
  3. готовит объяснение для аналитика;
  4. предлагает правило;
  5. получает обратную связь (ложное срабатывание или нет);
  6. возвращает фидбек в проверку качества.

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

Архитектура и стек: что реально работало

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

Компонент Назначение
LangChain + LangGraph Нижний уровень агентов
Claude Agent SDK Оркестрация агентов
Dagster Пайплайны
Kafka Событийная шина
ClickHouse Аналитика
OpenSearch Расследования
Kubernetes Инфраструктура
OpenAI, Anthropic, локальные модели с LoRA Модели (выбор по стоимости и приватности)
Langfuse Трассировка, проверки качества, стоимость

Важный нюанс: модели были смешанные. Локальные модели с LoRA использовались там, где это имело смысл по стоимости или приватности. Не везде нужен GPT-4 — иногда дешевле и безопаснее поднять маленькую локальную модель.

Где человек остаётся в контуре: границы автоматизации

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

«Если агент может блокировать движение денег, не надо давать ему косплеить отдел фрода.»

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

Что может пойти не так: риски и скрытые ограничения

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

Основные риски, которые стоит учитывать:

  1. Стоимость инференса. Если вы начнёте гонять каждый платёж через LLM, счёт за API может превысить потери от фрода.
  2. Задержки. Агент, который ходит в ClickHouse, OpenSearch и обратно, не может работать в реальном времени для каждого запроса.
  3. Качество фидбека. Если аналитики не будут давать качественную обратную связь, агент начнёт учиться на шуме.
  4. Безопасность. Рабочая защита становится сигналом для другой стороны. Как только атакующие поймут, что вы используете ИИ, они начнут адаптироваться.
  5. Субъективность кейса. Статья написана от первого лица, детали обезличены. Часть контекста может быть скрыта.

Практический чек-лист: что проверить до внедрения

Прежде чем начинать эксперимент с agentic AI в антифроде, проверьте эти шесть пунктов:

  • [ ] Готова ли событийная шина? Без Kafka или аналога агент не сможет получать события в реальном времени.
  • [ ] Есть ли аналитическая база? ClickHouse или аналогичная система нужна для быстрых срезов и сравнения когорт.
  • [ ] Организован ли фидбек-луп? Аналитики должны иметь возможность маркировать ложные срабатывания и возвращать их в модель.
  • [ ] Определены ли границы автоматизации? Где агент может действовать сам, а где нужен человек? Особенно для денежных операций.
  • [ ] Посчитана ли стоимость инференса? Сколько будет стоить каждый запрос к LLM, и не превысит ли это экономию от снижения фрода.
  • [ ] Есть ли план на адаптацию противника? Как вы будете менять стратегию, когда атакующие поймут, что вы используете ИИ.

Что делать на этой неделе

Если вы техлид или инженер, оценивающий применимость agentic AI в антифроде:

  1. Прочитайте оригинальную статью на Habr — в ней больше деталей по архитектуре и граблям, которые автор собрал за шесть недель.
  2. Проверьте свой стек. Если у вас уже есть Kafka, ClickHouse и Kubernetes, вы на полпути. Если нет — начните с инфраструктуры.
  3. Сделайте маленький эксперимент. Не пытайтесь внедрить агентный слой сразу во все платежи. Возьмите один сценарий (например, бонусный абьюз) и проверьте гипотезу на исторических данных.
  4. Обсудите с командой границы автоматизации. Кто принимает решение о блокировке платежа? Готовы ли вы доверить это агенту хотя бы в тестовом режиме?

Источники

Темы журнала

Что почитать дальше

Теги