Можно ли использовать ChatGPT в компании: 152-ФЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй приём — разделение контуров. Сценарии, где персональные данные неизбежны (обработка заявок, карточки клиентов, документы), уходят в контур на серверах в РФ; сценарии без персональных данных могут работать где угодно. Это архитектурное решение, а не настройка: разделение закладывается при проектировании, чтобы данные физически не могли уйти не туда. Мы придерживаемся того же принципа в собственных продуктах — например, в нашей МИС (статус MVP, продукт в разработке) контур 152-ФЗ заложен в архитектуру сразу: согласия, аудит доступа, сроки хранения данных пациентов, а изоляция данных клиник обеспечивается row-level security на уровне PostgreSQL, а не фильтром в коде.

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

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

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

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

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

На бесплатном экспресс-аудите (30 минут) мы разбираем ваши текущие сценарии, показываем, где проходит граница по персональным данным, и предлагаем конфигурацию: какие задачи закрывает российская модель по API, что имеет смысл разворачивать у себя, а что вообще не требует генеративной модели. Дальше, если задача этого стоит, идёт AI-консалтинг с дорожной картой и сметой. Стоимость работ называем после аудита, когда понятен объём сценариев, интеграций и требований к контуру.

Мы одинаково спокойно говорим и обратное: если задача решается обычной автоматизацией или готовым сервисом, внедрять AI ради AI не нужно. Вопрос «можно ли нам пользоваться ChatGPT» почти всегда оказывается вопросом «как устроен наш процесс работы с данными» — и отвечать честнее на второй.