Sự đồng ý và quyền được lãng quên

🌐 Cũng có bằng 28 ngôn ngữ khác

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

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 5 trong 6 của chương Chất lượng và quản trị dữ liệu, chương 5 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Luật quyền riêng tư định hình thiết kế · Tiếp theo: Bảo vệ, lưu giữ và chứng minh

Câu hỏi mô-đun này trả lời: Làm thế nào để thiết kế cho sự đồng ý, và cho việc xóa một con người?

Steve Trucking có số điện thoại của một Người nhận. Câu hỏi đơn giản: chúng ta có được nhắn tin cho họ không? Có thể. Về lần giao hàng hôm nay? Ngày mai? Chúng ta có được dùng số đó cho một chương trình khuyến mãi không? Nếu họ đã nói không nhận tin nhắn, hoặc đồng ý nhận cập nhật giao hàng nhưng không nhận marketing, rồi sau đó đổi ý thì sao?

Giờ là chiều ngược lại. Người nhận nói: hãy xóa thông tin cá nhân của tôi. Nó ở đâu? Salesforce, có lẽ vậy, nhưng chúng ta đã biết đó không phải là toàn bộ câu trả lời. Nó đến từ một Đối tác bán lẻ. Nó có thể nằm trong một nền tảng dữ liệu khách hàng, lịch sử trường, một kho lưu trữ, một ghi chú giao hàng, một bản xuất, một nhật ký tích hợp, một cuộc hội thoại của tác tử. Sự đồng ý và việc xóa nghe như những câu hỏi chính sách, nhưng sớm muộn hệ thống phải trả lời chúng. Đó là kiến trúc.

Sự đồng ý là dữ liệu

Nguyên tắc đầu tiên: sự đồng ý là dữ liệu. Đừng thu gọn nó thành Has_Opted_In__c = true. Câu hỏi thực sự không bao giờ chỉ là “họ có đồng ý không?” Mà là đồng ý với cái gì, qua kênh nào, tại địa chỉ hay số điện thoại nào, cho mục đích gì, khi nào, nó có thay đổi không, và chúng ta có chứng minh được không? Nếu doanh nghiệp ra quyết định dựa trên những câu trả lời đó, chúng phải được lưu dưới dạng dữ liệu có cấu trúc. Một đoạn văn trong chính sách quyền riêng tư là không đủ, một ô đánh dấu trên biểu mẫu web cũng vậy: ô đánh dấu ghi lại một sự kiện; kiến trúc phải giữ được ý nghĩa của sự kiện đó.

Dùng mô hình Salesforce đã xây sẵn

Lập trường của tôi: dùng mô hình đồng ý có sẵn ở bất cứ đâu có thể, thay vì xây lại cùng một thứ bằng các trường tùy chỉnh. Mô hình dữ liệu đồng ý của Salesforce quản lý sự đồng ý ở bốn cấp, mỗi cấp là một câu hỏi cụ thể hơn (Understand the Salesforce Consent Data Model (opens in a new tab), tiếng Anh):

• Đồng ý toàn cục, trên Individual: người này là ai, và họ đã nói không với mọi thứ chưa?
• Đồng ý theo kênh tương tác (Contact Point Type Consent): chúng ta có được dùng loại kênh này, như SMS hay email không?
• Đồng ý theo điểm liên lạc: còn số điện thoại hay địa chỉ email cụ thể này thì sao?
• Mục đích sử dụng dữ liệu: vì lý do gì: thông báo giao hàng, dịch vụ, marketing?

Ghép lại, kiến trúc có thể trả lời “chúng ta có được dùng thông tin của người này, qua điểm liên lạc này, cho mục đích này không?”, điều hữu ích hơn nhiều so với “đồng ý = có”. Bất kỳ bản ghi nào liên quan đến một cá nhân đều có thể tham gia: khách hàng tiềm năng, liên hệ, tài khoản cá nhân, người dùng.

Click to enlarge

Bốn câu hỏi, câu sau hẹp hơn câu trước. Một cờ đồng ý tham gia duy nhất không trả lời tốt câu nào cả.

Mục đích quan trọng

Một Đối tác bán lẻ gửi cho Steve Trucking số điện thoại của Người nhận để tổ giao hàng phối hợp lần giao. Điều đó không biến Người nhận thành một khách hàng tiềm năng marketing. Cùng một dữ liệu có thể có những mục đích sử dụng được phép khác nhau: phối hợp giao hàng, theo dõi sau dịch vụ, marketing, cá nhân hóa bằng AI. Nếu chính sách hay luật đối xử với chúng khác nhau, mô hình phải phân biệt được chúng. Câu hỏi không phải là chúng ta có số điện thoại không? Mà là chúng ta được phép làm gì với nó?

