Закони про приватність формують дизайн

🌐 Також доступно 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)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 4 з 6 розділу Якість даних і врядування, розділ 5 курсу Data Architect. Кожен модуль самостійний. Попередній: Знайте свої дані · Наступний: Згода і право на забуття

Питання, на яке відповідає цей модуль: Чого вимагають від дизайну Salesforce закони про приватність і галузеве регулювання?

Коли я працював в Австралії, я зустрів чимало початківців-архітекторів, які ніколи не чули про GDPR. Європейці часто не чули про закон про приватність Каліфорнії, чи Канади, чи Бразилії. Це природно: ви знаєте правила там, де працюєте. Але ці закони сягають через кордони і формують дизайн систем, хоча жоден із них не про Salesforce. Тож їм місце в курсі з архітектури даних.

Вам не треба ставати юристом. Але треба бачити, що регулювання може змінити, де зберігаються дані, що ви збираєте, хто їх бачить, чому ви можете їх використовувати, як довго їх зберігаєте, куди надсилаєте, чи можете видалити, яку історію зберігаєте і що зможете довести пізніше. Це не лише юридичні запитання. Це запитання архітектури даних.

Цей модуль — архітектурні настанови, а не юридична порада. Юридичні команди й фахівці з відповідності вирішують, які закони діють і чого вони вимагають. Архітектор перетворює ці вимоги на дизайн, який можна забезпечити.

Закони не зупиняються на кордоні

Спершу найбільша хибна думка: «ми не в Європі, тож GDPR не діє». Можливо, а можливо, ні. Територіальна сфера GDPR сягає організацій поза ЄС, що пропонують товари чи послуги людям в ЄС або відстежують їхню поведінку там (стаття 3, Регламент (ЄС) 2016/679 (opens in a new tab)). Тож те, де головний офіс вашої компанії, — не кінець запитання. Де ваші клієнти, співробітники, люди, чиї дані ви тримаєте, ваші системи, ваші обробники? Куди подорожують дані? Це знову ландшафт із розділу 4. Без знання, куди йдуть дані, добрих рішень щодо приватності не ухвалити.

Регулювання, яке треба впізнавати

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

Закон чи стандарт	Де чи що	Чому архітектор має його впізнавати
GDPR (opens in a new tab)	Європейський Союз	Персональні дані, законна обробка, права людини, зберігання, передача, приватність за задумом
CCPA у редакції CPRA (opens in a new tab)	Каліфорнія	Права споживачів щодо персональної інформації, яку про них збирають компанії
PIPEDA (opens in a new tab)	Канада	Як організації приватного сектору поводяться з персональною інформацією
LGPD (opens in a new tab)	Бразилія	Загальний закон Бразилії про захист персональних даних
Privacy Act 1988 (opens in a new tab)	Австралія	Як організації поводяться з персональною інформацією за Australian Privacy Principles
HIPAA (opens in a new tab)	Охорона здоров’я США	Захищена медична інформація у відповідних контекстах
PCI DSS (opens in a new tab)	Платіжні картки	Захист даних рахунків платіжних карток
Sarbanes-Oxley (SOX) (opens in a new tab)	Публічні компанії США	Контролі й докази за фінансовою звітністю
COPPA (opens in a new tab)	США, діти онлайн	Персональна інформація, зібрана онлайн у дітей

Перелік зростає (більше штатів США мають власні закони), а закони змінюються. Тому я не хочу, щоб ви завчили таблицю і думали, що вивчили архітектуру приватності. Вивчіть назви, а потім — запитання, що їх переживуть.

Що спільного в законах

Деталі різняться, але великі закони про приватність раз у раз повертаються до тих самих кількох речей, і кожна з них лягає на архітектуру.

Права. Люди можуть попросити побачити свої дані, виправити їх, видалити й забрати з собою; за законами Каліфорнії та Бразилії вони також можуть відмовитися від їх продажу. Кожен такий запит означає знайти дані людини, усі до одного.

Передавання. GDPR і LGPD контролюють вихід персональних даних за межі своєї юрисдикції і вимагають належного захисту там, куди вони йдуть; PIPEDA очікує того самого рівня захисту, коли дані обробляє третя сторона, де б вона не була. Це знову ландшафт: які стрілки перетинають кордон?

