Первичный разбор: нужна ли PIA

Быстро решает, нужна ли для новой обработки данных оценка воздействия на приватность, обязательная DPIA или можно продолжать, и ловит конфликты с политикой.

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Быстро решает, нужна ли для новой обработки данных оценка воздействия на приватность, обязательная DPIA или можно продолжать, и ловит конфликты с политикой.
Когда брать: Когда появилась новая функция, сбор данных или поставщик и нужно понять, нужна ли PIA, обязательна ли DPIA и не противоречит ли это политике приватности.
Когда не брать: Если нужна сама оценка воздействия: для неё есть скилл pia-generation. Без настроенного профиля практики скилл остановится или предложит предварительный режим по типовым настройкам.
Пример запроса: Нужна ли PIA для новой функции, которая использует поведенческие данные, чтобы персонализировать рекомендации?
Нужно подключить: доступ к файлам (папка настроек плагина)
Работает лучше с: инструмент юридического поиска (Westlaw, EUR-Lex)

Входит в плагин privacy-legal. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Скачайте архив и распакуйте его.
Положите папку use-case-triage в ~/.claude/skills/.
Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: use-case-triage
description: >
  Быстро определи, нужна ли для вида обработки данных оценка воздействия на приватность (PIA),
  обязательная по GDPR оценка воздействия на защиту данных (DPIA) или можно двигаться дальше. Скилл
  выявляет конфликты с политикой приватности и направляет к нужному следующему шагу. Используй, когда
  пользователь спрашивает «нужна ли для этого PIA», «сделай первичный разбор этой функции»,
  «проверка приватности для X», «это нормально с точки зрения приватности» или описывает новый вид
  обработки данных, функцию продукта либо отношения с поставщиком.
argument-hint: "[describe the data processing activity or feature]"
---

/use-case-triage

Прочитай ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Убедись, что практика приватности настроена; если нет, остановись и направь на настройку.
Выполни рабочий процесс ниже. Если описание вида обработки расплывчатое, уточни его.
Проверка внутренних триггеров → проверка обязательной DPIA (если GDPR входит в охват) → проверка конфликта с политикой приватности.
Результат: классификация (ПРОДОЛЖАТЬ / НУЖНА PIA / DPIA ОБЯЗАТЕЛЬНА / СТОП), обоснование, таблица условий, если они нужны, передачи другим плагинам.
Если оценка нужна, предложи продолжить созданием PIA.

/privacy-legal:use-case-triage "Новая функция, которая использует поведенческие данные для персонализации рекомендаций контента"

Первичный разбор вида обработки по приватности

Контекст дела

Контекст дела. Загляни в раздел ## Matter workspaces в CLAUDE.md уровня практики. Если Enabled равно ✗ (по умолчанию для юристов внутри компании), пропусти остаток этого абзаца: скиллы работают с контекстом уровня практики, а механизм дел остаётся невидимым. Если режим включён, а активного дела нет, спроси: «Для какого дела это нужно? Запустите /privacy-legal:matter-workspace switch <slug> или скажите practice-level». Загрузи matter.md активного дела — там контекст и исключения для этого дела. Результаты записывай в папку дела ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/. Файлы другого дела не читай, если только Cross-matter context не равен on.

Проверка получателя

Прежде чем выдавать результат, проверь, куда он пойдёт. Если пользователь назвал адресата (канал, список рассылки, контрагента, «всех»), спроси, находится ли он внутри круга привилегии (адвокатской тайны). Публичные каналы, общекорпоративные списки, контрагент и юристы противоположной стороны, поставщики и клиенты (если это рабочий материал) лишают защиты. Если адресат выглядит внешним для круга, отметь это и предложи (а) привилегированную версию только для юристов, (б) обезличенную версию для более широкого канала или (в) обе: не ставь молча привилегированный заголовок, а потом не помогай вставить материал туда, где этот заголовок его не защитит. См. эталонный раздел ## Shared guardrails → Destination check в CLAUDE.md этого плагина.

Назначение

Ответь на вопрос, который возникает до того, как кто-либо запустит PIA: «а нужна ли она вообще?» А если нужна, то какая и что мешает идти дальше?

Первичный разбор по приватности быстрее создания PIA, но стоит перед ним. Он не пишет оценку, а определяет, нужна ли она и на каких условиях. Глубокую работу делает скилл создания PIA.

Результат — одна из четырёх классификаций:

ПРОДОЛЖАТЬ (PROCEED) — PIA не нужна. Применяются стандартные меры защиты.
НУЖНА PIA (PIA REQUIRED) — оценка нужна до внедрения или одновременно с ним.
DPIA ОБЯЗАТЕЛЬНА (DPIA MANDATORY) — требуется оценка воздействия на защиту данных, предписанная режимом (изучи триггер применимого режима и цитируй первоисточники). Планка выше, вероятно, потребуется участие DPO или главного юрисконсульта.
СТОП (STOP) — вид обработки противоречит политике приватности или, как описан, не имеет законного основания. Перед продолжением нужно переделать.

Допущение о юрисдикции

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

Сначала прочитай конфигурацию

Прежде чем разбирать, всегда читай ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Критерии триггера PIA, нормативный охват и обязательства политики приватности из него — эталон. Общие рассуждения о праве приватности не заменяют то, что эта компания на самом деле пообещала.

Если файла нет или в нём есть [PLACEHOLDER], выведи такое сообщение:

Я вижу, что вы ещё не настроили профиль практики: именно по нему я подгоняю критерии триггера PIA, нормативный охват и обязательства политики приватности под вашу практику. Два варианта: - Запустите /privacy-legal:cold-start-interview (2 минуты), чтобы настроить профиль, и тогда я проведу разбор, подогнанный под ВАШУ практику. - Скажите «provisional» («предварительно»), и я проведу разбор по типовым настройкам — юрисдикция США, средняя готовность к риску, роль юриста, без плейбука — и помечу каждый результат [PROVISIONAL — configure your profile for tailored output], чтобы вы увидели, что я делаю, прежде чем настраивать.