Và sự đồng ý không phải lúc nào cũng là cơ sở pháp lý. Một số mục đích sử dụng dựa trên những căn cứ khác mà luật quy định, và đó là quyết định của Pháp chế. Đừng xây một kiến trúc giả định mọi quyết định về quyền riêng tư đều là một ô đánh dấu đồng ý tham gia. Hãy hỗ trợ bất cứ điều gì chính sách nói: nếu một mục đích sử dụng phụ thuộc vào sự đồng ý, hãy mô hình hóa và thực thi sự đồng ý; nếu một căn cứ khác áp dụng, vẫn lưu những gì cần để quyết định việc sử dụng có được phép không.

Sự đồng ý có vòng đời và có thẩm quyền

Người ta đưa ra sự đồng ý, rút lại nó, thay đổi lựa chọn, đổi số điện thoại. Doanh nghiệp thêm mục đích mới; luật thay đổi. Vì vậy hãy thiết kế vòng đời: điều gì đã được chọn, khi nào, bằng cách nào, cho mục đích nào, và chuyện gì xảy ra khi rút lại. Và đây là chỗ thú vị: khi một Người nhận rút lại sự đồng ý, Salesforce biết. Nền tảng nhắn tin có biết không? Hệ thống phân tích? Tác tử? Sự đồng ý nằm trong một hệ thống trong khi các hệ thống khác hành động dựa trên sự cho phép đã cũ thì không phải là một biện pháp kiểm soát đáng kể.

Điều đó có nghĩa là phải hỏi hệ thống nào có thẩm quyền đối với sự đồng ý. Salesforce, một nền tảng quản lý lựa chọn, hay nơi khác? Dù câu trả lời là gì, đừng để năm hệ thống tự quyết định độc lập liệu cùng một người có đồng ý cho cùng một mục đích hay không. Sự đồng ý cần những gì mọi dữ liệu được quản trị cần: một chủ sở hữu, một bản ghi có thẩm quyền, một cách đồng bộ, và sự thực thi.

Giờ người đó nói: hãy quên tôi đi

Bản năng đầu tiên là xóa liên hệ rồi coi như xong. Nhưng dữ liệu của người đó có thể nằm trên một liên hệ, một lần giao hàng, một ghi chú giao hàng, một trường hợp, một bức ảnh, trong lịch sử trường, trong Snowflake, trong một kho lưu trữ, một nhật ký tích hợp, một chỉ mục tìm kiếm hay lịch sử hội thoại của tác tử. Đó là lý do lập trường của tôi về việc xóa bắt đầu sớm hơn: trên thực tế việc xóa hiếm và khó, nên hãy kiểm soát dữ liệu cá nhân đi đâu trước. Hãy thiết kế để nó rơi vào càng ít chỗ càng tốt. Rồi khi có yêu cầu, làm mờ hoặc gỡ liên kết nó ở nơi điều đó thỏa mãn chính sách, và truy lùng mọi bản sao: lịch sử trường, kho lưu trữ, Data 360, và giờ là cả chỉ mục tìm kiếm và các cuộc hội thoại của tác tử.

Đừng bắt đầu cuộc truy lùng khi yêu cầu đến. Lúc đó đã quá muộn để bắt đầu tìm hiểu bản đồ hệ thống. Từ điển, dòng dõi dữ liệu và phân loại của mô-đun 3 không phải là giấy tờ; chúng là thứ làm cho điều này khả thi. Bạn đã biết những trường nào chứa dữ liệu cá nhân và các bản sao đã đi đâu.

Click to enlarge

Một yêu cầu “hãy quên tôi” là một quyết định cho từng bản sao.

Đồng hồ đang chạy

Những yêu cầu này đi kèm thời hạn. Theo GDPR, tổ chức phải xử lý yêu cầu của một người mà không chậm trễ quá mức và trong vòng một tháng kể từ khi nhận được; với các yêu cầu phức tạp hoặc nhiều, thời hạn có thể được gia hạn thêm hai tháng, nhưng người đó phải được thông báo trong tháng đầu tiên, kèm lý do (Điều 12(3), Regulation (EU) 2016/679 (opens in a new tab), tiếng Anh). Các luật khác đặt thời hạn riêng; Pháp chế sẽ cho bạn biết luật nào áp dụng. Dù thế nào, một tháng không đủ dài để khám phá bản đồ hệ thống. Đó là thời hạn mà bản đồ các bản sao phải về đích trước.

