Может ли ИИ выдать чужие персональные данные

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

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

Запоминание - это реально

Начну с того, что действительно правда. Большие языковые модели умеют запоминать дословные фрагменты обучающих данных и при определённых условиях воспроизводить их. Это не гипотеза, это показано в исследованиях. Работа 2021 года «Extracting Training Data from Large Language Models» продемонстрировала, что из модели можно извлечь дословные строки, которые встречались в обучающем корпусе, включая куски текста с персональными данными. В 2023 году был показан приём с «расхождением» (divergence): если заставить рабочего чат-бота бесконечно повторять один токен, он в какой-то момент срывается и начинает выдавать фрагменты обучающих данных.

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

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

Но риск надо калибровать

Теперь трезвая часть. Одно дело - показать в лаборатории, что извлечение в принципе возможно. Другое дело - утверждать, что произвольный человек может задать вопрос и получить паспорт конкретного незнакомца. Спонтанная, адресная выдача приватных данных конкретной частной персоны из чистых весов модели - событие относительно редкое и плохо управляемое. Нельзя надёжно навести модель на «данные вот этого человека» так, как наводят запрос в базе.

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

Ещё одна тонкость, о которой забывают. Извлечение из весов - это не «спросил и получил», это дорогой и шумный процесс. Исследователи, которые показывали такие атаки, генерировали огромные объёмы вывода и потом отдельно проверяли, какие фрагменты совпали с реальными обучающими данными. То есть даже когда извлечение получается, атакующий сначала выуживает гору правдоподобного текста, а потом верифицирует его по внешним источникам. Для случайного приватного человека, чьи данные негде проверить, эта схема почти не работает: атакующий не отличит настоящий адрес от галлюцинации. Именно поэтому целями таких демонстраций становятся публичные, проверяемые данные, а не переписка вашего клиента.

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

Где утечка действительно случается

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

• RAG и загрязнение контекста. Модель в момент ответа получает документы через поиск. Ошибка в извлечении или в контроле доступа - и данные одного клиента (арендатора, tenant) попадают в контекст ответа другому. Модель тут ни при чём, она честно пересказала то, что ей подали. Виноват слой поиска и изоляции.
• Общая история и логи. Журналы диалогов, кеши, промежуточные хранилища и баг с пересечением сессий раскрывают чужие запросы, в которых были персональные данные. Достаточно одной неправильной настройки доступа к логам.
• Сотрудники, вставляющие данные клиентов в промпты. Человек копирует в чат реальную клиентскую информацию, и она оседает в логах вендора, а иногда и в обучающих наборах. Это не атака, это обычная неосторожность, и она случается ежедневно.
• Инъекция промпта (prompt injection). Ассистенту с доступом к инструментам подсовывают текст, который уговаривает его прочитать и выдать данные, к которым он не должен был прикасаться. Здесь утечку провоцируют через инструменты, а не через память модели.

Общий знаменатель простой: во всех четырёх случаях утекают ВАШИ данные о ВАШИХ клиентах через ВАШУ систему. Не абстрактный незнакомец из обучающего корпуса, а конкретный человек из вашей базы. И это ровно та часть, которой вы владеете и которую можете починить. Подробнее про поисковый слой и его ловушки я писал в тексте про RAG в продакшене, а про ассистентов с доступом к инструментам - в разборе поверхности атаки на ассистентов.

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

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

Как я снижаю этот риск

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

• Минимизирую персональные данные на входе. Самый надёжный способ не утечь данными - не заводить их туда, где они не нужны. Я убираю или обезличиваю персональные данные до того, как они попадут в промпт или в поисковый индекс. Чего нет в контексте, то не всплывёт в ответе.
• Строгая изоляция арендаторов на извлечении. Контроль доступа применяется на уровне поиска, до модели, а не после. Каждый запрос к индексу несёт identity пользователя, и фильтр по владельцу данных стоит в самом запросе, а не в надежде, что модель «сама не покажет лишнее».
• Фильтрация вывода и вычистка данных. На выходе стоит проверка, которая ловит и вымарывает персональные данные в ответе. Это не основная защита, а страховочный слой поверх изоляции, но он ловит то, что просочилось раньше.
• Красная команда до запуска. Перед выкатом ассистента я прогоняю его адверсариальными промптами: инъекции, попытки вытащить чужой контекст, повторы токенов, социнженерия внутри диалога. Дешевле найти дыру самому, чем узнать о ней от клиента.
• Контроль хранения и логирования на стороне вендора. Договором и настройками фиксирую, что именно логируется, сколько хранится, идут ли данные в обучение. Часто это отключаемо, и это первое, что надо отключить.

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

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

152-ФЗ смотрит на это как на обработку

Отдельно про регуляторную сторону, потому что её любят откладывать. Когда ваш ассистент читает, пересказывает и передаёт данные клиентов, с точки зрения 152-ФЗ это обработка персональных данных, а нередко и их передача третьему лицу - вендору модели. Отвечает за это оператор, то есть вы, а не модель и не поставщик. Роскомнадзор не интересует, что «так работает нейросеть»: юридически значимо, что вы собрали данные, определили цель и передали их туда, где потеряли над ними контроль.

Из этого следуют скучные, но обязательные вещи: правовое основание на обработку и передачу, минимизация собираемого, понимание, куда физически уходят данные, и оценка вендора как обработчика. Техническая изоляция и юридическая рамка тут не альтернативы, а две половины одного и того же контроля. Про это я подробнее писал в разборе ИИ-контура и 152-ФЗ.

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

Честные оговорки

Несколько мест, где я сознательно не даю однозначного ответа.

• Я не называю цифр. Точная вероятность извлечения зависит от модели, размера, дедупликации корпуса, дообучения и способа атаки. Любое конкретное число здесь было бы выдумкой, а я предпочитаю честную неопределённость выдуманной точности.
• Модели и защиты меняются. То, что вчера извлекалось приёмом с повтором токена, сегодня может быть закрыто на стороне провайдера. И наоборот - завтра найдут новый приём. Считайте механизм существующим, а конкретную дыру - временной.
• Граница между «памятью модели» и «контекстом» размывается. В агентных системах модель ходит по инструментам и подтягивает данные на лету, и внешне это неотличимо от «модель вспомнила». Разбирать инцидент всё равно придётся по слоям, а не по ощущению.
• «Обезличено» не значит «безопасно навсегда». Слабое обезличивание переигрывается сопоставлением с другими наборами. Минимизация надёжнее маскировки: чего нет, то не восстановишь.

Если коротко

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

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