Какие данные нельзя отправлять во внешние нейросети и как это регулировать

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

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

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

Что происходит с данными, когда вы их отправляете

Когда сотрудник вставляет текст в чат-бот или отправляет его через API, данные:

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

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

Что нельзя отправлять во внешние сервисы

Без специальной оценки и разрешения во внешние нейросети не стоит отправлять:

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

Пара слов о 152-ФЗ

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

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

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

Классификация: три уровня вместо бесконечного списка

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

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

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

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

Каждый уровень стоит проиллюстрировать примерами из вашей компании. Абстрактное «конфиденциальная информация» понимают все по-разному, а «выгрузка из CRM с телефонами клиентов» — однозначно.

Как это внедрить

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

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

3. Обезличивайте там, где можно. Многие задачи не требуют настоящих имён и номеров. Замена ФИО на «Клиент А», номеров договоров на условные метки и удаление контактов перед отправкой — простой и действенный приём. Его можно автоматизировать: фильтр на входе корпоративного сервиса, который находит и маскирует типовые персональные данные.

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

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

6. Учите на примерах. Короткое обучение с реальными ситуациями работает лучше политики: «вот так можно, вот так нельзя, вот как обезличить». Повторяйте его при появлении новых инструментов.

Отдельные риски агентов и RAG

Когда модель получает доступ к внутренним системам, появляются новые угрозы:

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

Короткий чек-лист для руководителя

• Есть ли у сотрудников разрешённый корпоративный инструмент?
• Есть ли одностраничные правила с понятными примерами?
• Знаете ли вы, где физически обрабатываются данные в используемых сервисах?
• Прочитаны ли условия провайдера про хранение и обучение на данных?
• Проверил ли юрист схему работы с персональными данными?
• Есть ли обезличивание для типовых сценариев?
• Ограничены ли права агентов и RAG-систем?

Если хотя бы на половину вопросов ответ «нет», начинать стоит с них, а не с выбора следующей модели.