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

Марк Тьюрин

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

Запрос — это тоже передача

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

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

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

Текст, который кажется единственным

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

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

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

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

История не всегда остаётся за спиной

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

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

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

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

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

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

Вложения увеличивают масштаб

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

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

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

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

От устройства до ответа

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

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

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

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

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

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

Что происходит после отправки

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

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

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

Отдельно нужно разобраться, могут ли запросы использоваться для улучшения моделей или других функций. Условия различаются в зависимости от продукта, типа аккаунта, настроек и режима работы. Где-то предусмотрен специальный переключатель, где-то правила зависят от рабочего тарифа или соглашения с организацией. Отключение использования данных для обучения не отвечает на вопросы о хранении, проверках безопасности и сроках ведения журналов. Это разные параметры.

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

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

Почему нельзя переносить доверие с одного сервиса на другой

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

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

Имеет значение и тип учётной записи. Личный аккаунт и рабочее пространство могут отличаться настройками, договорами и ролями администраторов. Не считайте рабочий доступ автоматически более закрытым, а личный — более открытым. Проверяйте конкретные условия и правила организации. Если ответ поставщика расплывчатый или его не удаётся найти, разумнее считать этот пункт неизвестным и не передавать данные, безопасность которых зависит от него.

Для российских организаций важно также проверить требования к обработке персональных данных и внутренние правила работы с информацией. Если в запросе есть персональные данные, одной кнопки «отправить» недостаточно, чтобы понять, допустима ли передача. Организации нужно оценить условия обработки с учётом применимых требований, включая Федеральный закон № 152-ФЗ, договоры и локальные документы. Сотруднику следует пользоваться разрешённым рабочим инструментом и не переносить клиентские или кадровые сведения в личный сервис только потому, что так быстрее.

Проверка перед отправкой

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

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

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

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

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

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

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

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

Не всякая подробность одинаково опасна

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

Шесть карточек перед отправкой

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

А. «Объясни простыми словами, чем отличается гарантийный ремонт от платного».

Б. «Я руководитель смены на небольшом производственном предприятии в районном центре».

В. «Помоги составить список вопросов врачу: несколько недель беспокоит такой-то симптом, принимаю такое-то лекарство».

Г. «Проверь письмо: в нём указаны фамилия клиента, его телефон, адрес и номер документа».

Д. «Подготовь ответ на жалобу: клиент получил заказ с задержкой, в обращении есть номер заказа и дата доставки».

Е. «Оцени план: в документе — внутренний прогноз продаж, планируемая цена и сроки запуска нового продукта».

Единственного верного ярлыка для каждой карточки нет. Например, сведения о клиенте могут одновременно относиться к рабочему процессу, быть персональными данными другого человека и позволять установить его личность. Важно не выучить список запрещённых слов, а понять, что это за сведения, кому они принадлежат, можно ли по ним кого-то определить и к чему приведёт их раскрытие.

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

Оценка по независимым признакам

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

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

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

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

Теперь проверим карточки на практике.

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

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

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

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

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

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

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

В разговорной речи слово «личные» может означать сведения о частной жизни. Юридическое понятие персональных данных шире: в российском законодательстве это сведения, относящиеся прямо или косвенно к определённому или определяемому человеку. Поэтому стоит спрашивать не только «Есть ли здесь фамилия?», но и «Можно ли по этому фрагменту вместе с другими доступными сведениями понять, о ком речь?».

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

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

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

Кто может пострадать

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