Consent architecture: согласие как структурный объект, а не галочка

Зачем consent в виде архитектуры

Большинство операторов трактуют consent как однократный акт регистрации: клиент при подключении подписал договор — значит, на всё согласен. Это работало в эпоху bulk SMS-рассылок, но не работает при:

• ужесточении регуляторики (закон о ПДн, специальные категории данных, biometric data),
• росте количества use cases (CDP, fraud, scoring, partner sharing, AI training),
• partner-driven сценариях (банк, ритейлер, госуслуги через оператора).

Современный consent — structured object: «клиент Y дал согласие на использование данных типа X для цели Z в канале W на период T, с правом отзыва в момент R».

Без архитектуры consent невозможно:

• ответить регулятору, на каком основании конкретное использование данных было legal,
• предоставить клиенту прозрачную картину «что вы знаете обо мне и зачем»,
• быстро implementирован право withdrawal без перебивания всей системы.

Структурные элементы

Consent collector. Точки сбора consent: онбординг, app, web-form, contact center. Стандартизированный формат записи.

Consent registry. Centralised store consent claims. Каждая запись: subject (клиент), purpose (конкретная цель), data scope (какие категории данных), channel, validity period, source, version of consent text.

Purpose taxonomy. Контролируемый список целей использования данных: marketing communication, credit scoring, fraud prevention, partner sharing, product personalization. Каждая цель — отдельный consent.

Consent enforcement layer. Каждое использование данных идёт через check: «есть ли actual consent для этой цели у этого клиента?». Без consent — операция блокируется.

Withdrawal mechanism. Клиент в любой момент может отозвать consent. После withdrawal — данные не используются по этой цели, downstream-системы получают update.

Audit trail. Каждое consent-event (granted, withdrawn, expired) и каждое использование данных под consent — логируется.

Где обычно ломается

Consent есть в одной системе (например, в CRM как поле «согласие на маркетинг»), но другие системы не знают о нём — биллинг шлёт notification, fraud делится с партнёрами, аналитика тренирует модель. Inconsistency очевидна.

Purpose taxonomy не определена. «Согласие на коммуникацию» — это что? Marketing? Transactional? И то и другое? При претензии регулятора operator не может ответить чётко.

Consent text меняется, но registry хранит только последний. При проверке за прошлый период невозможно показать, какой текст клиент видел.

Withdrawal обрабатывается вручную — clear-cut SLA нет, withdrawal claims пропадают в очередях.

Granular consent невозможен — клиент может или согласиться на всё, или ни на что. Это нарушает GDPR-style требования.

Partner sharing идёт по generic «согласию», без специфики «передача данных партнёру X для цели Y». При претензии — оператор не может доказать legal basis.

Ключевые сценарии

Onboarding. Новый клиент. Granular consent сразу: marketing channels, partner sharing, profile-based personalization. Отдельные галочки, не одна общая.

Re-consent. При изменении consent text или новой purpose — клиенту показывается update. Без re-consent — старые данные не используются под новые purpose.

Withdrawal flow. Клиент в app может per-purpose отозвать consent. Изменение пушится в downstream-системы за минуты.

Subject access request. Клиент запрашивает, что оператор знает. Consent layer показывает purpose’ы, под которые данные использовались.

Data deletion. Клиент уходит — после legal retention period данные удаляются по всем purpose’ам.

Operating model

Owner — DPO (Data Protection Officer) с tech mandate, либо Head of Data Governance.

Команды:

• Platform engineering (consent registry, enforcement, APIs)
• Compliance / Legal (purpose taxonomy, consent text, regulator interface)
• Channel integration (где собираем consent, как enforce)
• Customer experience (UX consent collection и withdrawal)

Routine — quarterly consent audit, ежемесячный обзор withdrawal patterns, semi-annual review purpose taxonomy.

Что меряется

Consent coverage per purpose — какая доля базы имеет consent на каждую purpose.

Withdrawal rate — сколько withdrawal в месяц, по каким purpose, какие тренды.

Time to enforce withdrawal — сколько проходит от withdrawal до фактического прекращения использования.

Audit compliance — какая доля use cases имеет corresponding consent claim.

Как SamaraliSoft подключается

Consent Blueprint — 6-8 недель. Inventory current consent practice, gap analysis vs регулятор, дизайн purpose taxonomy, target architecture, governance framework, choice of platform (build / OneTrust / TrustArc / cloud-native). Pilot — обычно один use case (например, marketing communication) с миграцией существующих consents.

Связанное

• /architecture/telecom-cdp-architecture/ — CDP с consent enforcement
• /architecture/telecom-notification-fabric/ — notification fabric с consent gate
• /insights/telecom-data-protection/ — закон о ПДн
• /architecture/telecom-data-clean-room/ — clean room