Повідомлення про витік. Коли персональні дані розкрито, закони очікують, що ви повідомите органи влади, а іноді й людей, яких це зачепило, у строк, що залежить від закону. Не можна повідомити про дані, про які ви не знали, що вони у вас є, або сказати, що саме розкрито, якщо ви не можете знайти копії.

Підзвітність. Ви маєте вміти показати відповідність: записи про те, що ви обробляєте і навіщо, оцінки впливу для обробки з високим ризиком, а за GDPR і LGPD — ще й інспектора із захисту даних. Архітектура має створювати ці записи.

Почніть із того, що персональне

Перш ніж захищати персональну інформацію, знайдіть її. Частина очевидна: ім’я, домашня адреса, телефон, пошта. Частина — ні: місцезнаходження, ідентифікатори пристроїв, IP-адреси, зображення, поведінкові дані, усе, що можна пов’язати з людиною. І контекст важливий. Доставка Steve Trucking несе ім’я, адресу, номер телефону, нотатки до доставки й фото отримувача. Фото може показувати коробку на ґанку, або людину, або інтер’єр дому. Доставка — операційні дані, але деякі її атрибути персональні. Тому модуль 3 класифікував поля: приватність починається зі знання того, що у вас є.

Де це живе?

«Salesforce». Мабуть, не лише Salesforce. Це прийшло від роздрібного партнера? Скопійовано в Snowflake, поглинуто Data 360, записано в журнал інтеграції, експортовано користувачем, лишилося в історії полів, заархівовано, скопійовано в sandbox, передано партнерові, використано в розмові агента? Персональні дані поширюються. Тож коли юристи питають «де ми тримаємо інформацію про цю людину?», «ми знаємо, де поточне значення» — не відповідь. Мені потрібні ландшафт і походження: куди пішли копії.

Click to enlarge

Один номер телефону, багато копій. Приватність стосується й копій.

Чому вам дозволено це використовувати?

Мати дані і мати дозвіл їх використовувати — не одне й те саме. Steve Trucking має номер телефону отримувача, щоб узгодити сьогоднішню доставку. Чи робить це його маркетинговим списком? Ні. Правова підстава залежить від юрисдикції й ситуації, і це спрямовують юристи, але архітектура має нести відповідь: чому дані зібрано, яке використання дозволено, чи потрібна була згода, чи її надано, відкликано, і для якого каналу, адреси й мети. Дозвіл використовувати дані має бути представлений як дані, бо документ політики не може ухвалити рішення під час роботи системи. Наступний модуль це моделює.

Збирати менше — архітектурне рішення

Один із найсильніших контролів приватності — не збирати дані або не копіювати їх туди, де вони не потрібні. Чи потрібен Snowflake номер телефону отримувача? Чи потрібна аналітиці повна адреса з вулицею? Чи потрібні sandbox справжні фото доставок? Чи потрібні агентові персональні дані отримувача, щоб відповісти на це запитання? Якщо ні, найсильнішим контролем може бути не класти їх туди. Кожна копія, якої ви не зробили, — копія, яку не треба захищати, зберігати, видаляти, відстежувати для неї згоду, аудитувати чи повідомляти про неї в разі витоку. Найдешевші для врядування чутливі дані — ті, яких ви ніколи не копіювали.

Зберігання — частина моделі

«Поки що зберігаємо все» — це політика зберігання. Просто погана. Для важливих даних я хочу знати ще на етапі дизайну, як довго вони нам потрібні і чому; чи встановлює регулювання мінімум, а інше — максимум; коли запускається годинник; і що станеться в кінці: видалити, заархівувати, деідентифікувати, і де копії? Фінансові записи, можливо, доведеться зберігати встановлений строк. Код воріт отримувача не має жодної мети через роки після доставки. Ці рішення не чекають, доки база стане великою.

Анонімізоване, псевдонімізоване, зашифроване, замасковане

Замініть «Jane Smith» на 7F92A1. Jane анонімізовано? Ні, якщо інша таблиця досі каже 7F92A1 = Jane Smith. Це псевдонімізація: прямий ідентифікатор замінено, але дані можна знову пов’язати за допомогою інформації, що зберігається окремо, а за GDPR псевдонімізовані дані досі є персональними даними (стаття 4(5)). Анонімізація йде далі: дані більше не можна розумно пов’язати з людиною (преамбула, пункт 26). Тож коли хтось каже «нам не треба це видаляти, ми просто приберемо ім’я», будьте обережні. Якщо людину досі можна розумно ідентифікувати, ви цю межу не перетнули. Чи відповідає результат закону, вирішують юристи; робота архітектора — точно сказати, що робить система: чи можна знову пов’язати, які ключі лишаються, де зберігаються зіставлення?