Предварительный режим (provisional)

Если пользователь говорит «provisional», проведи разбор как обычно, взяв такие типовые настройки: средняя готовность к риску, роль юриста, юрисдикция США (CCPA и распространённые федеральные отраслевые основы), без плейбука (классифицируй по общим принципам права приватности, а не по совпадению с настроенными обязательствами). Пометь [PROVISIONAL] заметку для проверяющего и каждый блок выводов. В конце результата добавь:

«Это был типовой прогон по настройкам по умолчанию. Запустите /privacy-legal:cold-start-interview, чтобы результат был откалиброван под ВАШУ практику: ваш нормативный охват, обязательства вашей политики приватности, вашу готовность к риску. 2 минуты».

Порядок разбора

Шаг 1: Пойми вид обработки

Если описание расплывчатое, спроси, прежде чем классифицировать. Уточни:

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

Формулировок «новая функция» и «вид обработки данных» для точного разбора мало.

Шаг 2: Проверь внутренние триггеры

Прочитай ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA house style → критерии триггера (Trigger criteria). Примени их.

Если внутренний триггер сработал → как минимум НУЖНА PIA.

Если внутренний триггер не сработал, перейди к шагу 3, прежде чем заключать ПРОДОЛЖАТЬ. Некоторым видам обработки нужна PIA независимо от внутренней политики.

Шаг 3: Проверка обязательной оценки

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

Федеральные наложения по виду деятельности — спрашивай первыми: Затрагивает ли обработка: - Данные финансовых счетов или «непубличную персональную информацию» о потребителях (GLBA / Reg P — применяется к финансовым организациям и их неаффилированным третьим лицам; налагает существенные ограничения на передачу NPI в маркетинговых целях, отдельно от любого исключения по закону штата о приватности и сверх него)? - Защищённую медицинскую информацию, которой располагает охватываемая организация или деловой партнёр (правила HIPAA о приватности и безопасности — существенные ограничения на использование и раскрытие, уведомление об утечке от 500 записей, для любого поставщика нужно соглашение BAA)? - Образовательные записи, которыми располагает школа или поставщик услуг, действующий в её интересах (FERPA — требования к согласию на раскрытие, исключения для справочной информации)? - Данные детей младше 13 лет, собранные оператором онлайн-сервиса, ориентированного на детей, или при наличии фактического знания (COPPA — согласие родителей, уведомление, право на удаление, жёсткие ограничения на хранение и передачу)? - Другой федеральный отраслевой режим (например, VPPA для записей о просмотре видео, CPNI для данных операторов связи, DPPA для записей автомобильных ведомств, TCPA для согласия на SMS и звонки)? Если «да» хотя бы по одному пункту: федеральное наложение обычно задаёт определяющее существенное ограничение, а не просто исключение из закона штата о потребительской приватности. Изучи и процитируй конкретное положение, прежде чем продолжать. Вид деятельности, «исключённый» из CCPA по § 1798.145(e), потому что он подпадает под GLBA, всё равно подчиняется ограничениям GLBA (например, § 6802(a)-(c) о передаче NPI): исключение из CCPA не делает деятельность законной, а лишь переносит определяющую основу на GLBA.

По каждому режиму из ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Regulatory footprint изучи действующие на сегодня триггеры обязательной оценки приватности и защиты данных. Цитируй определяющий закон, нормативный акт или разъяснение регулятора с точными ссылками. Отмечай даты вступления в силу: национальные регуляторы и регуляторы штатов регулярно публикуют и обновляют перечни триггеров; не полагайся на статичный чек-лист. Неуверенность отмечай для проверки юристом, а не угадывай.

Если сработал обязательный триггер любого применимого режима → DPIA ОБЯЗАТЕЛЬНА (или эквивалентное предписание конкретного режима) независимо от внутреннего триггера.

Сильные признаки (не обязательно обязательные, но оценку всё равно проведи):

Новая технология или новое применение существующей технологии
Данные детей
Объединение наборов данных, которые не собирались вместе
Данные, которые могут привести к дискриминации
Обработка, которой пользователи не ожидают
Look-alike-аудитории (похожие аудитории), межконтекстная поведенческая реклама или другая рекламная технология на основе отслеживания (постоянный вопрос для компаний, работающих с потребителями; стабильно выявляет конфликты с обязательствами политики и федеральные отраслевые наложения)

Один или несколько сильных признаков без найденного обязательного триггера → повысь до НУЖНА PIA (не обязательная DPIA, но отметь это в результате).

Шаг 4: Проверка конфликта с политикой приватности

Прочитай ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Privacy policy commitments. Сверь предлагаемый вид деятельности с каждым заявленным обязательством.

Типичные конфликты, которые нужно ловить:

Политика говорит «мы собираем X, Y, Z», а эта деятельность собирает W. Нужно обновить политику до запуска или прекратить сбор W.
Политика говорит «мы не продаём данные и не передаём их третьим лицам», а эта деятельность передаёт данные поставщику для его собственных целей. Выясни, попадает ли передача под регулируемую категорию «продажи», «передачи» или иного раскрытия по каждому применимому режиму.
Политика устанавливает сроки хранения, а эта деятельность хранит данные дольше.
Политика говорит «мы используем данные только для [цели]», а эта деятельность использует их для новой цели без нового согласия или оценки законного интереса.
Политика перечисляет предоставляемые пользователям права, а эта деятельность создаёт новую категорию данных, под которую процесс обработки прав не рассчитан.

Если есть прямой конфликт → СТОП. Не «продолжай с осторожностью»: конфликт с политикой нужно устранить (обновить политику или переделать деятельность), прежде чем идти дальше.

Шаг 5: Классификация и результат

Итог

