Политика безопасности данных при работе с ChatGPT: что включить

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

Почему это не техническая, а организационная задача

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

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

Личный аккаунт или корпоративный доступ

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

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

Настройки истории и обучения на данных

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

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

Какие данные нельзя вставлять в чат

Список стоит формулировать конкретно, а не общими фразами о конфиденциальности:

1. Персональные данные клиентов и сотрудников — имена, контакты, паспортные данные.
2. Реквизиты компании и контрагентов, номера счетов.
3. Содержание договоров с пометкой о коммерческой тайне.
4. Пароли, ключи доступа, внутренние учётные данные любых систем.
5. Медицинские и другие чувствительные персональные данные, если компания с ними работает.

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

Кто отвечает за соблюдение политики

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

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

План действий при утечке данных

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

1. Зафиксировать, какие именно данные попали в чат и когда.
2. Уведомить ответственного за безопасность данных в компании.
3. Если в чат попали пароли или ключи доступа — сменить их немедленно.
4. Оценить, требует ли ситуация уведомления клиента или партнёра, если утекли их данные.
5. Разобрать случай с командой на общем примере, не называя виновного публично, чтобы будущие ошибки не скрывали из страха наказания.

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

Политика для ChatGPT и общий регламент по ИИ

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

Мобильные приложения и браузерные расширения

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

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

Отличие от других нейросетей в этом вопросе

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

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

Как объяснить политику команде без сопротивления

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

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

Пример формулировки для внутреннего документа

Шаблон ниже можно адаптировать под конкретную компанию.

1. Работаем с ChatGPT только через корпоративный доступ [название тарифа].
2. История чатов и использование переписки для обучения моделей отключены
   в настройках аккаунта.
3. Не вставляем в чат: персональные данные клиентов и сотрудников,
   реквизиты, содержание договоров с пометкой "коммерческая тайна",
   пароли и ключи доступа.
4. При случайной утечке данных — немедленно сообщаем [должность/имя],
   не пытаемся исправить ситуацию молча.
5. Ответственный за настройки и актуальность документа: [должность].

Где ИИ ошибается в контексте безопасности

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

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

Что дальше

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

Ярослав Сажнев — преподаватель ИИ в РАНХиГС, внедрение ИИ в компании. Подробнее об авторе