Когда SaaS-продукту или приложению нужна DPIA
Команда SaaS-продукта добавляет функцию, которая анализирует действия пользователей и присваивает им оценку риска. Клиенты смогут использовать ее, чтобы ограничивать операции в своих аккаунтах. Для разработки это новый набор событий, модель расчета и экран с результатом. Для людей, чьи действия оценивает система, последствия могут быть серьезнее: ошибочная оценка способна закрыть доступ к услуге или вызвать необоснованное подозрение.
В такой ситуации до запуска может потребоваться DPIA — Data Protection Impact Assessment, оценка воздействия обработки данных на права и свободы людей. Ее задача состоит не в том, чтобы подтвердить готовность продукта формальным документом. Оценка должна показать, какие последствия может вызвать новая обработка, можно ли достичь цели менее рискованным способом и какие изменения нужно внести в функцию до релиза.
Когда оценка обязательна
По GDPR DPIA проводится до начала обработки, если с учетом ее характера, масштаба, контекста и целей она, вероятно, создаст высокий риск для прав и свобод людей. Следовательно, сам факт выпуска новой функции еще не означает обязанности проводить полноценную оценку. Но и отсутствие медицинских или финансовых данных не гарантирует, что риска нет.
GDPR прямо выделяет, в частности, три ситуации: масштабную систематическую оценку личных характеристик с автоматизированными решениями, имеющими юридические или сопоставимо значимые последствия; масштабную обработку специальных категорий данных или сведений о судимостях; масштабное систематическое наблюдение за общедоступными местами. Надзорные органы также публикуют перечни операций, для которых DPIA требуется. При запуске продукта в конкретной стране соответствующий перечень нужно проверить.
Для цифрового продукта сигналами к более внимательной оценке могут быть профилирование, объединение данных из разных источников, постоянное наблюдение за поведением, обработка данных уязвимых людей или использование результата для решения, существенно влияющего на человека. Оценивается сочетание обстоятельств, а не наличие в описании функции слов «AI», «аналитика» или «скоринг».
| Новая функция | Что определить до решения о DPIA |
| Отчет о количестве активных пользователей | Какие данные нужны для подсчета, можно ли получить сводный результат без наблюдения за действиями конкретного человека |
| Запись сессий в приложении | Какие экраны и действия записываются, могут ли попасть в запись сообщения, платежные или чувствительные сведения |
| Оценка кандидатов в HR-сервисе | Какие данные влияют на результат, кто принимает итоговое решение и может ли ошибочная оценка лишить человека возможности трудоустройства |
| Автоматическое выявление «подозрительных» клиентов | Влечет ли оценка блокировку или отказ в услуге, можно ли оспорить результат и как проверяются ошибки модели |
Таблица не устанавливает, что для каждой указанной функции DPIA всегда обязательна. Она показывает, почему решение нельзя принимать по одному названию инструмента: важны данные, масштаб обработки и реальные последствия для человека.
На каком этапе продукта начинать DPIA
Оценку проводят, пока на архитектуру функции еще можно повлиять. Если команда уже выбрала поставщика, собрала исторические данные и включила функцию для всех клиентов, DPIA превращается в описание готового решения. Исправление выявленных проблем тогда требует значительно больше времени.
Практичный момент для первичной проверки — обсуждение требований к функции. Продуктовая команда описывает цель и ожидаемый результат, техническая команда объясняет, какие данные понадобятся и как будет работать обработка, а специалист по защите данных оценивает признаки высокого риска. Если их нет, решение и его основания фиксируют. Если признаки есть, начинают полноценную DPIA и уточняют ее по мере разработки.
Какие изменения требуют вернуться к оценке
DPIA не заканчивается первым релизом. Даже если первоначальная версия функции была оценена, условия ее использования могут измениться:
- Подключили новый источник данных. Например, к действиям внутри сервиса добавили сведения из CRM или данные стороннего поставщика. Комбинация позволяет делать выводы, которые были невозможны при первоначальной обработке.
- Изменили последствия результата. Сначала оценка риска служила подсказкой оператору, а теперь автоматически запускает блокировку аккаунта. Данные могут остаться прежними, но возможный вред для человека становится серьезнее.
- Расширили аудиторию или масштаб. Функцию, опробованную на небольшой группе, включили для всех клиентов или начали применять к детям, работникам либо другой группе, положение которой требует особого внимания.
- Передали данные новому поставщику. Внешний сервис получил доступ к исходным данным или результатам модели. Нужно проверить его роль, цели использования информации, условия хранения и влияние на ранее выбранные меры защиты.
Каждое такое изменение не означает, что оценку придется составлять заново с первой страницы. Но команда должна проверить, остаются ли верными ее выводы, и обновить DPIA до запуска измененной обработки, если риск стал иным.
Что анализировать на примере функции скоринга
Допустим, платформа помогает компаниям выявлять подозрительные действия в клиентских аккаунтах. Первоначально она показывала оператору список необычных событий. В новой версии система будет присваивать каждому пользователю балл риска и автоматически ограничивать доступ при достижении порога.
Цель функции понятна: снизить вероятность мошенничества. Для DPIA этого объяснения недостаточно. Нужно разобрать конкретную цепочку: какие события формируют балл, используются ли сведения из других сервисов, сколько хранится история, кто видит оценку и что именно происходит после срабатывания модели.
Затем оцениваются возможные последствия для людей. Ошибочная блокировка может помешать получить доступ к собственным средствам или необходимой услуге. Слишком широкий доступ сотрудников клиента к баллам риска способен привести к необоснованным выводам о пользователе. Если модель обучается на данных нескольких клиентов, возникает отдельный вопрос, для каких целей и на каком основании эти сведения используются.
Результатом DPIA могут стать изменения в продукте: убрать из модели ненужные признаки, сократить срок хранения истории, заменить автоматическую блокировку проверкой сотрудником или предоставить человеку понятный способ оспорить решение. Такая оценка влияет на требования к функции, а не только на содержание документации.
Что должно быть в самой оценке
GDPR требует описать планируемую обработку и ее цели, оценить необходимость и соразмерность действий, определить риски для людей и меры их снижения. Для SaaS-команды это удобно переводится в несколько рабочих вопросов:
- Зачем нужна функция и какие данные для нее действительно необходимы? Следует проверить, можно ли достичь результата с меньшим объемом данных, более коротким сроком хранения или без связи событий с конкретным пользователем.
- Какой вред может причинить обработка? Рассматриваются не только утечка или несанкционированный доступ. Ошибочный вывод модели, несправедливое ограничение услуги и невозможность оспорить решение тоже могут затронуть права человека.
- Какие меры меняют уровень риска? Для каждого значимого риска указывают конкретное решение: ограничение доступа, проверку человеком, изменение логики модели, контроль качества данных или понятную процедуру обжалования.
- Какой риск остается после этих мер? Команда фиксирует результат, ответственных за изменения и условия, при которых функцию можно запускать.
DPIA полезно обсуждать с теми, кто проектирует и использует функцию. При необходимости учитывается мнение людей, которых затронет обработка, или их представителей. Если у компании назначен DPO, его мнение также должно быть получено в рамках оценки.
Кто проводит DPIA в B2B SaaS
Если клиент использует SaaS для собственных целей и определяет, чьи данные в него загружать и как применять результат, обязанность оценить такую обработку обычно лежит на клиенте как на контролере данных. Поставщик продукта должен предоставить ему информацию и содействие, необходимые для оценки: описание работы функции, категорий данных, настроек, рисков и защитных мер.
При этом поставщику не стоит считать вопрос полностью чужим. Он принимает архитектурные решения и может сам определять цели отдельных операций, например использования данных для развития собственного продукта. Такие операции требуют самостоятельной оценки его роли и, при наличии высокого риска, собственной DPIA.
Для масштабируемого SaaS полезно подготовить материалы по функции, которые каждый клиент сможет использовать в своей оценке. Они экономят время, но не заменяют анализ конкретного применения: один клиент включает результат только как подсказку сотруднику, другой использует его для автоматического отказа в услуге. Последствия различаются.
Когда релиз нужно отложить
DPIA не дает компании разрешение принять любой риск, просто записав его в таблицу. Если оценка показывает высокий остаточный риск, который не удается снизить подходящими мерами, до начала обработки требуется предварительная консультация с компетентным надзорным органом. Запускать спорную функцию, пока этот вопрос не решен, нельзя.
Чаще оценка приводит к более прикладному решению: изменить настройки по умолчанию, убрать автоматическое действие, ограничить аудиторию пилота или добавить проверку результата человеком. После изменений риск оценивают повторно. Поэтому DPIA стоит включать в критерии готовности функции к релизу наравне с тестированием и безопасностью.
Главный вопрос для команды звучит так: что изменится для человека после запуска функции и сможет ли компания объяснить и ограничить возможный вред? Если ответ требует переработать продукт, DPIA выполнена вовремя.
Wolja Digital помогает SaaS-компаниям и разработчикам приложений определить, нужна ли DPIA для новой функции, провести оценку вместе с продуктовой командой и перевести ее выводы в конкретные требования к обработке данных до запуска.