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

Здесь описан процесс подготовки черновика для конкретного проекта. Он опирается на руководство по ответственному использованию ИИ, но не является политикой конфиденциальности, анкетой для поставщика, общим реестром рисков, юридическим заключением или автоматическим решением о DPIA.

Ключевые выводы

До подготовки черновика определите, требуется ли DPIA или другая оценка в конкретной юрисдикции.

Стройте оценку на проверенном и версионируемом реестре потоков данных.

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

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

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

Что такое PIA и чем может отличаться DPIA?

Оценка влияния на приватность (privacy impact assessment, PIA) — широкое название структурированной проверки того, как проект влияет на приватность. Юрисдикция, регулятор, договор или политика организации могут задавать конкретную оценку, пороги, процесс или роль утверждающего. Согласно статье 35 GDPR, оценка воздействия на защиту данных (DPIA) обязательна, если тип обработки, вероятно, создаёт высокий риск для прав и свобод людей, и имеет минимальные требования к содержанию.［1］

Британский регулятор ICO описывает предварительную проверку необходимости DPIA, консультации, описание обработки, необходимость и соразмерность, оценку рисков и меры по их снижению. На странице ICO сейчас указано, что часть руководства пересматривается после изменений британского законодательства, поэтому командам нужно сверяться с актуальным текстом для своей юрисдикции, а не считать старый шаблон неизменным законом.［2］

Прежде чем решать, какой документ нужен, заполните запись предварительной проверки:

Поле	Что записать
Проект и версия	Стабильная идентичность, владелец, этап и дата решения
Юрисдикции	Люди, подразделения, системы и передачи данных в области проверки
Основание для оценки	Закон, регулирование, политика, договор или добровольная практика
Признаки обработки	Масштаб, чувствительность, наблюдение, сопоставление данных, автоматизация, уязвимость, новизна
Доказательства проверки	Архитектура системы, карта данных, позиция юристов и факты о продукте
Решение	PIA, DPIA, другая оценка, совмещённый процесс или отсутствие оценки
Владелец решения	DPO, юрист по приватности, служба приватности или роль по политике
Триггеры повторной проверки	Изменение цели, данных, круга людей, технологии, получателей, масштаба или юрисдикции

ИИ не должен решать, что деятельность освобождена от требований закона. Если применимое основание или область неясны, запишите неопределённость и получите квалифицированную консультацию.

Шаг 1. Заморозьте проект, цель и границы решения

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

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

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

Это отделяет PIA от черновика внутренней политики. Политика устанавливает правила и полномочия для всей организации, а PIA применяет их к доказательствам и рискам одной операции обработки.

Шаг 2. Создайте проверенный реестр потоков данных

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

Для каждого потока запишите:

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

Стройте схему потоков по доказательствам, а не по устным преданиям об архитектуре. Если клиент отправляет идентификатор в API, API записывает его в журнал, очередь копирует, хранилище данных выводит из него атрибут, а поддержка может по нему искать, — все эти использования входят в реестр. Неясную ветвь пометьте VERIFY; не позволяйте ИИ выбирать самый правдоподобный путь.

Шаг 3. Минимизируйте пакет доказательств до обращения к ИИ

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

Создайте индекс доказательств:

ID доказательства	Безопасное описание	Владелец	Версия или дата	Разрешённое использование
`E-01`	Проверенная схема потока с синтетическими именами полей	Инженерия приватности	`v3`	Черновик PIA
`E-02`	Определение события только на уровне схемы	Платформа данных	`2026-04-12`	Инвентаризация полей
`E-03`	Фрагмент утверждённого графика хранения	Владелец записей	Текущая версия	Анализ хранения
`E-04`	Проверенные по договору сведения об обработчике	Закупки	Подписанная версия	Карта получателей

Оригиналы храните в уполномоченной системе и передавайте ИИ только минимальные утверждённые выдержки. VPN защищает сетевой трафик, но не делает загрузку персональных данных в сторонний сервис ИИ допустимой. Руководство по рискам приватности ИИ объясняет, почему настройки хранения, доступа и обучения на платформе нужно проверять отдельно.

Шаг 4. Оцените необходимость, соразмерность и правовое основание

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

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

Статья 35 требует систематического описания обработки и целей, оценки необходимости и соразмерности, оценки рисков для прав и свобод и мер по устранению этих рисков.［1］ Рассматривайте их как связанные анализы. Мера безопасности может снизить часть рисков, но не доказывает, что сбор данных вообще был необходим.

Шаг 5. Описывайте вред с точки зрения людей

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

Используйте структуру «причина — событие — последствие»:

