Может ли ИИ выдать чужие персональные данные: галлюцинации и приватные модели

Периодически в новостях появляется история: пользователь спросил у модели о каком-то человеке, и та выдала домашний адрес, номер телефона или подробности биографии. Репосты идут волнами. Кто-то делает вывод, что ИИ читает закрытые базы данных. Кто-то предполагает, что модель «утекает» данные, которые ей скормили предыдущие пользователи.

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

Галлюцинация против реальной утечки

Когда модель выдаёт «адрес реального человека», в большинстве случаев происходит не утечка данных, а галлюцинация.

Языковая модель не работает как поисковик и не хранит записи о конкретных людях в привычном смысле. Она обучена на огромном корпусе текстов и умеет генерировать правдоподобный текст в ответ на запрос. Когда её спрашивают про человека, о котором в обучающих данных почти ничего нет, она нередко генерирует детали, которые звучат убедительно, но выдуманы. Адрес, телефон, место работы берутся не из базы данных, а «сочиняются» по паттернам текста. Это и есть галлюцинация: не ложь намеренная, а правдоподобный вымысел.

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

Реальная утечка обучающих данных тоже существует, но как явление она устроена иначе. Если в обучающем корпусе содержались тексты с конкретными персональными данными (например, публичные форумы, новостные материалы или утёкшие ранее базы), модель может воспроизвести эти сведения дословно при определённых условиях запроса. Это задокументированный феномен, который исследователи называют запоминанием обучающих данных. Известные публичные модели проходили через такие проверки, и часть данных действительно воспроизводилась. Но это данные из публично доступных или ранее утёкших источников, а не «личное досье», которое кто-то тайно загрузил.

Этот класс рисков входит в типовые угрозы для систем на основе языковых моделей и хорошо известен в профессиональном сообществе.

Как это ограничивают на практике

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

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

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

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

Переворот: не «получим ли чужое», а «не отдадим ли своё»

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

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

Менеджер вставляет в запрос таблицу клиентов, чтобы сегментировать её. Разработчик добавляет реальные строки из тестовой выгрузки «для контекста». Юрист копирует кусок контракта, чтобы попросить помочь с формулировкой. Никакого злого умысла, просто удобный инструмент под рукой. А данные уже ушли.

Именно этот вектор является приоритетным при работе с регуляторными требованиями 152-ФЗ в части языковых моделей. Оператором персональных данных остаётесь вы. Ответственность за то, что с ними произошло после отправки в публичный сервис, тоже ваша.

Как решается задача контроля

Архитектурный ответ на этот вопрос устроен в два слоя.

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

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

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

Честный разговор о пределах

Несколько вещей, которые стоит называть прямо.

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

Маскирование хорошо работает со структурированными данными. Свободный текст сложнее: «клиент из Воронежа, Алексей Петрович, заказывал в марте» автоматически поймать труднее, чем поле телефон: +7 900 000 00 00. Технический контроль и работа с сотрудниками по правилам работы с данными дополняют друг друга.

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

Итог

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

Это решается корпоративным шлюзом с маскированием ПДн и журналированием, а строгие требования к изоляции закрываются приватными или локально развёрнутыми моделями. Контроль над входом и выходом модели остаётся у вас.

Если вы разбираетесь с тем, как выстроить этот контроль применительно к вашей инфраструктуре, подробнее об услуге на странице корпоративного шлюза.