Правовой режим данных для обучения ИИ: персональные и цифровые данные
Небольшая зарисовка, из которой обычно и начинается головная боль
У меня есть любимый тип диалога с бизнесом. Он звучит примерно так: «Эльвира, у нас есть данные, хотим обучить модель. Это же наши данные, да? Значит можно». И дальше, пока человек наливает себе кофе, выясняется, что «наши данные» это выгрузка из CRM с телефонами, письмами, адресами доставки, перепиской поддержки, иногда голосовыми, и парой сканов паспортов, которые “случайно” остались в папке. А ещё там есть таблица с контрагентами, где половина строк набрана вручную менеджером, а другая половина приехала из внешней базы. И вот на этом месте правовой режим данных перестаёт быть теорией из учебника и превращается в то, что либо спасает проект, либо хоронит его под рисками.
Самое забавное, что внутри команды обычно все добрые и рациональные. Никто не хочет нарушать закон. Просто данные для обучения ИИ воспринимаются как “сырьё”, а не как объект, у которого есть свой правовой режим персональных данных в РФ, свой правовой режим цифровых данных, и иногда даже правовой режим базы данных. И если это пропустить, вы можете потратить месяцы на подготовки данных для обучения, а потом в последнюю неделю выяснить, что датасет нельзя использовать в исходном виде. Я такое видела не раз, и каждый раз жалко времени: и своего, и клиента.
Что можно унести с собой и применить на практике
Ниже я раскладываю, как в реальном проекте проверить “годность” массива под данные для обучения модели: где там персональные данные по 152-ФЗ, где обезличенные данные (которые иногда всё равно могут “склеиться” обратно в человека), что делать с синтетическими данными, и как не забыть про права на базу как объект. Если сделать всё последовательно, можно собрать нормальный правовой режим защиты персональных данных, не тормозя машинное обучение для анализа данных, и не превращая юриста в человека, который приходит только сказать «нельзя».
Пошаговый гайд: как легально и спокойно собрать данные для обучения
Шаг 1. Назвать данные своими именами, а не “у нас просто табличка”
Первое, что мы делаем, это раскладываем массив на виды данных. Не по форматам “CSV/JSON”, а по правовой природе. Персональные данные по 152-ФЗ это любая информация, относящаяся к прямо или косвенно определяемому физлицу. То есть телефон, email, ID в приложении, история заказов, голос клиента, и даже “косвенные” связки. Тут и появляется понятие и правовой режим персональных данных, от которого потом пляшут все решения. Параллельно отмечаем, что в наборе может быть то, что люди называют “цифровыми данными” в широком смысле: логи, клики, события, метрики, тексты обращений. На них тоже может распространяться правовой режим цифровых данных, но главное, что часть из них внезапно окажется персональными.
Типичная ошибка на этом шаге: считать, что если в датасете нет ФИО, то “Нет данных данные для обучения” про людей. Увы, нет. Проверьте себя простым тестом: может ли сотрудник компании, имея доступ к внутренним системам, по этим полям понять, кто это? Если да, вы в зоне персональных данных. И ещё один маркер: если вы в будущем планируете обогащать набор другими источниками, риск реидентификации растёт, и обезличивание уже не выглядит “магической таблеткой”.
Шаг 2. Понять, на каком основании вы вообще берёте это в обучение
Дальше вопрос неприятный, но честный: на каком правовом основании данные попадают в обучение? Если это персональные данные, то чаще всего упираемся в согласие субъектов. Практический совет, который я видела в хороших согласиях: формулировка должна прямо покрывать “использование данных для автоматизированной обработки, включая обучение алгоритмов и моделей ИИ”. И это не придирка ради придирки. Данные для обучения искусственного интеллекта это не то же самое, что “для исполнения договора доставки”, и контролирующие органы могут задать вопросы. Особенно если вы обучаете не узкую внутреннюю штуку, а что-то масштабнее.
Типичная ошибка: взять старые согласия “на обработку” и решить, что они резиновые. Проверка простая: откройте тексты согласий в вашем сайте/приложении, найдите цель обработки, состав данных и действия с данными. Если обучения моделей там нет, лучше не фантазировать. Один кейс из практики: у клиента, который продавал через маркетплейсы и свой сайт, юристы за два рабочих дня пересобрали форму согласия и политику, а команда данных спокойно продолжила готовить признаки. Потеряли неделю на согласования с продуктом, зато не пришлось выбрасывать датасет за день до старта экспериментов.
Шаг 3. Развести “обучение внутри” и “обучение наружу”, а потом ещё раз развести
Здесь я часто торможу команду и задаю странный вопрос: а где будет жить модель и кто её будет трогать руками? Если подрядчик обучает модель на ваших данных, это совсем другой разговор, чем когда вы делаете всё у себя. В договорной части это влияет на режим доступа, конфиденциальность, запреты на вторичное использование, и вообще на то, что вы реально контролируете. Если планируется обмен данными между юрлицами, логично заранее закрепить, что именно считается данными для машинного обучения, кто оператор, кто обработчик, и что происходит с датасетом после обучения. Правовой режим данных в таких проектах обычно ломается не на “законах”, а на бытовом: кто куда скинул архив и кто кому дал доступ в облако.
Типичная ошибка: отправить подрядчику “тестовый” датасет, который на самом деле боевой, просто обрезан на 10%. Проверка простая и скучная: список полей и пример строк (да, вручную глазами) до передачи. В одном проекте по скорингу в финсекторе команда обезличила часть идентификаторов, но оставила редкие комбинации признаков, по которым сотрудник банка мог восстановить конкретного клиента. Пришлось переделывать обезличивание и параллельно править ТЗ, чтобы не потерять качество модели. Неприятно, зато честно.
Шаг 4. Обезличить так, чтобы не получилось “собрали обратно”
Обезличенные данные звучат как спасение: удалили ФИО, заменили телефон на хеш, и вперёд, данные для обучения нейронных сетей готовы. Но у обезличивания есть подлая сторона: риск реидентификации. Если набор богатый и его можно скрестить с другими источниками, то “безличный” пользователь внезапно становится вполне конкретным. Про это часто забывают, особенно когда хотят сделать “витрину” под аналитиков и дать к ней широкий доступ. Правовой режим персональных данных не исчезает только потому, что вам так удобнее. Он может смягчиться, но не испариться.
Типичная ошибка: обезличивать только прямые идентификаторы и оставлять всё остальное, включая редкие адреса, координаты, свободный текст обращений. Проверка: попробуйте внутри компании провести “игру в детектива”. Дайте сотруднику, который знает бизнес, десять строк обезличенного набора и попросите угадать, кто где живёт, кто ругался в поддержке и кто “тот самый клиент”. Если угадывается, значит обезличивание декоративное, и правовой режим защиты персональных данных у вас на честном слове.
Шаг 5. Рассмотреть синтетические данные, когда для обучения нужны данные, но нельзя трогать живых людей
Синтетические данные это искусственно сгенерированные наборы, которые имитируют свойства реальных данных без прямого воспроизведения исходных сведений о конкретных лицах. В проектах, где данные чувствительные, это реально выручает. Мне нравится подход “сначала синтетика, потом узкий пилот на реальном”: он дисциплинирует команду, позволяет проверить пайплайн, качество признаков, устойчивость модели. И если потом окажется, что юридически реальный датасет “не проходит”, вы хотя бы не стоите с пустыми руками. Правовой режим больших данных тоже проще обсуждать, когда часть нагрузки снята синтетикой.
Типичная ошибка: думать, что синтетические данные это всегда “на 100% безопасно” и “на 100% так же эффективно”. Они снижают риски, да, и исследования отмечают, что можно сохранить высокую эффективность моделей, но качество зависит от того, как вы генерируете синтетику. Проверка: сравните распределения ключевых признаков и метрики на валидации, а ещё попросите data science команду показать, нет ли “утечек” редких комбинаций, которые слишком напоминают реальных людей. Мини-кейс: в медицине синтетика часто используется для обучения диагностических моделей, чтобы не раскрывать данные пациентов. Но там обычно очень строго следят за тем, чтобы синтетический набор не “копировал” конкретные истории болезни. И это правильно, потому что цена ошибки высокая, вобще без шуток.
Шаг 6. Не забыть про базу данных как объект, даже если вы “просто обучаете модель”
Иногда в проекте всплывает не только персоналка, но и правовой режим базы данных. Если вы собрали базу с существенными затратами, она может охраняться как объект, и тогда вопрос “кто имеет право использовать” становится не менее важным, чем “можно ли обрабатывать”. Особенно когда часть массива пришла от партнёров, из сторонних источников, или из стартапа, который купили вместе с кодом. Правовой режим данных здесь упирается в цепочку прав: кто создавал, на каких условиях, что было в договорах с подрядчиками, кому принадлежат исключительные права на состав и структуру.
Типичная ошибка: считать, что раз доступ есть, значит право тоже есть. Проверка: поднимите договоры с разработчиками, интеграторами, и условия получения внешних выгрузок. Если где-то написано “только для внутренней аналитики” или “запрет на передачу третьим лицам”, обучение внешней модели может оказаться нарушением. Был случай: маркетинговая команда купила доступ к коммерческой базе для рассылок, а потом тот же массив захотели использовать как данные для обучения нейросети, которая пишет тексты для sales. Пришлось остановиться, потому что лицензия не покрывала такое использование, и это было бы уже не про креатив, а про риск.
Шаг 7. Зафиксировать режим в документах и в технике, иначе всё развалится от человеческого фактора
Когда юридическая часть более-менее ясна, её надо “прикрутить” к реальности: доступы, журналы, роли, хранение, сроки, удаление. Тут не нужно изображать госорган, но нужно сделать так, чтобы правовой режим персональных данных и правовой режим цифровых данных совпадали с тем, что реально происходит в инфраструктуре. Часто помогает простая вещь: единый паспорт датасета, где написано, откуда данные, какие поля персональные, какое основание обработки, где хранится, кто имеет доступ, и можно ли использовать для обучения модели. Да, звучит скучно, но это экономит недели споров.
Типичная ошибка: документы отдельно, инженерия отдельно. Проверка: попросите DevOps или безопасника показать, где лежат данные для обучения ИИ, кто может их скачать, и как быстро можно отозвать доступ. Если ответ “ну там ссылка в чате была” или “у нас один общий токен”, то правовой режим без данных становится реальнее, чем хотелось бы: формально всё запрещено, потому что контролировать нечего. И ещё момент: подпишитесь на Телеграмм канал Патентного бюро Лирейт», там мы иногда разбираем такие бытовые провалы без морализаторства. Если Телеграмм неудобен, есть Канал в Максе Патентного бюро Лирейт», формат тот же, просто платформа другая.
Подводные камни, о которые чаще всего спотыкаются
Первый камень это вера в “обезличивание по умолчанию”. Команда честно удаляет ФИО и телефоны, и думает, что дальше можно жить свободно. Но потом в датасет добавляют историю заказов, редкие адреса, тексты обращений, и получается почти биография человека, просто без подписи. И если к этому подключить другие массивы, шанс реидентификации растёт. Тут важно не впадать в паранойю, но держать в голове: обезличенные данные не равны “никаких рисков”. Если вы строите продукт на больших массивах, правовой режим больших данных почти всегда будет требовать дисциплины, а не “разовой чистки”.
Второй камень это договоры и лицензии, которые “не про ИИ”. Особенно когда данные пришли из партнёрских систем, интеграций, купленных баз, или от подрядчика, который когда-то собирал всё “под ключ”. Правовой режим базы данных может оказаться тем самым замком, который закрывает дверь. У меня было ощущение, что некоторые компании тратят больше сил на выбор фреймворка, чем на проверку, есть ли у них право использовать конкретный массив как данные для обучения модели. А потом удивляются, почему юристы тормозят запуск. Они не вредные, они просто видят, где у вас тонко.
Третий камень это странные запросы из серии “дайте определение понятия государственно правовой режим”. Обычно его задают не потому, что человеку реально нужно определение, а потому что он пытается понять: “а государство вообще как к этому относится?”. И тут честный ответ такой: подход развивается, появляются новые инициативы и обсуждения, но базовые правила про персональные данные уже действуют. Поэтому лучше не ждать идеального отдельного закона “про данные для обучения нейронных сетей”, а выстроить у себя понятный правовой режим защиты персональных данных и нормальную работу с доступами. Иначе у вас будет много умных разговоров и мало работающего датасета.
Когда имеет смысл подключать помощь по интеллектуальной собственности
Если вы собираете собственный датасет, вкладываетесь в разметку, чистку, подготовки данных для обучения, и планируете, что это станет активом, я бы не оставляла всё “на уровне устных договорённостей”. Тут важны и права на базу, и условия с подрядчиками по разметке, и режим коммерческой тайны, и то, как вы будете доказывать происхождение массива. Иногда один нормально оформленный комплект документов экономит месяцы, потому что следующий инвестор или партнёр не начинает проверку с нуля и не задаёт сто одинаковых вопросов.
Ещё помощь нужна, когда проект на стыке: часть данных персональные, часть партнерские, часть синтетические, а модель вы хотите внедрить в продукт, где будут пользователи и обновления. Это не “юридическая красота”, это способ не остановиться на середине. Если хотите, можно посмотреть материалы и контакты на https://lireate.com/, а новости и разборы кейсов удобнее ловить в каналах, я выше оставила ссылки. Мне самой проще обсуждать такие вещи на примерах, а не в вакууме.
FAQ
Вопрос: Персональные данные для обучения ИИ это только ФИО и паспорт?
Ответ: Нет. По 152-ФЗ персональные данные это любая информация о прямо или косвенно определяемом человеке. Это могут быть телефоны, email, идентификаторы, история заказов, голос, переписка, и даже набор признаков, по которому человека можно “угадать” внутри системы.
Вопрос: Если мы обезличили датасет, правовой режим персональных данных больше не применяется?
Ответ: Обезличивание снижает риски, но не отменяет их автоматически. Есть риск реидентификации, особенно если данные можно скрестить с другими источниками. Проверяйте обезличивание на практике, а не по ощущению “вроде всё убрали”.
Вопрос: Можно ли использовать клиентские данные для обучения модели без отдельного согласия?
Ответ: На практике безопаснее исходить из того, что для обучения алгоритмов и моделей ИИ нужно явное согласие, где эта цель прямо названа. Старые формулировки “на обработку для оказания услуг” часто не покрывают обучение модели в нужном объёме.
Вопрос: Что считается синтетическими данными, и почему их любят для машинного обучения?
Ответ: Синтетические данные это искусственно сгенерированные наборы, которые имитируют свойства реальных данных без прямого воспроизведения сведений о конкретных людях. Их используют, когда для обучения нужны данные, но трогать реальные персональные массивы рискованно или неудобно.
Вопрос: У нас “просто выгрузка из CRM”. Это правовой режим базы данных или что-то другое?
Ответ: Может быть и то, и другое. Внутри выгрузки часто есть персональные данные, а сама структура и подборка могут подпадать под правовой режим базы данных. Всё зависит от того, как база создавалась, кто её собирал и какие права закреплены договорами.
Вопрос: Что делать, если команда данных говорит “Нет данных данные для обучения”, но бизнес просит быстрее?
Ответ: Не ускорять за счёт “взяли что нашли”. Часто спасает синтетика для отладки пайплайна, параллельно работа с согласиями и чисткой реального массива, и чёткий паспорт датасета. Тогда проект не стоит, но и не едет на нарушениях.
Вопрос: Почему все внезапно вспоминают запрос “дайте определение понятия государственно правовой режим” именно в ИИ-проектах?
Ответ: Потому что людям хочется простого ответа “можно или нельзя”. Но в данных для обучения искусственного интеллекта всё упирается в конкретику: какие данные, чьи, на каком основании, где хранятся и кто имеет доступ. Определения тут помогают мало, помогает дисциплина и документы.