Безопасный ИИ: Как пользоваться нейросетями и не раскрывать лишнее

Просить результат, не отдавая исходник

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

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

Промпт на диете

Вот типичный избыточный запрос:

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

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

Начинать лучше не с вопроса «какой документ загрузить?», а с вопроса «какой результат мне нужен?». Иногда нужен готовый текст, иногда — план ответа, список вопросов для уточнения или несколько вариантов формулировки. Для каждого результата потребуется свой объём контекста.

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

Сначала цель, потом материал

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

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

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

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

Четыре версии одной задачи

Для примера возьмём условную ситуацию, не связанную с реальным заказом. Покупатель ждёт товар, отправка задержана на три дня из-за переноса поставки. Новая дата неизвестна. Клиент спрашивает, когда получит заказ и можно ли отказаться от покупки. Сотрудник вправе проверить статус, но не может подтвердить срок или компенсацию, пока не уточнит условия.

Сравним, как меняется запрос.

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

Вторая версия — описать задачу и добавить только важный контекст:

«Подготовь черновик ответа клиенту на русском языке. Условная ситуация: заказ задержан на три дня из-за переноса поставки. Точную дату отправки пока не подтвердили. Клиент спрашивает о сроке и возможности отказаться от заказа. Сотрудник может пообещать проверку статуса, но не новую дату и не компенсацию. Тон спокойный и уважительный. Не придумывай условия возврата. До 90 слов».

Фактической точности здесь меньше, зато границы задачи обозначены яснее. Черновик может выглядеть так:

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

В тексте оставлено поле для сведений, которые нужно проверить. Нейросеть не получила имя, номер заказа или адрес, и от неё не просили самостоятельно устанавливать условия возврата. Однако отправлять такой черновик нельзя, пока сотрудник не подставит реальный срок и не сверит фразу о возврате с применимыми условиями.

Третья версия — попросить не готовый текст, а план:

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

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