DPIA — Data Protection Impact Assessment, оценка воздействия на защиту персональных данных. Изначально инструмент из европейского GDPR, но суть универсальна: до запуска системы выяснить, какие данные она обрабатывает, кому может навредить и что с этим делать. Для ИИ-систем оценка особенно важна: модель способна выдавать чувствительные выводы о людях, запоминать промпты и галлюцинировать на персональных данных.
В России требование оценивать вред закреплено 152-ФЗ с 1 сентября 2022 года: оператор определяет степень возможного вреда субъектам, сведения об этом попадают в уведомление об обработке персональных данных, а в основе лежит модель угроз по методике ФСТЭК. DPIA для ИИ-системы собирает это в один документ, пригодный и для регулятора, и для собственной команды. Проведение оценки у НЬЮ-ССТ — от 90 000 ₽, в составе пакета защиты ИИ — от 480 000 ₽ (сентябрь 2026).
Пошаговый план
Зафиксируйте границы оценки
Опишите систему одним абзацем: что она делает, чьи данные обрабатывает, кто оператор и на каком основании. Отметьте, входит ли в контур внешняя LLM через API, векторная база знаний, логи и интеграции с CRM. Границы важны: оценки «про ассистента вообще» не работают — работать должен документ про конкретный контур с конкретными потоками.
Постройте схему потоков данных
Нарисуйте путь персональных данных: источник (анкета, обращение, звонок) → извлечение и предобработка → промпт модели → логи и история диалогов → векторная база → выгрузки в другие системы. Для каждого перехода отметьте: копируются ли данные, где физически обрабатываются, кто имеет доступ, сколько хранятся. На этом шаге обычно всплывают «забытые» хранилища: экспорт диалогов в таблицы, резервные копии, тестовые стенды с боевыми данными.
Обоснуйте необходимость и пропорциональность
Ответьте на вопрос: можно ли достичь цели с меньшим вмешательством? Цель обработки, её правовое основание, минимально необходимый состав данных. Если ассистенту для ответа достаточно обезличенного фрагмента, сырые персональные данные в промпт попадать не должны. Если задачу решает фильтр на правилах, LLM можно не подключать. Такие решения — ядро пропорциональности.
Свяжите DPIA с требованиями 152-ФЗ
Российская опора оценки — оценка вреда и модель угроз: определите одну из степеней возможного вреда субъектам, зафиксируйте актуальные угрозы и меры по ним. Проверьте локализацию: первичный сбор персональных данных россиян должен происходить на территории РФ, а трансграничная передача требует отдельных оснований. Отдельно учтите отраслевые ограничения — например, требования к ИИ в государственных информационных системах.
Оцените риски, специфичные для ИИ
Выпишите сценарии вреда именно от ИИ-части: галлюцинация с неверными выводами о человеке в ответе клиенту; утечка промптов с персональными данными через логи или вендора; вывод системой чувствительных категорий из косвенных признаков; деградация качества после обновления модели; раскрытие персональных данных одного субъекта другому через контекст диалога. Для каждого сценария — вероятность, серьёзность и кто пострадает.
Назначьте меры и проверьте их достаточность
К рискам подберите меры: обезличивание и псевдонимизация до попадания в промпт, guardrails на входе и выходе, human-in-the-loop для решений о людях, договорные гарантии вендора про обучение на данных, шифрование хранилищ и логов, сроки удаления диалогов. Меры должны закрывать конкретные сценарии из предыдущего шага, а не существовать «для галочки» — иначе при проверке их спросят по существу.
Оформите отчёт и остаточные риски
Сведите результат в документ: описание системы, потоки, обоснование, риски, меры, остаточные риски с решением о приемлемости. Подпись ставит владелец системы — с этого момента оценка становится управленческим решением, а не мнением аналитика. Запись о DPIA и его дата попадают в реестр ИИ-активов: связь «актив — оценка — меры» должна восстанавливаться за минуты.
Назначьте условия пересмотра
DPIA — не разовый документ. Определите триггеры пересмотра: новые категории данных, смена модели или провайдера, инцидент, изменение законодательства. Периодическая ревизия — раз в год даже без триггеров. Дата следующего пересмотра фиксируется в отчёте; просроченная оценка при инциденте выглядит хуже, чем её отсутствие.
Чек-лист
По итогам оценки должны быть закрыты пункты:
- Система описана с границами и оператором
- Правовое основание обработки зафиксировано
- Схема потоков данных построена до уровня хранилищ
- Тестовые стенды с боевыми данными найдены и очищены
- Минимальность состава данных обоснована
- Степень вреда по 152-ФЗ определена и отражена в уведомлении
- Модель угроз актуализирована под ИИ-контур
- Локализация и трансграничная передача проверены
- Сценарии вреда от ИИ выписаны с вероятностью и серьёзностью
- Меры привязаны к конкретным рискам, а не списком «вообще»
- Обезличивание до промпта внедрено где возможно
- Решения о людях проходят человека
- Остаточные риски приняты владельцем под подпись
- Запись о DPIA внесена в реестр ИИ-активов
- Триггеры и дата пересмотра зафиксированы
Что влияет на результат
Глубина оценки зависит от контура. Система на публичных обезличенных данных закрывается упрощённым анализом за считанные дни. Как только в контуре появляются персональные данные или решения, влияющие на людей, цена ошибки растёт, и основной объём работы смещается в потоки данных и сценарии вреда. Сильно влияет зрелость архитектуры: документированные интеграции и известные хранилища ускоряют оценку в разы по сравнению с «легаси, где всё связано со всем». Опыт команды тоже фактор: первая DPIA занимает втрое больше времени из-за методологических вопросов, вторая и последующие идут по шаблону. Имеет значение и выбор места обработки: внешний API с логированием промптов порождает отдельный блок рисков, которого нет у локального контура — оценка честно отражает эту разницу.
Оформление не должно съедать проект: документ на 10–15 страниц закрывает требования, приложения со схемами важнее объёмного текста. Типичная очерёдность работ: границы и потоки — первая неделя, риски и меры — вторая, согласование и подписание — третья. Тянуть с оценкой до запуска системы не стоит: половина мер дешева именно на этапе проектирования, после релиза те же меры стоят в разы дороже. Если в компании несколько ИИ-систем, начните с той, что трогает клиентов: внутренние ассистенты подождут. Результат первой оценки — шаблон и словарь для следующих; методология после первого прохода перестаёт быть препятствием. Повторную оценку привязывайте к плану развития системы, а не к календарю: изменение состава данных — сигнал пересмотреть документ немедленно.
Частые ошибки
Оценки чаще всего получаются бесполезными из-за следующих ошибок:
- DPIA после запуска. оценка, сделанная post factum, не предотвращает вред — её пишут для отчёта, а не для решений
- Потоки данных «по памяти». без поиска по реальным хранилищам и логам схема пропускает именно те места, где утечка и случится
- Копирование GDPR без российской опоры. в РФ у оценки есть собственный каркас: степень вреда, модель угроз, локализация — их спрашивают первыми
- Меры списком без привязки к рискам. «у нас есть шифрование» не отвечает на вопрос, закрыт ли конкретный сценарий утечки промптов
- Отчёт без владельца. неподписанные остаточные риски означают, что за них не отвечает никто — при инциденте это дорогая экономия
Инструменты и сроки
Нужны схема потоков данных, реестр рисков и шаблон отчёта; по времени закладывайте 2–3 недели на одну ИИ-систему средней сложности вместе с выпиской мер. Первую оценку делайте на самом чувствительном сценарии: опыт и шаблон перенесёте на остальные системы компании.
- Схема потоков данных
- Шаблон реестра рисков
- Отчёт DPIA с планом мер
Что получится в итоге
Результат оценки — документ, который держит оборону с двух сторон: перед регулятором он показывает системную работу с рисками по 152-ФЗ, а перед командой — конкретные меры и границы допустимого. Остаточные риски приняты осознанно, у каждой меры есть владелец, а пересмотр привязан к событиям, а не к календарю. Для корпоративных клиентов и госзаказчиков готовая DPIA становится решающим аргументом при допуске ИИ-системы в эксплуатацию.