[PIA нужна / Обязательна DPIA / Можно продолжать — почему, одним предложением]

ВИД ОБРАБОТКИ: [Опиши вид обработки так, как ты его понял]

КЛАССИФИКАЦИЯ: [ПРОДОЛЖАТЬ / НУЖНА PIA / DPIA ОБЯЗАТЕЛЬНА / СТОП]

Сработал внутренний триггер? [Да / Нет] Триггер обязательной DPIA по GDPR? [Да — [триггер] / Нет / Н/Д (GDPR не входит в охват)] Конфликт с политикой приватности? [Нет / Да — [конкретный конфликт]]

Обоснование: [1–3 предложения. Для ПРОДОЛЖАТЬ: почему это безопасно при действующей политике. Для PIA/DPIA: что создаёт обязанность. Для СТОП: какое именно обязательство политики или принцип нарушены.]

*Если НУЖНА PIA или DPIA ОБЯЗАТЕЛЬНА — условия перед продолжением:*

Требование	Ответственный	Выполнено?
[например, оценка воздействия на приватность — полный формат DPIA]	[Юрист по приватности]	☐
[например, оценка законного интереса (если основание — законный интерес)]	[Юрист по приватности]	☐
[например, консультация с DPO (трек обязательной DPIA)]	[DPO]	☐
[например, заключено соглашение DPA с поставщиком]	[Приватность / Юристы]	☐
[например, обновление политики приватности до запуска]	[Юрист по приватности]	☐
[например, механизм получения согласия создан и протестирован]	[Продукт]	☐
[например, процесс обработки прав субъектов данных охватывает новую категорию данных]	[Приватность / Продукт]	☐

Законное основание (если GDPR входит в охват): [Согласие / Договор / Законный интерес / Юридическая обязанность — или «неясно — нужно определить в PIA»]

Следующий шаг — предложи продолжить:

Представив результат НУЖНА PIA или DPIA ОБЯЗАТЕЛЬНА, всегда заканчивай так:

«Хотите, я начну PIA прямо сейчас? Я могу задать вводные вопросы и подготовить документ оценки, и вам не придётся запускать отдельную команду».

Если пользователь отвечает «да», загрузи скилл pia-generation и продолжай в том же разговоре, передав описание вида обработки и уже выявленные триггеры.

Если отвечает «нет», результат разбора остаётся в силе. PIA можно запустить в любой момент командой: /privacy-legal:pia-generation [вид обработки]

*Если СТОП:*

Конфликт: [Конкретное обязательство политики приватности или принцип, который нарушен]

Чтобы продолжить, нужно изменить одно из двух:

[Вариант А — переделать деятельность так, чтобы конфликт не возникал]
[Вариант Б — обновить политику приватности, чтобы она покрывала эту обработку (требуется проверить, согласуется ли само обновление с законным основанием)]

Не предлагай путь вперёд, если его нет. Если обработку просто нельзя согласовать с заявленными обязательствами или законным основанием, так и скажи.

Шаг 6: Передачи другим плагинам

Передача в управление ИИ: если вид обработки включает систему ИИ, которая принимает решения о людях или влияет на них:

«Эта деятельность включает принятие решений с помощью ИИ. Вероятно, помимо PIA нужна оценка воздействия ИИ. Запустите /ai-governance-legal:aia-generation [вид обработки], чтобы вести её параллельно: одно не заменяет другое».

Передача юристу по продукту: если это новая функция продукта или запуск:

«Если это часть запуска продукта, подключите юриста по продукту. Используйте /product-legal:launch-review: он обнаружит компонент приватности и направит сюда, в этот плагин».

Отмечай только те передачи, которые действительно уместны. Не добавляй обе как шаблонную приписку.

Пакетный разбор

Если пользователь приносит список функций, дорожную карту или бэклог, сначала дай сводную таблицу, затем разверни каждую запись, у которой результат не «ПРОДОЛЖАТЬ»:

№	Вид обработки	Классификация	Ключевое условие / препятствие
1	[вид обработки]	🟢 Продолжать	—
2	[вид обработки]	🟡 Нужна PIA	Требуется оценка законного основания; DPA с поставщиком нет
3	[вид обработки]	🟠 DPIA обязательна	Данные особых категорий в больших объёмах
4	[вид обработки]	🔴 Стоп	Конфликт с политикой приватности: ограничение цели

Пограничные случаи и сбои

«Данные анонимизированы» не означает автоматически ПРОДОЛЖАТЬ. Спроси, как именно они анонимизированы и возможна ли реальная деанонимизация с учётом набора данных. Псевдонимизированные данные по GDPR остаются персональными.

«Мы уже делаем что-то подобное» — это не разбор. Существующая обработка, которую никогда не оценивали, не освобождает новую обработку от оценки (grandfathering). Если новая деятельность существенно отличается по масштабу, цели или категории данных, разбирай её заново.

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

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

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

Заверши деревом следующих шагов

Заверши деревом следующих шагов по разделу CLAUDE.md ## Outputs. Подгони варианты под то, что этот скилл только что выдал: пять веток по умолчанию (подготовить X, эскалировать, собрать больше фактов, наблюдать и ждать, что-то другое) — отправная точка, а не жёсткое правило. Дерево и есть результат; выбирает юрист.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/privacy-legal/skills/use-case-triage, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: use-case-triage
description: >
  Quickly determine whether a processing activity needs a PIA, a mandatory GDPR
  DPIA, or can proceed — surfaces privacy policy conflicts and routes to the right
  next step. Use when the user asks "does this need a PIA", "triage this feature",
  "privacy check on X", "is this okay from a privacy perspective", or describes a
  new data processing activity, product feature, or vendor relationship.
argument-hint: "[describe the data processing activity or feature]"
---

# /use-case-triage