Элемент	Синтетический пример
Причина	Широкий доступ поддержки к точной истории местоположения
Событие	Неуполномоченный сотрудник ищет запись бывшего партнёра
Влияние на человека	Риск преследования и потеря безопасности
Существующие меры	Ограничение ролей, согласование, журнал запросов и оповещения
Пробел в доказательствах	Реакция на оповещение не отрабатывалась
Дополнительное действие	Провести контролируемый тест обнаружения и реагирования
Владелец	Роль службы мониторинга безопасности

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

NIST Privacy Framework описывает подход к управлению рисками на уровне организации, который помогает выявлять риски приватности и управлять ими при создании продуктов и услуг.［3］ Такой подход полезен, чтобы связать обработку данных, управление, коммуникацию, защиту и проверку, не сводя приватность только к конфиденциальности.

Шаг 6. Свяжите меры контроля с рисками и доказательствами

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

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

Вопросы к поставщикам можно собрать через процесс анкеты комплексной проверки поставщика. В PIA переносите только проверенные ответы и факты из договоров. Не позволяйте модели превращать маркетинговые заявления или вопросы без ответа в подтверждённые меры.

Шаг 7. Оценка влияния на приватность с ИИ требует строгого контракта

Передайте шаблон, очищенный индекс доказательств, утверждённую терминологию и матрицу ответственности:

Подготовь разделы PIA, используя только предоставленные ID доказательств.
Точно сохрани факты о проекте, системах, данных, целях, получателях, хранении и владельцах.
Не делай выводов о правовом основании, юрисдикции, ролях контролёра, необходимости, согласии,
вероятности, тяжести, эффективности мер, остаточном риске или утверждении.
Неподтверждённые поля помечай [VERIFY] и не объединяй противоречащие утверждения.
Свяжи каждый фактический абзац с ID доказательств и верни вопросы для проверки.
Не запрашивай и не воспроизводи персональные данные, учётные данные или производственные записи.

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

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

Шаг 8. Проведите раздельные проверки с владельцами областей

Проводите отдельные проверки вместо одного общего утверждения:

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

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

Если ИИ-агент будет выполнять действия, а не только готовить текст, примените процесс безопасной работы с ИИ-агентами к правам доступа, инструментам, внедрению инструкций, утверждению, журналированию и откату. Эти меры должны подтверждаться реальными доказательствами из системы, а не обещаниями в PIA.

Шаг 9. Определите остаточный риск, консультации и утверждение

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

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

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

Шаг 10. Версионируйте оценку и задайте триггеры пересмотра

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

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

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

Что проверить до утверждения?

Итоги

Определите требуемую оценку до выбора шаблона.
Зафиксируйте проект и создайте проверенный реестр потоков данных.
Минимизируйте и очищайте доказательства, передаваемые ИИ.
Анализируйте необходимость, правовое основание, вред, меры и остаточный риск как отдельные решения.
Оставьте правовые решения, решения DPO, безопасности и утверждение рисков за людьми.
Версионируйте PIA и возвращайтесь к ней при изменении обработки или доказательств.

Часто задаваемые вопросы (FAQ)

PIA всегда совпадает с GDPR DPIA?

Нет. PIA — широкое понятие, а DPIA может быть конкретной обязательной правовой процедурой с определёнными триггерами и содержанием. Какой процесс применим к проекту и юрисдикциям, должны определить квалифицированные специалисты по приватности или юристы.

Может ли ИИ решить, требуется ли DPIA?

Нет. ИИ может упорядочить анкету предварительной проверки и отметить недостающие факты, но не может надёжно определить юрисдикцию, правовой порог, исключения или полномочия в организации. Запишите проверенное решение ответственного человека.

Что исключить из запроса к ИИ?

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

Достаточно ли схемы потоков данных для PIA?

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

Кто утверждает черновик?

Следуйте применимому праву и политике организации. Типичные роли: владелец продукта, команда приватности, DPO, юристы, безопасность, владельцы данных, владельцы рисков и ответственное руководство; их обязанности должны оставаться раздельными.

Устраняют ли сильные меры безопасности все риски приватности?

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

Что делать, если проверяющие не согласны?

Запишите каждую позицию, подтверждающие доказательства, полномочия на решение, итог, условия и особое мнение, где оно требуется. Не просите ИИ выбрать самую гладкую или самую удобную для запуска трактовку.

Как часто нужен пересмотр PIA?

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

Материал носит общий характер и не является юридической консультацией. Обязанности в области приватности различаются по юрисдикциям и меняются со временем; получите актуальные рекомендации DPO, специалистов по приватности и квалифицированных юристов.

Источники

EUR-Lex, Regulation (EU) 2016/679, Article 35 — https://eur-lex.europa.eu/eli/reg/2016/679/art_35/oj
UK Information Commissioner's Office, Data Protection Impact Assessments — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
NIST, Privacy Framework — https://www.nist.gov/privacy-framework/privacy-framework
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 4 сентября 2026 г.

Оценка влияния на приватность с ИИ: черновик PIA по шагам