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

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

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

Персональные данные клиентов в чате нейросети - это уже обработка?

Статья 3 закона перечисляет, что считается обработкой. В списке прямо названы сбор, хранение, извлечение, использование, передача, предоставление и доступ. Персональные данные клиентов проходят сразу через несколько этих операций, как только выгрузка уходит в чат.

Отдельно закон разделяет два понятия. Распространение - это раскрытие неопределённому кругу лиц, то есть публикация. Предоставление - раскрытие определённому лицу или кругу лиц. Отправка базы в сервис вендора относится ко второму.

Отсюда практический вывод: аргумент «я никуда это не выкладывал» юридического веса не имеет. Персональные данные клиентов ушли конкретному получателю - обработка состоялась.

Какие поля в вашей CRM - персональные данные?

Формулировка из пункта 1 статьи 3 звучит так: любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу. Работают оба слова - «косвенно» и «определяемому». Поэтому персональные данные клиентов остаются в колонках, где нет ни одного имени.

Средняя строка - та, на которой ошибаются чаще всего. Выгрузка «без ФИО», где остались дата покупки, сумма, город и модель автомобиля, в небольшом городе позволяет определить человека с одного заказа. Формально имени в файле нет, фактически персональные данные клиентов остались на месте.

Достаточно ли вырезать ФИО и телефон?

Пункт 9 статьи 3 определяет обезличивание так:

«действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных»

• Федеральный закон № 152-ФЗ «О персональных данных», п. 9 ст. 3 (источник)

Та же логика в требованиях к обезличиванию, утверждённых приказом Роскомнадзора № 140 от 19.06.2025: нужна невозможность определить принадлежность данных субъекту без использования дополнительной информации.

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

Обезличивание или псевдонимизация: что выбрать?

Разница простая. Обезличивание требует, чтобы восстановить личность было невозможно без дополнительной информации. Псевдонимизация заменяет идентификаторы на условные - клиент №1, клиент №2, - и таблица соответствий сохраняется. Эта таблица и есть та самая дополнительная информация, поэтому обезличиванием такая замена не считается.

Дальше начинается прикладная часть. Команда Raft прогнала 102 синтетических банковских запроса в трёх вариантах: чистые данные, маскировка символами XXXX и псевдонимизация ярлыками вида PERSON_1. Вывод авторов:

«псевдонимизация не имеет значительного влияния на работу конечного агента. В то время как маскировка вызывает более заметную просадку»

• блог компании Raft на Хабре (источник)

Это эксперимент вендора на синтетических данных, рыночной статистикой его считать нельзя. Но направление понятное: маскировка символами обходится дороже по качеству, чем осмысленные ярлыки. По ярлыкам модель сохраняет структуру запроса - где стояло имя, где телефон. Для рабочих задач это и нужно: персональные данные клиентов ярлык скрывает, а смысл запроса сохраняет.

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

Как обезличить выгрузку в обычной таблице: 5 шагов

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

1. Выгрузите из CRM только то, что нужно для задачи. Возьмите колонки под конкретный вопрос, а карточку целиком оставьте в CRM. Если считаете возвраты - хватит даты, суммы, канала и статуса.
2. Добавьте колонку ID. Порядковый номер строки или внутренний номер сделки.
3. Разнесите на два листа. Лист «Ключ» - это ID плюс ФИО, телефон и email. Он остаётся на вашем компьютере. Лист «Для модели» - ID плюс рабочие поля без имён.
4. Проверьте лист для модели на косвенные признаки. Уберите точный адрес, редкую должность, диагноз, номер договора. Дату и сумму при необходимости округлите.
5. Отправьте модели только второй лист. Ответ придёт с теми же ID, обратную связку сделаете функцией ВПР по своему ключу.

Отдельно про случай, когда персональные данные клиентов попадают в свободный текст - в переписки и обращения. Телефоны, почта, ИНН и карты находятся регулярными выражениями, потому что у них жёсткий формат. Имена, адреса и названия компаний так не находятся, для них нужны отдельные модели распознавания сущностей, и с русским языком они работают заметно хуже без дообучения. Команда Just AI, которая делает такой фильтр, формулирует ограничение прямо: пропущенная сущность означает утечку персональных данных, а ложное срабатывание искажает смысл запроса (разбор на Хабре).

Что вендоры моделей делают с вашим вводом?

Российские вендоры пишут об этом прямо. В соглашении об использовании GigaChat для физических лиц (редакция от 06.02.2026) есть пункт 8.7:

«Клиент обязуется не предоставлять/загружать в Сервис какие-либо персональные данные третьих лиц»

• Соглашение об использовании сервиса GigaChat для физических лиц, п. 8.7, Сбер (источник)

То есть, отправив персональные данные клиентов в потребительский GigaChat, вы нарушаете и 152-ФЗ, и договор с самим вендором.