1. Read `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. Confirm privacy practice is configured — if not, stop and direct to setup.
2. Run the workflow below. Clarify the activity if vague.
3. House trigger check → mandatory DPIA check (if GDPR in footprint) → privacy policy conflict check.
4. Output: classification (PROCEED / PIA REQUIRED / DPIA MANDATORY / STOP), reasoning, conditions table if required, cross-plugin handoffs.
5. Offer to continue into PIA generation if assessment is required.

```
/privacy-legal:use-case-triage "New feature that uses behavioral data to personalize content recommendations"
```

---

# Privacy Use Case Triage

## Matter context

**Matter context.** Check `## Matter workspaces` in the practice-level CLAUDE.md. If `Enabled` is `✗` (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run `/privacy-legal:matter-workspace switch <slug>` or say `practice-level`." Load the active matter's `matter.md` for matter-specific context and overrides. Write outputs to the matter folder at `~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/`. Never read another matter's files unless `Cross-matter context` is `on`.

---

## Destination check

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical `## Shared guardrails → Destination check` in this plugin's CLAUDE.md.

## Purpose

Answer the question that comes up before anyone runs a PIA: "does this thing even
need one?" And if it does, what kind, and what's blocking the way?

Privacy triage is faster than PIA generation but upstream of it. It doesn't write
the assessment — it determines whether one is needed and on what terms. The PIA
generation skill does the deep work.

