Согласие и право на забвение

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 5 из 6 главы Качество данных и управление ими, глава 5 курса Data Architect. Каждый модуль самостоятелен. Назад: Законы о конфиденциальности определяют проектирование · Далее: Защищать, хранить и доказывать

Вопрос, на который отвечает этот модуль: как проектировать с учетом согласия и удаления данных о человеке?

У Steve Trucking есть номер телефона получателя. Простой вопрос: можем ли мы отправить ему SMS? Возможно. О сегодняшней доставке? О завтрашней? Можем ли мы использовать этот номер для рекламной акции? А если он сказал «никаких SMS» или «да» для обновлений о доставке, но «нет» для маркетинга, а потом передумал?

Теперь в другую сторону. Получатель говорит: удалите мою персональную информацию. Где она? В Salesforce, наверное, но мы уже знаем, что это не весь ответ. Она пришла от розничного партнера. Она может быть в платформе клиентских данных, в истории полей, в архиве, в заметке к доставке, в выгрузке, в журнале интеграции, в диалоге агента. Согласие и удаление звучат как вопросы политики, но в конце концов на них должна отвечать система. Это архитектура.

Согласие — это данные

Первый принцип: согласие — это данные. Не сводите его к Has_Opted_In__c = true. Настоящий вопрос никогда не звучит просто «дал ли человек согласие?». Он звучит так: согласие на что, через какой канал, на какой адрес или номер, с какой целью, когда, менялось ли оно и можем ли мы это доказать? Если бизнес принимает решения на основе этих ответов, их нужно хранить как структурированные данные. Абзаца в политике конфиденциальности недостаточно, как и флажка в веб-форме: флажок фиксирует событие; архитектура должна сохранить, что это событие означает.

Используйте модель, которую Salesforce уже построил

