Оценка воздействия на приватность

Проводит опрос продуктовой команды и пишет оценку воздействия на приватность (PIA) в принятом у вас формате: риски, меры и условия запуска.

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

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

Что делает: Проводит опрос продуктовой команды и пишет оценку воздействия на приватность (PIA) в принятом у вас формате: риски, меры и условия запуска.
Когда брать: Когда готовится новая функция, продукт или вид обработки персональных данных и нужна PIA с проверкой на соответствие вашей политике приватности.
Когда не брать: Если нужно только быстро решить, нужна ли PIA: для этого есть скилл use-case-triage. Скилл не утверждает обработку и не пишет DPIA для надзорного органа.
Пример запроса: Напиши PIA для новой функции передачи геолокации: вот PRD.
Нужно подключить: доступ к файлам (папка настроек плагина)
Работает лучше с: инструмент юридического поиска (Westlaw, EUR-Lex), Google Drive (PRD)

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

Как включить

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

Текст

---
name: pia-generation
description: >
  Подготовь оценку воздействия на приватность (Privacy Impact Assessment, PIA) в формате, принятом у
  вас, для новой функции, продукта или вида обработки данных, по структуре, которую скилл усвоил из
  вашей образцовой PIA. Используй, когда пользователь говорит «напиши PIA», «оценка воздействия на
  приватность для», «нужна ли нам PIA для этого», «проверь эту функцию на приватность» или описывает
  новый вид обработки данных.
argument-hint: "[feature name or description]"
---

/pia-generation

Загрузи ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → внутренний формат PIA (триггер, структура, глубина, согласование).
Выполни рабочий процесс ниже.
Проверь: действительно ли нужна PIA? (Внутренний триггер + изучи триггеры обязательной оценки по каждому применимому режиму — цитируй первоисточники, проверяй актуальность.)
Вводный опрос: задай вопросы продуктовой команде. Можно взять ответы из PRD, если он есть.
Напиши PIA во внутреннем формате. Включи проверку соответствия политике приватности.
Выдай результат со списком условий и названными ответственными. Направь на согласование.

/privacy-legal:pia-generation "Функция передачи геолокации"

/privacy-legal:pia-generation
PRD: [ссылка на Drive]

Подготовка PIA

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

Контекст дела. Загляни в раздел ## 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 при первичной настройке.

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

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

Загрузи прежний контекст по этой функции / виду обработки

Прежде чем писать новую PIA, проверь папку результатов: нет ли прежних работ по той же функции, виду обработки или контрагенту. Путь возьми из ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Outputs. Просмотри:

**Прежние результаты use-case-triage** по этому виду обработки: оценка риска, обязательные условия и отмеченные тревоги из первичного разбора — отправная точка для PIA.
**Прежние результаты pia-generation** по тому же или пересекающемуся виду обработки: заменяющая PIA должна их согласовывать (что изменилось, что осталось). PIA, которая молча приходит к иным выводам, чем прежняя PIA по той же обработке, создаёт противоречие, которого проверяющий юрист не видит.
**Прежние результаты dpa-review** по поставщикам в области: выводы проверки DPA помогают проанализировать риски субпроцессоров, трансграничной передачи и хранения.

Если прежний результат найден, сошлись на него в PIA:

«Предыдущий первичный разбор ([дата]) оценил это как [уровень риска] и потребовал [условия]. Эта PIA опирается на тот вывод — [какие условия выполнены, какие остались, какие изменили объём]».

Если прежняя PIA существует:

«Эта PIA заменяет PIA от [дата], потому что [причина — изменился объём, появилась новая категория данных, сменился поставщик, изменилось регулирование]. Выводы, оставленные без изменений: [X]. Выводы, пересмотренные: [Y, потому что Z]».

Переноси серьёзность, определённую выше по цепочке, как нижнюю границу по межскилловому правилу нижней границы серьёзности из ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Shared guardrails. Первичный разбор (use-case-triage), оценивший вид обработки как высокорисковый, не может превратиться в PIA с выводом о низком риске без объяснения, почему и что изменилось.

Если прежних результатов нет, скажи об этом прямо — «В папке результатов нет предыдущего первичного разбора или PIA по этому виду обработки; это работа с нуля», — чтобы проверяющий юрист знал: проверка прошла и согласовывать было нечего.

Загрузи внутренний формат

Прочитай ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA house style. Там записано:

что запускает PIA у вас (может не совпадать с регуляторными триггерами DPIA: одни команды делают PIA на всё, другие только на высокорисковое)
шаблон структуры, извлечённый из образцовой PIA
обычная глубина
кто согласовывает

Если структура образцовой PIA есть в конфигурационном CLAUDE.md, используй её. Смысл в том, чтобы эта PIA выглядела как другие PIA вашей команды, а не как типовая.

Шаг 0: Нужна ли PIA?

Проверь критерии триггера в ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Это внутренний ответ команды.

Кроме того, изучи действующие на сегодня триггеры обязательной оценки по каждому режиму из нормативного охвата (триггеры DPIA по GDPR / UK GDPR, триггеры оценки рисков по CCPA/CPRA, триггеры оценки защиты данных в других штатах США, отраслевые режимы). Цитируй определяющий закон, нормативный акт или разъяснение регулятора с точными ссылками. Проверяй актуальность: пороги и определения для оценок меняются с новыми законами штатов, нормотворчеством и разъяснениями по правоприменению. Неуверенность отмечай, а не угадывай.