Xóa, khử định danh hay giữ lại?

Một yêu cầu không nhất thiết có nghĩa là mọi thứ ở mọi nơi đều biến mất. Một số bản ghi phải hoặc được phép giữ lại; một số bản ghi vận hành có thể ở lại nhưng không còn định danh người đó; một số dữ liệu có thể được khử định danh. Chính sách và luật áp dụng quyết định; kiến trúc hỗ trợ từng kết quả, theo từng vị trí: xóa nó, khử định danh nó, hoặc giữ nó theo một yêu cầu đã được phê duyệt (và khi đó ai được thấy nó, trong bao lâu, vì sao?).

Hãy nhớ sự phân biệt của mô-đun 4. Gỡ liên kết chỉ được coi là lãng quên khi người đó không thể được nhận diện lại một cách hợp lý. Dữ liệu giả danh hóa vẫn là dữ liệu cá nhân. Đừng dùng việc làm mờ dữ liệu như một lối tắt để lách một yêu cầu pháp lý.

Bạn không thể xóa thứ bạn không tìm thấy

Trước khi xóa được ai đó, bạn phải tìm ra họ. Yêu cầu đến từ một địa chỉ email. Một Đối tác bán lẻ gửi “Jane Smith”, đối tác khác gửi “J. Smith”, và số điện thoại đã thay đổi. Người nhận hoàn toàn không phải là một liên hệ; thông tin của họ nằm trên từng lần giao hàng. Cùng một người nhận hàng cho hai đối tác khác nhau. Một hệ thống biết họ qua email, hệ thống khác qua một ID bên ngoài. Việc xóa phụ thuộc vào danh tính, và bạn không muốn xóa dữ liệu của người khác vì việc so khớp của bạn quá mạnh tay. Kiến trúc danh tính là một phần của kiến trúc quyền riêng tư.

Steve Trucking còn làm nó khó hơn. Một Đối tác bán lẻ không bao giờ được thấy các lần giao hàng hay Người nhận của đối tác khác. Nếu cùng một người nhận hàng cho hai đối tác, vận hành phải giữ những quan hệ đó tách biệt, trong khi quyền riêng tư vẫn có thể cần tìm người đó trên cả hai. Đừng giải quyết quyền riêng tư bằng cách phá vỡ ranh giới bảo mật, và đừng bảo vệ ranh giới bằng cách làm cho yêu cầu quyền riêng tư trở nên bất khả thi. Kiến trúc phải làm được cả hai.

Ảnh và văn bản tự do cũng là dữ liệu

Rất dễ nghĩ về quyền riêng tư như các trường: tên, email, điện thoại, địa chỉ. Nhưng Steve Trucking chụp hàng triệu ảnh giao hàng mỗi năm, và một số cho thấy con người hay bên trong một ngôi nhà. Một chính sách lưu giữ hay xóa chỉ nhìn vào các trường có cấu trúc là chưa đầy đủ; một chính sách bỏ qua tệp, tài liệu, bản ghi lời thoại, nhật ký, và lời nhắc cùng câu trả lời của AI cũng vậy.

Và văn bản tự do thì nguy hiểm. Bạn xóa tên, số điện thoại và địa chỉ, rồi tìm thấy ghi chú giao hàng này: “Gọi Jane theo số 602-555-0198. Mã cổng 4821. Có chó trong sân.” Nó đây rồi. Phân loại ghi chú giao hàng là nhạy cảm cho bạn biết có thể có vấn đề; nó không tìm và xóa dữ liệu cá nhân bên trong văn bản. Đôi khi câu trả lời tốt nhất là ngăn những chi tiết cá nhân không cần thiết rơi vào đó ngay từ đầu. Hãy kiểm soát dữ liệu cá nhân đi đâu trước.

Privacy Center là một công cụ, không phải toàn bộ kiến trúc