Моя позиция: используйте стандартную модель согласия везде, где можете, вместо того чтобы заново строить то же самое в пользовательских полях. Модель данных согласия Salesforce управляет согласием на четырех уровнях, и каждый задает более конкретный вопрос (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Глобальное согласие, на объекте Individual (физическое лицо): кто этот человек и не сказал ли он «нет» всему?
• Согласие на канал взаимодействия (Contact Point Type Consent): можем ли мы использовать такой тип канала, например SMS или электронную почту?
• Согласие на точку контакта (Contact Point Consent): а как насчет этого конкретного номера телефона или адреса электронной почты?
• Цель использования данных (Data Use Purpose): по какой причине — уведомления о доставке, обслуживание, маркетинг?

Вместе это позволяет архитектуре ответить на вопрос «можем ли мы использовать информацию этого человека через эту точку контакта с этой целью?», а это гораздо полезнее, чем «согласие = да». Участвовать может любая запись, связанная с физическим лицом: интересы (Lead), контакты, персональные учетные записи (Person Account), пользователи.

Click to enlarge

Четыре вопроса, каждый уже предыдущего. Один флаг согласия ни на один из них хорошо не отвечает.

Цель имеет значение

Розничный партнер присылает Steve Trucking номер получателя, чтобы бригада могла согласовать доставку. Это не делает получателя маркетинговым интересом. У одних и тех же данных могут быть разные разрешенные виды использования: согласование доставки, последующее обслуживание, маркетинг, персонализация с помощью ИИ. Если политика или закон относятся к ним по-разному, модель должна их различать. Вопрос не в том, есть ли у нас номер телефона? Вопрос в том, что нам разрешено с ним делать?

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

У согласия есть жизненный цикл и авторитетный источник

Люди дают согласие, отзывают его, меняют предпочтения, меняют номера. Бизнес добавляет новые цели; законы меняются. Поэтому проектируйте жизненный цикл: что было выбрано, когда, каким образом, для какой цели и что происходит при отзыве. И вот тут становится интересно: когда получатель отзывает согласие, Salesforce об этом знает. А платформа рассылок? Аналитика? Агент? Согласие, которое живет в одной системе, пока другие действуют по устаревшему разрешению, — так себе контроль.

Это значит, что нужно спросить, какая система авторитетна для согласия. Salesforce, платформа управления предпочтениями, что-то еще? Каким бы ни был ответ, не позволяйте пяти системам независимо решать, согласился ли один и тот же человек на одно и то же использование. Согласию нужно то же, что и любым управляемым данным: владелец, авторитетная запись, способ синхронизации и обеспечение.

А теперь человек говорит: забудьте меня

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

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

Click to enlarge

Запрос «забудьте меня» — это решение для каждой копии.

Время идет

У таких запросов есть сроки. По GDPR организация должна выполнить запрос человека без неоправданной задержки и в течение одного месяца с момента его получения; для сложных или многочисленных запросов срок можно продлить еще на два месяца, но человеку нужно сообщить об этом в течение первого месяца, с указанием причин (статья 12(3), Regulation (EU) 2016/679 (opens in a new tab)). Другие законы устанавливают свои сроки; какие из них применяются, скажут юристы. В любом случае месяца недостаточно, чтобы изучить ландшафт. Это срок, который должна опередить карта копий.

Удалить, обезличить или сохранить?

Запрос не обязательно означает, что все и везде исчезает. Некоторые записи нужно или можно сохранить; некоторые операционные записи могут остаться, но перестать идентифицировать человека; некоторые данные можно обезличить. Решают применимая политика и закон; архитектура поддерживает каждый исход, место за местом: удалить, обезличить или сохранить по утвержденному требованию (а тогда — кто может это видеть, как долго и зачем?).

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

Нельзя удалить то, что нельзя найти

Прежде чем удалить данные о человеке, его нужно найти. Запрос приходит с адреса электронной почты. Один розничный партнер прислал «Jane Smith», другой — «J. Smith», а номер телефона сменился. Получатель вообще не контакт; его данные лежат в каждой доставке. Один и тот же человек получал доставки для двух разных партнеров. Одна система знает его по электронной почте, другая — по внешнему ID. Удаление зависит от идентичности, и вы не хотите удалить чужие данные из-за слишком агрессивного сопоставления. Архитектура идентичности — часть архитектуры конфиденциальности.

Steve Trucking делает задачу еще сложнее. Один розничный партнер никогда не должен видеть доставки или получателей другого. Если один и тот же человек получал доставки для двух партнеров, операционная работа должна держать эти отношения раздельно, а конфиденциальности, возможно, все равно нужно найти человека в обоих. Не решайте вопрос конфиденциальности, ломая границу безопасности, и не защищайте границу, делая запросы о конфиденциальности невыполнимыми. Архитектура должна делать и то, и другое.

Фотографии и свободный текст — тоже данные

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

А свободный текст опасен. Вы удаляете имя, телефон и адрес, а потом находите такую заметку к доставке: «Позвонить Jane по номеру 602-555-0198. Код от ворот 4821. Во дворе собака». Вот они. Классификация заметок к доставке как чувствительных говорит вам, что проблема может быть; но она не находит и не удаляет персональные данные внутри текста. Иногда лучший ответ — вообще не давать ненужным персональным данным туда попадать. Прежде всего контролируйте, куда попадают персональные данные.

Privacy Center — это инструмент, а не вся архитектура

Salesforce Privacy Center помогает выполнять эти процессы. Его политики права на забвение строятся по объектам, чтобы охватить все, что вы хотите удалить, и запускаются для конкретной записи клиента (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). Это полезно. Но «мы купили Privacy Center, значит, все готово» — это не архитектура. Данные человека могут жить вне досягаемости любого отдельного инструмента: Data 360, хранилище, системы партнеров, архивы, журналы, поиск, файлы, диалоги агентов. Предприятию по-прежнему нужен ответ на уровне предприятия, и вам нужно проверить, что на самом деле охватывает каждый инструмент, прежде чем на него полагаться.

Переносимость и доказательства

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

А дальше: как доказать, что вы это сделали? Запрос получен, личность проверена, системы просмотрены, действия выполнены, исключения записаны, сохраненные данные обоснованы, завершение зафиксировано в журнале. Здесь есть реальное противоречие: вы удаляете персональные данные человека и при этом сохраняете достаточно доказательств, чтобы показать, что запрос обработан правильно. Именно поэтому архитекторы не должны сами придумывать правила хранения. Какие доказательства должны остаться, решают юристы и специалисты по соответствию требованиям; архитектура сохраняет их, не сохраняя данные, которые должна была удалить.

За пределами экзамена: что меняет ИИ. ИИ создает новые цели и новые копии. Разрешение использовать данные для предоставления услуги не распространяется автоматически на заземление агента (grounding), персонализацию или обучение; Data Use Purpose — естественное место, чтобы их различать. А персональные данные могут сохраняться в запросах к модели, контексте заземления, диалогах, сводках, поисковых и векторных индексах и журналах. «Мы удалили исходную запись» — неполный ответ, если слой ИИ все еще помнит.

Что здесь решает архитектор

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

Согласие и удаление выглядят противоположностями (можем ли мы использовать эти данные? можем ли мы прекратить и удалить их?), но опираются на одни и те же основы: идентичность, цель, классификацию, происхождение, владение, обеспечение и доказательства. Используйте стандартную модель согласия, контролируйте, куда попадают персональные данные, знайте, где копии, и спроектируйте процесс удаления до того, как придет первый запрос. Когда кто-то спрашивает «можете меня забыть?», у архитектуры должен быть ответ получше, чем «думаем, что да».

Дополнительно

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (на английском, проверено 2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), статья 12(3), срок выполнения запроса (на английском, проверено 2026-10-14).
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center) (на английском, проверено 2026-10-14).