Сотрудник службы поддержки получает сообщение от нового контакта. Тон спокойный, просьба выглядит разумной, собеседник не давит и не присылает подозрительных вложений. Через несколько сообщений он предлагает перейти в другой канал, уточняет внутренний процесс и просит небольшое действие. Именно такая вежливость делает AI-ботов опасными: они не похожи на грубый спам.
Классическая фильтрация привыкла искать массовость, одинаковые тексты и резкие признаки мошенничества. AI меняет картину: сообщения становятся разнообразными, стиль подстраивается под контекст, а доверие строится постепенно. Поэтому SOC и антифрод должны смотреть не только на содержание, но и на граф взаимодействий, скорость сближения и переходы между каналами.
Риск особенно заметен в продажах, поддержке, рекрутинге, финансовых операциях и работе с партнёрами. Там нормальное общение с внешними людьми уже является частью процесса, поэтому простая блокировка новых контактов невозможна. Нужны сигналы риска, которые помогают человеку заметить необычную динамику, не ломая бизнес.
Практическая задача — собрать признаки AI-усиленной социальной инженерии: как меняется тон, когда появляется просьба, какие аккаунты координируются, где возникает попытка вывести разговор из контролируемой среды и как это связать с последующим действием.
Почему тон больше не доказательство доверия
Вежливость, грамотность и отсутствие давления больше не являются сильным признаком легитимности. Генеративные системы позволяют быстро создавать ровные, уважительные и контекстные сообщения. Такой стиль снижает настороженность и помогает пройти первые этапы общения.
Защитная модель должна учитывать не стиль сам по себе, а несоответствие между стилем, историей аккаунта, заявленной ролью и запрошенным действием. Новый контакт может звучать идеально, но его поведение всё равно будет отличаться от нормальной коммуникации.
- новый аккаунт быстро переходит к доверию;
- контакт избегает проверяемых каналов;
- вежливый тон сочетается с просьбой ускорить процесс;
- повторяются похожие сценарии у разных сотрудников;
- диалог постепенно уводится во внешний канал;
- после разговора появляется финансовое или доступовое действие.
Какие журналы и признаки нужны
Для расследования нужны не тексты личной переписки целиком, а структурные признаки. Важно видеть канал, время, направление контакта, тип просьбы, переход между площадками и связь с последующим событием: платёж, выдача доступа, отправка файла или изменение реквизитов.
Если организация использует AI для помощи операторам, отдельный риск возникает в подсказках. Модель может суммировать диалог слишком мягко и не подчеркнуть признаки манипуляции. Поэтому для спорных кейсов нужна карточка риска, а не только краткая сводка.
- исходный_канал и целевой_канал;
- возраст и репутация аккаунта;
- частота сообщений и паузы;
- тип запрошенного действия;
- факт смены канала;
- связанные платежи или заявки;
- оценка риска и причина решения.
Как реагировать без тотальной слежки
Цель защиты — не читать все коммуникации, а ловить рискованные переходы. Например, если внешний контакт просит сменить реквизиты, выдать доступ, открыть файл или перейти в неконтролируемый канал, событие получает повышенный риск и требует подтверждения.
Сотрудникам нужно объяснять, что вежливость и подробность не заменяют проверку личности. Проверка должна идти по известному каналу, а не по тому, который предложил новый собеседник.
- использовать подтверждение по заранее известному каналу;
- помечать смену канала как риск-событие;
- сравнивать просьбу с ролью контакта;
- обучать сотрудников на вежливых сценариях;
- строить граф повторяющихся диалогов;
- сохранять только минимальные признаки для расследования.
Как внедрять без лишнего риска
Начинать нужно с режима наблюдения. Команда собирает события, сравнивает решения модели с ручным разбором и только после этого включает частичную автоматизацию. Любое действие, которое меняет доступ, блокирует пользователя, раскрывает данные или влияет на деньги, должно иметь ручное подтверждение или заранее утверждённую политику.
Владелец процесса должен видеть не только итоговое решение, но и доказательства. Если модель рекомендует блокировку, повышение риска или отклонение действия, в карточке события должны быть исходные сигналы, версия правила, ссылка на журнал и причина уверенности.
- определить владельца процесса и владельца данных;
- включить режим наблюдения на первые недели;
- сохранить версии правил и шаблонов;
- запретить скрытые исключения без срока;
- проводить выборочную проверку решений;
- назначить процедуру отката и пересмотра.
Контроль качества после запуска
После запуска нельзя измерять успех только числом срабатываний. Важно понять, сократилась ли неопределённость, уменьшилась ли ручная работа и не появились ли решения, которые никто не может объяснить. Если объяснение отсутствует, автоматизация становится новым источником риска.
Отдельно нужно следить за дрейфом. Поведение пользователей, атакующих и сервисов меняется, поэтому правила, признаки и пороги должны пересматриваться. Иначе контроль быстро превращается в устаревшую формальность.
- доля событий с полным набором журналов;
- время до первичного решения;
- число ручных откатов;
- доля спорных решений;
- количество исключений без владельца;
- частота пересмотра правил.
Работа с командами поддержки и продаж
Поддержка и продажи чаще других общаются с незнакомыми людьми, поэтому им нельзя просто запретить внешние контакты. Нужен понятный порядок: какие просьбы можно выполнить в диалоге, какие требуют проверки личности, а какие сразу передаются в SOC или антифрод.
Обучение должно включать мягкие сценарии. Сотрудник должен видеть, что риск создаёт не грубость, а постепенное накопление доверия. Если новый контакт просит исключение, ускорение, изменение канала или обход обычной процедуры, тон сообщения уже не имеет значения.
- составить список действий, требующих проверки;
- дать сотрудникам короткую форму сообщения о риске;
- проверять новые контакты по независимому каналу;
- разбирать кейсы без обвинения сотрудника;
- использовать примеры вежливых сценариев;
- связывать обращения с последующими заявками.