У Яндекса в условиях использования генеративных технологий (редакция от 24.10.2025) сформулировано иначе, но не мягче:

«Яндекс вправе использовать Запросы и Контент для любых целей и любыми способами по своему усмотрению»

• Условия использования технологий генеративного искусственного интеллекта Яндекса, п. 3.2 (источник)

По зарубежным вендорам формулировки приведены пересказом их публичных политик, без кавычек. Смысл у обоих один: потребительский продукт и бизнес-договор разведены. Если сотрудник оплатил подписку личной картой, он работает в потребительском режиме независимо от тарифа. Подробнее про выбор между зарубежными и российскими моделями - в разборе российских нейросетей для бизнеса и отдельно про GigaChat.

Три сценария: чат, бот с CRM и локальная модель

По исследованию «Информзащиты» (июль 2026), 20% организаций, столкнувшихся с утечками, связали инциденты с несанкционированным применением ИИ - годом ранее таких было 12%. Внутри этой доли 42% инцидентов пришлись на веб-интерфейсы нейросетей, 24% на браузерные расширения и помощники, 19% на самостоятельно подключённые API. Почти у трети компаний, использующих ИИ, находят хотя бы один ключ доступа или секрет в небезопасном месте.

Второй сценарий выглядит безопаснее первого, и здесь его главный риск: объём переданного определяют настройки интеграции. Сотрудник этот объём уже не контролирует. Поэтому при подключении бота к системе учёта набор доступных полей описывают заранее - именно на это уходит основная работа при интеграции чат-бота с CRM. Как устроена сама связка, разбирал отдельно в материале про ИИ для CRM.

Что подписать с клиентом и подрядчиком?

Часть 3 статьи 6 разрешает оператору поручить обработку другому лицу с согласия субъекта и на основании договора. В поручении должны быть определены перечень данных и действий с ними, цели обработки и обязанность соблюдать конфиденциальность.

Дальше идёт норма, которая закрывает популярную отговорку:

«В случае, если оператор поручает обработку персональных данных другому лицу, ответственность перед субъектом персональных данных за действия указанного лица несет оператор»

• Федеральный закон № 152-ФЗ «О персональных данных», ч. 5 ст. 6 (источник)

Со стороны клиента нужно согласие. Часть 1 статьи 9 требует, чтобы оно было конкретным, предметным, информированным, сознательным и однозначным, и оформлялось отдельно от прочих документов. Практический смысл: согласие «на обработку в целях исполнения договора», подписанное два года назад, не покрывает передачу тех же данных в стороннюю ИИ-систему. Цель другая - значит, и согласие нужно другое, с упоминанием обработчика по поручению.

С площадки бота или CRM полезно письменно получить три ответа: какую модель она использует и где та физически работает, есть ли поручение на обработку в оферте, какие поля уходят в модель. Если вендор не отвечает на них письменно, это повод искать другого.

Сколько стоит ошибка: штрафы по КоАП

Суммы ниже сняты со статьи 13.11 КоАП в редакции от 7 июля 2026 года. Редакция меняется, перед решениями сверяйте актуальную.

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

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

Почему Сбер, Яндекс и Авито просят смягчить правила

Обращение подписали Авито, Сбер, Ростелеком, Яндекс, HH и VK. Суть просьбы - упростить использование обезличенной персональной информации для разработки и обучения нейросетей. Условия, которые ассоциация предлагает сама:

«Обработка при этом должна проходить в России, российскими компаниями и только для разработки, обучения и применения ИИ»

• об обращении Ассоциации больших данных в Минцифры, Anti-Malware.ru, 06.08.2026 (источник)

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

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

Типичная же выгрузка из CRM отправляется в чат сырой, вместе с персональными данными клиентов. Общий контур регулирования ИИ разбирал в материале про закон об ИИ для бизнеса.

С чего начать на этой неделе

1. Напишите правило на одну страницу. Что можно отправлять в нейросети, что нельзя, каким сервисом пользоваться. По данным ГК «Солар», изучившей трафик 150 компаний, около 60% российских организаций не имеют формализованных политик работы с ИИ-сервисами, а объём отправляемых наружу данных за 2025 год вырос в 30 раз.
2. Разведите выгрузки на два листа. Ключ остаётся у вас, наружу идут ID и рабочие поля. Схема с листом «Ключ» и листом «Для модели».
3. Проверьте, какие поля читают ваши боты и интеграции. Часто доступ выдан ко всей карточке, хотя задача требует двух полей.
4. Соберите документы. Уведомление оператора в Роскомнадзор, актуальное согласие с упоминанием обработчика, поручение на обработку в договоре с подрядчиком.
5. Решите вопрос с режимом. Для регулярной работы с данными клиентов нужен корпоративный доступ или модель в своём контуре. Личный аккаунт сотрудника для этого не подходит.

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