Почти каждый ИИ-проект в российской компании рано или поздно упирается в персональные данные. Резюме, обращения клиентов, записи разговоров, документы — все это подпадает под 152-ФЗ, и вопрос не в том, обойти его или нет, а в том, как построить решение так, чтобы оно было и полезным, и законным. Разберем практическую сторону: что реально мешает, а что оказывается мнимым препятствием.
Сразу оговорка: это инженерный разбор, а не юридическая консультация. Конкретную конфигурацию всегда согласовывайте со своим юристом и службой безопасности — здесь мы описываем, какие технические решения обычно позволяют это согласование пройти.
Что считается персональными данными в ИИ-проекте
Шире, чем обычно думают. Помимо очевидных ФИО, паспорта и телефона, это записи голоса, изображения лица, история покупок, привязанная к клиенту, тексты обращений с упоминанием личных обстоятельств. Отдельная категория — специальные данные: здоровье, судимости, национальность. Требования к ним жестче, и попадают они в проекты чаще, чем ожидается: например, в анкете кандидата или в обращении клиента.
Практический вывод: инвентаризацию данных надо делать до архитектуры, а не после. Обнаружить специальные категории на этапе приемки — значит переделывать хранение и доступы.
Основание обработки — первый вопрос, а не последний
Обрабатывать персональные данные можно только на законном основании. В ИИ-проектах чаще всего работают три.
- Согласие субъекта. Универсально, но хрупко: по закону оно должно быть конкретным, предметным, информированным, сознательным и однозначным, а с 1 сентября 2025 года — оформленным отдельно от других документов. Согласие можно отозвать, и тогда данные надо уметь удалить — включая те, что попали в обучающую выборку.
- Исполнение договора. Работает, когда обработка нужна для того, ради чего договор и заключен: доставка, обслуживание, кадровое оформление. Обучение модели на этих данных под это основание обычно не подпадает.
- Законные интересы оператора. Гибче, но толкуется узко: нужно обосновать, что обработка не нарушает права и свободы человека. Для внутренних задач вроде антифрода применимо, для маркетинговых профилей — спорно.
Главная ошибка здесь — выбрать основание постфактум, когда решение уже построено. Основание определяет, что вообще можно делать с данными, и потому идет первым.
Обезличивание: что это дает и чего не дает
Обезличивание — самый рабочий инструмент в ИИ-проектах. Если из данных убраны идентификаторы и восстановить личность по ним нельзя, режим обработки существенно мягче, хотя по закону такие данные остаются персональными. Для обучения моделей этого обычно достаточно: модели нужны закономерности, а не имена.
Чего обезличивание не решает
Замены имени на идентификатор недостаточно, если по остальным полям человек все равно определяется. Комбинация должности, подразделения и даты приема нередко указывает на единственного сотрудника. Проверять надо не наличие ФИО, а фактическую возможность идентификации — это отдельная работа, и ее стоит закладывать в проект.
Отдельная проблема: данные внутри модели
Языковая модель, дообученная на текстах с персональными данными, может воспроизвести их в ответе. Это не гипотетический риск. Поэтому мы предпочитаем подход, при котором модель не дообучается на чувствительных текстах, а обращается к ним поиском в момент запроса, — тогда права доступа работают на каждом обращении, а не «зашиты» в веса.
Локализация и трансграничная передача
Базы с персональными данными россиян должны находиться в России. Отсюда прямое следствие для ИИ: отправка таких данных в зарубежный облачный сервис — это трансграничная передача со всеми требованиями к ней, включая предварительное уведомление Роскомнадзора, а для многих компаний просто неприемлемый вариант.
Практических выходов три: обезличивать данные до отправки, использовать российские облачные модели, размещенные внутри страны, или разворачивать открытую модель в собственном контуре. Обезличивание снижает риск, но режим трансграничной передачи формально не снимает: по закону такие данные остаются персональными. Третий вариант дороже, но снимает вопрос целиком: данные не покидают периметр физически.
Три архитектуры и их правовые последствия
Зарубежное облако
Дешево и быстро, но для персональных данных россиян почти всегда неприменимо без обезличивания. Годится для задач, где чувствительных данных нет вовсе: работа с обезличенной статистикой, генерация маркетинговых текстов, разбор публичных документов.
Российское облако
Компромисс: локализация соблюдена, инфраструктуру не нужно закупать. Требуется поручить провайдеру обработку по договору и проверить его меры защиты. Для большинства задач среднего бизнеса этого достаточно.
Закрытый контур
Максимальная защищенность и максимальная стоимость: серверы с GPU, размещение, обновления, эксплуатация. Для банков, медицины и государственных учреждений это часто единственный проходимый вариант. У нас есть проект, где собственная языковая модель развернута в контуре заказчика именно потому, что выгрузка кода и данных была запрещена.
Что обычно требует служба безопасности
- Перечень обрабатываемых данных с указанием категорий и оснований обработки.
- Схему потоков: откуда данные приходят, где хранятся, куда уходят, кто имеет доступ.
- Подтверждение локализации: где физически лежит база.
- Механизм удаления по требованию субъекта, включая обучающие выборки и резервные копии.
- Журналирование доступа: кто и когда обращался к данным, с возможностью выгрузки.
- Оценку того, что происходит при компрометации: какой объем данных под угрозой и как это обнаруживается. Об утечке закон требует уведомить Роскомнадзор в течение 24 часов.
Этот список стоит запросить у своей службы безопасности до начала проекта, а не на приемке. Половина требований влияет на архитектуру, и добавить их потом дороже, чем заложить сразу. В нашей практике именно позднее подключение службы безопасности — самая частая причина срыва сроков в ИИ-проектах.
Пять типичных ошибок
- Обучать модель на «сырых» данных, потому что так проще, а обезличить обещать позже. Позже это будет означать переобучение с нуля.
- Считать замену ФИО на идентификатор достаточным обезличиванием, не проверив возможность идентификации по совокупности полей.
- Отправлять данные в зарубежный сервис на этапе прототипа «для быстроты». Прототип часто становится основой рабочей системы.
- Не предусмотреть удаление данных при отзыве согласия — включая копии в обучающих выборках и резервных копиях.
- Подключать службу безопасности после того, как решение готово. Это гарантированная переделка.
Записи разговоров и биометрия
Отдельная зона, где ошибаются чаще всего. Голосовые проекты почти всегда работают с записями разговоров, и здесь есть два разных вопроса, которые смешивают.
Первый: запись содержит персональные данные — то, что человек о себе сообщил. Это обычная обработка со стандартными требованиями. Второй: голос как таковой может использоваться для идентификации, и тогда речь идет о биометрических персональных данных, требования к которым существенно строже.
Практическая граница проходит по цели. Если запись распознается в текст, чтобы понять запрос, и голос не используется для установления личности, это не биометрия. Это, например, обычный голосовой бот вместо IVR. Если система определяет, кто говорит, по голосу — биометрия со всеми последствиями. Это стоит зафиксировать в документах проекта явно, потому что вопрос обязательно возникнет.
Практический прием для голосовых проектов: после распознавания хранить текст, а аудио удалять через короткий срок. Текст обычно достаточен и для работы, и для дообучения, а объем чувствительных данных сокращается радикально. Исключение — задачи, где нужен именно звук, но их меньше, чем кажется на старте.
Что должно быть в согласии, чтобы оно покрывало ИИ
Типичная ситуация: согласие получено давно, сформулировано под учетные задачи и обучение моделей не покрывает. Формально обработка идет за пределами того, на что человек соглашался.
- Цели должны быть перечислены конкретно, включая обучение и проверку моделей, если они планируются. Общая формулировка «в целях деятельности организации» проверку не проходит.
- Перечень обрабатываемых данных должен соответствовать реальности, а не быть шире на всякий случай — избыточность здесь работает против оператора.
- Должны быть названы действия с данными, включая автоматизированную обработку.
- Срок действия согласия и порядок отзыва — с указанием, куда обращаться, и с работающим механизмом отзыва.
Отдельный вопрос — привлечение подрядчика. Если разработчик получает доступ к данным, это поручение обработки: оно оформляется договором с описанием мер защиты и, как правило, требует согласия субъекта. На практике проще и безопаснее строить работу так, чтобы подрядчик работал с обезличенными данными или внутри вашего контура.
Сроки хранения и удаление
Данные нельзя хранить бессрочно «на всякий случай»: срок определяется целью, и по ее достижении данные подлежат удалению или обезличиванию. В ИИ-проектах это создает специфическую сложность — данные размножаются по системам.
К моменту, когда приходит требование об удалении, копии данных человека могут лежать в исходной системе, в промежуточном хранилище, в векторном индексе, в обучающей выборке и в резервных копиях. Механизм удаления должен покрывать все эти места, и проектировать его надо сразу — восстанавливать связи постфактум мучительно.
Практическое решение: сквозной идентификатор субъекта во всех производных хранилищах. Тогда удаление становится процедурой, а не расследованием. Стоит это дешево на этапе проектирования и очень дорого — потом.
Порядок действий для нового проекта
- Составьте перечень данных, которые понадобятся, с указанием категорий и источников. Отдельно отметьте специальные категории.
- Определите основание обработки для каждой цели — до выбора архитектуры.
- Решите, что можно обезличить, и проверьте, что после обезличивания идентификация действительно невозможна.
- Определите, где данные будут находиться физически на каждом этапе, включая обучение и отладку.
- Согласуйте схему со службой безопасности и юристом до начала разработки, а не на приемке.
- Заложите механизм удаления и журналирование доступа в первую версию решения.
Этот порядок выглядит бюрократичным ровно до первого проекта, где его не соблюли. Переделка архитектуры после замечаний безопасности обходится дороже, чем неделя согласований на старте, и почти всегда срывает сроки.
Обезличивание на практике: как это делается
Разберем приемы, которые реально применяются, потому что «обезличить данные» — это не одна операция, а набор решений с разными последствиями для качества модели.
- Удаление прямых идентификаторов: ФИО, паспорт, телефон, адрес. Самое очевидное и самое недостаточное.
- Замена на устойчивый псевдоним: вместо имени — идентификатор, одинаковый для одного человека во всех записях. Позволяет сохранить связи между событиями, что часто критично для модели.
- Огрубление: вместо точной даты рождения — год, вместо точного адреса — район. Снижает риск идентификации, почти не теряя полезного сигнала.
- Обобщение редких значений: если в выборке один человек с определенной должностью, его все равно узнают. Такие категории объединяются в более широкие.
- Маскирование в свободном тексте: имена и контакты внутри обращений и переписки надо находить и заменять автоматически — вручную это нереально на объеме.
Последний пункт заслуживает отдельного внимания, потому что о нем забывают. Персональные данные в структурированных полях обезличить легко. Но те же данные встречаются внутри текста обращения: «звонил Иван Петрович по договору такому-то». Если обезличивание работает только по колонкам, оно создает ложное ощущение безопасности.
Проверять результат стоит не глазами, а попыткой обратного восстановления: возьмите обезличенную выборку и посмотрите, можно ли по совокупности признаков определить конкретного человека. Если да — обезличивание не состоялось, каким бы аккуратным оно ни выглядело.
Коротко
- Основание обработки выбирается до архитектуры, а не после: оно определяет, что вообще можно делать с данными.
- Обезличивание — главный рабочий инструмент, но проверять надо фактическую невозможность идентификации, а не отсутствие ФИО.
- Дообучение на чувствительных текстах опаснее поиска по ним: из весов данные не удалить.
- Для персональных данных правила трансграничной передачи почти закрывают путь в зарубежные облака: остаются обезличивание (оно снижает риск, но этих правил не отменяет), российское облако и закрытый контур.
- Служба безопасности должна войти в проект на этапе архитектуры — позднее подключение стабильно срывает сроки.