Обсудить задачу

DikLabСтатьибезопасность

Статья · безопасность · подход

Что нельзя отправлять в чат с нейросетью

4 минбезопасностьподход

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

Поставить это мне

Содержание

В чём фокус

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

Почему «у них же есть настройки приватности» — плохая опора

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

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

Поэтому решение принимается не по галочке в настройках, а по самому куску данных.

Что нельзя никогда

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

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

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

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

Что можно после обработки

Большая часть рабочих задач решается на обезличенных данных, и это не компромисс, а нормальный рабочий режим.

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

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

Скриншот — тоже отправка.

На экране обычно видно больше, чем вы смотрите: соседние вкладки, имена в списке, почта в углу. Снимайте область, а не весь экран.

Файл целиком опаснее куска.

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

Инструмент с доступом к вашим файлам читает больше, чем вы дали.

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

Бесплатный доступ часто оплачен вашими данными.

Для учёбы это нормально. Для клиентской работы — нет: вы отдаёте не своё.

Как устроить это в работе

  1. Держите секреты вне кода

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

  2. Заведите набор выдуманных данных

    Несколько строк с правильной структурой и вымышленным содержимым. Один раз сделали — дальше подставляете вместо настоящих.

  3. Разделите личное и клиентское

    Разные проекты, разные папки, а при возможности и разные учётные записи. Смешанная папка рано или поздно уедет целиком.

  4. Договоритесь с заказчиком заранее

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

  5. Если отправили лишнее — меняйте, а не надейтесь

    Ключ заменить, пароль сменить, заказчику сообщить. Молчаливое «наверное, обойдётся» — самый дорогой из вариантов.

Частые вопросы

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

Пишу об этом в канале

Короткие разборы и то, что не дотянуло до отдельного материала.