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

Поэтому рядом с вопросом «Что это за данные?» стоит задать другой: «Чьи интересы они затрагивают?». Если в тексте есть сведения о клиенте, важно учитывать не только удобство автора запроса, но и возможный ущерб для клиента. Если описан рабочий конфликт, под угрозой могут оказаться несколько сотрудников. Раскрытие внутреннего плана может затронуть компанию, партнёров и покупателей.

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

Когда имя не требуется

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

Вместо полной медицинской выписки можно написать: «Составь нейтральный список вопросов для врача для взрослого пациента с таким-то симптомом, который продолжается около месяца; сейчас он принимает такие-то препараты». Если точный возраст важен, укажите возраст или диапазон, но не добавляйте остальные идентификаторы автоматически.

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

Теперь вернёмся к жалобе клиента. Для ответа обычно нужны суть проблемы, сроки, доступные варианты решения и подходящий тон. Имя, телефон, адрес, номер заказа и скриншот переписки могут оказаться лишними. Часто достаточно написать: «Клиент А», «заказ Б», «доставка задержана на несколько дней». Если номер заказа нужен для внутренней системы, его можно оставить там, но не переносить в запрос к модели без необходимости и разрешения.

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

Эффект домино

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

Должность — единственный инженер, обслуживающий определённое оборудование.

Место — небольшой населённый пункт или конкретная площадка.

Дата — точный день недавнего происшествия.

Событие — редкий сбой, после которого работа объекта остановилась.

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

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

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

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

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

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

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

Как определить достаточный контекст

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

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

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

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

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

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

Три проверки перед отправкой

Чтобы быстро оценить запрос, ответьте на три вопроса.

Что именно я передаю: сведения о себе, данные другого человека, рабочую или общедоступную информацию? В одном фрагменте могут сочетаться сразу несколько признаков.

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

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

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

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

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

Один запрос — несколько маршрутов

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

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

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

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

Отправка и формирование ответа

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

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

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

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

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

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

История диалога и технический журнал

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

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

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

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

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

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

Когда данные помогают улучшать сервис

Фраза «используем данные для улучшения сервиса» может описывать разные действия: анализ сбоев, оценку качества ответов, тестирование новых функций, работу с обращениями или обучение моделей. Иногда эти цели перечислены отдельно, иногда объединены общей формулировкой. По одному слову «улучшение» нельзя понять, использовали ли конкретный запрос для обучения модели.

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

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

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

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

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

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

Кто может получить доступ

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

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

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

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

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

Удалить диалог — не значит уничтожить всё связанное

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

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

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

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

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

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

Место обработки и применимое право

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

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