Безопасность ИИ в компании: какие риски несут нейросети и как их снизить

Что ушло вместе с запросом

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

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

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

Какие данные сотрудник может передать

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

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

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

Что выяснить у поставщика до подключения

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

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

Кто вычитывает ответ и сверяет обещания

Точный тон легко спутать с точностью ответа. В профиле NIST AI 600-1 уверенная генерация ошибочных сведений отнесена к риску конфабуляции в разделе 2.2. Для службы поддержки это может означать неверный срок возврата или уверенное обещание выплаты до решения ответственного. Попросите сотрудника найти срок и условия в действующем документе, прежде чем отправлять ответ под своим именем. В спорном случае нужно передать обращение владельцу правила: это даёт сотруднику способ разобраться, когда похожие заявки заканчиваются по-разному.

Подтверждает сотрудник, отправляющий ответ. Удобно хранить исходное обращение и ссылку на действующие правила в рабочей системе, потому что тогда человек сверяет именно те условия, которые относятся к покупке, а не пытается восстановить их по общей переписке. Начинать лучше с черновиков типовых ответов: команда увидит, где модель ошибается, пока автоматически отправлять текст она ещё не может. Для работы внутри клиентской системы пригодится разбор задач для ИИ в CRM.

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

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

Доступ меняет цену ошибки. Если помощник может найти текст правила и составить черновик, сотрудник ещё контролирует отправку. Как только помощник получает право писать в карточку или пользоваться корпоративной почтой, ошибка в ответе может изменить запись о покупателе или стать сообщением от лица компании. В разделе OWASP LLM06:2025 среди причин опасных действий названы лишние функции, разрешения и автономность.

Список прав берите из задачи. Для подготовки ответа нужен доступ к утверждённым правилам, а работа с карточкой клиента может оставаться у сотрудника. Если помощнику всё же нужен доступ к обращениям, ограничьте его теми, с которыми работает отдел, и проверьте отказ при открытии чужого обращения. Право на отправку выдавайте только после проверки самого сценария, если отдел сможет вручную подтвердить адресата и текст. Отдельно полезно пройти распределение прав в CRM и проверить, что ограничения видны со стороны реальной роли.

Входящее письмо может содержать инструкции для модели

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

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

Что показать на приёмке и во время учения

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

Об ошибке сообщают сразу. В рекомендациях NIST действие MG-4.3-002 описывает учёт ошибок, случаев, едва не приведших к сбою, и отрицательных последствий, поэтому в порядок команды полезно внести один доступный способ сообщить об инциденте и имя того, кто примет решение о доступах. Попросите сотрудника назвать время, сервис и вид сведений. Если для разбора нужно больше деталей, передайте их по принятому внутреннему каналу, где они уже защищены правами. Сотрудник может назвать затронутую заявку по её внутреннему номеру. Этого достаточно, чтобы дежурный нашёл запись с выданными ему полномочиями.

Что передать владельцу процесса

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

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

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