Никаких тихих дополнений. Если запрос к настроенному инструменту юридического поиска возвращает мало результатов или не возвращает ничего по триггерам DPIA / оценки рисков или правилам законного основания какого-либо режима, сообщи, что нашлось, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели без вопроса. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / вопрос], похоже, скудное. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент, (3) поискать в вебе: результаты получат пометку [web search — verify], и их нужно сверить с первоисточником, прежде чем полагаться на них, или (4) пометить как непроверенное и остановиться. Что выберете?» Принимать ли источники с меньшей достоверностью, решает юрист. Указание источника. Помечай каждую ссылку в PIA тем, откуда она взята: [Westlaw], [regulator site] или имя MCP-инструмента для ссылок, полученных из исследовательского коннектора; [web search — verify] для ссылок из веб-поиска; [model knowledge — verify] для ссылок, восстановленных из обучающих данных; [user provided] для ссылок, которые дал пользователь. Ссылки с пометкой verify несут больший риск выдумки, и проверять их нужно в первую очередь. Никогда не убирай и не склеивай пометки.

Помимо законодательных предписаний, считай следующее сильными признаками того, что PIA стоит делать, даже если она не строго обязательна (выясни, не запускает ли какой-либо из них самостоятельно обязательную оценку по применимому режиму):

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

Если ни один законодательный триггер не применим и внутренний триггер тоже не сработал → «Похоже, для этого PIA не нужна. Вот заметка на один абзац в дело с объяснением, почему, на случай если кто-то спросит».

Вводный опрос

Прежде чем что-либо писать, получи от продуктовой команды ответы на эти вопросы. Разговорный формат подойдёт: это не анкета, которую им нужно рассылать.

Что и зачем

Что за функция / продукт / изменение?
Какую проблему оно решает для пользователей?
Каких персональных данных оно касается? Конкретно: «данные пользователей» — не ответ. Какие поля?
Это новый сбор или всё это данные, которые у вас уже есть?
Какая обработка: хранение, анализ, передача, автоматизированные решения?

Законное основание / проверки по конкретным режимам

По каждому применимому режиму изучи действующую на сегодня основу для вопроса ниже и цитируй первоисточники:

По режимам, требующим определённого законного основания для обработки (например, GDPR, UK GDPR), определи основание для каждой цели (договор / законный интерес / согласие / юридическая обязанность / жизненно важные интересы / публичная задача / иное). Изучи конкретные требования и ожидания по тесту баланса или стандарту согласия; цитируй определяющий источник.
По режимам, регулирующим раскрытие данных (например, CCPA/CPRA и другие законы штатов США о приватности), проверь, не похожа ли какая-либо передача на «продажу», «передачу» (share) или иное регулируемое раскрытие по действующим сегодня законодательным определениям. Сторонняя реклама — постоянная ловушка: выясни, подпадает ли она под регулируемую категорию применимого режима.
По отраслевым режимам (HIPAA, GLBA, COPPA, FERPA и т. д.) изучи правила основания или раскрытия, специфичные для режима.

Проверяй актуальность: законодательные определения и основания часто меняются. Неуверенность отмечай для проверки юристом.

Кто и где

Кто внутри компании может видеть эти данные? Инженеры? Поддержка? Аналитики?
Есть ли третьи лица? Поставщики, партнёры, аналитика?
Где хранится? В каком регионе? Новая инфраструктура или существующая?
Как долго хранится? Есть график удаления или данные живут вечно?

Что может пойти не так

Если эти данные утекут, какой вред это причинит человеку?
Могут ли эти данные использоваться для дискриминации, пусть и случайно?
Удивятся ли пользователи, что это происходит? (Тест «жутковатости» — не правовой стандарт, но полезный.)
Есть ли возможность отказаться? Должна ли быть?

Написание PIA

Используй структуру образцовой PIA из конфигурационного CLAUDE.md. Если её не зафиксировали, используй эту типовую. Добавь в начало заголовок рабочего материала из раздела ## Outputs файла ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md (он зависит от роли пользователя — см. ## Who's using this).