Privacy Center của Salesforce giúp vận hành các quy trình này. Các chính sách quyền được lãng quên của nó được xây theo từng đối tượng, để bao quát mọi thứ bạn muốn xóa, và chạy trên một bản ghi khách hàng cụ thể (Delete Data with Right to Be Forgotten Policies (opens in a new tab), tiếng Anh). Điều đó hữu ích. Nhưng “chúng tôi đã mua Privacy Center, nên xong rồi” không phải là một kiến trúc. Dữ liệu của người đó có thể nằm ngoài tầm với của bất kỳ công cụ nào: Data 360, kho dữ liệu, hệ thống đối tác, kho lưu trữ, nhật ký, tìm kiếm, tệp, các cuộc hội thoại của tác tử. Doanh nghiệp vẫn cần một câu trả lời ở cấp doanh nghiệp, và bạn cần kiểm tra mỗi công cụ thực sự bao quát những gì trước khi dựa vào nó.

Chuyển dữ liệu và chứng minh

Một số luật còn cho người ta quyền nhận một bản sao dữ liệu của mình. Để ý rằng đó là cùng một bài toán khám phá: việc xóa hỏi dữ liệu của người này ở đâu, để chúng ta hành động với nó? Việc chuyển dữ liệu hỏi nó ở đâu, để chúng ta cung cấp nó? Cả hai đều dựa trên danh tính, phân loại, dòng dõi dữ liệu, bản kiểm kê hệ thống và quyền sở hữu.

Và rồi: làm sao bạn chứng minh mình đã làm? Đã nhận yêu cầu, đã xác minh danh tính, đã tìm kiếm các hệ thống, đã thực hiện hành động, đã ghi nhận ngoại lệ, đã biện minh cho dữ liệu được giữ lại, đã ghi nhật ký hoàn tất. Có một sự căng thẳng thực sự ở đây: bạn đang xóa dữ liệu cá nhân của ai đó trong khi giữ đủ bằng chứng để cho thấy bạn đã xử lý yêu cầu đúng cách. Đó chính là lý do kiến trúc sư không nên tự bịa ra quy tắc lưu giữ. Pháp chế và tuân thủ quyết định bằng chứng nào phải được giữ lại; kiến trúc giữ nó mà không giữ dữ liệu lẽ ra phải bị xóa.

Ngoài kỳ thi: AI thay đổi điều gì. AI tạo ra những mục đích mới và những bản sao mới. Sự cho phép dùng dữ liệu để cung cấp một dịch vụ không tự động bao gồm việc neo dữ liệu cho tác tử, cá nhân hóa hay huấn luyện; Data Use Purpose là nơi tự nhiên để phân biệt chúng. Và dữ liệu cá nhân có thể tồn tại trong lời nhắc, ngữ cảnh neo dữ liệu, các cuộc hội thoại, bản tóm tắt, chỉ mục tìm kiếm và chỉ mục vector, và nhật ký. “Chúng tôi đã xóa bản ghi nguồn” không phải là câu trả lời đầy đủ nếu tầng AI vẫn còn nhớ.

Kiến trúc sư quyết định gì ở đây

• Sự đồng ý và mục đích sử dụng được phép được mô hình hóa thế nào, để các hệ thống trả lời được ai, kênh nào, điểm liên lạc nào và mục đích gì.
• Hệ thống nào có thẩm quyền đối với sự đồng ý, và việc rút lại đến được mọi hệ thống hành động dựa trên nó bằng cách nào.
• Dữ liệu cá nhân có thể lan đến đâu: các trường, văn bản tự do, tệp, lịch sử, phân tích, kho lưu trữ, tích hợp, tìm kiếm và AI.
• Một yêu cầu tìm đúng người thế nào và điều khiển việc xóa, khử định danh hay giữ lại có phê duyệt ở từng vị trí.
• Bằng chứng nào còn lại để chứng minh sự đồng ý và các yêu cầu quyền riêng tư đã được xử lý.

Sự đồng ý và việc xóa trông như hai thái cực (chúng ta có được dùng dữ liệu này không? chúng ta có dừng và xóa nó được không?) nhưng chúng dựa trên cùng những nền móng: danh tính, mục đích, phân loại, dòng dõi dữ liệu, quyền sở hữu, sự thực thi và bằng chứng. Hãy dùng mô hình đồng ý chuẩn, kiểm soát dữ liệu cá nhân đi đâu, biết các bản sao ở đâu, và thiết kế quy trình xóa trước khi yêu cầu đầu tiên đến. Khi ai đó hỏi “bạn có thể quên tôi không?”, kiến trúc cần một câu trả lời tốt hơn “chúng tôi nghĩ là có”.

Tìm hiểu thêm

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), Điều 12(3), thời hạn xử lý một yêu cầu, kiểm tra ngày 2026-10-14.
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, tiếng Anh), kiểm tra ngày 2026-10-14.