сразу ответ, потом обязательная оговорка. работать с нейросетями и не нарушать 152-фз можно, и для этого есть три рабочие схемы: обезличивание данных до отправки в модель (подходит большинству), российские модели внутри рф-контура (когда данные нужны как есть), локальное развёртывание (когда регуляторика жёсткая или объёмы большие). какую выбрать — зависит от того, что за данные и какова цена ошибки; разбор ниже.
что вообще считается персональными данными
рабочее определение из 152-фз: любая информация, относящаяся к прямо или косвенно определённому физическому лицу. на практике это шире, чем кажется:
- очевидное: фио, телефон, почта, адрес, паспортные данные, дата рождения;
- менее очевидное: связки, по которым человека можно вычислить. «иван, директор по маркетингу компании ромашка» — персональные данные, даже без фамилии;
- совсем неочевидное: история заказов, привязанная к идентификатору клиента; записи звонков с голосом; фотографии; переписка, где человек представился.
практическое следствие: если вы собираетесь скормить нейросети выгрузку из crm, историю переписки с клиентами или записи звонков — вы почти наверняка оперируете персональными данными, и 152-фз к этому имеет прямое отношение.
где именно возникает проблема с нейросетями
152-фз не запрещает нейросети. проблемных места три:
- трансграничная передача. отправка персональных данных россиян на серверы за пределами рф — отдельно регулируемая операция с уведомлением роскомнадзора и условиями по стране-получателю. запрос к chatgpt или claude с персональными данными в промпте — это фактическая передача данных на зарубежный сервер. без оформления — нарушение, независимо от того, «удаляет провайдер данные или нет».
- цель обработки. данные можно обрабатывать в целях, на которые человек давал согласие. клиент оставлял телефон, чтобы ему привезли заказ, — а не чтобы его переписку анализировала нейросеть для «улучшения сервиса». формально это новая цель, и на неё нужно основание.
- поручение обработки. когда вашими данными оперирует третья сторона (провайдер модели, подрядчик), с ней положен договор поручения с конкретными пунктами. с зарубежными провайдерами публичных api такой договор в российской юридической конструкции не заключить.
итого без драматизации: слать пд россиян как есть в зарубежные публичные модели — плохая идея не потому, что «данные украдут», а потому, что сама операция передачи не оформляется законным способом.
схема 1: обезличивание — вариант по умолчанию
ключевая мысль всей статьи: обезличенные данные перестают быть персональными, и ограничения 152-фз на них не распространяются. а нейросети для полезной работы почти никогда не нужны реальные имена и телефоны.
как это выглядит в работе агента:
- агент получает заявку: имя, телефон, вопрос;
- перед отправкой в модель прослойка вырезает идентификаторы: модель видит «клиент спрашивает про доставку в другой город, заказ на крупную сумму»;
- модель генерирует ответ по сути;
- на вашей стороне, внутри вашего контура, в ответ подставляются реальные данные из crm.
модель делает умную работу, не видя ни одного персонального поля. в моих внедрениях такая прослойка — стандартная часть архитектуры, когда данные ходят в зарубежные модели, а не опция за отдельные деньги.
важная честная оговорка: обезличивание должно быть настоящим. замена «иванов иван» на «клиент 12345» при том, что рядом в тексте остались его адрес и номер заказа, — это псевдонимизация, по которой человек восстанавливается, а значит, данные остались персональными ? граница между «обезличено» и «псевдонимизировано» — как раз то место, где нужен юрист, а не подрядчик. я знаю, как построить прослойку; что считать достаточным обезличиванием в вашем случае — вопрос к юристу. . вырезать нужно всё, по чему восстанавливается личность, а не только фио.
схема 2: российские модели
когда данные нужны модели как есть — например, агент работает с полной историей клиента и обезличивание выхолащивает задачу — используются модели, развёрнутые в рф: gigachat, yandexgpt и совместимые с ними облака.
что это даёт: данные не пересекают границу — трансграничная передача не возникает; с российским провайдером заключается нормальный договор с поручением обработки; для госсектора и компаний с строгими политиками это часто единственный приемлемый вариант из облачных.
что стоит знать честно: по качеству на сложных задачах российские модели уступают топовым западным — на типовых бизнес-сценариях (ответы по базе знаний, классификация заявок, черновики документов) разница часто некритична, на сложной генерации и рассуждениях — заметна. рабочий компромисс, который я использую: гибридная схема, где персональные данные обрабатывает российская модель внутри контура, а обезличенные задачи уходят в более сильную зарубежную.
схема 3: локальное развёртывание
открытая модель на вашем сервере: данные не покидают компанию вообще, вопрос передачи кому-либо снимается по построению. когда это оправданно: медицина и финансы, большие регулярные объёмы пд, корпоративные запреты на любые внешние api. цена вопроса: сервер с gpu (своё железо от ~500к или аренда от ~50–150к в месяц) плюс человек, который это сопровождает.
для большинства малого и среднего бизнеса это перебор: схема 1 закрывает те же риски за долю цены. локалка выбирается по необходимости, а не для спокойствия.
что сделать на этой неделе — чек-лист
- инвентаризация. выпишите, где сотрудники и автоматизации уже отправляют данные в нейросети. почти всегда найдётся личный chatgpt с рабочими вставками — это и есть риск номер один, а не ваш будущий агент.
- правило одной страницы. что можно отправлять в модели, что только обезличенно, что никогда. без 40-страничной политики — одна страница, которую реально прочитают.
- проверьте согласия. посмотрите с юристом, покрывает ли текущая формулировка согласия обработку с использованием автоматизированных систем. часто дело решается обновлением текста согласия для новых клиентов.
- выберите схему по данным. типовые заявки и переписка — схема 1. глубокая работа с историей клиентов — схема 2 или гибрид. регулируемая отрасль — считайте схему 3.
- зафиксируйте архитектуру письменно. какие данные, в какую модель, через какую прослойку. этот документ — половина разговора и с юристом, и с любым проверяющим.
частые вопросы
нас вообще касается 152-фз? мы маленькие
если у вас есть клиенты-физлица или сотрудники — вы оператор персональных данных, размер компании роли не играет. другое дело, что риск проверки для малого бизнеса невысок; но строить процессы «на авось» — так себе фундамент, тем более что правильная схема стоит почти столько же, сколько неправильная.
сотрудник со своего аккаунта вставил данные клиента в chatgpt — что теперь?
формально — инцидент. практически — повод не для паники, а для пунктов 1 и 2 чек-листа: официальный корпоративный доступ с правилами вместо тихих личных аккаунтов. запреты без альтернативы не работают — проверено везде.
подрядчик говорит «мы всё делаем по 152-фз» — верить?
просите показать, как именно: где физически обрабатываются данные, есть ли прослойка обезличивания, какой договор поручения. подрядчик, который делал это хоть раз, отвечает схемой за две минуты. подрядчик, который отвечает «у нас всё сертифицировано», отвечает вам маркетингом.