Вживайте слова точно, бо вони розв’язують різні задачі. Шифрування захищає дані від несанкціонованого розкриття; уповноважений користувач досі може їх розшифрувати. Маскування змінює те, що бачать певні користувачі чи середовища. Псевдонімізація відокремлює пряму ідентичність, зберігаючи шлях назад. Анонімізація прибирає розумну можливість ідентифікувати людину. Лише остання виводить дані з категорії «персональних».

Регулювання стає вимогами

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

Click to enlarge

Від регулювання до доказів: юристи тлумачать, власник встановлює політику, архітектор робить так, щоб це працювало і було доказовим.

І відповідність — не продукт. Не можна купити «відповідність: увімк.». Шифрування може підтримувати вимогу, функції аудиту дають докази, інструменти зберігання виконують політику, дані згоди підтримують дозволене використання, але ліцензування функції не робить архітектуру відповідною. Відповідність випливає з усього дизайну: людей, політики, процесу, даних, контролів і доказів. Salesforce — частина цього, але не все. А якщо політика достатньо важлива, щоб її забезпечувати, запитайте, чи достатньо вона важлива, щоб її доводити: хто мав доступ до цього запису 17 березня, хто змінив це поле, що містив той експорт? Модуль 6 розглядає докази.

Приватність змінює ландшафт

У Steve Trucking персональні дані отримувача надходять через три інтеграції партнерів. Salesforce вони потрібні для доставок; бригадам потрібна їх частина, лише для своїх зупинок, лише того дня; Snowflake хоче аналітику доставок; фінансам потрібно достатньо, щоб виставити рахунок, але не те, що бачить бригада. А один роздрібний партнер ніколи не має бачити отримувачів іншого. Приватність змінює стрілки: певні поля не йдуть у Snowflake, аналітика отримує менш ідентифіковану версію, бригади бачать лише свої зупинки, зберігання нижче за потоком відрізняється від операційного. Вимога приватності не стоїть поруч із діаграмою ландшафту. Вона її змінює.

Запитання, що переживуть регулювання

Регулювання змінюється, тож носіть із собою стійкий набір запитань для будь-яких чутливих чи регульованих даних:

• Що це? Персональні, чутливі, фінансові, медичні, платіжні, дитячі чи інакше регульовані дані?
• Де це живе? Кожна копія: інтеграції, історія, аналітика, архіви, sandboxes, журнали, використання ШІ.
• Чому ми можемо це використовувати? Яка мета і правова підстава діють? Чи залучена згода?
• Хто може це використовувати? Люди, системи, партнери, інтеграції, агенти.
• Як довго ми це зберігаємо і що станеться в кінці?
• Чи може людина реалізувати свої права щодо цього? Доступ, виправлення, видалення, перенесення, заперечення — як передбачає закон.
• Чи можемо ми довести, що сталося? Доступ, зміни, експорти, згода, видалення, зберігання.

Врядування ШІ стає законом

ШІ додає ще одного споживача керованих даних. Чи може ШІ-система використовувати ці дані, для якої мети, як grounding, у поєднанні з чим, повторюючи у своєму виводі, з журналюванням де і як довго? Врядування ШІ переходить із політики компаній у закон: Акт ЄС про штучний інтелект (Регламент (ЄС) 2024/1689 (opens in a new tab)) — перший широкий приклад. Чого він вимагає, залежить від системи й використання. Напрям для архітекторів ясний: ШІ не стоїть поза врядуванням; це ще один споживач керованих даних.

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

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

Регулювання не стає архітектурою, коли його назви пишуть на слайді. Воно стає архітектурою, коли змінює те, як дані збирають, класифікують, переміщують, захищають, зберігають, видаляють і доводять.

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

• Офіційні джерела регулювання — у посиланнях у таблиці вище (перевірено 2026-10-14).
• Регламент (ЄС) 2016/679 (GDPR) (opens in a new tab): стаття 3 (територіальна сфера), стаття 4(5) (псевдонімізація), преамбула, пункт 26 (анонімна інформація).
• Регламент (ЄС) 2024/1689 (Акт про ШІ) (opens in a new tab), EUR-Lex.