Почти каждый разговор про ИИ в компании рано или поздно упирается в одну фразу: «а давайте обучим модель на нашей клиентской базе».
Звучит логично. У вас накоплены годы переписок, заявок, договоров, историй сделок — именно на этом ИИ и был бы полезнее всего. Проблема в том, что почти всё перечисленное содержит персональные данные, а с ними так просто поступать нельзя.
Разберём, что закон разрешает, что запрещает и какие шаги нужно сделать до того, как отдавать данные разработчику. Сразу оговорюсь: я не юрист и статья не заменяет консультацию. Пишу из практики проектов, где эти вопросы приходится решать до начала работ.
Что вообще считается персональными данными
Здесь у предпринимателей чаще всего и возникает первое заблуждение.
Персональные данные — это не только паспорт и адрес. Это любая информация, по которой человека можно определить. Телефон, электронная почта, номер заказа, привязанный к имени, история покупок конкретного клиента — всё это попадает под закон.
И тут возникает главная развилка. Пока данные позволяют опознать человека, они защищены со всеми вытекающими требованиями. Как только опознать невозможно — это уже обезличенные данные, и работать с ними значительно проще.
Собственно, весь сюжет про обучение ИИ на клиентской базе сводится к тому, чтобы правильно перейти из первого состояния во второе.
Что такое обезличивание и как это делают
Обезличивание — не «замазали фамилию и ладно». Это набор конкретных технических приёмов, и государство их описало.
Постановление Правительства от 1 сентября 2025 года № 1154 определяет допустимые методы для государственных систем: удалить прямые идентификаторы, заменить их на новые сгенерированные, убрать квазиидентификаторы, комбинировать эти способы между собой. Роскомнадзор в своём приказе перечисляет похожий набор: введение идентификаторов, изменение состава или смысла данных, разбиение на части, перемешивание.
Звучит сухо, поэтому переведу на понятный язык.
Прямые идентификаторы — имя, телефон, почта, номер документа. Их либо удаляют совсем, либо заменяют на служебный код: вместо «Иванов Иван» появляется «клиент №4471», и связь между кодом и человеком хранится отдельно, в другом месте и под другим доступом.
Квазиидентификаторы — самое интересное и самое недооценённое. Это данные, которые по отдельности никого не выдают, а вместе — вполне. Город, год рождения, должность и размер компании по отдельности безобидны. Вместе они могут указывать ровно на одного человека в вашей базе. Поэтому обезличивание — это не только «стереть имя», но и проверить, не собирается ли личность обратно из оставшихся кусочков.
Перемешивание и разбиение нужны там, где важна структура данных, но не важна их привязка друг к другу. Например, для обучения модели на текстах обращений сами тексты нужны, а вот кто именно писал — нет.
Что бизнес обязан отдавать государству
Отдельный сюжет, о котором многие не знают.
С сентября 2025 года в России работает государственная система обезличенных данных. Компании-операторы данных загружают в неё датасеты по запросам уполномоченных органов — порядок описан в постановлении № 1154 и опирается на закон о едином регистре сведений о населении.
Смысл государственной затеи понятен: собрать большие наборы обезличенных данных, на которых можно обучать российские модели, не нарушая прав людей.
Что из этого следует для вас практически. Если ваша компания обрабатывает значительные объёмы персональных данных, вопрос обезличивания перестал быть вашим внутренним делом — к нему может появиться внешний интерес. Проверить свой статус и обязанности стоит заранее, а не в момент получения запроса. Это как раз тот вопрос, который лучше один раз задать юристу.
Как это выглядит в реальном проекте
Теперь практическая часть — как мы обычно раскладываем такую задачу.
Первым делом отвечаем на вопрос, нужны ли персональные данные для решения задачи вообще. В восьми случаях из десяти оказывается, что не нужны. Чтобы система научилась отвечать на типовые вопросы клиентов, ей нужны сами вопросы и ответы, а не имена и телефоны тех, кто их задавал. Это самый дешёвый и самый надёжный способ закрыть тему: не берите то, что вам не требуется.
Если данные всё-таки нужны — например, система должна учитывать историю конкретного клиента, — работают с ними иначе. Модель не обучают на этих данных, а дают ей доступ к ним в момент ответа, при этом данные остаются в вашем контуре и никуда не копируются. Технически это та же схема, что я описывал в статье про нейросети для документов: система ищет по вашей базе и отвечает по найденному.
И третий вариант, для случаев с самыми чувствительными данными: всё разворачивается на вашем сервере. Ни один запрос не уходит наружу, обучение и работа идут внутри периметра. Дороже, чем облако, зато вопрос передачи данных третьим лицам снимается полностью — а вместе с ним и часть требований, которые эту передачу регулируют.
Что здесь важно понять владельцу: выбор между этими тремя вариантами делается не программистами и не по цене. Он определяется тем, какие данные нужны и какие ограничения на них наложены. Поэтому юрист в таком проекте появляется на первой встрече, а не на приёмке.
Три вопроса перед стартом проекта
Прежде чем отдавать данные подрядчику, ответьте на три вещи.
Какие данные действительно нужны для задачи? Не «выгрузим всё, пусть разбираются», а конкретный минимальный набор. Это и дешевле, и безопаснее.
Можно ли решить задачу без персональных данных? Чаще всего можно, и это стоит проверить до начала работ, а не после.
Где данные будут храниться и обрабатываться? Ваш сервер, российское облако, зарубежный сервис — три разных правовых режима, и решать это нужно до того, как что-то куда-то уехало.
Компании, которые проходят эти три вопроса до старта, тратят на юридическую часть проекта недели. Те, кто вспоминает о них на середине, — месяцы, а иногда переделывают всё заново.