Минимизация данных по GDPR: API реального времени
Актуально на 2026 год.
Статья 5(1)(c) GDPR обязывает собирать только то, что необходимо. Это принцип минимизации данных. Большинство команд нарушают его из-за дизайна форм, а не из злого умысла. Поля свободного текста вбирают имена, адреса и идентификационные номера, которые никто не планировал собирать.
Очистка базы данных постфактум не исправляет ситуацию. Нарушение происходит в момент сбора данных. Остановить его у источника — единственное настоящее решение. Проверка через API реального времени при отправке формы предотвращает избыточный сбор до его возникновения.
См. наш обзор по комплаенсу и практики безопасности для понимания того, как мы поддерживаем GDPR статью 5.
Почему формы собирают лишние данные
Поля свободного текста в веб-приложениях аккумулируют ПДн, которые никто не планировал:
- Поля «причина обращения» в тикетах поддержки, заполненные историями болезней и номерами полисов
- Разделы «дополнительные комментарии» в опросах с полными именами и телефонами
- Столбцы «примечания» в HR-системах с годами неструктурированных персональных данных
- Поля «примечание к заказу» с номерами клиентов, введёнными для решения вопросов
Принцип минимизации требует, чтобы эти ПДн никогда не попадали в ваши системы. Ретроактивная очистка лечит симптом. Обнаружение в реальном времени устраняет причину.
Почему ретроактивная очистка недостаточна
Команды, очищающие хранящиеся ПДн, сталкиваются с четырьмя проблемами.
Полнота. Сопоставление паттернов находит очевидные ПДн — адреса электронной почты и номера документов. Оно пропускает контекстные упоминания. «Моя сестра Ирина столкнулась с той же проблемой» содержит имя, которое большинство сканеров не заметит.
Правовые сроки. Нарушение происходит в момент сбора. Очистка данных спустя месяцы не исправляет это. Если регулятор проверяет период, когда данные хранились, нарушение уже зафиксировано.
Неполное удаление. Базы данных резервируются. Системы пишут журналы. Аналитические инструменты экспортируют данные. Даже после удаления из основной базы копии могут оставаться в резервных файлах и журналах аудита.
Риск нарушения. Между сбором и очисткой избыточные ПДн хранятся в ваших системах. Утечка в этот период включает сверхсобранные данные в её периметр.
Остановка сбора у источника решает все четыре проблемы. Данные, которые никогда не поступили, не могут быть взломаны, не требуют удаления и не считаются нарушением.
Паттерны обнаружения для валидации форм
Существует три способа добавить обнаружение ПДн в реальном времени в форму.
На стороне клиента (Chrome-расширение). Расширение отслеживает события вставки в поля браузера. Когда пользователь вставляет текст с ПДн, сущности подсвечиваются немедленно. Пользователь удаляет их до отправки. API-вызов не требуется — обнаружение работает локально. Определения типов сущностей — в глоссарии.
На стороне сервера (интеграция API). Форма отправляется на ваш сервер. До записи в базу данных ваш код вызывает API обнаружения. API возвращает типы сущностей с оценками достоверности. Высокодостоверные совпадения блокируют отправку с понятным сообщением. Среднедостоверные инициируют шаг проверки. Данные чисты до сохранения.
Гибридный (рекомендуется). Подсветка на стороне клиента даёт пользователям быструю обратную связь. Проверки на стороне сервера обеспечивают гарантию соответствия. Если пользователь проигнорировал предупреждение клиента, серверная проверка всё равно поймает ПДн. В базу не попадает ничего непроверенного. Часто задаваемые вопросы о пороговых значениях обнаружения — в разделе FAQ.
Пример: медицинский портал для пациентов
Портал позволяет пациентам описать симптомы в поле свободного текста перед записью. В поле регулярно вводятся имена других пациентов, идентификационные номера и домашние адреса. Ничему из этого не место в системе записи.
До интеграции обнаружения в реальном времени:
- ПДн в поле симптомов: около 12% отправок
- Метод очистки: еженедельный пакетный процесс
- Статус соответствия: реактивный — нарушение статьи 5(1)(c) происходило в момент сбора
После интеграции API при отправке:
- API обнаруживает высокодостоверные ПДн до любой записи в базу данных
- Пациент видит: «Ваше сообщение, похоже, содержит персональные данные. Пожалуйста, удалите их перед отправкой»
- Пациент правит и отправляет повторно
- База данных получает только описание симптомов
В этом сценарии доля ПДн в поле снизилась примерно с 12% до менее 1% отправок. Соответствие теперь подтверждается журналами серверного обнаружения, а не ретроспективными сессиями очистки.
Аудиторские записи в точке сбора
Регуляторы по-разному относятся к реактивным командам и командам с выстроенным контролем. Статья 25 GDPR — защита уже на этапе проектирования и по умолчанию — поощряет последних.
Обнаружение в точке сбора создаёт полезные аудиторские записи:
- Журнал обнаружения. Каждое сканирование формы сохраняется с типами обнаруженных сущностей, оценками достоверности, предпринятым действием и результатом.
- Ежемесячные отчёты. Сводки показывают долю обнаружения по полям и типам сущностей, а также реакцию пользователей.
- Записи о конфигурации. Пороговые настройки, охватываемые поля и отслеживаемые типы сущностей — это свидетельство чёткой управляемой политики.
Эти записи помогают при проверках регулятора. Они также поддерживают внутренний аудит и реестры обработки. Примеры контроля в точке сбора — в разделе кейсов.
ИИ-инструменты и минимизация данных
Специалисты поддержки нередко вставляют письма клиентов в ИИ-инструменты для составления ответов. Эти письма могут содержать имена, адреса и номера счетов. Отправка их в ИИ-модель может выходить за рамки необходимого.
MCP-сервер добавляет шаг обнаружения до того, как текст достигает модели. Имена клиентов превращаются в [CUSTOMER]. Конкретные детали очищаются. ИИ составляет ответ на основе очищенного текста. Специалист добавляет обратно только то, что нужно для ответа.
Это соответствует принципу минимизации данных при использовании ИИ. Модель получает только необходимое — как правило, ПДн вообще не нужны. Полный список типов обнаруживаемых сущностей — на странице сущностей.