“Откровенная и пугающая статистика о сливах данных через ChatGPT, это лишь симптом. На деле компании даже не видят, как сотрудники отправляют в AI весь их бизнес по кускам. Они строят защиту от внешних угроз, пока внутренняя утечка идёт через обычный браузер. Главная проблема — не персонал, а отсутствие модели для работы с генеративным AI внутри организаций. Мы не учим людей использовать ChatGPT безопасно, мы просто запрещаем или делаем вид, что этого не существует”
.
Что на самом деле происходит в чатах с AI
Когда сотрудник вставляет кусок кода в ChatGPT, чтобы найти ошибку, или загружает таблицу с финансовыми прогнозами для анализа, он редко задумывается о том, куда эти данные отправляются. Они попадают на серверы внешнего провайдера, становятся частью его обучающей выборки или, как минимум, хранятся для целей обслуживания. Этот процесс не требует злого умысла — люди просто хотят сделать свою работу быстрее. Проблема в том, что корпоративные секреты, персональные данные клиентов, стратегические планы утекают в чужие руки через интерфейс, который выглядит как обычный помощник.
Почему традиционные средства защиты бессильны
СИБ, DLP и прокси-серверы настроены на блокировку известных угроз: фишинговых сайтов, передачи файлов на подозрительные домены. ChatGPT работает через стандартные HTTPS-соединения к официальным и доверенным доменам (api.openai.com и аналоги). Для сетевого фильтра это выглядит как обычный легитимный веб-трафик. Системы DLP, ищущие шаблоны (например, номера кредитных карт), могут пропустить неструктурированный текст, в котором конфиденциальная информация подана в свободной форме. Запретить доступ ко всем AI-сервисам — значит лишить команду мощного инструмента, что в современной конкуренции равносильно самоограничению.
От запретов к управлению: создание политик работы с AI
Первым шагом должна стать не техническая блокировка, а формализация правил. Политика определяет, какие типы данных можно обрабатывать через публичные AI-сервисы, а какие — категорически запрещено.
- Открытые данные: Общедоступная информация, документация по открытым библиотекам, личные неконфиденциальные запросы.
Ограниченные данные (только в корпоративном контуре): Внутренняя техническая документация, код модулей без ключей, шаблоны документов. Для работы с ними должен быть развёрнут корпоративный инстанс или использован специальный режим API с гарантиями неиспользования данных для обучения.
Конфиденциальные данные (полный запрет): Персональные данные (ПДн), коммерческая тайна, патенты, исходный код ключевых продуктов, финансовая отчётность, данные для аудита по 152-ФЗ.
Такая политика должна быть доведена до каждого сотрудника не в форме грозного приказа, а как часть инструктажа по информационной безопасности, с понятными примерами.
Технический контроль: что можно сделать прямо сейчас
Политики работают только вместе с техническим контролем. Вот реализуемые меры:
- Сегментация сетевого доступа: Разрешить доступ к доменам публичных AI-сервисов (chat.openai.com, bard.google.com) только с выделенных, немаршрутизированных сетей или виртуальных машин, не имеющих доступа к внутренним ресурсам компании.
Шифрование и токенизация на стороне клиента: Использовать браузерные расширения или прокси, которые автоматически заменяют в тексте запроса чувствительные данные (имена, номера, ключевые слова) на токены перед отправкой в интернет. На стороне компании токены могут быть расшифрованы для анализа контекста, но для AI-провайдера информация будет бессмысленной.
Глубокий анализ контента (Content Inspection): Настроить межсетевые экраны нового поколения (NGFW) или специализированные прокси на анализ тела HTTPS-запросов (с расшифровкой трафика) к известным AI-API. Искать не только шаблоны данных, но и семантические маркеры: фразы вроде «конфиденциально», «не для распространения», названия внутренних проектов.
Корпоративные sandbox-решения: Развернуть внутри компании локальную версию подобного AI-инструмента (например, на основе открытых моделей Llama или отечественных аналогов). Все запросы остаются внутри периметра. Это дороже, но это единственный способ безопасно работать с данными ограниченной категории.
Важный нюанс: для анализа HTTPS-трафика необходимо иметь на рабочих станциях доверенный корпоративный сертификат. Без этого технические средства слепы.
Человеческий фактор: обучение вместо запугивания
Сотрудники сливают данные не из-за вредности, а из-за непонимания рисков. Тренинги по ИБ часто сфокусированы на внешних угрозах. Нужно добавить в программу конкретный модуль про генеративный AI:
- Показывать, как выглядит «сырой» запрос к API OpenAI, куда он уходит и почему его может прочитать провайдер.
- Разбирать реальные (анонимизированные) кейсы утечек через чат-ботов.
- Обучать приёмам «обезличивания» запросов: как сформулировать вопрос, не раскрывая сути. Например, вместо «Вот фрагмент кода нашего платежного шлюза, найди уязвимость» — «Разбери типовую уязвимость буфера в Си на этом синтетическом примере».
- Чётко обозначить «красные линии»: что отправлять нельзя ни при каких условиях.
Цель — не запугать, а сделать сотрудника осознанным союзником в защите данных.
Юридические и регуляторные аспекты для российских компаний
Использование зарубежных AI-сервисов создаёт дополнительные риски с точки зрения российского законодательства.
- 152-ФЗ «О персональных данных»: Передача ПДн на серверы, находящиеся за пределами РФ, без обеспечения адекватной защиты и согласия субъекта является нарушением. Провайдеры типа OpenAI не предоставляют гарантий соответствия требованиям российского регулятора (Роскомнадзора).
ФСТЭК России: Требования к защите информации, составляющей государственную тайну, и конфиденциальной информации (приказы ФСТЭК) могут быть нарушены фактом передачи таких данных иностранному субъекту, что трактуется как утечка.
КоАП и уголовная ответственность: В случае инцидента, повлёкшего ущерб, компанию могут привлечь к административной ответственности за ненадлежащую защиту информации. При наличии доказательств халатности или умысла не исключена и уголовная статья для ответственных лиц.
Единственный способ полностью соблюсти законодательство — либо полный запрет на использование зарубежных сервисов для работы с какими-либо внутренними данными, либо переход на решения, развёрнутые в национальной юрисдикции.
Действенный план на первые две недели
- Аудит и оценка (Дни 1-3): Проанализируйте логи прокси-серверов и DNS-запросов. Узнайте реальные масштабы: сколько сотрудников и с каких IP-адресов обращаются к chat.openai.com, api.anthropic.com и другим подобным доменам.
- Временные технические ограничения (Дни 4-5): На уровне сетевого периметра ограничьте доступ к основным AI-доменам только для групп, которым это критически необходимо для работы (например, R&D отдел). Для остальных доступ временно приостановите.
- Разработка и публикация политики (Дни 6-8): Создайте черновик политики использования генеративного AI. Опубликуйте его во внутренней сети для сбора обратной связи от ключевых подразделений (разработка, аналитика, маркетинг).
- Пилотное обучение и запуск корпоративного инструмента (Дни 9-14): Проведите обучение для пилотной группы. Параллельно протестируйте и, если возможно, разверните корпоративный sandbox с локальной моделью для безопасных экспериментов.
Игнорировать использование ChatGPT сотрудниками больше нельзя. Выбор стоит между хаотичной утечкой данных и созданием управляемой, безопасной среды для работы с самыми эффективными инструментами нашего времени. Начать нужно с понимания реальной картины и диалога с командой, а не с жёстких запретов, которые всё равно будут обходиться.