Згода і право на забуття

🌐 Також доступно 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», або «так» оновленням про доставку, але «ні» маркетингу, а потім передумав?

Тепер в інший бік. Отримувач каже: видаліть мою персональну інформацію. Де вона? Мабуть, у 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 чи пошта?
• Згода на контактну точку: а як щодо цього конкретного номера телефону чи адреси пошти?
• Мета використання даних (Data Use Purpose): з якої причини: сповіщення про доставку, сервіс, маркетинг?

Разом архітектура може відповісти: «чи можемо ми використати інформацію цієї людини через цю контактну точку для цієї мети?» — що набагато корисніше, ніж «згода = так». Брати участь може будь-який запис, пов’язаний з окремою людиною: ліди, контакти, персональні акаунти, користувачі.

Click to enlarge

Чотири запитання, кожне вужче за попереднє. Одна позначка згоди (opt-in) жодне з них добре не відповідає.

Мета важлива

Роздрібний партнер надсилає Steve Trucking номер отримувача, щоб бригада могла узгодити доставку. Це не робить отримувача маркетинговим лідом. Ті самі дані можуть мати різні дозволені використання: узгодження доставки, подальший сервіс, маркетинг, персоналізація ШІ. Якщо політика чи закон розглядає їх по-різному, модель має їх розрізняти. Запитання не чи є в нас номер телефону? Воно — що нам дозволено з ним робити?

І згода — не завжди правова підстава. Деякі використання спираються на інші підстави, які передбачає закон, і це визначають юристи. Не будуйте архітектуру, що припускає, ніби кожне рішення щодо приватності — позначка opt-in. Підтримуйте те, що каже політика: якщо використання залежить від згоди, моделюйте й забезпечуйте згоду; якщо діє інша підстава, однаково зберігайте те, що потрібно, щоб вирішити, чи дозволене використання.

Згода має життєвий цикл і авторитетну систему

Люди дають згоду, відкликають її, змінюють уподобання, змінюють номери. Бізнес додає нові цілі; закони змінюються. Тож проєктуйте життєвий цикл: що обрано, коли, як, для якої мети і що стається при відкликанні. І тут стає цікаво: коли отримувач відкликає згоду, Salesforce про це знає. А платформа повідомлень? Аналітика? Агент? Згода, що живе в одній системі, поки інші діють на застарілому дозволі, — не надто вдалий контроль.

Це означає питати, яка система авторитетна щодо згоди. Salesforce, платформа вподобань, щось інше? Хоч би якою була відповідь, не дозволяйте п’яти системам незалежно вирішувати, чи погодилася та сама людина на те саме використання. Згоді потрібне те саме, що й будь-яким керованим даним: власник, авторитетний запис, спосіб синхронізації і забезпечення.

А тепер людина каже: забудьте мене

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

Не починайте пошуки, коли надходить запит. Тоді вже запізно починати розуміти ландшафт. Словник, походження і класифікація з модуля 3 — не паперова робота; саме вони роблять це можливим. Ви вже знаєте, які поля містять персональні дані і куди пішли копії.

Click to enlarge

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

Годинник цокає

Ці запити мають строки. За GDPR організація має відреагувати на запит людини без невиправданої затримки і протягом одного місяця з моменту його отримання; для складних чи численних запитів строк можна продовжити ще на два місяці, але людині треба повідомити про це протягом першого місяця, з поясненням причин (стаття 12(3), Регламент (ЄС) 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, сховище даних, системи партнерів, архіви, журнали, пошук, файли, розмови агентів. Підприємству досі потрібна відповідь рівня підприємства, і вам треба перевірити, що кожен інструмент справді охоплює, перш ніж на нього покладатися.

Перенесення і докази

Деякі закони також дають людям право отримати копію своїх даних. Зверніть увагу: це та сама задача пошуку. Видалення питає: де дані цієї людини, щоб ми могли з ними діяти? Перенесення питає: де вони, щоб ми могли їх надати? Обидва спираються на ідентичність, класифікацію, походження, інвентар систем і власність.

А потім: як довести, що ви це зробили? Запит отримано, ідентичність перевірено, системи переглянуто, дії вжито, винятки записано, збережені дані обґрунтовано, завершення зафіксовано. Тут справжня напруга: ви прибираєте чиїсь персональні дані, зберігаючи достатньо доказів, щоб показати, що запит оброблено правильно. Саме тому архітектори не повинні самі вигадувати правила зберігання. Юристи й фахівці з відповідності вирішують, які докази мають лишитися; архітектура зберігає їх, не зберігаючи даних, які мала прибрати.

За межами іспиту: що змінює ШІ. ШІ створює нові цілі й нові копії. Дозвіл використовувати дані для надання послуги не охоплює автоматично заземлення агента, персоналізацію чи навчання; Data Use Purpose — природне місце, щоб їх розрізняти. А персональні дані можуть виживати в промптах, контексті для grounding, розмовах, підсумках, пошукових і векторних індексах та журналах. «Ми видалили вихідний запис» — неповна відповідь, якщо шар ШІ досі пам’ятає.

Що тут вирішує архітектор

• Як моделюються згода й дозволене використання, щоб системи могли відповісти: хто, який канал, яка контактна точка і яка мета.
• Яка система авторитетна щодо згоди і як відкликання доходять до кожної системи, що на ній діє.
• Куди можуть поширюватися персональні дані: поля, вільний текст, файли, історія, аналітика, архіви, інтеграції, пошук і ШІ.
• Як запит знаходить правильну людину і запускає видалення, деідентифікацію чи погоджене зберігання в кожному місці.
• Які докази лишаються, щоб довести, що згоду і запити щодо приватності оброблено.

Згода і видалення здаються протилежностями (чи можемо ми використовувати ці дані? чи можемо ми зупинитися й прибрати їх?), але спираються на ті самі основи: ідентичність, мету, класифікацію, походження, власність, забезпечення і докази. Використовуйте стандартну модель згоди, контролюйте, куди йдуть персональні дані, знайте, де копії, і проєктуйте процес видалення до того, як надійде перший запит. Коли хтось питає «чи можете ви мене забути?», архітектурі потрібна краща відповідь, ніж «думаємо, що так».

Додаткові матеріали

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (англійською, перевірено 2026-10-14).
• Регламент (ЄС) 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).