Что нельзя загружать в нейросети на работе, сотрудник обычно узнаёт уже после того, как загрузил: выгрузку клиентской базы вставили в чат, чтобы «быстро сгруппировать», и таблица ушла на серверы поставщика, откуда её не отозвать. Правило он при этом не нарушал — его просто никто не написал. Я смотрю на эту тему как инженер инфраструктуры: не «можно ли доверять сервису», а куда физически уходит текст, кто за это отвечает и какое правило люди будут соблюдать, а не обходить.
Отправленный текст уже не принадлежит компании
Публичная нейросеть — это сервис, в котором сотрудник работает под личной или стандартной учётной записью и не управляет тем, где хранятся его запросы: веб-чат, мобильное приложение, бесплатный тариф. С точки зрения инфраструктуры это чужие серверы. Отправленный туда текст покидает контур компании: он передаётся поставщику, хранится по его правилам и может использоваться для дальнейшего обучения модели, если в настройках не указано обратное.
Отсюда практическое следствие, которое стоит проговаривать сотрудникам прямо: отправленное отозвать нельзя. Удаление переписки в интерфейсе не означает удаления данных на стороне сервиса.
Вопрос не в том, надёжен ли поставщик. Вопрос в том, что вы передали данные третьему лицу — и с точки зрения закона отвечаете за это вы, а не он.
Что нельзя загружать в нейросети: четыре категории
- Персональные данные. ФИО, телефоны, адреса, паспортные данные, медицинские сведения — всё, по чему человека можно опознать. Передача их третьему лицу без основания нарушает 152-ФЗ, и ответственность несёт компания, а не сотрудник.
- Коммерческие условия. Себестоимость, маржа, индивидуальные скидки, условия договоров с поставщиками. Утечка здесь не про штраф, а про переговорную позицию.
- Внутренние документы. Регламенты, финансовые отчёты, планы, переписка руководства. Отдельная опасность в том, что такие файлы загружают целиком, не глядя, что внутри.
- Учётные данные и ключи. Пароли, токены, ключи API, куски конфигураций. Попадают в чат чаще всего вместе с кодом или логами, когда просят «разобраться, почему не работает».
Пятая категория — чужие данные, которые вам доверил клиент. Формально это те же персональные данные, но напоминать о них стоит отдельно: сотруднику кажется, что раз файл прислал сам клиент, значит с ним можно всё.
Заметьте, что ни одна категория не про секретность в бытовом смысле. Прайс-лист не секрет, а скидка, которую дали конкретному клиенту, — уже коммерческое условие. Граница проходит не по важности документа, а по тому, чьи это данные и что случится, если их прочитает посторонний.
Цена ошибки зависит от того, что именно ушло
| Что ушло | Последствие |
|---|---|
| Персональные данные клиентов | Нарушение 152-ФЗ; отвечает оператор данных, то есть компания |
| Себестоимость и скидки | Потеря переговорной позиции, если данные всплывут |
| Внутренние документы | Разглашение коммерческой тайны, если режим введён |
| Ключи и пароли | Прямой доступ к системам; отзывать придётся всё |
Строку про ключи недооценивают сильнее остальных. У первых трёх последствия наступают, если данные где-то всплывут; у ключа — в тот момент, когда им кто-то воспользуется. Поэтому ключ или пароль, который побывал в чате с нейросетью, я считаю скомпрометированным: менять его нужно сразу, не выясняя, видел ли его кто-нибудь. Это дешевле, чем потом разбираться, откуда в системе чужой доступ.
Текст уходит не только через окно чата
Когда говорят об утечках через нейросети, представляют человека, который копирует текст в окно чата. Этот канал хотя бы виден самому сотруднику. Есть каналы, где данные уходят без явного действия, и правило «не вставляй» их не закрывает.
Загрузка файлов. Документ уходит целиком — со скрытыми листами таблицы, примечаниями рецензентов и свойствами файла. Человек думает, что отправил сводку с одной вкладки, а отправил книгу с исходными данными на соседних.
Расширения браузера. Помощники «перескажи страницу» и «улучши текст» читают содержимое открытой вкладки, а открытой вкладкой бывает карточка клиента в CRM или рабочая почта. Ставятся они в один клик, и сотрудник не воспринимает это как передачу данных.
Боты для встреч и расшифровки. Сервис, который подключается к видеозвонку и присылает итоги, получает запись всего разговора — включая участников с другой стороны, которые на это не соглашались. Про согласие на запись и проверку итогов — в статье о протоколе встречи с ИИ.
Помощники в коде. Им отправляется контекст проекта, и если в репозитории лежит файл с настройками и паролями, он может уйти вместе с кодом. Для разработки это главный канал утечки ключей.
Интеграции с почтой и хранилищем. Сервис, которому дали доступ к диску или почтовому ящику, получает не один документ, а всё, до чего дотягивается учётная запись.
Что это значит на практике: правило для сотрудников должно говорить не только «что не вставлять», но и «что не подключать без согласования». Расширения, боты встреч и интеграции с доступом к рабочей почте — решение не одного сотрудника, а того, кто отвечает за инфраструктуру компании.
Разрешающий список важнее запрещающего
Запретительный список без разрешительного не работает: сотрудник, которому сказали только «нельзя», либо перестаёт пользоваться инструментом, либо пользуется тайком. Второе хуже первого.
Рабочая формулировка состоит из двух частей. Первая — что можно всегда: обезличенный текст, публичная информация, собственные черновики, задачи без имён и цифр. Вторая — простое правило проверки на всё остальное.
Не отправляйте в публичный сервис то, что не отправили бы незнакомому подрядчику по почте. Если сомневаетесь — обезличьте: замените имена и суммы на условные.
Обезличивание решает большинство случаев. Разбор возражения клиента прекрасно работает без его фамилии, а расчёт скидки — на условных числах в той же пропорции.
У обезличивания есть предел: человека иногда выдаёт не имя, а сочетание деталей — должность, город и отрасль вместе указывают на одного конкретного клиента. Что обезличивание закрывает, а чего нет, подробно разобрано в статье об ИИ и коммерческой тайне. Для сотрудника хватит короткой проверки: убрали имя — перечитайте и спросите себя, узнаётся ли человек по остальному.
Полный запрет создаёт слепую зону
Полный запрет на нейросети выглядит безопасным решением и им не является: сотрудники начинают пользоваться личными аккаунтами с личных устройств, и компания теряет не только контроль, но и саму возможность узнать, что произошло.
Практичнее обратный ход: дать разрешённый инструмент, объяснить правила и сделать удобным то, что безопасно. Тогда обходить нечего.
Личные устройства и личные аккаунты
Главный канал, который не закрывается никакими корпоративными настройками: сотрудник открывает публичный сервис с телефона со своего аккаунта и вставляет туда рабочий текст. Ни блокировка на корпоративных машинах, ни списки разрешённых сервисов этого не видят.
Бороться техническими средствами здесь почти невозможно, и попытки обычно ухудшают положение: чем неудобнее разрешённый инструмент, тем активнее пользуются личным. Работает другое — сделать разрешённый путь удобнее запретного.
Практически это означает: разрешённый сервис должен быть доступен без заявок и согласований, работать на телефоне и решать те же задачи. Если корпоративный инструмент требует входа через две системы и не открывается вне офиса, правило будет обходиться независимо от того, что написано в регламенте.
Когда свой контур не нужен и хватит правила
Из разговора об утечках легко сделать вывод, что компании нужна своя модель на своих серверах. Часто это не так, и начинать с этого я бы не советовал.
Если нейросетью пишут черновики писем и тексты для сайта, разбирают публичные документы и обезличенные ситуации, закрытый контур не окупится: серверы, обновление моделей и человек, который всё это поддерживает, стоят дороже риска, который и так закрывают правило одной фразы и разрешённый сервис. То же в небольшой компании, где с данными клиентов работают несколько человек: их проще научить, чем строить для них инфраструктуру.
Свой контур или договор с поставщиком об обработке данных становится нужен, когда нейросеть должна работать именно с тем, что наружу не уходит: с записями звонков, карточками клиентов, договорами. Тогда вопрос уже не в дисциплине сотрудников, а в том, где физически обрабатываются данные. Как принимать это решение — в разборе открытых моделей и облачных API.
Моя позиция такая: сначала правило и разрешённый инструмент для обычных задач, потом — отдельное решение для задач с данными клиентов. Строить закрытую инфраструктуру ради черновиков писем — всё равно что покупать сейф для телефонного справочника. В проектах 404ai этот вопрос решается до пилота на реальных данных, а не после: записи разговоров, которые обрабатывают наши продукты, хранятся в России.
Как заметить нарушение, не устраивая слежку
Тотальный контроль переписки дорог, юридически сложен и разрушает доверие. При этом заметить систематическое нарушение можно гораздо более простыми средствами.
Первый сигнал — расход на корпоративный сервис заметно ниже ожидаемого при том, что работа идёт. Это означает, что пользуются чем-то другим. Второй — тексты, которые появляются в работе, но не могли быть написаны в разрешённом инструменте: узнаваемый стиль, форматирование, характерные обороты. Третий — прямые вопросы на встречах: «чем пользуетесь» без обвинительного тона отвечают честно чаще, чем ожидают.
Цель наблюдения — не поймать человека, а понять, чего не хватает в разрешённом наборе. Почти всегда обнаруживается конкретная задача, которую корпоративный инструмент не решает, и её закрытие снимает нарушение надёжнее любых мер.
Утечка через нейросети — не единственный риск, связанный с ИИ. Обратная угроза — когда нейросетью пользуются против компании: подделывают голос руководителя и звонят бухгалтеру с просьбой срочно оплатить счёт. Какие процедуры защищают от этого, даже если подделку не отличить на слух, — в статье о дипфейк-звонках.
Что делать, если данные уже ушли
Первое, что нужно понять: отправленное отозвать нельзя. Удаление переписки в интерфейсе не удаляет данные у поставщика, и исходить надо из того, что информация покинула контур навсегда.
Порядок действий сводится к оценке и ограничению последствий. Установить точно, что именно ушло, в каком объёме и когда — по возможности из первоисточника, а не по памяти сотрудника. Оценить, попадает ли это под персональные данные или под режим коммерческой тайны: от этого зависят обязанности компании, в том числе по уведомлению.
Дальше — то, что реально снижает ущерб: сменить пароли и ключи, если ушли учётные данные; предупредить контрагента, если ушли его сведения; зафиксировать инцидент письменно. Последнее делается не для отчётности, а потому что через полгода восстановить обстоятельства будет невозможно.
Как объяснить правило, чтобы его не обходили
Список запретов, выданный без объяснений, воспринимается как бюрократия и обходится при первом же неудобстве. Объяснение занимает две минуты и меняет отношение.
Работает конкретика последствий, а не общие слова о безопасности. Не «это может привести к утечке», а «клиент, чьи данные ушли, вправе потребовать объяснений, и отвечать будет компания». Не «нельзя загружать себестоимость», а «конкурент, узнавший вашу маржу, знает, до какой цены вы можете опуститься».
И один приём, который работает лучше всего: показать на реальном примере из вашей же практики. Один разобранный случай — что человек отправил, чем это грозило, что сделали — запоминается прочнее страницы правил и обсуждается в курилке, то есть распространяется сам.
Что сделать на этой неделе
- Написать список из четырёх категорий на одну страницу и разослать.
- Назвать разрешённый сервис — тот, которым пользоваться можно.
- Показать на одном примере, как обезличить типичный рабочий запрос.
- Сказать, к кому идти с вопросом «а это можно?» — с именем, а не «в IT».
Проверьте на трёх запросах, а не на политике
Главное, что эта тема меняет в решении руководителя: утечка через нейросеть — вопрос не выбора «надёжного» сервиса, а того, какие данные вообще уходят наружу. За передачу персональных данных отвечает компания как оператор, а не поставщик и не сотрудник. Поэтому начинать стоит не с запрета, а с того, чтобы узнать реальную картину.
Узнать её можно без аудита и слежки. Попросите нескольких сотрудников из разных отделов показать три последних рабочих запроса к нейросети — добровольно и с правом скрыть лишнее. Разложите запросы по четырём категориям и отдельно отметьте задачи, которые люди решали в личных сервисах, потому что разрешённого инструмента под них нет. Первое покажет, насколько срочно нужно правило, второе — чего не хватает в разрешённом наборе. Через месяц после рассылки правила повторите ту же проверку: если запросов с данными из четырёх категорий не стало меньше, правило либо не прочитали, либо ему неудобно следовать.
Правила работы с данными входят в обучение сотрудников работе с ИИ, как оформить их документом — в статье о регламенте работы с ИИ, а про хранение записей разговоров — в разборе записи разговоров и 152-ФЗ.