[ЗАГОЛОВОК РАБОЧЕГО МАТЕРИАЛА — по разделу ## Outputs конфигурации плагина]

# Оценка воздействия на приватность: [Название функции / продукта]

**Подготовил(а):** [имя] | **Дата:** [дата] | **Статус:** ЧЕРНОВИК / УТВЕРЖДЕНО
**Владелец продукта:** [имя] | **Проверяющий по приватности:** [имя]

---

## Краткое резюме

[Два предложения: что это и допустимо ли. Например: «Функция X собирает данные
о местоположении, чтобы обеспечить Y. Обработка соответствует действующим
обязательствам политики приватности и использует согласие как законное
основание. Ниже рекомендованы две меры смягчения; блокирующих факторов не выявлено».]

**Общий риск:** [Выставляет проверяющий: 🟢 Низкий / 🟡 Средний / 🟠 Высокий / 🔴 Очень высокий]

---

## 1. Описание обработки

**Что:** [функция простым языком]
**Категории данных:** [конкретные поля, а не «данные пользователей»]
**Субъекты данных:** [клиенты / конечные пользователи / сотрудники / и т. д.]
**Цель:** [зачем, с привязкой к пользе для пользователя]
**Новый сбор?** [да — эти поля новые / нет — используются имеющиеся данные]

---

## 2. Законное основание

| Цель | Основание | Примечания |
|---|---|---|
| [цель 1] | [Договор / Законный интерес / Согласие / и т. д.] | [для законного интереса: краткое изложение теста баланса; для согласия: как получено] |

---

## 3. Движение данных

**Сбор:** [как и где данные поступают]
**Хранение:** [система, регион, шифрование]
**Доступ:** [кто и через какие средства контроля]
**Передача:** [третьи лица, цель, по какому DPA]
**Срок хранения:** [как долго, механизм удаления]

---

## 4. Соответствие политике приватности

| Обязательство политики | Соответствует? | Примечания |
|---|---|---|
| [обязательство из раздела политики приватности в конфигурационном CLAUDE.md] | 🟢 / 🟡 | |

[Если есть 🟡: перед запуском нужно обновить политику или изменить обработку]

---

## 5. Риски и меры смягчения

| № | Риск | Вероятность | Влияние | Мера смягчения | Статус | Ответственный |
|---|---|---|---|---|---|---|
| 1 | [конкретный риск, привязанный к решению, а не просто «утечка данных»] | Н/С/В | Н/С/В | [конкретная мера контроля] | Готово / Запланировано / Пробел | [имя] |

**Остаточный риск после мер смягчения:** [оценка]

---

## 6. Права субъектов данных

| Право | Можно ли осуществить? | Как |
|---|---|---|
| Доступ | | |
| Удаление | | |
| Исправление | | |
| Переносимость | | |
| Возражение | | |

---

## 7. Рекомендация

[УТВЕРЖДЕНО / УТВЕРЖДЕНО С УСЛОВИЯМИ / ТРЕБУЮТСЯ ИЗМЕНЕНИЯ / НЕ УТВЕРЖДЕНО]

**Условия (если есть):**
- [ ] [что конкретно должно произойти до запуска]

**Согласование:** [имя, дата]

Стандарты качества рисков

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

Плохой риск	Почему плох	Лучше
«Утечка данных»	Относится ко всему; ничего не говорит	«История местоположений доступна сотрудникам поддержки через админ-панель без журнала аудита, и злонамеренный сотрудник мог бы отслеживать пользователя незаметно»
«Несоответствие GDPR»	Порочный круг: PIA как раз должна оценивать соответствие	Назови конкретную статью и разрыв
«Пользователям может не понравиться»	Расплывчато	«Пользователи, отказавшиеся от маркетинга, всё равно могут это получать, потому что в этом потоке не проверяется флаг отказа»

Стремись к 2–5 настоящим рискам, а не к 15 раздутым.

Сверка с политикой приватности

Каждая PIA должна перекрёстно сверяться с обязательствами политики приватности из ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Типичные расхождения:

Политика говорит «мы собираем X, Y, Z», а новая функция собирает W. Политику нужно обновить или прекратить сбор W.
Политика говорит «мы не продаём данные», а новая функция передаёт их рекламному партнёру. Это может быть продажей по CCPA.
Политика говорит, что данные хранятся «пока ваша учётная запись активна», а новая функция хранит данные после удаления.

Отмечай каждое несоответствие. Одно из двух должно измениться до запуска.

Передача дальше

Продуктовой команде: список условий с ответственными и сроками. Не «улучшить безопасность», а «добавить журнал аудита в поиск местоположения в админ-панели, ответственный: [руководитель разработки], до запуска».
В скилл reg-gap-analysis: если PIA выявила несоответствие политики, этот скилл отслеживает обновление политики.
В процесс согласования: по ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → кто утверждает PIA.

Барьер: подача DPIA регулятору

Подготовить внутреннюю PIA — это исследование и документирование. Значимое действие — *подать DPIA надзорному органу* или добровольно раскрыть её регулятору в ответ на запрос.

Прежде чем подавать DPIA (или любую равнозначную оценку воздействия) регулятору, надзорному органу или органу правоприменения: прочитай ## Who's using this в ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Если роль — Non-lawyer (не юрист):

Подача регулятору имеет правовые последствия: документ становится частью надзорного дела, а любой существенный пропуск или ошибка — риском правоприменения. Вы согласовали это с юристом? Если да, продолжайте. Если нет, вот краткая справка, с которой стоит к нему прийти: [Составь резюме на одну страницу: режим и регулятор, почему делается подача (обязательный триггер или добровольно), выявленные риски, остаточный риск после мер смягчения, отмеченная неуверенность и три вопроса юристу до подачи.] Если вам нужно найти лицензированного юриста, адвоката (solicitor, barrister) или иного уполномоченного специалиста в вашей юрисдикции, быстрее всего начать со справочной службы вашего профессионального регулятора (коллегия адвокатов штата в США, SRA / Bar Standards Board в Англии и Уэльсе, Law Society в Шотландии, Северной Ирландии, Ирландии, Канаде и Австралии или эквивалент в вашей юрисдикции).

Не проходи этот барьер без явного «да».

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

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

Чего этот скилл не делает

Не утверждает обработку. PIA подписывает человек.
Не пишет DPIA для надзорного органа: это более формальный документ с особыми регуляторными требованиями. Здесь внутренняя оценка.
Не разрабатывает меры смягчения. Он описывает, что нужно смягчать; исправление проектирует инженерная команда.

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

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

---
name: pia-generation
description: >
  Generate a Privacy Impact Assessment in house format for a new feature, product,
  or processing activity, using the structure learned from your seed PIA. Use when
  the user says "write a PIA", "privacy impact assessment for", "do we need a PIA
  for this", "privacy review this feature", or describes a new data processing
  activity.
argument-hint: "[feature name or description]"
---

# /pia-generation

1. Load `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → PIA house style (trigger, structure, depth, sign-off).
2. Run the workflow below.
3. Check: is a PIA actually needed? (House trigger + research the mandatory-assessment triggers for each applicable regime — cite primary sources, verify currency.)
4. Intake: ask the product-team questions. Can pull from PRD if provided.
5. Write PIA in house format. Include privacy policy consistency check.
6. Output with conditions list and named owners. Route for sign-off.

```
/privacy-legal:pia-generation "Location sharing feature"
```

```
/privacy-legal:pia-generation
PRD: [Drive link]
```

---

# PIA Generation

## 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

A PIA is a conversation with the product team, captured. It asks: what data, why, how long, who sees it, what could go wrong. This skill structures that conversation and writes the output in this team's format — the one learned from the seed PIA during cold-start.

## Jurisdiction assumption

This assessment 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 analysis may not apply as written.

## Load prior context on this feature / activity

Before writing a new PIA, check the outputs folder for prior work on the same feature, processing activity, or counterparty. Read `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Outputs` for the path. Scan for:

- **Prior `use-case-triage` results** covering this activity — the triage's risk rating, mandatory conditions, and called-out concerns are the entry point for the PIA.
- **Prior `pia-generation` outputs** for the same or an overlapping activity — a superseding PIA should reconcile (what changed, what carried over). A PIA that silently produces different conclusions than a prior PIA on the same activity is a contradiction a reviewing attorney cannot see.
- **Prior `dpa-review` outputs** for vendors in scope — the DPA review's findings inform the PIA's analysis of subprocessor / cross-border / retention risk.

If a prior output is found, cite it in the PIA:

> "Prior triage ([date]) rated this [risk level] and required [conditions]. This PIA builds on that finding — [which conditions are satisfied, which remain, which are re-scoped]."

If a prior PIA exists:
> "This PIA supersedes the [date] PIA because [reason — scope change, new data category, vendor change, regulatory change]. Conclusions carried over: [X]. Conclusions revised: [Y, because Z]."

**Carry severity from upstream as a floor** per the cross-skill severity floor rule in `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Shared guardrails`. A use-case-triage that rated the activity high-risk cannot become a PIA that concludes low-risk without stating why and what changed.

If no prior output is found, say so explicitly — "No prior triage or PIA on this activity in outputs folder; this is a cold start" — so the reviewing attorney knows the check ran and didn't find anything to reconcile.

## Load house style

Read `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## PIA house style`. That has:
- What triggers a PIA here (may not match regulatory DPIA triggers — some teams PIA everything, some only high-risk)
- The structure template extracted from the seed PIA
- Typical depth
- Who signs off

If the seed PIA structure is in the config CLAUDE.md, **use it**. The point is that this PIA looks like the other PIAs this team produces, not like a generic one.

## Step 0: Is a PIA needed?

Check the trigger criteria in `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. That is the team's house answer.

In addition, **research the currently operative mandatory-assessment triggers** for each regime in the regulatory footprint (GDPR/UK GDPR DPIA triggers, CCPA/CPRA risk-assessment triggers, other US state data-protection assessment triggers, sectoral regimes). Cite the controlling statute, regulation, or regulator guidance with pinpoint references. Verify currency — assessment thresholds and definitions shift through new state laws, rulemaking, and enforcement guidance. Flag uncertainty rather than guess.

> **No silent supplement.** If a research query to the configured legal research tool returns few or no results for a regime's DPIA / risk-assessment triggers or lawful-basis rules, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / question]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged `[web search — verify]` and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.
>
> **Source attribution.** Tag every citation in the PIA with where it came from: `[Westlaw]`, `[regulator site]`, or the MCP tool name for citations retrieved from a legal research connector; `[web search — verify]` for web-search citations; `[model knowledge — verify]` for citations recalled from training data; `[user provided]` for citations the user supplied. Citations tagged `verify` carry higher fabrication risk and should be checked first. Never strip or collapse the tags.

Beyond statutory mandates, treat these as **strong indicators** that a PIA is worth doing even if not strictly mandatory (research whether any of them independently triggers a mandatory assessment under the applicable regime):

- New technology or novel use of existing tech
- Children's data
- Combining datasets that weren't collected together
- Data that could enable discrimination
- Processing that users wouldn't expect

If no statutory trigger applies and the house trigger also isn't met → "Doesn't look like this needs a PIA. Here's a one-paragraph note for the file explaining why, in case anyone asks."

## The intake

Before writing anything, get answers to these from the product team. Conversational is fine — this isn't a form to send them.

### What and why

- What's the feature/product/change?
- What problem does it solve for users?
- What personal data does it touch? Be specific — "user data" is not an answer. Which fields?
- Is any of it new collection, or is it all data you already have?
- What's the processing — storage, analysis, sharing, automated decisions?

### Legal basis / regime-specific checks

For each applicable regime, **research the currently operative framework** for the question below and cite primary sources:

- Under regimes that require an identified lawful basis for processing (e.g., GDPR, UK GDPR), identify the basis for each purpose (contract / legitimate interest / consent / legal obligation / vital interests / public task / other). Research the specific requirements and any balancing-test or consent-standard expectations; cite controlling authority.
- Under regimes that regulate disclosures (e.g., CCPA/CPRA and other US state privacy laws), check whether any flow looks like a "sale," "share," or other regulated disclosure under the currently operative statutory definitions. Third-party advertising is a recurring trap — research whether it falls within the regulated category for the applicable regime.
- Under sectoral regimes (HIPAA, GLBA, COPPA, FERPA, etc.), research any regime-specific basis or disclosure rules.

Verify currency; statutory definitions and bases are amended often. Flag uncertainty for attorney verification.

### Who and where

- Who inside the company can see this data? Engineers? Support? Analysts?
- Any third parties? Vendors, partners, analytics?
- Where is it stored? Which region? New infrastructure or existing?
- How long is it kept? Is there a deletion schedule or does it live forever?

### What could go wrong

- If this data leaked, what's the harm to the person?
- Could this data be used to discriminate, even accidentally?
- Would users be surprised this is happening? (The "creepy test" — not a legal standard but a useful one.)
- Is there an opt-out? Should there be?

## Writing the PIA

**Use the seed PIA structure from the config CLAUDE.md.** If none was captured, use this default. Prepend the work-product header from `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` `## Outputs` (it differs by user role — see `## Who's using this`).

```markdown
[WORK-PRODUCT HEADER — per plugin config ## Outputs]

# Privacy Impact Assessment: [Feature/Product Name]

**Prepared by:** [name] | **Date:** [date] | **Status:** DRAFT / APPROVED
**Product owner:** [name] | **Privacy reviewer:** [name]

---

## Executive summary

[Two sentences: what this is, whether it's okay. E.g., "Feature X collects
location data to provide Y. Processing is consistent with existing privacy
policy commitments and uses consent as lawful basis. Two mitigations
recommended below; no blockers identified."]

**Overall risk:** [Reviewer to set: 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high]

---

## 1. Description of processing

**What:** [the feature, in plain English]
**Data categories:** [specific fields — not "user data"]
**Data subjects:** [customers / end users / employees / etc.]
**Purpose:** [why — tie to user benefit]
**New collection?** [yes — these fields are new / no — reusing existing data]

---

## 2. Lawful basis

| Purpose | Basis | Notes |
|---|---|---|
| [purpose 1] | [Contract / LI / Consent / etc.] | [if LI: balancing test summary; if consent: how obtained] |

---

## 3. Data flow

**Collection:** [how/where data enters]
**Storage:** [system, region, encryption]
**Access:** [who, via what controls]
**Sharing:** [third parties, purpose, governed by which DPA]
**Retention:** [how long, deletion mechanism]

---

## 4. Privacy policy consistency

| Policy commitment | Consistent? | Notes |
|---|---|---|
| [commitment from config CLAUDE.md privacy policy section] | 🟢 / 🟡 | |

[If any 🟡: policy update needed before launch, or processing needs to change]

---

## 5. Risks and mitigations

| # | Risk | Likelihood | Impact | Mitigation | Status | Owner |
|---|---|---|---|---|---|---|
| 1 | [specific risk, tied to the design — not "data breach" generically] | L/M/H | L/M/H | [specific control] | Done / Planned / Gap | [name] |

**Residual risk after mitigations:** [assessment]

---

## 6. Data subject rights

| Right | Can be exercised? | How |
|---|---|---|
| Access | | |
| Deletion | | |
| Correction | | |
| Portability | | |
| Objection | | |

---

## 7. Recommendation

[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED]

**Conditions (if any):**
- [ ] [specific thing that has to happen before launch]

**Sign-off:** [name, date]
```

## Risk quality standards

Risks in a PIA should be **specific and tied to the design**, not generic. Bad risks pad the document and train readers to skim.

| Bad risk | Why bad | Better |
|---|---|---|
| "Data breach" | Applies to everything; says nothing | "Location history accessible by support staff via the admin panel without audit logging — a malicious insider could track a user undetected" |
| "Non-compliance with GDPR" | Circular — the PIA is supposed to *assess* compliance | Name the specific article and the gap |
| "Users might not like it" | Vague | "Users who opted out of marketing may still receive this because the opt-out flag isn't checked in this flow" |

Aim for 2-5 real risks, not 15 padded ones.

## Privacy policy diff

Every PIA should cross-check against the privacy policy commitments in `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. The common drift:

- Policy says "we collect X, Y, Z" — new feature collects W. Policy needs updating, or stop collecting W.
- Policy says "we don't sell data" — new feature shares with an ad partner. That might be a CCPA sale.
- Policy says retention is "as long as your account is active" — new feature keeps data post-deletion.

Flag every mismatch. One of them has to change before launch.

## Handoff

- **To product team:** Conditions list with owners and deadlines. Not "improve security" — "add audit logging to the admin panel's location lookup, owner: [eng lead], before launch."
- **To reg-gap-analysis skill:** If the PIA uncovered a policy inconsistency, that skill tracks the policy update.
- **To the sign-off process:** Per `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → who approves PIAs.

## Gate: submitting a DPIA to a regulator

Producing an internal PIA is research and documentation. *Submitting a DPIA to a supervisory authority* — or voluntarily disclosing one to a regulator in response to an inquiry — is the consequential act.

**Before proceeding to submit a DPIA (or any equivalent impact assessment) to a regulator, supervisory authority, or enforcement body:** Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. If the Role is Non-lawyer:

> Submitting to a regulator has legal consequences — the document becomes part of the supervisory record and any material omission or error becomes enforcement exposure. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
>
> [Generate a 1-page summary: regime and regulator, why a submission is being made (mandatory trigger or voluntary), the risks identified, residual risk after mitigations, any flagged uncertainty, and the three things to ask the attorney before filing.]
>
> If you need to find a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not proceed past this gate without an explicit yes.

## 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.

## What this skill does not do

- It doesn't approve the processing. A human signs the PIA.
- It doesn't write a DPIA for a supervisory authority — that's a more formal document with specific regulatory requirements. This is the internal assessment.
- It doesn't design the mitigation. It describes what needs mitigating; engineering designs the fix.

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

---
name: pia-generation
description: >
  Подготовь оценку воздействия на приватность (Privacy Impact Assessment, PIA) в формате, принятом у
  вас, для новой функции, продукта или вида обработки данных, по структуре, которую скилл усвоил из
  вашей образцовой PIA. Используй, когда пользователь говорит «напиши PIA», «оценка воздействия на
  приватность для», «нужна ли нам PIA для этого», «проверь эту функцию на приватность» или описывает
  новый вид обработки данных.
argument-hint: "[feature name or description]"
---

# /pia-generation

1. Загрузи `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → внутренний формат PIA (триггер, структура, глубина, согласование).
2. Выполни рабочий процесс ниже.
3. Проверь: действительно ли нужна PIA? (Внутренний триггер + изучи триггеры обязательной оценки по каждому применимому режиму — цитируй первоисточники, проверяй актуальность.)
4. Вводный опрос: задай вопросы продуктовой команде. Можно взять ответы из PRD, если он есть.
5. Напиши PIA во внутреннем формате. Включи проверку соответствия политике приватности.
6. Выдай результат со списком условий и названными ответственными. Направь на согласование.

```
/privacy-legal:pia-generation "Функция передачи геолокации"
```

```
/privacy-legal:pia-generation
PRD: [ссылка на Drive]
```

---

# Подготовка PIA

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

**Контекст дела.** Загляни в раздел `## 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 при первичной настройке.

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

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

## Загрузи прежний контекст по этой функции / виду обработки

Прежде чем писать новую PIA, проверь папку результатов: нет ли прежних работ по той же функции, виду обработки или контрагенту. Путь возьми из `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Outputs`. Просмотри:

- **Прежние результаты `use-case-triage`** по этому виду обработки: оценка риска, обязательные условия и отмеченные тревоги из первичного разбора — отправная точка для PIA.
- **Прежние результаты `pia-generation`** по тому же или пересекающемуся виду обработки: заменяющая PIA должна их согласовывать (что изменилось, что осталось). PIA, которая молча приходит к иным выводам, чем прежняя PIA по той же обработке, создаёт противоречие, которого проверяющий юрист не видит.
- **Прежние результаты `dpa-review`** по поставщикам в области: выводы проверки DPA помогают проанализировать риски субпроцессоров, трансграничной передачи и хранения.

Если прежний результат найден, сошлись на него в PIA:

> «Предыдущий первичный разбор ([дата]) оценил это как [уровень риска] и потребовал [условия]. Эта PIA опирается на тот вывод — [какие условия выполнены, какие остались, какие изменили объём]».

Если прежняя PIA существует:
> «Эта PIA заменяет PIA от [дата], потому что [причина — изменился объём, появилась новая категория данных, сменился поставщик, изменилось регулирование]. Выводы, оставленные без изменений: [X]. Выводы, пересмотренные: [Y, потому что Z]».

**Переноси серьёзность, определённую выше по цепочке, как нижнюю границу** по межскилловому правилу нижней границы серьёзности из `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Shared guardrails`. Первичный разбор (use-case-triage), оценивший вид обработки как высокорисковый, не может превратиться в PIA с выводом о низком риске без объяснения, почему и что изменилось.

Если прежних результатов нет, скажи об этом прямо — «В папке результатов нет предыдущего первичного разбора или PIA по этому виду обработки; это работа с нуля», — чтобы проверяющий юрист знал: проверка прошла и согласовывать было нечего.

## Загрузи внутренний формат

Прочитай `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## PIA house style`. Там записано:
- что запускает PIA у вас (может не совпадать с регуляторными триггерами DPIA: одни команды делают PIA на всё, другие только на высокорисковое)
- шаблон структуры, извлечённый из образцовой PIA
- обычная глубина
- кто согласовывает

Если структура образцовой PIA есть в конфигурационном CLAUDE.md, **используй её**. Смысл в том, чтобы эта PIA выглядела как другие PIA вашей команды, а не как типовая.

## Шаг 0: Нужна ли PIA?

Проверь критерии триггера в `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. Это внутренний ответ команды.

Кроме того, **изучи действующие на сегодня триггеры обязательной оценки** по каждому режиму из нормативного охвата (триггеры DPIA по GDPR / UK GDPR, триггеры оценки рисков по CCPA/CPRA, триггеры оценки защиты данных в других штатах США, отраслевые режимы). Цитируй определяющий закон, нормативный акт или разъяснение регулятора с точными ссылками. Проверяй актуальность: пороги и определения для оценок меняются с новыми законами штатов, нормотворчеством и разъяснениями по правоприменению. Неуверенность отмечай, а не угадывай.

> **Никаких тихих дополнений.** Если запрос к настроенному инструменту юридического поиска возвращает мало результатов или не возвращает ничего по триггерам DPIA / оценки рисков или правилам законного основания какого-либо режима, сообщи, что нашлось, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели без вопроса. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / вопрос], похоже, скудное. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент, (3) поискать в вебе: результаты получат пометку `[web search — verify]`, и их нужно сверить с первоисточником, прежде чем полагаться на них, или (4) пометить как непроверенное и остановиться. Что выберете?» Принимать ли источники с меньшей достоверностью, решает юрист.
>
> **Указание источника.** Помечай каждую ссылку в PIA тем, откуда она взята: `[Westlaw]`, `[regulator site]` или имя MCP-инструмента для ссылок, полученных из исследовательского коннектора; `[web search — verify]` для ссылок из веб-поиска; `[model knowledge — verify]` для ссылок, восстановленных из обучающих данных; `[user provided]` для ссылок, которые дал пользователь. Ссылки с пометкой `verify` несут больший риск выдумки, и проверять их нужно в первую очередь. Никогда не убирай и не склеивай пометки.

Помимо законодательных предписаний, считай следующее **сильными признаками** того, что PIA стоит делать, даже если она не строго обязательна (выясни, не запускает ли какой-либо из них самостоятельно обязательную оценку по применимому режиму):

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

Если ни один законодательный триггер не применим и внутренний триггер тоже не сработал → «Похоже, для этого PIA не нужна. Вот заметка на один абзац в дело с объяснением, почему, на случай если кто-то спросит».

## Вводный опрос

Прежде чем что-либо писать, получи от продуктовой команды ответы на эти вопросы. Разговорный формат подойдёт: это не анкета, которую им нужно рассылать.

### Что и зачем

- Что за функция / продукт / изменение?
- Какую проблему оно решает для пользователей?
- Каких персональных данных оно касается? Конкретно: «данные пользователей» — не ответ. Какие поля?
- Это новый сбор или всё это данные, которые у вас уже есть?
- Какая обработка: хранение, анализ, передача, автоматизированные решения?

### Законное основание / проверки по конкретным режимам

По каждому применимому режиму **изучи действующую на сегодня основу** для вопроса ниже и цитируй первоисточники:

- По режимам, требующим определённого законного основания для обработки (например, GDPR, UK GDPR), определи основание для каждой цели (договор / законный интерес / согласие / юридическая обязанность / жизненно важные интересы / публичная задача / иное). Изучи конкретные требования и ожидания по тесту баланса или стандарту согласия; цитируй определяющий источник.
- По режимам, регулирующим раскрытие данных (например, CCPA/CPRA и другие законы штатов США о приватности), проверь, не похожа ли какая-либо передача на «продажу», «передачу» (share) или иное регулируемое раскрытие по действующим сегодня законодательным определениям. Сторонняя реклама — постоянная ловушка: выясни, подпадает ли она под регулируемую категорию применимого режима.
- По отраслевым режимам (HIPAA, GLBA, COPPA, FERPA и т. д.) изучи правила основания или раскрытия, специфичные для режима.

Проверяй актуальность: законодательные определения и основания часто меняются. Неуверенность отмечай для проверки юристом.

### Кто и где

- Кто внутри компании может видеть эти данные? Инженеры? Поддержка? Аналитики?
- Есть ли третьи лица? Поставщики, партнёры, аналитика?
- Где хранится? В каком регионе? Новая инфраструктура или существующая?
- Как долго хранится? Есть график удаления или данные живут вечно?

### Что может пойти не так

- Если эти данные утекут, какой вред это причинит человеку?
- Могут ли эти данные использоваться для дискриминации, пусть и случайно?
- Удивятся ли пользователи, что это происходит? (Тест «жутковатости» — не правовой стандарт, но полезный.)
- Есть ли возможность отказаться? Должна ли быть?

## Написание PIA

**Используй структуру образцовой PIA из конфигурационного CLAUDE.md.** Если её не зафиксировали, используй эту типовую. Добавь в начало заголовок рабочего материала из раздела `## Outputs` файла `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` (он зависит от роли пользователя — см. `## Who's using this`).

```markdown
[ЗАГОЛОВОК РАБОЧЕГО МАТЕРИАЛА — по разделу ## Outputs конфигурации плагина]

# Оценка воздействия на приватность: [Название функции / продукта]

**Подготовил(а):** [имя] | **Дата:** [дата] | **Статус:** ЧЕРНОВИК / УТВЕРЖДЕНО
**Владелец продукта:** [имя] | **Проверяющий по приватности:** [имя]

---

## Краткое резюме

[Два предложения: что это и допустимо ли. Например: «Функция X собирает данные
о местоположении, чтобы обеспечить Y. Обработка соответствует действующим
обязательствам политики приватности и использует согласие как законное
основание. Ниже рекомендованы две меры смягчения; блокирующих факторов не выявлено».]

**Общий риск:** [Выставляет проверяющий: 🟢 Низкий / 🟡 Средний / 🟠 Высокий / 🔴 Очень высокий]

---

## 1. Описание обработки

**Что:** [функция простым языком]
**Категории данных:** [конкретные поля, а не «данные пользователей»]
**Субъекты данных:** [клиенты / конечные пользователи / сотрудники / и т. д.]
**Цель:** [зачем, с привязкой к пользе для пользователя]
**Новый сбор?** [да — эти поля новые / нет — используются имеющиеся данные]

---

## 2. Законное основание

| Цель | Основание | Примечания |
|---|---|---|
| [цель 1] | [Договор / Законный интерес / Согласие / и т. д.] | [для законного интереса: краткое изложение теста баланса; для согласия: как получено] |

---

## 3. Движение данных

**Сбор:** [как и где данные поступают]
**Хранение:** [система, регион, шифрование]
**Доступ:** [кто и через какие средства контроля]
**Передача:** [третьи лица, цель, по какому DPA]
**Срок хранения:** [как долго, механизм удаления]

---

## 4. Соответствие политике приватности

| Обязательство политики | Соответствует? | Примечания |
|---|---|---|
| [обязательство из раздела политики приватности в конфигурационном CLAUDE.md] | 🟢 / 🟡 | |

[Если есть 🟡: перед запуском нужно обновить политику или изменить обработку]

---

## 5. Риски и меры смягчения

| № | Риск | Вероятность | Влияние | Мера смягчения | Статус | Ответственный |
|---|---|---|---|---|---|---|
| 1 | [конкретный риск, привязанный к решению, а не просто «утечка данных»] | Н/С/В | Н/С/В | [конкретная мера контроля] | Готово / Запланировано / Пробел | [имя] |

**Остаточный риск после мер смягчения:** [оценка]

---

## 6. Права субъектов данных

| Право | Можно ли осуществить? | Как |
|---|---|---|
| Доступ | | |
| Удаление | | |
| Исправление | | |
| Переносимость | | |
| Возражение | | |

---

## 7. Рекомендация

[УТВЕРЖДЕНО / УТВЕРЖДЕНО С УСЛОВИЯМИ / ТРЕБУЮТСЯ ИЗМЕНЕНИЯ / НЕ УТВЕРЖДЕНО]

**Условия (если есть):**
- [ ] [что конкретно должно произойти до запуска]

**Согласование:** [имя, дата]
```

## Стандарты качества рисков

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

| Плохой риск | Почему плох | Лучше |
|---|---|---|
| «Утечка данных» | Относится ко всему; ничего не говорит | «История местоположений доступна сотрудникам поддержки через админ-панель без журнала аудита, и злонамеренный сотрудник мог бы отслеживать пользователя незаметно» |
| «Несоответствие GDPR» | Порочный круг: PIA как раз должна *оценивать* соответствие | Назови конкретную статью и разрыв |
| «Пользователям может не понравиться» | Расплывчато | «Пользователи, отказавшиеся от маркетинга, всё равно могут это получать, потому что в этом потоке не проверяется флаг отказа» |

Стремись к 2–5 настоящим рискам, а не к 15 раздутым.

## Сверка с политикой приватности

Каждая PIA должна перекрёстно сверяться с обязательствами политики приватности из `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. Типичные расхождения:

- Политика говорит «мы собираем X, Y, Z», а новая функция собирает W. Политику нужно обновить или прекратить сбор W.
- Политика говорит «мы не продаём данные», а новая функция передаёт их рекламному партнёру. Это может быть продажей по CCPA.
- Политика говорит, что данные хранятся «пока ваша учётная запись активна», а новая функция хранит данные после удаления.

Отмечай каждое несоответствие. Одно из двух должно измениться до запуска.

## Передача дальше

- **Продуктовой команде:** список условий с ответственными и сроками. Не «улучшить безопасность», а «добавить журнал аудита в поиск местоположения в админ-панели, ответственный: [руководитель разработки], до запуска».
- **В скилл reg-gap-analysis:** если PIA выявила несоответствие политики, этот скилл отслеживает обновление политики.
- **В процесс согласования:** по `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → кто утверждает PIA.

## Барьер: подача DPIA регулятору

Подготовить внутреннюю PIA — это исследование и документирование. Значимое действие — *подать DPIA надзорному органу* или добровольно раскрыть её регулятору в ответ на запрос.

**Прежде чем подавать DPIA (или любую равнозначную оценку воздействия) регулятору, надзорному органу или органу правоприменения:** прочитай `## Who's using this` в `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`. Если роль — Non-lawyer (не юрист):

> Подача регулятору имеет правовые последствия: документ становится частью надзорного дела, а любой существенный пропуск или ошибка — риском правоприменения. Вы согласовали это с юристом? Если да, продолжайте. Если нет, вот краткая справка, с которой стоит к нему прийти:
>
> [Составь резюме на одну страницу: режим и регулятор, почему делается подача (обязательный триггер или добровольно), выявленные риски, остаточный риск после мер смягчения, отмеченная неуверенность и три вопроса юристу до подачи.]
>
> Если вам нужно найти лицензированного юриста, адвоката (solicitor, barrister) или иного уполномоченного специалиста в вашей юрисдикции, быстрее всего начать со справочной службы вашего профессионального регулятора (коллегия адвокатов штата в США, SRA / Bar Standards Board в Англии и Уэльсе, Law Society в Шотландии, Северной Ирландии, Ирландии, Канаде и Австралии или эквивалент в вашей юрисдикции).

Не проходи этот барьер без явного «да».

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

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

## Чего этот скилл не делает

- Не утверждает обработку. PIA подписывает человек.
- Не пишет DPIA для надзорного органа: это более формальный документ с особыми регуляторными требованиями. Здесь внутренняя оценка.
- Не разрабатывает меры смягчения. Он описывает, что нужно смягчать; исправление проектирует инженерная команда.

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