что можно и нельзя отправлять в нейросети: данные компании

главное, в трёх строчках

1. бесплатный чат по умолчанию учится на ваших переписках, api — нет. это главная развилка.
2. ваши сотрудники уже отправляют рабочие данные в chatgpt. вопрос не «разрешать ли», а «по каким правилам».
3. запрет без альтернативы не работает никогда — получите теневой ии с личных телефонов и нулевым контролем.

теперь подробно.

чат и api — разные вещи

когда сотрудник вставляет текст в бесплатный chatgpt, эти данные по умолчанию могут использоваться для обучения моделей (в настройках отключается, но кто туда ходил). когда программа обращается к модели через api, провайдеры — openai, anthropic, google — заявляют, что на api-данных не обучаются.

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

между ними есть средний вариант: корпоративные тарифы чатов (team/enterprise у openai, аналоги у остальных). там провайдер обязуется не обучаться на данных и даёт админку с контролем доступов. если команда живёт в чатах, а не в api — это минимальный гигиенический уровень, и стоит он дешевле одного инцидента.

светофор по типам данных

зелёный — можно спокойно:

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

жёлтый — можно, но через api и с головой:

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

красный — нельзя, точка:

• персональные данные клиентов пачками: фио + телефон + что купил — это уже обработка пд со всеми последствиями по 152-фз, включая трансграничную передачу на зарубежные серверы
• пароли, ключи, доступы — в любом виде
• врачебная, банковская, адвокатская тайна и прочие спецрежимы
• чужие данные под nda

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

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

не пишите регламент на 20 страниц — его не прочитают. одна страница, пять пунктов:

1. рабочие задачи — только в утверждённых инструментах (перечислить каких, с корпоративными аккаунтами)
2. в чаты не вставляем: контакты клиентов, пароли, договоры с nda
3. перед вставкой клиентского текста — убрать имена и телефоны
4. результат ии проверяем перед отправкой наружу
5. сомневаешься — спроси у (имя конкретного человека)

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

что пойдёт не так

• «у нас никто ии не пользуется». пользуются. опросите анонимно — обычно выясняется, что половина отдела давно живёт в chatgpt, включая тех, кто громче всех против.
• политику напишут и забудут. без назначенного владельца и без пересмотра раз в квартал документ мёртв через месяц.
• паранойя дороже риска. видел компании, где согласование каждого промпта убило пользу целиком. риски управляются процессом, а не запретом.
• on-premise как карго-культ. «поставим свою модель, чтобы ничего не утекало» — для 95% бизнесов это сотни тысяч на железо ради задач, которые решаются обезличиванием данных за ноль.

если нужен процесс, а не памятка

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