TL;DR
Когда LLM просят найти риски приватности в описании системы, она уверенно находит технические угрозы — несанкционированный доступ, слабое шифрование, утечки. А вот риски, связанные с правами человека — доступ к своим данным, право на исправление, механизм обжалования решений — модель упускает почти всегда, даже если явно не просить её сфокусироваться только на безопасности.
Разница огромная: угрозу "несанкционированный доступ" модели пропускают в 30% случаев, а проблему "нет механизма для доступа/исправления/обжалования данных" — в 91% случаев. Причина простая: тексты про security threats модель видела тысячи раз в обучении, а формулировки про процедурные права пользователя — редкий и специфичный паттерн, который не активируется сам по себе.
Исследователи не предлагают новую технику промптинга — они честно замерили, насколько LLM справляется с полноценной оценкой рисков приватности (Privacy Impact Assessment, официальный документ для госорганов США), сравнив ответы моделей с экспертными заключениями. Вывод: без явной структуры и подсказки категорий модель делает однобокий анализ — сильный по безопасности, слабый по правам пользователя.
Схема метода (как тестировали, применимо как workflow)
ШАГ 1: Дать модели описание системы (что собирают, зачем, кто видит, сколько хранят) → текст
ШАГ 2: Попросить сгенерировать до 10 рисков + до 10 мер снижения, каждый с описанием, обоснованием и цитатой-доказательством → структурированный JSON
ШАГ 3: (опционально) Добавить инструкцию "думай по шагам" (Chain-of-Thought) → эффект непостоянный
ШАГ 4: Сравнить со списком эксперта → посчитать совпадения
Все шаги — в одном запросе к модели (кроме сравнения с эталоном, которое делали отдельно исследователи).
Пример применения
Задача: Команда делает мобильное приложение для трекинга здоровья (по типу разделов "Здоровье" у Яндекса или Сбера) и перед релизом хочет быстро прогнать проверку рисков приватности через ChatGPT, а не ждать штатного юриста.
Промпт:
Ты — эксперт по приватности, проводишь оценку рисков приватности (Privacy Impact Assessment) для системы ниже.
Контекст системы:
Мобильное приложение собирает данные о шагах, пульсе, сне и весе пользователя через синхронизацию с фитнес-браслетом. Данные хранятся в облаке 3 года, передаются партнёру-аналитику для персонализации рекомендаций. Пользователь регистрируется по номеру телефона.
Задача:
1. Составь список до 8 рисков приватности, ранжированных по важности. Для каждого укажи описание, обоснование и на что в описании системы это опирается.
2. Явно проверь и отдельно укажи риски по каждой категории:
- Технические угрозы безопасности (утечка, взлом, несанкционированный доступ)
- Права пользователя (может ли он посмотреть свои данные, исправить, удалить, обжаловать автоматическое решение, получить уведомление об изменениях)
- Избыточный сбор данных или неясная цель использования
- Передача данных третьим лицам без явного согласия
3. Для каждого риска предложи конкретную меру снижения с обоснованием — без общих фраз типа "усилить защиту", только конкретика под этот контекст.
Выведи результат как два списка: "Риски" и "Меры", без вступлений.
Результат: Модель выдаст структурированный список рисков и мер. Без явного указания категорий в пункте 2 модель, скорее всего, сделает акцент на технической безопасности и передаче данных партнёру, а пункты про право пользователя на удаление/исправление/обжалование даст поверхностно или пропустит. С явным указанием категорий — покрытие будет заметно шире.
Почему это работает
LLM генерирует текст по паттернам, которые чаще встречались в обучении. Про "утечку данных" и "несанкционированный доступ" написано огромное количество текстов — модель уверенно воспроизводит этот паттерн без подсказок.
А формулировки про процедурные права ("механизм обжалования решения", "право на исправление персональных данных") — узкая юридическая терминология, которая реже встречается вне специфичных регуляторных документов (GDPR, Privacy Act). Модель не ошибается, она просто не видит повода поднять эту тему, если её не попросить прямо.
Рычаг управления: если вы просите модель оценить риски (не только приватности — любые комплаенс- или бизнес-риски), не надейтесь на то, что она сама покроет все аспекты. Явно перечислите категории проверки — это заставляет модель "заглянуть" в те зоны, которые иначе останутся слепыми.
Второй рычаг: инструкция "думай шаг за шагом" (Chain-of-Thought) в этой задаче работала непредсказуемо — где-то улучшала результат, где-то ухудшала. Не добавляйте её автоматически как "универсальный улучшитель" — для задач комплаенс-анализа проверяйте оба варианта и сравнивайте.
Шаблон промпта
Ты — эксперт по приватности/рискам, проводишь оценку для системы ниже.
Контекст системы:
{описание_системы: что делает продукт, какие данные собирает, зачем, кто имеет доступ, сколько хранит, кому передаёт}
Задача:
1. Составь список до {число} рисков, ранжированных по важности. Для каждого: описание, обоснование, цитата/факт из контекста, который это подтверждает.
2. Явно проверь и укажи риски по категориям:
- {категория_1, например: технические угрозы безопасности}
- {категория_2, например: права пользователя — доступ, исправление, удаление, обжалование}
- {категория_3, например: избыточность сбора / неясная цель}
- {категория_4, например: передача третьим лицам}
3. Для каждого риска — конкретная мера снижения с обоснованием, без общих фраз.
Выведи два списка: "Риски" и "Меры".
Подставляйте в {категория_N} те аспекты, которые важны для вашей задачи — не только приватность, но и, например, юридические, репутационные, финансовые риски проекта.
🚀 Быстрый старт — вставь в чат:
Вот шаблон оценки рисков. Адаптируй под мою задачу: {твоя задача — опиши продукт/систему}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про детали системы (какие данные, кому передаются, как долго хранятся) — потому что без конкретики модель либо выдаст общие фразы, либо упустит категории, которые вы не назвали явно.
Ограничения
⚠️ Слепая зона по умолчанию: без явного перечисления категорий модель систематически упускает риски, связанные с правами человека (доступ, исправление, обжалование) — почти в 9 из 10 случаев.
⚠️ Не замена эксперту: даже лучшая модель в среднем совпадает с экспертной оценкой меньше чем наполовину. Используйте как черновик для быстрого старта, не как финальный документ для регулятора.
⚠️ CoT непредсказуем: инструкция "думай по шагам" в задачах комплаенс-анализа иногда улучшает результат, иногда портит. Проверяйте оба варианта на своей задаче.
⚠️ Читаемость не улучшается: тексты, сгенерированные LLM, читаются не легче, чем тексты, написанные экспертами-юристами — не ждите, что модель сделает документ понятнее для нетехнического человека.
Как исследовали
Исследователи собрали 499 официальных документов оценки приватности, опубликованных пятью федеральными агентствами США (от Минсельхоза до Минздрава) — это обязательные публичные отчёты, которые готовят перед запуском систем, собирающих личные данные. Из них отобрали 73 документа, где анализ рисков можно чисто отделить от описания системы, и с помощью LLM-классификатора (проверенного вручную на точность 96–100%) выделили 451 риск и 831 меру как эталонные ответы экспертов.
Дальше пять моделей (четыре открытые — Qwen, Llama, DeepSeek — и GPT-5.4-mini) получали описание системы и должны были сами предложить риски и меры, с CoT и без. Ответы сравнивали с эталоном через LLM-судью.
Что удивило: увеличение модели с 7 до 14 миллиардов параметров и добавление рассуждений по шагам давали противоречивый эффект — иногда лучше, иногда хуже. Это значит, что дело не в "уме" модели, а в отсутствии структурированного знания о том, как выглядит полноценная оценка рисков. Отсюда практический вывод: бесполезно просто взять модель побольше или добавить "подумай shag за шагом" — нужно явно задавать структуру и категории проверки в самом промпте.
Ресурсы
PIA-Bench (готовится к публикации репозиторий). Авторы: Jiamin Zheng, Luo Mai, Jingjie Li (University of Edinburgh), Hao-Ping (Hank) Lee (Carnegie Mellon University). Упомянутые фреймворки для расширения категорий проверки: LINDDUN и базы знаний CNIL.