The output is one of four classifications:
- **PROCEED** — No PIA needed. Standard safeguards apply.
- **PIA REQUIRED** — Assessment needed before or alongside deployment.
- **DPIA MANDATORY** — A regime-mandated data protection impact assessment is
  required (research the applicable regime's trigger and cite primary sources).
  Harder bar, DPO/GC involvement likely.
- **STOP** — Processing activity conflicts with the privacy policy or has no
  lawful basis as described. Needs redesign before proceeding.

## Jurisdiction assumption

This triage assumes the jurisdictional scope specified in your configuration. Privacy rules, assessment triggers, and lawful bases vary materially by jurisdiction (GDPR vs. state consumer privacy laws vs. sectoral). If the processing activity, controller, or affected data subjects fall under a different jurisdiction, this classification may not apply as written.

## Read the config first

Before triaging, always read `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. The PIA trigger criteria, regulatory
footprint, and privacy policy commitments there are authoritative. Generic privacy
law reasoning is not a substitute for what this company has actually committed to.

If the file is missing or contains `[PLACEHOLDER]`, surface this bounce:

> I notice you haven't configured your practice profile yet — that's how I tailor the PIA trigger criteria, regulatory footprint, and privacy policy commitments to your practice.
>
> **Two choices:**
> - Run `/privacy-legal:cold-start-interview` (2 minutes) to configure your profile, then I'll triage tailored to YOUR practice.
> - Say **"provisional"** and I'll triage against generic defaults — US jurisdiction, middle risk appetite, lawyer role, no playbook — and tag every output `[PROVISIONAL — configure your profile for tailored output]` so you can see what I do before committing.

### Provisional mode

If the user says "provisional," run triage normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction (CCPA + common federal sectoral baselines), no playbook (classify from general privacy-law principles rather than matching to configured commitments). Tag the reviewer note and every finding block with `[PROVISIONAL]`. At the end of the output, append:

> "That was a generic run against default assumptions. Run `/privacy-legal:cold-start-interview` to get output calibrated to YOUR practice — your regulatory footprint, your privacy policy commitments, your risk appetite. 2 minutes."

---

## Triage process

### Step 1: Understand the activity

If the description is vague, ask before classifying. Get specific on:

- What data is being collected or processed? Which categories?
- Who are the data subjects — customers, employees, third parties?
- What's the purpose? What problem is this solving?
- Is this new data collection, or repurposing data you already have?
- Is a third-party vendor involved? New vendor or existing?
- Is any automated decision-making involved — does the output affect anyone?
- What's the deployment context — internal only, customer-facing, public?

"New feature" and "data processing activity" are not enough to triage accurately.

---

### Step 2: Check house triggers

Read `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## PIA house style` → Trigger criteria. Apply them.

If the house trigger is met → at minimum **PIA REQUIRED**.

If house trigger is not met, continue to Step 3 before concluding PROCEED. Some
activities need a PIA regardless of internal policy.

---

### Step 3: Mandatory assessment check

**Before researching regime-specific triggers, ask the activity-based federal overlay question first.** If the processing touches a federally-regulated data category, the federal overlay is usually the controlling framework, not state privacy law, and the triage needs to surface that early rather than as an afterthought.

> **Activity-based federal overlays — ask first:**
>
> Does this processing touch:
> - **Financial account data or "nonpublic personal information" about consumers** (GLBA / Reg P — applies to financial institutions and their non-affiliated third parties; imposes substantive restrictions on sharing NPI for marketing, separate from and on top of any state privacy-law exemption)?
> - **Protected health information held by a covered entity or business associate** (HIPAA Privacy / Security Rules — substantive restrictions on use and disclosure, breach notification at 500+ records, BAA required for any vendor)?
> - **Education records held by a school or a service provider acting for a school** (FERPA — consent requirements for disclosure, directory-information carve-outs)?
> - **Data from children under 13 collected by an operator of an online service directed to children or with actual knowledge** (COPPA — parental consent, notice, deletion rights, strict limits on retention and sharing)?
> - **Another sectoral federal regime** (e.g., VPPA for video-viewing records, CPNI for carrier data, DPPA for DMV records, TCPA for SMS/call consent)?
>
> If yes to any: the federal overlay usually supplies the controlling substantive restriction, not just an exemption from a state consumer privacy law. Research and cite the specific provision before continuing. An activity that is "exempt" from CCPA under § 1798.145(e) because it is GLBA-covered is still subject to the GLBA restrictions (e.g., § 6802(a)-(c) on NPI sharing) — the CCPA exemption does not make the activity lawful; it just moves the governing framework to GLBA.

For each regime in `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Regulatory footprint`, **research the currently operative mandatory privacy/data-protection assessment triggers**. Cite controlling statute, regulation, or regulator guidance with pinpoint references. Note effective dates — national and state regulators publish and update trigger lists regularly; do not rely on a static checklist. Flag uncertainty for attorney verification rather than guess.

If **any** applicable regime's mandatory trigger is met → **DPIA MANDATORY** (or the equivalent regime-specific mandate), regardless of house trigger.

**Strong indicators (not necessarily mandatory but do one anyway):**
- New technology or novel use of existing technology
- Children's data
- Combining datasets that weren't collected together
- Data that could enable discrimination
- Processing users would not expect
- Lookalike audiences, cross-context behavioral advertising, or other tracking-based ad-tech activity (recurring question for consumer-facing companies; surfaces policy-commitment conflicts and federal sectoral overlays reliably)

One or more strong indicators with no researched mandatory trigger → escalate to **PIA REQUIRED**
(not DPIA mandatory, but flag in the output).

---

### Step 4: Privacy policy conflict check

Read `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Privacy policy commitments`. Check the proposed activity
against every stated commitment.

**Common conflicts to catch:**
- Policy says "we collect X, Y, Z" — this activity collects W. Policy update
  needed before launch, or stop collecting W.
- Policy says "we don't sell or share data with third parties" — this activity
  passes data to a vendor for their own purposes. Research whether the flow falls
  within a regulated "sale," "share," or other disclosure category under each
  applicable regime.
- Policy states retention limits — this activity retains data longer.
- Policy says "we use data only for [purpose]" — this activity uses it for a new
  purpose without fresh consent or legitimate interest assessment.
- Policy specifies user rights offered — this activity creates a new data category
  the rights process wasn't built for.

If a direct conflict exists → **STOP**. Not "proceed with caution" — the policy
conflict has to be resolved (policy update or activity redesign) before this
proceeds.

---

### Step 5: Classification and output

---

### Bottom line
[PIA required / Mandatory DPIA required / Proceed — one-sentence why]

---

**ACTIVITY:** [State the processing activity as you understand it]

**CLASSIFICATION:** [PROCEED / PIA REQUIRED / DPIA MANDATORY / STOP]

**House trigger met?** [Yes / No]
**GDPR mandatory DPIA trigger?** [Yes — [trigger] / No / N/A (GDPR not in footprint)]
**Privacy policy conflict?** [None / Yes — [specific conflict]]

**Reasoning:**
[1-3 sentences. For PROCEED: what makes it safe under current policy. For PIA/DPIA:
what creates the obligation. For STOP: which specific policy commitment or principle
is in conflict.]

---

*If PIA REQUIRED or DPIA MANDATORY — conditions before proceeding:*

| Requirement | Owner | Done? |
|---|---|---|
| [e.g., Privacy Impact Assessment — full DPIA format] | [Privacy counsel] | ☐ |
| [e.g., Legitimate interest assessment (if LI basis)] | [Privacy counsel] | ☐ |
| [e.g., DPO consultation (DPIA mandatory track)] | [DPO] | ☐ |
| [e.g., Vendor DPA in place] | [Privacy / Legal] | ☐ |
| [e.g., Privacy policy update before launch] | [Privacy counsel] | ☐ |
| [e.g., Consent mechanism built and tested] | [Product] | ☐ |
| [e.g., Data subject rights process covers new data category] | [Privacy / Product] | ☐ |

**Lawful basis (if GDPR in footprint):** [Consent / Contract / Legitimate Interest /
Legal Obligation — or "unclear — needs determination in PIA"]

**Next step — offer to continue:**

After presenting a PIA REQUIRED or DPIA MANDATORY result, always end with:

> "Want me to start the PIA now? I can run the intake questions and produce the
> assessment document without you needing to run a separate command."

If they say yes, load the `pia-generation` skill and continue in the same
conversation — pass the activity description and any triggers already identified.

If they say no, the triage result stands. The PIA can be run any time with:
`/privacy-legal:pia-generation [activity]`

---

*If STOP:*

**Conflict:** [Specific privacy policy commitment or principle in conflict]

**To proceed, one of these has to change:**
- [Option A — redesign the activity so it doesn't create the conflict]
- [Option B — update the privacy policy to cover this processing (requires review
  of whether the update is itself consistent with lawful basis)]

Don't offer a path forward if there isn't one. If the processing simply can't be
reconciled with stated commitments or lawful basis, say so.

---

### Step 6: Cross-plugin handoffs

**AI governance handoff:** If the activity involves an AI system making or
influencing decisions about individuals:

> "This activity involves AI decision-making. An AI impact assessment is likely
> required in addition to a PIA. Use `/ai-governance-legal:aia-generation [activity]`
> to run that in parallel — they're not substitutes."

**Product counsel handoff:** If this is a new product feature or launch:

> "If this is part of a product launch, loop in product counsel.
> Use `/product-legal:launch-review` — it will detect the privacy component
> and route to this plugin."

Only flag handoffs that are actually relevant. Don't append both as boilerplate.

---

## Batch triage

If the user presents a feature list, roadmap, or backlog — summary table first,
then expand each non-PROCEED entry:

| # | Activity | Classification | Key condition / blocker |
|---|---|---|---|
| 1 | [activity] | 🟢 Proceed | — |
| 2 | [activity] | 🟡 PIA required | Lawful-basis assessment needed; vendor DPA not in place |
| 3 | [activity] | 🟠 DPIA mandatory | Large-scale special category data |
| 4 | [activity] | 🔴 Stop | Privacy policy conflict — purpose limitation |

---

## Edge cases and failure modes

**"It's anonymized" doesn't automatically mean PROCEED.**
Ask how it's anonymized and whether re-identification is realistically possible
given the data set. Pseudonymized data is still personal data under GDPR.

**"We already do something similar" isn't a triage.**
Existing processing that was never assessed doesn't grandfather new processing.
If the new activity is materially different in scale, purpose, or data category,
triage it fresh.

**"Just a pilot" doesn't skip triage.**
A pilot that touches real user or employee data is subject to the same triggers.
Apply the same classification; if a PIA is required, the pilot should have one.

**"The vendor handles all the privacy."**
Vendor handles the infrastructure. You're still the controller determining the
purposes. If personal data flows to the vendor, a DPA is required and triage still
applies to the purpose.

**Inferred data and derived attributes count.**
If the activity generates inferred data about individuals (e.g., a behavioral score,
a predicted preference), treat the inferred attribute as personal data for triage
purposes. Don't let "we're just computing a score" obscure what the score represents.

## Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md `## Outputs`. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

Источник: anthropics/claude-for-legal / privacy-legal / use-case-triage ↗. Ссылка проверена 2026-10-10.

---
name: use-case-triage
description: >
  Быстро определи, нужна ли для вида обработки данных оценка воздействия на приватность (PIA),
  обязательная по GDPR оценка воздействия на защиту данных (DPIA) или можно двигаться дальше. Скилл
  выявляет конфликты с политикой приватности и направляет к нужному следующему шагу. Используй, когда
  пользователь спрашивает «нужна ли для этого PIA», «сделай первичный разбор этой функции»,
  «проверка приватности для X», «это нормально с точки зрения приватности» или описывает новый вид
  обработки данных, функцию продукта либо отношения с поставщиком.
argument-hint: "[describe the data processing activity or feature]"
---

# /use-case-triage

1. Прочитай `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. Убедись, что практика приватности настроена; если нет, остановись и направь на настройку.
2. Выполни рабочий процесс ниже. Если описание вида обработки расплывчатое, уточни его.
3. Проверка внутренних триггеров → проверка обязательной DPIA (если GDPR входит в охват) → проверка конфликта с политикой приватности.
4. Результат: классификация (ПРОДОЛЖАТЬ / НУЖНА PIA / DPIA ОБЯЗАТЕЛЬНА / СТОП), обоснование, таблица условий, если они нужны, передачи другим плагинам.
5. Если оценка нужна, предложи продолжить созданием PIA.

```
/privacy-legal:use-case-triage "Новая функция, которая использует поведенческие данные для персонализации рекомендаций контента"
```

---

# Первичный разбор вида обработки по приватности

## Контекст дела

**Контекст дела.** Загляни в раздел `## Matter workspaces` в CLAUDE.md уровня практики. Если `Enabled` равно `✗` (по умолчанию для юристов внутри компании), пропусти остаток этого абзаца: скиллы работают с контекстом уровня практики, а механизм дел остаётся невидимым. Если режим включён, а активного дела нет, спроси: «Для какого дела это нужно? Запустите `/privacy-legal:matter-workspace switch <slug>` или скажите `practice-level`». Загрузи `matter.md` активного дела — там контекст и исключения для этого дела. Результаты записывай в папку дела `~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/`. Файлы другого дела не читай, если только `Cross-matter context` не равен `on`.

---

## Проверка получателя

Прежде чем выдавать результат, проверь, куда он пойдёт. Если пользователь назвал адресата (канал, список рассылки, контрагента, «всех»), спроси, находится ли он внутри круга привилегии (адвокатской тайны). Публичные каналы, общекорпоративные списки, контрагент и юристы противоположной стороны, поставщики и клиенты (если это рабочий материал) лишают защиты. Если адресат выглядит внешним для круга, отметь это и предложи (а) привилегированную версию только для юристов, (б) обезличенную версию для более широкого канала или (в) обе: не ставь молча привилегированный заголовок, а потом не помогай вставить материал туда, где этот заголовок его не защитит. См. эталонный раздел `## Shared guardrails → Destination check` в CLAUDE.md этого плагина.

## Назначение

Ответь на вопрос, который возникает до того, как кто-либо запустит PIA: «а нужна ли она вообще?» А если нужна, то какая и что мешает идти дальше?

Первичный разбор по приватности быстрее создания PIA, но стоит перед ним. Он не пишет оценку, а определяет, нужна ли она и на каких условиях. Глубокую работу делает скилл создания PIA.

Результат — одна из четырёх классификаций:
- **ПРОДОЛЖАТЬ (PROCEED)** — PIA не нужна. Применяются стандартные меры защиты.
- **НУЖНА PIA (PIA REQUIRED)** — оценка нужна до внедрения или одновременно с ним.
- **DPIA ОБЯЗАТЕЛЬНА (DPIA MANDATORY)** — требуется оценка воздействия на защиту данных, предписанная режимом (изучи триггер применимого режима и цитируй первоисточники). Планка выше, вероятно, потребуется участие DPO или главного юрисконсульта.
- **СТОП (STOP)** — вид обработки противоречит политике приватности или, как описан, не имеет законного основания. Перед продолжением нужно переделать.

## Допущение о юрисдикции

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

## Сначала прочитай конфигурацию

Прежде чем разбирать, всегда читай `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. Критерии триггера PIA, нормативный охват и обязательства политики приватности из него — эталон. Общие рассуждения о праве приватности не заменяют то, что эта компания на самом деле пообещала.

Если файла нет или в нём есть `[PLACEHOLDER]`, выведи такое сообщение:

> Я вижу, что вы ещё не настроили профиль практики: именно по нему я подгоняю критерии триггера PIA, нормативный охват и обязательства политики приватности под вашу практику.
>
> **Два варианта:**
> - Запустите `/privacy-legal:cold-start-interview` (2 минуты), чтобы настроить профиль, и тогда я проведу разбор, подогнанный под ВАШУ практику.
> - Скажите **«provisional»** («предварительно»), и я проведу разбор по типовым настройкам — юрисдикция США, средняя готовность к риску, роль юриста, без плейбука — и помечу каждый результат `[PROVISIONAL — configure your profile for tailored output]`, чтобы вы увидели, что я делаю, прежде чем настраивать.

### Предварительный режим (provisional)

Если пользователь говорит «provisional», проведи разбор как обычно, взяв такие типовые настройки: средняя готовность к риску, роль юриста, юрисдикция США (CCPA и распространённые федеральные отраслевые основы), без плейбука (классифицируй по общим принципам права приватности, а не по совпадению с настроенными обязательствами). Пометь `[PROVISIONAL]` заметку для проверяющего и каждый блок выводов. В конце результата добавь:

> «Это был типовой прогон по настройкам по умолчанию. Запустите `/privacy-legal:cold-start-interview`, чтобы результат был откалиброван под ВАШУ практику: ваш нормативный охват, обязательства вашей политики приватности, вашу готовность к риску. 2 минуты».

---

## Порядок разбора

### Шаг 1: Пойми вид обработки

Если описание расплывчатое, спроси, прежде чем классифицировать. Уточни:

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

Формулировок «новая функция» и «вид обработки данных» для точного разбора мало.

---

### Шаг 2: Проверь внутренние триггеры

Прочитай `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## PIA house style` → критерии триггера (Trigger criteria). Примени их.

Если внутренний триггер сработал → как минимум **НУЖНА PIA**.

Если внутренний триггер не сработал, перейди к шагу 3, прежде чем заключать ПРОДОЛЖАТЬ. Некоторым видам обработки нужна PIA независимо от внутренней политики.

---

### Шаг 3: Проверка обязательной оценки

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

> **Федеральные наложения по виду деятельности — спрашивай первыми:**
>
> Затрагивает ли обработка:
> - **Данные финансовых счетов или «непубличную персональную информацию» о потребителях** (GLBA / Reg P — применяется к финансовым организациям и их неаффилированным третьим лицам; налагает существенные ограничения на передачу NPI в маркетинговых целях, отдельно от любого исключения по закону штата о приватности и сверх него)?
> - **Защищённую медицинскую информацию, которой располагает охватываемая организация или деловой партнёр** (правила HIPAA о приватности и безопасности — существенные ограничения на использование и раскрытие, уведомление об утечке от 500 записей, для любого поставщика нужно соглашение BAA)?
> - **Образовательные записи, которыми располагает школа или поставщик услуг, действующий в её интересах** (FERPA — требования к согласию на раскрытие, исключения для справочной информации)?
> - **Данные детей младше 13 лет, собранные оператором онлайн-сервиса, ориентированного на детей, или при наличии фактического знания** (COPPA — согласие родителей, уведомление, право на удаление, жёсткие ограничения на хранение и передачу)?
> - **Другой федеральный отраслевой режим** (например, VPPA для записей о просмотре видео, CPNI для данных операторов связи, DPPA для записей автомобильных ведомств, TCPA для согласия на SMS и звонки)?
>
> Если «да» хотя бы по одному пункту: федеральное наложение обычно задаёт определяющее существенное ограничение, а не просто исключение из закона штата о потребительской приватности. Изучи и процитируй конкретное положение, прежде чем продолжать. Вид деятельности, «исключённый» из CCPA по § 1798.145(e), потому что он подпадает под GLBA, всё равно подчиняется ограничениям GLBA (например, § 6802(a)-(c) о передаче NPI): исключение из CCPA не делает деятельность законной, а лишь переносит определяющую основу на GLBA.

По каждому режиму из `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Regulatory footprint` **изучи действующие на сегодня триггеры обязательной оценки приватности и защиты данных**. Цитируй определяющий закон, нормативный акт или разъяснение регулятора с точными ссылками. Отмечай даты вступления в силу: национальные регуляторы и регуляторы штатов регулярно публикуют и обновляют перечни триггеров; не полагайся на статичный чек-лист. Неуверенность отмечай для проверки юристом, а не угадывай.

Если сработал обязательный триггер **любого** применимого режима → **DPIA ОБЯЗАТЕЛЬНА** (или эквивалентное предписание конкретного режима) независимо от внутреннего триггера.

**Сильные признаки (не обязательно обязательные, но оценку всё равно проведи):**
- Новая технология или новое применение существующей технологии
- Данные детей
- Объединение наборов данных, которые не собирались вместе
- Данные, которые могут привести к дискриминации
- Обработка, которой пользователи не ожидают
- Look-alike-аудитории (похожие аудитории), межконтекстная поведенческая реклама или другая рекламная технология на основе отслеживания (постоянный вопрос для компаний, работающих с потребителями; стабильно выявляет конфликты с обязательствами политики и федеральные отраслевые наложения)

Один или несколько сильных признаков без найденного обязательного триггера → повысь до **НУЖНА PIA** (не обязательная DPIA, но отметь это в результате).

---

### Шаг 4: Проверка конфликта с политикой приватности

Прочитай `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Privacy policy commitments`. Сверь предлагаемый вид деятельности с каждым заявленным обязательством.

**Типичные конфликты, которые нужно ловить:**
- Политика говорит «мы собираем X, Y, Z», а эта деятельность собирает W. Нужно обновить политику до запуска или прекратить сбор W.
- Политика говорит «мы не продаём данные и не передаём их третьим лицам», а эта деятельность передаёт данные поставщику для его собственных целей. Выясни, попадает ли передача под регулируемую категорию «продажи», «передачи» или иного раскрытия по каждому применимому режиму.
- Политика устанавливает сроки хранения, а эта деятельность хранит данные дольше.
- Политика говорит «мы используем данные только для [цели]», а эта деятельность использует их для новой цели без нового согласия или оценки законного интереса.
- Политика перечисляет предоставляемые пользователям права, а эта деятельность создаёт новую категорию данных, под которую процесс обработки прав не рассчитан.

Если есть прямой конфликт → **СТОП**. Не «продолжай с осторожностью»: конфликт с политикой нужно устранить (обновить политику или переделать деятельность), прежде чем идти дальше.

---

### Шаг 5: Классификация и результат

---

### Итог
[PIA нужна / Обязательна DPIA / Можно продолжать — почему, одним предложением]

---

**ВИД ОБРАБОТКИ:** [Опиши вид обработки так, как ты его понял]

**КЛАССИФИКАЦИЯ:** [ПРОДОЛЖАТЬ / НУЖНА PIA / DPIA ОБЯЗАТЕЛЬНА / СТОП]

**Сработал внутренний триггер?** [Да / Нет]
**Триггер обязательной DPIA по GDPR?** [Да — [триггер] / Нет / Н/Д (GDPR не входит в охват)]
**Конфликт с политикой приватности?** [Нет / Да — [конкретный конфликт]]

**Обоснование:**
[1–3 предложения. Для ПРОДОЛЖАТЬ: почему это безопасно при действующей политике. Для PIA/DPIA: что создаёт обязанность. Для СТОП: какое именно обязательство политики или принцип нарушены.]

---

*Если НУЖНА PIA или DPIA ОБЯЗАТЕЛЬНА — условия перед продолжением:*

| Требование | Ответственный | Выполнено? |
|---|---|---|
| [например, оценка воздействия на приватность — полный формат DPIA] | [Юрист по приватности] | ☐ |
| [например, оценка законного интереса (если основание — законный интерес)] | [Юрист по приватности] | ☐ |
| [например, консультация с DPO (трек обязательной DPIA)] | [DPO] | ☐ |
| [например, заключено соглашение DPA с поставщиком] | [Приватность / Юристы] | ☐ |
| [например, обновление политики приватности до запуска] | [Юрист по приватности] | ☐ |
| [например, механизм получения согласия создан и протестирован] | [Продукт] | ☐ |
| [например, процесс обработки прав субъектов данных охватывает новую категорию данных] | [Приватность / Продукт] | ☐ |

**Законное основание (если GDPR входит в охват):** [Согласие / Договор / Законный интерес / Юридическая обязанность — или «неясно — нужно определить в PIA»]

**Следующий шаг — предложи продолжить:**

Представив результат НУЖНА PIA или DPIA ОБЯЗАТЕЛЬНА, всегда заканчивай так:

> «Хотите, я начну PIA прямо сейчас? Я могу задать вводные вопросы и подготовить документ оценки, и вам не придётся запускать отдельную команду».

Если пользователь отвечает «да», загрузи скилл `pia-generation` и продолжай в том же разговоре, передав описание вида обработки и уже выявленные триггеры.

Если отвечает «нет», результат разбора остаётся в силе. PIA можно запустить в любой момент командой:
`/privacy-legal:pia-generation [вид обработки]`

---

*Если СТОП:*

**Конфликт:** [Конкретное обязательство политики приватности или принцип, который нарушен]

**Чтобы продолжить, нужно изменить одно из двух:**
- [Вариант А — переделать деятельность так, чтобы конфликт не возникал]
- [Вариант Б — обновить политику приватности, чтобы она покрывала эту обработку (требуется проверить, согласуется ли само обновление с законным основанием)]

Не предлагай путь вперёд, если его нет. Если обработку просто нельзя согласовать с заявленными обязательствами или законным основанием, так и скажи.

---

### Шаг 6: Передачи другим плагинам

**Передача в управление ИИ:** если вид обработки включает систему ИИ, которая принимает решения о людях или влияет на них:

> «Эта деятельность включает принятие решений с помощью ИИ. Вероятно, помимо PIA нужна оценка воздействия ИИ. Запустите `/ai-governance-legal:aia-generation [вид обработки]`, чтобы вести её параллельно: одно не заменяет другое».

**Передача юристу по продукту:** если это новая функция продукта или запуск:

> «Если это часть запуска продукта, подключите юриста по продукту. Используйте `/product-legal:launch-review`: он обнаружит компонент приватности и направит сюда, в этот плагин».

Отмечай только те передачи, которые действительно уместны. Не добавляй обе как шаблонную приписку.

---

## Пакетный разбор

Если пользователь приносит список функций, дорожную карту или бэклог, сначала дай сводную таблицу, затем разверни каждую запись, у которой результат не «ПРОДОЛЖАТЬ»:

| № | Вид обработки | Классификация | Ключевое условие / препятствие |
|---|---|---|---|
| 1 | [вид обработки] | 🟢 Продолжать | — |
| 2 | [вид обработки] | 🟡 Нужна PIA | Требуется оценка законного основания; DPA с поставщиком нет |
| 3 | [вид обработки] | 🟠 DPIA обязательна | Данные особых категорий в больших объёмах |
| 4 | [вид обработки] | 🔴 Стоп | Конфликт с политикой приватности: ограничение цели |

---

## Пограничные случаи и сбои

**«Данные анонимизированы» не означает автоматически ПРОДОЛЖАТЬ.**
Спроси, как именно они анонимизированы и возможна ли реальная деанонимизация с учётом набора данных. Псевдонимизированные данные по GDPR остаются персональными.

**«Мы уже делаем что-то подобное» — это не разбор.**
Существующая обработка, которую никогда не оценивали, не освобождает новую обработку от оценки (grandfathering). Если новая деятельность существенно отличается по масштабу, цели или категории данных, разбирай её заново.

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

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

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

## Заверши деревом следующих шагов

Заверши деревом следующих шагов по разделу CLAUDE.md `## Outputs`. Подгони варианты под то, что этот скилл только что выдал: пять веток по умолчанию (подготовить X, эскалировать, собрать больше фактов, наблюдать и ждать, что-то другое) — отправная точка, а не жёсткое правило. Дерево и есть результат; выбирает юрист.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/privacy-legal/skills/use-case-triage, лицензия Apache-2.0. Изменения: перевод на русский язык.