P9.6 — Responsible Product với privacy, security, accessibility, compliance và ethics

Module: P9 - Senior Product Practice
Mục tiêu đọc: Thiết kế Responsible Product (sản phẩm có trách nhiệm) như hệ thống quyết định xuyên vòng đời. Nhận diện tác hại. Phân tầng rủi ro. Chuyển rủi ro thành kiểm soát, bằng chứng, quyền phê duyệt, giám sát và cơ chế dừng.

Ranh giới năng lực: Đọc chương giúp người học hiểu khái niệm, quyết định và artifact. Đọc không thay thế kinh nghiệm triển khai, kiểm thử, xử lý sự cố, làm việc với chuyên gia hoặc chịu trách nhiệm pháp lý và vận hành thực tế.

Nguồn nền: NIST Privacy Framework; NIST Cybersecurity Framework 2.0; NIST AI Risk Management Framework; W3C Web Content Accessibility Guidelines 2.2; OWASP Application Security Verification Standard.

Mental model

Responsible Product (sản phẩm có trách nhiệm) không phải checklist cuối dự án. Nó là Decision System (hệ thống quyết định), nối giá trị sản phẩm với tác động lên con người, tài sản, tổ chức và xã hội.

Hệ thống này buộc đội trả lời trước, trong và sau phát hành:

1. Sản phẩm tạo giá trị cho ai?
2. Ai chịu tác hại, gồm người không trực tiếp dùng?
3. Dữ liệu, quyền, tiền, dịch vụ và uy tín nào là Asset (tài sản cần bảo vệ)?
4. Điều gì có thể sai do lỗi, tấn công, lạm dụng, thiết kế kém hoặc động cơ kinh doanh?
5. Control (biện pháp kiểm soát) nào giảm khả năng, tác động hoặc thời gian tồn tại của tác hại?
6. Residual Risk (rủi ro còn lại) là gì sau kiểm soát?
7. Ai có quyền chấp nhận, chặn, leo thang hoặc dừng?
8. Bằng chứng nào chứng minh kiểm soát hoạt động?
9. Tín hiệu nào buộc mở lại quyết định?

Chuỗi vận hành:

Bối cảnh → tác hại → tầng rủi ro → yêu cầu → kiểm soát → bằng chứng → phê duyệt → giám sát → ứng phó

Năm miền liên kết nhưng không thay thế nhau:

Miền	Câu hỏi cốt lõi
Privacy (quyền riêng tư)	Con người có bị quan sát, suy luận, phân loại, mất kiểm soát dữ liệu hoặc chịu tác hại từ xử lý dữ liệu không?
Security (an ninh)	Tài khoản, dữ liệu, quyền, dịch vụ có bị truy cập, sửa đổi, phá hoại hoặc lạm dụng không?
Accessibility (khả năng tiếp cận)	Người khuyết tật có hoàn thành tác vụ bằng phương thức và công nghệ hỗ trợ phù hợp không?
Compliance (sự tuân thủ)	Nghĩa vụ áp dụng có được đáp ứng và chứng minh được không?
Ethics (đạo đức)	Sản phẩm có thao túng, phân phối tác hại bất công, tước quyền phản đối hoặc khai thác người dễ tổn thương không?

Một biện pháp có thể cải thiện miền này nhưng làm xấu miền khác. Xác thực nhiều bước có thể giảm chiếm tài khoản nhưng tạo rào cản cho người dùng công nghệ hỗ trợ. Cá nhân hóa có thể tăng giá trị nhưng tăng giám sát và phân biệt đối xử. Đồng ý của người dùng không biến thu thập quá mức thành chấp nhận được.

Decision rule (quy tắc quyết định): Tăng mức kiểm soát, bằng chứng và thẩm quyền theo:

• Mức tác hại.
• Độ khó đảo ngược.
• Quy mô phơi nhiễm.
• Độ nhạy dữ liệu.
• Mức yếu thế của người bị tác động.
• Khả năng lạm dụng.
• Khả năng phát hiện và phục hồi.

Không tăng nghi thức chỉ vì tính năng lớn. Tăng governance vì hậu quả lớn.

Core

1. Responsible Product xuyên vòng đời

Rà soát cuối dự án thất bại vì giải pháp, dữ liệu, kiến trúc và cam kết thương mại đã khóa. Legal, Security, Accessibility hoặc Compliance bị biến thành cổng chặn cuối. Áp lực ngày phát hành làm giảm tiêu chuẩn và đẩy rủi ro sang người dùng.

Giai đoạn	Quyết định cần làm
Strategy (chiến lược)	Giá trị nào được theo đuổi? Tác hại nào là red line, không đánh đổi?
Discovery (khám phá)	Ai bị tác động? Có người dễ tổn thương không? Dữ liệu nào thật sự cần?
Design (thiết kế)	Mặc định, lựa chọn, thông báo, phản đối, hỗ trợ và phục hồi hoạt động ra sao?
Build (xây dựng)	Rủi ro nào thành yêu cầu kỹ thuật, tiêu chí chấp nhận và kiểm soát?
Validation (xác thực)	Kiểm thử chức năng, lạm dụng, bảo mật, khả năng tiếp cận và hiệu lực kiểm soát ra sao?
Go-live (đưa vào vận hành)	Bằng chứng nào đủ? Ai phê duyệt? Ai nhận rủi ro còn lại?
Operate (vận hành)	Theo dõi tác hại, khiếu nại, sự cố, chênh lệch kết quả và suy giảm kiểm soát ra sao?
Retire (ngừng vận hành)	Dữ liệu, quyền truy cập, nhà cung cấp, hồ sơ và nghĩa vụ còn lại xử lý ra sao?

Responsible Product Brief

Responsible Product Brief (bản tóm tắt sản phẩm có trách nhiệm) mở đầu mọi thay đổi có rủi ro. Artifact này định khung câu hỏi và người cần tham gia. Nó không thay đánh giá của Legal, Security, Data hoặc Accessibility specialist.

Trường	Nội dung cần có
Decision	Thay đổi, tính năng hoặc quyết định cần xem xét
Intended value	Giá trị dự kiến và nhóm nhận giá trị
Affected people	Người dùng, người không dùng nhưng bị tác động, nhân viên, đối tác
Vulnerable users	Người dễ chịu tác hại hơn hoặc khó tự bảo vệ hơn
Data scope	Dữ liệu thu, tạo, suy luận, chia sẻ, lưu và xóa
Assets	Tài khoản, tiền, dữ liệu, quyền, dịch vụ và uy tín cần bảo vệ
Harm scenarios	Kịch bản tác hại cụ thể và cơ chế gây hại
Abuse cases	Cách chức năng hợp lệ bị dùng để gây hại
Accessibility scope	Tác vụ cốt lõi, nền tảng và công nghệ hỗ trợ
Jurisdictions	Khu vực tài phán và thị trường liên quan
Ethical concerns	Thao túng, bất công, thiếu giải thích và thiếu phản đối
Risk tier	Tầng rủi ro tạm thời và lý do
Accountable owner	Người chịu trách nhiệm giải trình
Required reviewers	Chuyên gia bắt buộc tham gia
Kill switch	Cách giới hạn, tắt hoặc thu hồi
Review trigger	Điều kiện mở lại quyết định

Quality criteria (tiêu chí chất lượng):

• Nêu người chịu tác động gián tiếp.
• Phân biệt dữ liệu người dùng cung cấp với dữ liệu hệ thống suy luận.
• Mô tả tác hại và cơ chế gây hại, không chỉ ghi nhãn “privacy risk”.
• Ghi điều chưa biết.
• Ghi owner cụ thể, không ghi tên đội chung.
• Có điều kiện đánh giá lại.
• Không ghi “đã hỏi Legal” thay cho bằng chứng.

Anti-pattern (mẫu sai): Brief ghi “low risk” nhưng không có luồng dữ liệu, nhóm chịu tác động, kịch bản lạm dụng hoặc người nhận Residual Risk.

2. Privacy by Design — giảm dữ liệu trước khi bảo vệ dữ liệu

Privacy by Design (quyền riêng tư từ thiết kế) đặt quyền kiểm soát và tác hại với con người vào thiết kế sản phẩm, kiến trúc, mặc định, vận hành và vòng đời dữ liệu. Nó không chỉ là mã hóa, banner cookie hoặc chính sách quyền riêng tư.

NIST Privacy Framework hỗ trợ quản trị Privacy Risk (rủi ro quyền riêng tư) như rủi ro tổ chức. Framework không xác định luật áp dụng hoặc cơ sở xử lý. Legal và Privacy specialist xác nhận phần đó.

2.1 Data minimization

Data Minimization (tối thiểu hóa dữ liệu) nghĩa là chỉ xử lý dữ liệu cần cho mục đích đã xác định. “Có thể hữu ích sau này” không đủ làm lý do thu thập.

Bốn câu hỏi:

1. Có tạo giá trị cốt lõi mà không thu dữ liệu này không?
2. Có dùng dữ liệu ít chi tiết hơn không?
3. Có thể xử lý cục bộ, tạm thời hoặc tổng hợp thay vì lưu tập trung không?
4. Có thể xóa sớm hơn hoặc không tạo dữ liệu suy luận không?

Phạm vi gồm dữ liệu nhập trực tiếp, Event Log (nhật ký sự kiện), truy vấn tìm kiếm, định danh thiết bị, hồ sơ hành vi, dữ liệu suy luận, bản ghi hỗ trợ, dữ liệu huấn luyện, bản sao lưu và dữ liệu từ nhà cung cấp.

Decision rule: Nếu bỏ trường dữ liệu mà sản phẩm vẫn tạo giá trị cốt lõi và đáp ứng nghĩa vụ xác nhận, mặc định không thu trường đó.

2.2 Purpose limitation

Purpose Limitation (giới hạn mục đích) nghĩa là dùng dữ liệu cho mục đích cụ thể, rõ ràng và phù hợp kỳ vọng hợp lý của người bị tác động cùng nghĩa vụ áp dụng.

Function Creep (trượt mục đích) xảy ra khi dữ liệu thu cho chức năng A dần được dùng cho quảng cáo, chấm điểm, huấn luyện mô hình hoặc chia sẻ đối tác mà không có đánh giá mới.

Mục đích mới phải trả lời:

• Có tương thích với mục đích cũ không?
• Người bị tác động có dự đoán hợp lý việc dùng này không?
• Tác hại mới nào xuất hiện?
• Có cần thông báo, lựa chọn hoặc cơ sở xử lý khác không?
• Quyền truy cập và thời hạn lưu có thay đổi không?
• Risk Tier có tăng không?

“Cải thiện dịch vụ” quá rộng. Cụm này che mất quyết định thật.

2.3 Consent

Consent (sự đồng ý) là cơ chế lựa chọn. Nó không là giấy miễn trừ cho thu thập quá mức hoặc thiết kế gây hại.

Consent có ý nghĩa khi:

• Mục đích đủ cụ thể.
• Thông tin dễ hiểu.
• Lựa chọn không bị ép.
• Hành động đồng ý rõ.
• Rút lại được theo cách phù hợp.
• Từ chối không khó hơn chấp nhận.
• Lựa chọn không bị gộp vô lý với dịch vụ cốt lõi.

Consent yếu khi người dùng lệ thuộc dịch vụ, không hiểu hậu quả hoặc bị đẩy bằng Dark Pattern (mẫu thiết kế thao túng).

Decision rule: Giảm dữ liệu trước. Chỉ xin Consent khi người dùng có lựa chọn thật và lựa chọn đó thay đổi cách sản phẩm xử lý dữ liệu.

2.4 Retention

Retention (thời hạn lưu giữ) phải gắn với mục đích, nhu cầu vận hành, nghĩa vụ áp dụng và khả năng xóa thật.

Retention Schedule (lịch lưu giữ) cần ghi:

• Loại dữ liệu.
• Mục đích.
• Nơi lưu.
• Owner.
• Thời hạn hoặc sự kiện kích hoạt xóa.
• Ngoại lệ giữ lại.
• Cách xử lý cache, bản sao và backup.
• Cách chứng minh xóa hoặc ẩn danh.

“Lưu vô thời hạn vì lưu trữ rẻ” là red flag. Lưu lâu tăng bề mặt sự cố, chi phí thực hiện quyền và nguy cơ Function Creep.

2.5 Data subject risk

Data Subject (chủ thể dữ liệu) là người mà dữ liệu liên quan. Data Subject Risk (rủi ro với chủ thể dữ liệu) không chỉ là lộ dữ liệu.

Tác hại có thể gồm:

• Mất quyền tự chủ.
• Bị theo dõi hoặc suy luận ngoài kỳ vọng.
• Phân biệt đối xử.
• Thiệt hại tài chính, danh tiếng, thể chất hoặc tâm lý.
• Bị loại khỏi dịch vụ hoặc cơ hội.
• Không sửa được dữ liệu sai.
• Không biết, không hiểu hoặc không phản đối được quyết định.

Đánh giá cần xem khả năng xảy ra, mức tác động, quy mô phơi nhiễm và khả năng phục hồi. Không biến đánh giá thành điểm số giả chính xác.

Privacy artifacts

Data Inventory (danh mục dữ liệu) và Data Flow Map (bản đồ luồng dữ liệu) phải cho thấy:

• Nguồn dữ liệu.
• Loại dữ liệu.
• Mục đích.
• Biến đổi và suy luận.
• Nơi lưu.
• Hệ thống, người và nhà cung cấp truy cập.
• Bên nhận dữ liệu.
• Thời hạn lưu và cơ chế xóa.
• Luồng xuyên biên giới nếu có.
• Kiểm soát liên quan.

Quality check: Chọn một hồ sơ người dùng. Truy vết dữ liệu từ lúc thu đến xóa, gồm hệ thống phụ và nhà cung cấp. Không truy vết được nghĩa là chưa kiểm soát được.

3. Security — từ tài sản tới khả năng ứng phó

NIST Cybersecurity Framework 2.0 dùng sáu chức năng:

• Govern (quản trị): Vai trò, chính sách và quản trị rủi ro.
• Identify (nhận diện): Tài sản, phụ thuộc, bối cảnh và rủi ro.
• Protect (bảo vệ): Biện pháp giảm truy cập và thay đổi trái phép.
• Detect (phát hiện): Nhận ra sự kiện bất thường.
• Respond (ứng phó): Cô lập, xử lý và giao tiếp khi xảy ra sự cố.
• Recover (khôi phục): Khôi phục dịch vụ, dữ liệu và niềm tin vận hành.

OWASP Application Security Verification Standard hỗ trợ chọn yêu cầu kiểm chứng an ninh ứng dụng. Security và Engineering xác định phạm vi, mức áp dụng và bằng chứng. PM không tự tuyên bố sản phẩm “ASVS compliant”.

3.1 Threat, asset và attack surface

• Threat (mối đe dọa): Tác nhân hoặc hoàn cảnh có thể gây hại.
• Asset (tài sản cần bảo vệ): Dữ liệu, tài khoản, tiền, khóa bí mật, quyền, dịch vụ và uy tín.
• Attack Surface (bề mặt tấn công): Điểm tác nhân có thể tương tác hoặc khai thác.

Attack Surface gồm giao diện, API, đăng nhập, phục hồi tài khoản, tích hợp, tải tệp, quản trị, hạ tầng, hỗ trợ khách hàng, nhà cung cấp và nhân viên có quyền.

Thêm tính năng thường thêm Attack Surface. Không phải mọi bề mặt phải bị loại bỏ. Đội phải nhận diện, giới hạn và kiểm soát nó.

3.2 Abuse case

Abuse Case (kịch bản lạm dụng) mô tả cách chức năng hợp lệ bị dùng để gây hại. Nó khác lỗi kỹ thuật.

Mẫu:

Tác nhân [ai] dùng khả năng [gì] để đạt mục tiêu gây hại [gì], tác động đến [ai hoặc tài sản nào], trong điều kiện [gì].

Ví dụ:

• Luồng mời thành viên bị dùng để quấy rối.
• Xuất dữ liệu hợp lệ bị dùng để thu thập hàng loạt.
• Phục hồi tài khoản bị dùng để chiếm quyền.
• Tìm kiếm bị dùng để định vị người dễ tổn thương.
• Hệ thống báo cáo bị dùng để bịt tiếng người khác.

Tính năng liên quan danh tính, quyền, tiền, dữ liệu nhạy cảm, truyền thông hoặc nội dung cần phân tích Abuse Case trước Build.

3.3 Control và residual risk

Control giảm khả năng xảy ra, mức tác động hoặc thời gian tồn tại của tác hại.

Loại kiểm soát	Mục đích	Ví dụ
Preventive Control (biện pháp phòng ngừa)	Chặn trước	Kiểm soát quyền truy cập
Detective Control (biện pháp phát hiện)	Phát hiện sai lệch	Cảnh báo truy cập bất thường
Responsive Control (biện pháp ứng phó)	Giới hạn tác hại	Khóa phiên, thu hồi token
Recovery Control (biện pháp khôi phục)	Khôi phục sau sự cố	Khôi phục dịch vụ, xác minh toàn vẹn

Không có Control hoàn hảo. Sau kiểm soát vẫn có Residual Risk.

Trạng thái	Hành động
Rủi ro trong ngưỡng đã duyệt	Owner theo dõi
Cần giảm thêm	Sửa thiết kế hoặc thêm kiểm soát
Vượt thẩm quyền owner	Escalation
Không thể giảm về mức chấp nhận	Không phát hành, giới hạn phạm vi hoặc dừng

PM không tự nhận Residual Risk thay Security authority hoặc system owner.

3.4 Incident readiness

Incident Readiness (mức sẵn sàng ứng phó sự cố) phải tồn tại trước sự cố.

Nó gồm:

• Tín hiệu phát hiện.
• Phân loại mức nghiêm trọng.
• Kênh báo động.
• Owner trực.
• Incident authority.
• Quyền cô lập hoặc tắt.
• Runbook.
• Bảo toàn bằng chứng.
• Kế hoạch giao tiếp.
• Khôi phục và xác nhận an toàn.
• Rà soát sau sự cố.
• Cập nhật kiểm soát.

Kill Switch (cơ chế tắt) phải được kiểm thử. Nút tắt không ai có quyền dùng, không biết tác động phụ hoặc mất nhiều giờ kích hoạt không phải Control tin cậy.

4. Accessibility — khả năng hoàn thành tác vụ cho nhiều cách tương tác

Accessibility (khả năng tiếp cận) bảo đảm người khuyết tật có thể dùng sản phẩm và hoàn thành tác vụ. Nó không chỉ là “dễ dùng”, không chỉ là bàn phím và không chỉ là công cụ quét lỗi.

W3C Web Content Accessibility Guidelines 2.2 tổ chức yêu cầu theo POUR (Perceivable, Operable, Understandable, Robust — có thể nhận biết, vận hành, hiểu và tương thích bền vững).

4.1 Perceivable

Perceivable (có thể nhận biết) nghĩa là thông tin và thành phần giao diện được trình bày theo cách người dùng có thể nhận biết.

Kiểm tra:

• Nội dung phi văn bản có phương án tương đương phù hợp.
• Không chỉ dùng màu để truyền thông tin.
• Cấu trúc nội dung được công nghệ hỗ trợ nhận biết.
• Âm thanh và video có phương án hỗ trợ khi tiêu chí áp dụng.
• Tương phản, phóng to và reflow được kiểm tra theo tiêu chí WCAG 2.2 áp dụng.

4.2 Operable

Operable (có thể vận hành) nghĩa là người dùng thao tác được bằng phương thức phù hợp.

Kiểm tra:

• Tác vụ dùng được bằng bàn phím.
• Focus (điểm tập trung tương tác) rõ, không bị kẹt và đi theo thứ tự hợp lý.
• Không tạo giới hạn thời gian không cần thiết.
• Cử chỉ kéo, thao tác phức tạp và xác thực có cách thay thế phù hợp.
• Không tạo nội dung có nguy cơ phản ứng thể chất theo tiêu chí áp dụng.

4.3 Understandable

Understandable (có thể hiểu) nghĩa là nội dung và hành vi giao diện rõ, nhất quán và có thể dự đoán.

Kiểm tra:

• Nhãn và hướng dẫn rõ.
• Lỗi có mô tả bằng nội dung, không chỉ bằng màu.
• Người dùng biết cách sửa lỗi.
• Điều hướng và thành phần nhất quán.
• Hành động quan trọng không gây thay đổi bất ngờ.
• Trợ giúp nằm ở vị trí nhất quán khi tiêu chí áp dụng.

4.4 Robust

Robust (tương thích bền vững) nghĩa là nội dung hoạt động với nhiều trình duyệt, thiết bị và Assistive Technology (công nghệ hỗ trợ).

Assistive Technology có thể gồm screen reader, phóng đại màn hình, điều khiển giọng nói, thiết bị công tắc, màn hình chữ nổi và thiết lập hỗ trợ của hệ điều hành.

Dùng HTML native và thành phần nền tảng đúng ngữ nghĩa thường tốt hơn tự tạo widget phức tạp. ARIA không sửa được cấu trúc HTML sai. Automation chỉ phát hiện một phần lỗi.

4.5 Inclusive design

Inclusive Design (thiết kế bao trùm) xem khác biệt về khả năng, ngôn ngữ, thiết bị, môi trường và tải nhận thức là đầu vào thiết kế.

Nó gồm người:

• Hạn chế vận động tạm thời.
• Dùng thiết bị cũ hoặc băng thông thấp.
• Ở môi trường ồn.
• Dùng ngôn ngữ thứ hai.
• Có kiến thức số thấp.
• Chịu áp lực hoặc tải nhận thức cao.

Inclusive Design rộng hơn WCAG 2.2. WCAG 2.2 cung cấp tiêu chí kiểm tra được cho nội dung web. Hai phần cần cùng tồn tại.

Accessibility Acceptance

Accessibility Acceptance (tiêu chí chấp nhận khả năng tiếp cận) phải nằm trong backlog, thiết kế và kiểm thử.

Trường	Nội dung
User task	Tác vụ cần hoàn thành
Applicable criteria	Tiêu chí WCAG 2.2 áp dụng
Keyboard behavior	Thứ tự, focus, kích hoạt và thoát
Screen reader behavior	Tên, vai trò, trạng thái và thông báo
Visual behavior	Tương phản, phóng to, reflow và trạng thái
Error behavior	Nhận diện, mô tả và sửa lỗi
Alternative interaction	Cách thay thế cho kéo, cử chỉ hoặc nhập phức tạp
Test environments	Trình duyệt, OS và công nghệ hỗ trợ đã chọn
Evidence	Kết quả tự động, thủ công và lỗi mở
Owner	Người sửa và người xác nhận

Decision rule: Luồng cốt lõi thất bại với bàn phím hoặc công nghệ hỗ trợ trong phạm vi hỗ trợ là lỗi chức năng. Không xem là lỗi thẩm mỹ.

Anti-pattern:

• Chỉ chạy công cụ tự động.
• Dùng ARIA để vá HTML sai.
• Chờ người khuyết tật báo lỗi sau phát hành.
• Tuyên bố “accessible” cho toàn sản phẩm từ một màn hình.
• Dùng overlay thay sửa cấu trúc sản phẩm.
• Loại người khuyết tật khỏi nghiên cứu vì tuyển khó.

5. Compliance — nối nghĩa vụ với kiểm soát và bằng chứng

Compliance (sự tuân thủ) là trạng thái đáp ứng yêu cầu áp dụng. Compliance không đồng nghĩa an toàn, công bằng hoặc có đạo đức. Sản phẩm có thể đạt mức tuân thủ tối thiểu nhưng vẫn gây hại.

5.1 Requirement, policy và jurisdiction

• Regulatory Requirement: Nghĩa vụ từ luật, quy định hoặc cơ quan có thẩm quyền.
• Policy: Quy tắc nội bộ tổ chức cam kết tuân theo.
• Contractual Requirement: Nghĩa vụ từ hợp đồng.
• Standard Requirement: Yêu cầu từ tiêu chuẩn tổ chức chọn hoặc buộc áp dụng.
• Jurisdiction: Phạm vi pháp lý có thẩm quyền dựa trên thị trường, tổ chức, người dùng, hoạt động hoặc dữ liệu.

PM không tự xác định luật áp dụng. Legal hoặc Compliance xác nhận Jurisdiction, nghĩa vụ, ngoại lệ, diễn giải và yêu cầu bằng chứng.

Mỗi requirement cần có:

• Nguồn.
• Phạm vi áp dụng.
• Nghĩa vụ cụ thể.
• Owner.
• Ngày hiệu lực nếu có.
• Sản phẩm hoặc quy trình bị tác động.
• Control đáp ứng.
• Evidence chứng minh.
• Cơ chế theo dõi thay đổi.

5.2 Compliance evidence

Compliance Evidence (bằng chứng tuân thủ) chứng minh Control được thiết kế và vận hành. Policy đơn lẻ không đủ.

Ví dụ Evidence:

• Hồ sơ phê duyệt.
• Cấu hình hệ thống.
• Kết quả kiểm thử.
• Nhật ký truy cập.
• Bằng chứng xóa.
• Biên bản rà soát.
• Hồ sơ ngoại lệ.
• Báo cáo giám sát.
• Bằng chứng đào tạo khi phù hợp.

Ảnh chụp màn hình đơn lẻ thường yếu vì thiếu phiên bản, phạm vi, người thực hiện và thời điểm.

5.3 Audit trail

Audit Trail (dấu vết kiểm toán) cho phép tái dựng hành động quan trọng:

• Ai hoặc hệ thống nào hành động.
• Làm gì.
• Khi nào.
• Trên đối tượng nào.
• Kết quả gì.
• Theo yêu cầu nào.
• Giá trị trước và sau nếu phù hợp.

Audit Trail phải được bảo vệ khỏi sửa trái phép, giới hạn truy cập và lưu theo chính sách. Logging vô hạn tạo Privacy Risk mới. Chỉ ghi dữ liệu cần cho mục đích vận hành, an ninh hoặc nghĩa vụ đã xác định.

5.4 Control Map

Control Map (bản đồ kiểm soát) nối rủi ro hoặc nghĩa vụ với Control, owner, Evidence và trạng thái.

ID	Requirement hoặc risk	Control	Owner	Evidence	Tiêu chí đạt	Residual risk	Status
C-01	Nghĩa vụ hoặc kịch bản cụ thể	Cách giảm rủi ro	Vai trò cụ thể	Hồ sơ xác minh	Điều kiện pass/fail	Điều còn lại	Mở/đạt/ngoại lệ

Quality criteria:

• Mỗi requirement áp dụng có Control hoặc lý do không áp dụng.
• Mỗi Control có owner cụ thể.
• Mỗi Control có Evidence kiểm chứng được.
• Mỗi test có điều kiện pass/fail.
• Ngoại lệ có người chấp nhận, hạn hết hiệu lực và kế hoạch xử lý.
• Thay đổi phạm vi, nhà cung cấp, mục đích hoặc thị trường kích hoạt đánh giá lại.

Anti-pattern: Compliance Theater (sân khấu tuân thủ) có nhiều policy nhưng ít bằng chứng vận hành. Owner ghi “Engineering”. Ngoại lệ không hết hạn. Audit Trail không truy xuất được.

6. Ethics — hỏi có nên làm

Ethical Risk (rủi ro đạo đức) xuất hiện khi sản phẩm làm giảm quyền tự chủ, khai thác điểm yếu, phân phối tác hại bất công hoặc tạo quyết định không thể phản đối. Tuân thủ là sàn, không phải toàn bộ ranh giới.

6.1 Dark pattern

Dark Pattern dùng thiết kế để đẩy người dùng làm điều trái lợi ích hoặc ý định của họ.

Dấu hiệu:

• Chấp nhận dễ, từ chối khó.
• Chi phí thật bị che tới bước cuối.
• Khan hiếm hoặc khẩn cấp sai.
• Mặc định có lợi doanh nghiệp nhưng gây bất ngờ.
• Ngôn ngữ làm nhục khi từ chối.
• Hủy, rút lại hoặc xóa khó hơn đăng ký.
• Quảng cáo hoặc tài trợ bị làm mờ.
• Thông báo lặp để bào mòn từ chối.

Decision rule: Nếu luồng chỉ đạt KPI khi người dùng hiểu sai, quên, mệt hoặc không tìm được đường từ chối, không dùng luồng đó.

6.2 Vulnerable user

Vulnerable User (người dùng dễ tổn thương) là người có khả năng chịu tác hại lớn hơn hoặc ít khả năng nhận biết, tránh, phản đối và phục hồi. Đây là trạng thái theo bối cảnh, không phải nhãn cố định.

Yếu tố có thể gồm tuổi, khuyết tật, khó khăn tài chính, sức khỏe, lệ thuộc dịch vụ, bạo lực hoặc cưỡng ép, kiến thức số thấp, rào cản ngôn ngữ, chênh lệch quyền lực và tình trạng khẩn cấp.

Thiết kế cho Vulnerable User cần giảm áp lực, tăng rõ ràng, tăng khả năng phục hồi, có hỗ trợ con người khi cần và tránh dùng dữ liệu dễ gây hại ngoài mục đích.

6.3 Fairness

Fairness (tính công bằng) không có một định nghĩa duy nhất. Nó có thể liên quan cơ hội tiếp cận, chất lượng dịch vụ, tỷ lệ lỗi, phân phối lợi ích, phân phối tác hại, quy trình quyết định và khả năng sửa sai.

Các định nghĩa Fairness có thể xung đột. Đội phải ghi:

• Nhóm nào được so sánh.
• Vì sao so sánh đó có ý nghĩa.
• Tác hại nào cần tránh.
• Chỉ số nào dùng để đo.
• Dữ liệu có đại diện không.
• Ai quyết trade-off.
• Điều gì không thể suy ra từ dữ liệu hiện có.

Không dùng chỉ số tổng để che chênh lệch nhóm. Không suy luận thuộc tính nhạy cảm chỉ để đo Fairness nếu suy luận tạo rủi ro lớn hơn. Data, Privacy, Legal và domain specialist xác nhận cách làm.

6.4 Explainability

Explainability (khả năng giải thích) cho phép người bị tác động hiểu đủ về quyết định hoặc khuyến nghị để hành động.

Mức giải thích tăng theo hậu quả. Có thể cần nêu:

• Dữ liệu nào được dùng.
• Yếu tố chính ảnh hưởng kết quả.
• Hệ thống có tự động hóa không.
• Giới hạn và mức không chắc chắn.
• Cách sửa dữ liệu sai.
• Cách yêu cầu xem xét.

Giải thích kỹ thuật dài không mặc định hữu ích. Mục tiêu là hiểu, hành động và phản đối.

6.5 Human oversight và contestability

Human Oversight (giám sát của con người) chỉ có ý nghĩa khi người giám sát:

• Có năng lực.
• Có đủ thông tin.
• Có đủ thời gian.
• Có quyền thay đổi kết quả.
• Không bị KPI ép duyệt máy móc.
• Có dấu vết quyết định.

Nút “approve” bấm hàng nghìn lần không tạo giám sát thật.

Contestability (khả năng phản đối) cho phép người bị tác động:

• Biết quyết định tồn tại.
• Hiểu căn cứ đủ dùng.
• Sửa dữ liệu sai.
• Nộp phản đối.
• Được người có thẩm quyền xem xét.
• Nhận kết quả và lý do.
• Không bị trả đũa vì phản đối.

NIST AI Risk Management Framework dùng bốn chức năng:

• Govern (quản trị).
• Map (lập bản đồ bối cảnh).
• Measure (đo lường).
• Manage (quản lý).

Framework hỗ trợ quản trị rủi ro AI. Nó không tự quyết định điều gì công bằng hoặc chấp nhận được.

7. Risk tier, quyền và giám sát

7.1 Risk tier

Risk Tier (tầng rủi ro) quyết định độ sâu phân tích, kiểm thử, Evidence và phê duyệt.

Tầng	Dấu hiệu	Governance mặc định
Low	Tác động hẹp, dữ liệu ít nhạy cảm, dễ đảo ngược	Đội tự đánh giá; Evidence gọn
Moderate	Dữ liệu cá nhân đáng kể, tích hợp ngoài, ảnh hưởng nhiều người, cần hỗ trợ tiếp cận sâu	Review chuyên môn; Control Map; Monitoring rõ
High	Ảnh hưởng quyền, tiền, cơ hội, sức khỏe, an toàn; nhóm dễ tổn thương; dữ liệu nhạy cảm; tự động hóa; khó đảo ngược	Review liên chức năng; phê duyệt độc lập; rollout giới hạn; Kill Switch; Incident Readiness
Unacceptable	Tác hại không giảm được, mục đích trái nguyên tắc tổ chức, thiếu quyền hợp lệ hoặc không vận hành an toàn	Không xây, không phát hành hoặc thu hồi

Đây là mô hình governance nội bộ, không là phân loại pháp lý.

Yếu tố tăng tầng:

• Quy mô người bị tác động.
• Độ nhạy dữ liệu.
• Tính khó đảo ngược.
• Tác động tới quyền, tiền hoặc sinh kế.
• Trẻ em hoặc Vulnerable User.
• Tự động hóa quyết định.
• Khả năng lạm dụng.
• Khó phát hiện tác hại.
• Phụ thuộc nhà cung cấp.
• Nhiều Jurisdiction.
• Thiếu Contestability.

7.2 Accountable owner và quyết định chuyên môn

Accountable Owner (người chịu trách nhiệm giải trình) chịu trách nhiệm về kết quả governance. Owner không tự làm mọi Control.

Quyết định	Quyền phù hợp
Giá trị, phạm vi và trade-off sản phẩm	Product
Kiến trúc và kiểm soát kỹ thuật	Engineering hoặc Security authority
Diễn giải nghĩa vụ pháp lý	Legal
Chương trình tuân thủ và Evidence	Compliance
Trải nghiệm và kiểm thử Accessibility	Design hoặc Accessibility owner cùng Engineering
Chất lượng dữ liệu và chênh lệch kết quả	Data owner
Chấp nhận Residual Risk lớn	Executive hoặc risk authority được ủy quyền
Dừng khẩn cấp	Incident authority theo Runbook

PM tổng hợp quyết định, bảo đảm vấn đề được xử lý và trade-off rõ. PM không ký thay Legal, Security, Data, Accessibility, Finance hoặc approver.

7.3 Escalation và approval

Escalation (leo thang xử lý) bắt buộc khi:

• Hai nghĩa vụ xung đột.
• Rủi ro vượt thẩm quyền owner.
• Evidence chưa đủ cho phê duyệt.
• Deadline thương mại ép giảm Control.
• Chuyên gia bất đồng về mức tác hại chấp nhận được.
• Monitoring vượt ngưỡng.
• Kill Switch gây tác động rộng.

Approval (phê duyệt) phải ghi:

• Phạm vi.
• Phiên bản.
• Evidence đã xem.
• Rủi ro còn mở.
• Người chấp nhận.
• Điều kiện.
• Thời hạn nếu tạm thời.
• Review trigger.

Approval không vĩnh viễn. Thay đổi mục đích dữ liệu, mô hình, nhà cung cấp, thị trường hoặc quy mô có thể làm approval cũ mất hiệu lực.

7.4 Monitoring và kill switch

Monitoring (giám sát) đo hiệu suất và tác hại.

Tín hiệu có thể gồm:

• Truy cập bất thường.
• Khiếu nại quyền riêng tư.
• Dữ liệu giữ quá hạn.
• Lỗi Control.
• Báo cáo Abuse Case.
• Tỷ lệ thất bại theo công nghệ hỗ trợ.
• Tỷ lệ bỏ tác vụ cốt lõi.
• Chênh lệch kết quả giữa nhóm.
• Tỷ lệ phản đối và đảo quyết định.
• Sự cố nhà cung cấp.
• Tăng liên hệ hỗ trợ sau thay đổi.

Kill Switch có thể:

• Tắt toàn tính năng.
• Tắt theo Jurisdiction.
• Tắt theo nhóm người dùng.
• Chuyển sang xử lý thủ công.
• Dừng ghi hoặc chia sẻ dữ liệu.
• Thu hồi quyền hoặc token.
• Quay lại phiên bản trước.
• Giới hạn tốc độ hoặc công suất.

Quality criteria:

• Signal rõ.
• Threshold hoặc nguyên tắc phán đoán rõ.
• Có người trực và quyền hành động.
• Có Runbook.
• Có kiểm thử.
• Có phương án phục hồi.
• Có kế hoạch giao tiếp khi người bị tác động cần biết.

8. Risk và decision artifacts

8.1 Risk Register

Risk Register (sổ đăng ký rủi ro) là hồ sơ sống.

Trường	Nội dung
Risk ID	Định danh
Harm	Tác hại cụ thể
Affected people/assets	Người hoặc tài sản bị tác động
Scenario	Cơ chế hoặc kịch bản xảy ra
Domain	Privacy, Security, Accessibility, Compliance, Ethics
Inherent risk	Rủi ro trước Control
Controls	Kiểm soát hiện tại
Evidence	Bằng chứng hiệu lực
Residual risk	Rủi ro còn lại
Owner	Người chịu trách nhiệm
Action	Giảm, tránh, chuyển hoặc chấp nhận
Due date	Hạn xử lý
Trigger	Điều kiện mở lại
Status	Trạng thái

Không ghi “data breach” đơn độc. Ghi tác nhân, dữ liệu, đường xảy ra, người bị tác động và hậu quả.

8.2 Evidence quality

Evidence tốt phải trả lời:

• Control nào được kiểm tra?
• Phạm vi nào được kiểm tra?
• Phiên bản nào được kiểm tra?
• Ai thực hiện?
• Khi nào thực hiện?
• Điều kiện pass/fail là gì?
• Lỗi nào còn mở?
• Ai xác nhận kết quả?
• Kết quả có còn hiệu lực sau thay đổi không?

Một policy không chứng minh hệ thống thực thi policy. Một ảnh chụp màn hình không chứng minh mọi phiên bản đều hoạt động. Một bài kiểm thử tự động không chứng minh Accessibility đầy đủ.

8.3 Go-live Evidence

Go-live Evidence (bằng chứng sẵn sàng phát hành) tối thiểu:

Miền	Evidence cần có
Product responsibility	Responsible Product Brief đã cập nhật
Risk	Risk Register có Residual Risk và owner
Privacy	Data Inventory, Data Flow Map, mục đích, Retention, quyền truy cập, đánh giá tác hại
Security	Phân tích Threat và Abuse Case, kiểm thử phù hợp, lỗ hổng mở, Incident Readiness
Accessibility	Acceptance Criteria, kiểm thử tự động và thủ công, lỗi mở, phạm vi hỗ trợ
Compliance	Requirement mapping, Policy áp dụng, Approval, Audit Trail
Ethics	Vulnerable User, Fairness, Explainability, Oversight, Contestability
Operations	Monitoring, alert, support, rollback, Kill Switch
Decision	Approval record, dissent, exception, Review Trigger

Go-live không phải phiếu trung bình. Một lỗi chí mạng không được bù bằng nhiều ô xanh.

Trạng thái	Hành động
Tất cả Control bắt buộc đạt	Phát hành theo phạm vi duyệt
Lỗi thấp, có owner, được thẩm quyền chấp nhận	Phát hành có điều kiện
Evidence thiếu nhưng có thể giới hạn an toàn	Pilot kín nếu được duyệt
Rủi ro cao chưa giảm hoặc owner không rõ	Không phát hành
Không phát hiện hoặc dừng được tác hại quan trọng	Không mở rộng

Applied

Case mô phỏng: xếp hạng ứng viên trong nền tảng tuyển dụng

Đây là case mô phỏng. Dữ kiện, quyết định và ngưỡng trong case không phải số liệu thực tế, tư vấn pháp lý hoặc kết luận áp dụng cho mọi thị trường.

Bối cảnh

Nền tảng tuyển dụng B2B muốn thêm xếp hạng ứng viên. Hệ thống dùng hồ sơ, câu trả lời sàng lọc và lịch sử tương tác để đề xuất danh sách ưu tiên.

Mục tiêu sản phẩm là giảm thời gian đọc hồ sơ cho nhà tuyển dụng. Người nhận giá trị trực tiếp là nhà tuyển dụng. Người chịu tác động chính là ứng viên, dù ứng viên không trực tiếp chọn thứ hạng.

Điều chưa rõ:

• Nhà tuyển dụng dùng thứ hạng như gợi ý hay quyết định.
• Dữ liệu lịch sử có phản ánh thiên lệch cũ không.
• Ứng viên dùng công nghệ hỗ trợ có hoàn thành hồ sơ không.
• Jurisdiction nào áp dụng.
• Nhà cung cấp mô hình giải thích được tới đâu.
• Ứng viên phản đối thứ hạng bằng cách nào.

1. Chọn phạm vi ban đầu

Ba Options:

1. Tự động loại ứng viên dưới ngưỡng.
2. Xếp hạng để nhà tuyển dụng tham khảo.
3. Chỉ tóm tắt tiêu chí liên quan, không xếp hạng tổng.

Option 1: tự động loại

Giá trị là tốc độ cao. Tác hại là loại sai, khuếch đại thiên lệch lịch sử, giảm cơ hội việc làm và khó phục hồi sau quyết định. Độ khó đảo ngược cao. Human Oversight và Contestability yếu nếu ứng viên không biết hoặc không thể phản đối.

Option 2: xếp hạng tham khảo

Giá trị vận hành vẫn tồn tại. Tác hại tự động loại giảm, nhưng Automation Bias (thiên kiến tin quá mức vào đầu ra tự động) còn đó. Nhà tuyển dụng có thể xem thứ hạng như quyết định dù giao diện ghi “gợi ý”.

Option 3: tóm tắt tiêu chí

Rủi ro giảm vì hệ thống không đưa ra thứ hạng tổng. Giá trị giảm vì nhà tuyển dụng vẫn phải tự đánh giá. Khả năng giải thích và kiểm tra tiêu chí tốt hơn.

2. Decision record theo nguyên tắc Facts → Current behavior → Underlying need → Options → Decision criteria → Decision → Authority → Artifact → Consequence if wrong

Facts

• Nền tảng muốn giảm thời gian đọc hồ sơ.
• Hệ thống dự kiến dùng hồ sơ, câu trả lời sàng lọc và lịch sử tương tác.
• Ứng viên chịu tác động dù không trực tiếp chọn thứ hạng.
• Dữ liệu lịch sử có thể chứa thiên lệch cũ.
• Nhà cung cấp mô hình chưa xác nhận mức Explainability cần thiết.
• Jurisdiction áp dụng chưa được Legal xác nhận.
• Khả năng Accessibility của luồng chưa được kiểm chứng.

Current behavior

Nhà tuyển dụng hiện đọc hồ sơ và dùng bộ lọc hiện có. Hệ thống chưa tự động loại ứng viên. Nhà tuyển dụng chưa nhận điểm hoặc lý do từ mô hình.

Underlying need

Nhà tuyển dụng cần tìm ứng viên phù hợp nhanh hơn. Nhu cầu thật không nhất thiết là “có điểm xếp hạng”. Nhu cầu có thể được đáp ứng bằng tóm tắt tiêu chí, bộ lọc minh bạch hoặc công cụ so sánh có kiểm soát.

Options

• Tự động loại.
• Xếp hạng tham khảo.
• Tóm tắt tiêu chí liên quan.
• Không xây cho tới khi có Evidence đủ.

Decision criteria

• Tác động tới cơ hội việc làm.
• Khả năng phát hiện và sửa sai.
• Fairness và đại diện dữ liệu.
• Explainability và Contestability.
• Human Oversight có quyền thật.
• Accessibility của tác vụ cốt lõi.
• Data Minimization và Purpose Limitation.
• Khả năng giới hạn thị trường và Kill Switch.
• Evidence của nhà cung cấp.
• Thẩm quyền pháp lý và Compliance theo Jurisdiction.

Decision

Đội loại Option 1. Chọn pilot Option 2 với phạm vi giới hạn, không tự động loại, không xuất dữ liệu hàng loạt và có quyền dừng. Nếu Explainability hoặc Fairness không đạt, chuyển về Option 3 hoặc không phát hành.

Authority

• Product quyết định phạm vi giá trị và trải nghiệm.
• Legal xác nhận Jurisdiction và nghĩa vụ áp dụng.
• Privacy xác nhận mục đích, Data Minimization, Retention và quyền Data Subject.
• Security xác nhận Asset, Threat, Abuse Case và Control kỹ thuật.
• Accessibility owner cùng Engineering xác nhận Accessibility Acceptance.
• Data owner xác nhận chất lượng, đại diện và phân tích chênh lệch.
• Risk authority chấp nhận Residual Risk High.
• Incident authority dùng Kill Switch khi có sự cố hoặc tín hiệu vượt ngưỡng.

PM không ký thay các authority này.

Artifact

• Responsible Product Brief.
• Data Inventory.
• Data Flow Map.
• Risk Register.
• Threat and Abuse Analysis.
• Control Map.
• Accessibility Acceptance.
• Approval Record.
• Go-live Evidence Pack.
• Monitoring and Incident Plan.
• Kill Switch Runbook.

Consequence if wrong

Nếu đội phát hành tự động loại khi mô hình sai, ứng viên có thể mất cơ hội việc làm mà không biết lý do hoặc không thể sửa dữ liệu. Tổ chức có thể chịu tác hại vận hành, mất niềm tin, tăng khiếu nại, phát sinh sự cố dữ liệu hoặc phải thu hồi tính năng trên phạm vi lớn.

3. Privacy decision

Facts

Lịch sử mở email và lịch sử tương tác có thể cho biết hành vi tương tác, nhưng chưa chứng minh phù hợp nghề nghiệp.

Current behavior

Hệ thống lưu lịch sử tương tác để vận hành liên lạc. Dữ liệu chưa được dùng để xếp hạng ứng viên.

Underlying need

Mô hình cần tín hiệu để sắp xếp hồ sơ. Nhưng nhu cầu giảm thời gian đọc không chứng minh cần dữ liệu hành vi chi tiết.

Options

• Dùng toàn bộ lịch sử tương tác.
• Dùng dữ liệu hồ sơ và câu trả lời sàng lọc.
• Dùng dữ liệu tổng hợp tối thiểu.
• Không xây xếp hạng nếu không xác định được mục đích hợp lệ.

Decision criteria

• Giá trị tăng thêm của từng trường dữ liệu.
• Kỳ vọng hợp lý của ứng viên.
• Tác hại từ theo dõi và suy luận.
• Khả năng giảm độ chi tiết.
• Retention và khả năng xóa.
• Purpose Limitation.
• Nghĩa vụ áp dụng theo Jurisdiction.

Decision

Đội loại lịch sử mở email khỏi mô hình. Mục đích dữ liệu tương tác vẫn là vận hành liên lạc, không phải đánh giá ứng viên. Mục đích mới cần Privacy và Legal review trước khi dùng.

Authority

Privacy xác nhận rủi ro quyền riêng tư. Legal xác nhận nghĩa vụ. Product quyết định thay đổi phạm vi sau khi nhận đánh giá. Data owner xác nhận trường dữ liệu còn lại.

Artifact

Data Inventory, Data Flow Map, Purpose Register, Retention Schedule và Risk Register.

Consequence if wrong

Nếu dùng dữ liệu ngoài kỳ vọng, ứng viên có thể bị đánh giá từ hành vi không liên quan. Tổ chức tăng rủi ro Function Creep, khiếu nại và khó thực hiện quyền xóa hoặc phản đối.

4. Security và Abuse Case

Facts

Assets gồm hồ sơ ứng viên, điểm, quyền nhà tuyển dụng và tính toàn vẹn quy trình tuyển dụng.

Current behavior

Nhà tuyển dụng có quyền xem hồ sơ trong tổ chức của họ. Hệ thống chưa có tính năng xuất hàng loạt điểm. Thay đổi tiêu chí chưa có Audit Trail đầy đủ.

Underlying need

Nhà tuyển dụng cần xem kết quả trong phạm vi tổ chức. Họ không cần quyền xuất hàng loạt hoặc sửa tiêu chí không để lại dấu vết.

Options

• Cho phép xuất điểm.
• Giới hạn xem trong giao diện.
• Phân quyền theo vai trò và tổ chức.
• Ghi Audit Trail cho thay đổi.
• Chỉ cho phép cấu hình tiêu chí đã được duyệt.

Decision criteria

• Quy mô dữ liệu có thể bị lấy.
• Khả năng chiếm tài khoản.
• Khả năng lạm dụng quyền hợp lệ.
• Khả năng phát hiện.
• Khả năng thu hồi.
• Tác động tới ứng viên và tính toàn vẹn quy trình.

Decision

Đội không cho xuất dữ liệu hàng loạt ở lần phát hành đầu. Đội dùng phân quyền theo vai trò và tổ chức, giới hạn truy vấn, ghi Audit Trail cho thay đổi tiêu chí, phát hiện truy cập bất thường và chuẩn bị thu hồi quyền.

Authority

Security xác định Control và Residual Risk kỹ thuật. Engineering triển khai. System owner chịu trách nhiệm vận hành. Incident authority dùng Kill Switch hoặc thu hồi quyền khi sự cố xảy ra.

Artifact

Threat and Abuse Analysis, Access Control Matrix, Audit Trail specification, test evidence và Incident Runbook.

Consequence if wrong

Kẻ tấn công hoặc người có quyền hợp lệ có thể thu thập hồ sơ hàng loạt, thay đổi tiêu chí để ưu tiên nhóm riêng hoặc làm sai lệch quy trình tuyển dụng.

5. Accessibility

Facts

Luồng xếp hạng có bộ lọc, danh sách thay đổi động, trạng thái màu và tooltip giải thích.

Current behavior

Bộ lọc chưa dùng hoàn toàn bằng bàn phím. Screen reader không nhận thông báo khi danh sách cập nhật. Giải thích chỉ xuất hiện khi hover. Trạng thái dùng màu mà không có nhãn văn bản.

Underlying need

Ứng viên và nhà tuyển dụng cần đọc, lọc, hiểu và thao tác với kết quả bằng phương thức tương tác phù hợp.

Options

• Phát hành với lỗi mở.
• Sửa cấu trúc HTML và keyboard behavior.
• Thêm nhãn trạng thái bằng văn bản.
• Cung cấp thông báo phù hợp cho cập nhật động.
• Đưa giải thích ra khỏi tooltip hover.
• Kiểm thử automation và manual testing với Assistive Technology đã chọn.

Decision criteria

• Tác vụ cốt lõi có hoàn thành được không.
• Lỗi có chặn người dùng không.
• Phạm vi hỗ trợ đã công bố.
• Khả năng sửa trước phát hành.
• Evidence kiểm thử.
• Lỗi có tạo bất bình đẳng trong quyền tiếp cận không.

Decision

Lỗi bàn phím ở bộ lọc chặn go-live. Đội sửa keyboard behavior, focus, trạng thái văn bản, thông báo screen reader và giải thích không phụ thuộc hover. Chỉ phát hành sau Accessibility Acceptance đạt trong phạm vi duyệt.

Authority

Accessibility owner xác nhận tiêu chí. Engineering sửa. Design xác nhận trải nghiệm. Product không hạ tiêu chuẩn thành “lỗi thẩm mỹ”.

Artifact

Accessibility Acceptance, test matrix, lỗi mở, kết quả automation và manual testing.

Consequence if wrong

Người dùng khuyết tật không hoàn thành tác vụ cốt lõi hoặc không hiểu kết quả. Đội mất khả năng chứng minh chất lượng Accessibility và có thể phải sửa gấp sau phát hành.

6. Ethics và governance

Facts

Nhà tuyển dụng có thể tin thứ hạng dù giao diện ghi “gợi ý”. Ứng viên có thể không biết hệ thống dùng dữ liệu nào. Nhóm dễ tổn thương có thể khó phản đối.

Current behavior

Nhà tuyển dụng đọc thứ hạng từ trên xuống. Không có yêu cầu xem xét lý do. Không có luồng phản đối cho ứng viên.

Underlying need

Nhà tuyển dụng cần giảm thời gian tìm kiếm nhưng vẫn phải chịu trách nhiệm về quyết định tuyển dụng. Ứng viên cần biết khi hệ thống ảnh hưởng cơ hội của họ và cần cách sửa sai.

Options

• Tự động loại.
• Xếp hạng không giải thích.
• Xếp hạng có yếu tố chính, giới hạn sử dụng, quyền xem hồ sơ đầy đủ và quy trình phản đối.
• Tóm tắt tiêu chí không xếp hạng.

Decision criteria

• Tác động tới quyền và cơ hội.
• Automation Bias.
• Explainability.
• Human Oversight có quyền thật.
• Contestability.
• Fairness và chất lượng dữ liệu.
• Khả năng đo chênh lệch.
• Khả năng dừng và phục hồi.

Decision

Không tự động loại. Giao diện không dùng nhãn “best candidate”. Giao diện hiển thị yếu tố chính, dữ liệu thiếu và giới hạn của hệ thống. Nhà tuyển dụng vẫn xem hồ sơ ngoài thứ hạng. Hệ thống ghi nhận khi người dùng đảo đề xuất. Đội xây quy trình phản đối theo phạm vi Legal xác nhận.

Authority

Product quyết định trải nghiệm. Data xác nhận cách đo chênh lệch. Legal xác nhận phạm vi phản đối. Risk authority chấp nhận Residual Risk High. Nhà tuyển dụng vẫn chịu trách nhiệm quyết định tuyển dụng theo quy trình của họ.

Artifact

Fairness assessment, Explainability specification, Human Oversight procedure, Contestability flow, Approval Record và Monitoring Plan.

Consequence if wrong

Nhà tuyển dụng có thể tự động hóa thiên lệch lịch sử. Ứng viên bị loại mà không biết lý do. Đội không phát hiện tác hại vì người bị tác động không có kênh phản đối hoặc dữ liệu giám sát.

7. Go-live decision

Facts

Evidence còn thiếu:

• Chưa đủ dữ liệu chênh lệch kết quả giữa nhóm.
• Chưa xác nhận nghĩa vụ cho mọi thị trường.
• Nhà cung cấp chưa giải thích được ở mức cần thiết.
• Accessibility lỗi chặn chưa sửa.
• Xuất dữ liệu hàng loạt chưa có Control đáng tin cậy.

Current behavior

Tính năng chưa phát hành. Nhà tuyển dụng vẫn dùng tìm kiếm và lọc hiện tại. Không có tác động từ thứ hạng trong môi trường thật.

Underlying need

Đội muốn kiểm tra giá trị giảm thời gian đọc mà không mở tác hại trên toàn thị trường.

Options

• Phát hành toàn thị trường.
• Phát hành pilot trong Jurisdiction đã xác nhận.
• Chuyển sang tóm tắt tiêu chí.
• Trì hoãn cho tới khi Evidence đủ.

Decision criteria

• Risk Tier High.
• Control bắt buộc đã đạt chưa.
• Evidence có truy xuất được không.
• Authority có phê duyệt đúng phạm vi không.
• Có Kill Switch và Monitoring thật không.
• Có thể giới hạn tác động không.
• Có thể phục hồi khi sai không.

Decision

Đội không mở toàn thị trường. Đội pilot tại Jurisdiction đã xác nhận, chỉ hỗ trợ sắp xếp, không tự động loại, không dùng dữ liệu tương tác ngoài mục đích, không xuất hàng loạt và theo dõi:

• Tỷ lệ đảo đề xuất.
• Tỷ lệ phản đối.
• Lỗi Accessibility.
• Chênh lệch kết quả.
• Abuse Case.
• Khiếu nại.
• Suy giảm Control.

Kill Switch được kích hoạt khi có tác hại nghiêm trọng, Control truy cập lỗi hoặc chênh lệch chưa giải thích vượt ngưỡng nội bộ đã duyệt.

Authority

Risk authority phê duyệt pilot và Residual Risk. Legal xác nhận Jurisdiction. Security xác nhận Incident Readiness. Accessibility owner xác nhận luồng cốt lõi. Product chịu trách nhiệm phạm vi và theo dõi Outcome.

Artifact

Approval Record, Go-live Evidence Pack, Monitoring Plan, Incident Runbook và Kill Switch Runbook.

Consequence if wrong

Nếu pilot vẫn gây tác hại, phạm vi giới hạn giúp giảm số người bị tác động và rút ngắn thời gian dừng. Nếu đội mở toàn thị trường, chi phí phát hiện, thu hồi, giao tiếp và phục hồi sẽ lớn hơn.

Senior Lens

1. Không lấy điểm trung bình giữa các miền

Security tốt không bù Accessibility thất bại. Consent rõ không bù Data Minimization yếu. Compliance đạt không bù Dark Pattern. Human Oversight không bù mô hình không kiểm soát được.

Dùng Risk Register để nhìn toàn cảnh. Đánh giá red line riêng. Một lỗi chí mạng ở một miền vẫn có thể chặn phát hành dù các miền khác đạt.

2. Phân biệt constraint, control và preference

• Constraint (ràng buộc): Điều không được vi phạm.
• Control: Cách giảm rủi ro.
• Preference: Cách triển khai có thể thay.

Ví dụ: chỉ người có quyền mới xem dữ liệu là Constraint. Role-Based Access Control là Control. Vị trí nút phân quyền là Preference.

Không biến Control quen thuộc thành giải pháp duy nhất. Không biến Constraint thành “ý kiến cần cân nhắc”.

3. Residual Risk phải có người nhận thật

“Business accepts risk” vô nghĩa nếu không có cá nhân hoặc thẩm quyền được ủy quyền.

Người nhận Residual Risk phải:

• Hiểu kịch bản và hậu quả.
• Có thẩm quyền với tài sản hoặc kết quả.
• Biết Control nào chưa đạt.
• Chấp nhận bằng văn bản khi cần.
• Đặt hạn và Review Trigger.
• Không đẩy trách nhiệm xuống đội không có quyền.

PM phải hỏi: “Ai ký? Người đó có quyền gì? Quyết định áp dụng tới phạm vi nào? Khi nào xem lại?”

4. Vendor không nhận thay accountability

Nhà cung cấp có thể xử lý dữ liệu, cung cấp mô hình hoặc Control kỹ thuật. Tổ chức vẫn phải biết:

• Dữ liệu đi đâu.
• Nhà cung cấp dùng dữ liệu thế nào.
• Phụ thuộc nào tồn tại.
• Sự cố được báo ra sao.
• Dữ liệu được xóa, xuất hoặc thu hồi ra sao.
• Control nào được kiểm chứng.
• Thay đổi dịch vụ ảnh hưởng sản phẩm ra sao.
• Cách thoát nhà cung cấp.

“Vendor compliant” không chứng minh sản phẩm của tổ chức tuân thủ hoặc có trách nhiệm.

5. Monitoring phải đo tác hại im lặng

Nhiều tác hại không tạo lỗi hệ thống:

• Người yếu thế bỏ cuộc.
• Nhóm bị xếp hạng thấp không biết lý do.
• Người dùng screen reader không hoàn thành tác vụ.
• Nhân viên luôn chấp thuận đề xuất máy.
• Dữ liệu bị dùng sai mục đích nhưng chưa bị lộ.
• Dark Pattern tăng chuyển đổi nhưng giảm niềm tin dài hạn.

Nguồn tín hiệu:

• Telemetry có giới hạn mục đích.
• Khiếu nại và support.
• Kiểm thử Accessibility định kỳ.
• Phân tích chênh lệch.
• Audit sampling.
• Research với nhóm bị tác động.
• Incident và near miss.
• Review chuyên gia.

Monitoring không chỉ đo KPI sản phẩm. Monitoring phải đo người nào chịu tác hại, tác hại xảy ra ở đâu và Control có còn hiệu lực không.

6. Escalation boundary

PM phải Escalate khi:

• Quyết định tác động quyền, tiền, cơ hội, sức khỏe hoặc an toàn.
• Requirement pháp lý chưa được xác nhận.
• Evidence thiếu nhưng deadline ép phát hành.
• Residual Risk vượt quyền Product.
• Chuyên gia bất đồng về tác hại.
• Vendor không cung cấp Evidence cần thiết.
• Không có người có quyền dùng Kill Switch.
• Monitoring không thể phát hiện tác hại quan trọng.
• Dữ liệu, thị trường, mô hình hoặc mục đích thay đổi.

PM có thể quyết định phạm vi sản phẩm. PM không tự quyết nghĩa vụ pháp lý, chấp nhận rủi ro Security lớn, xác nhận WCAG hoặc tuyên bố Fairness.

7. Red flags

• “Sẽ thêm privacy sau MVP.”
• “Dữ liệu đã ẩn tên nên không còn rủi ro.”
• “Người dùng đã đồng ý điều khoản.”
• “Không có breach nên Security ổn.”
• “Máy quét không báo lỗi nên accessible.”
• “Legal chưa phản đối nên compliant.”
• “Mô hình chỉ khuyến nghị nên không cần Fairness.”
• “Có người bấm approve nên đã có Human Oversight.”
• “Vendor chịu trách nhiệm.”
• “Không thể xây Kill Switch vì kiến trúc.”
• “Risk owner là Product team.”
• “Phát hành trước, Monitoring sau.”
• “Tác hại chưa xảy ra nên xác suất bằng không.”
• “Mọi thị trường dùng cùng approval.”
• “Ngoại lệ tạm thời” nhưng không có ngày hết hạn.

Quick reference

Decision rules

1. Mô tả người nhận giá trị và người chịu tác hại.
2. Xác định dữ liệu, Asset, mục đích và Jurisdiction.
3. Viết kịch bản lỗi, tấn công và Abuse Case.
4. Kiểm tra Vulnerable User và tác vụ dùng Assistive Technology.
5. Chuyển requirement và risk thành Control có owner.
6. Yêu cầu Evidence kiểm tra hiệu lực Control.
7. Đánh giá Residual Risk, không chỉ Inherent Risk.
8. Tăng governance theo hậu quả và độ khó đảo ngược.
9. Không phát hành nếu Control bắt buộc thiếu, owner không rõ hoặc không dừng được tác hại.
10. Theo dõi tác hại sau phát hành.
11. Mở lại quyết định khi Review Trigger xuất hiện.
12. Ghi dissent và exception, không che bất đồng bằng trạng thái “approved”.

Bộ artifact tối thiểu

Artifact	Mục đích
Responsible Product Brief	Định khung giá trị, tác hại, dữ liệu, nhóm bị tác động, Risk Tier và quyền
Risk Register	Theo dõi rủi ro trước và sau Control
Data Inventory và Data Flow Map	Truy vết thu, dùng, chia sẻ, lưu và xóa dữ liệu
Threat and Abuse Analysis	Xác định Asset, Threat, Attack Surface và Abuse Case
Control Map	Nối requirement hoặc risk với Control, owner và Evidence
Accessibility Acceptance	Chuyển WCAG 2.2 và nhu cầu Assistive Technology thành tiêu chí kiểm thử
Approval Record	Ghi phạm vi, Residual Risk, điều kiện và thẩm quyền
Go-live Evidence Pack	Tập Evidence sẵn sàng phát hành
Monitoring and Incident Plan	Phát hiện, ứng phó, khôi phục và học
Kill Switch Runbook	Quyền, bước dừng, tác động và cách phục hồi
Retention Schedule	Ghi mục đích, thời hạn, ngoại lệ và cách xóa
Contestability Flow	Cho phép biết, sửa, phản đối và nhận kết quả xem xét

Go-live gate

• [ ] Responsible Product Brief đúng phạm vi hiện tại.
• [ ] Risk Tier được xác nhận.
• [ ] Accountable Owner có tên và thẩm quyền.
• [ ] Data Minimization và Purpose Limitation đã kiểm tra.
• [ ] Consent, Retention và quyền Data Subject được thiết kế theo requirement áp dụng.
• [ ] Asset, Threat, Attack Surface và Abuse Case đã phân tích.
• [ ] Security Controls có Evidence kiểm thử phù hợp.
• [ ] Incident Readiness và Kill Switch đã xác nhận.
• [ ] Accessibility Acceptance bao phủ luồng cốt lõi.
• [ ] Kiểm thử gồm automation và manual testing phù hợp.
• [ ] Regulatory Requirement, Policy và Jurisdiction được chuyên gia xác nhận.
• [ ] Control Map không có Control bắt buộc thiếu owner.
• [ ] Audit Trail đủ truy vết, không ghi dữ liệu quá mức.
• [ ] Dark Pattern đã loại.
• [ ] Vulnerable User, Fairness và Explainability đã đánh giá.
• [ ] Human Oversight có quyền thật.
• [ ] Contestability có quy trình vận hành.
• [ ] Residual Risk được thẩm quyền chấp nhận.
• [ ] Monitoring có signal, owner và trigger.
• [ ] Go-live Evidence lưu được và truy xuất được.
• [ ] Thay đổi sau phê duyệt có Review Trigger rõ.

Thuật ngữ sử dụng trong chương

Thuật ngữ	Giải nghĩa
Responsible Product	Sản phẩm được thiết kế và vận hành có trách nhiệm với tác động lên con người và tổ chức
Decision System	Hệ thống quyền, quy tắc, bằng chứng và phản hồi để ra quyết định
Privacy by Design	Tích hợp quyền riêng tư từ thiết kế
Data Minimization	Chỉ xử lý dữ liệu cần thiết
Purpose Limitation	Chỉ dùng dữ liệu theo mục đích đã xác định
Consent	Sự đồng ý có thông tin và lựa chọn có ý nghĩa
Retention	Thời hạn lưu giữ dữ liệu
Data Subject	Người mà dữ liệu liên quan
Threat	Mối đe dọa có thể gây hại
Asset	Tài sản, dữ liệu, quyền hoặc dịch vụ cần bảo vệ
Attack Surface	Điểm tương tác có thể bị khai thác
Abuse Case	Kịch bản chức năng bị lợi dụng để gây hại
Control	Biện pháp giảm khả năng hoặc tác động của rủi ro
Residual Risk	Rủi ro còn lại sau kiểm soát
Incident Readiness	Mức sẵn sàng phát hiện và ứng phó sự cố
POUR	Có thể nhận biết, vận hành, hiểu và tương thích bền vững
WCAG 2.2	Hướng dẫn khả năng tiếp cận nội dung web phiên bản 2.2
Assistive Technology	Công nghệ hỗ trợ người khuyết tật
Inclusive Design	Thiết kế bao trùm nhiều khả năng và hoàn cảnh
Regulatory Requirement	Yêu cầu từ quy định áp dụng
Compliance Evidence	Bằng chứng chứng minh Control tuân thủ hoạt động
Audit Trail	Dấu vết cho phép tái dựng hành động
Jurisdiction	Khu vực tài phán có thẩm quyền
Dark Pattern	Mẫu thiết kế thao túng lựa chọn
Vulnerable User	Người dễ chịu tác hại hoặc khó tự bảo vệ
Fairness	Tính công bằng trong quy trình và kết quả
Explainability	Khả năng giải thích kết quả đủ để hành động
Human Oversight	Giám sát có năng lực và quyền can thiệp của con người
Contestability	Khả năng biết, phản đối và yêu cầu xem xét quyết định
Risk Tier	Tầng phân loại rủi ro để chọn governance
Accountable Owner	Người chịu trách nhiệm giải trình
Kill Switch	Cơ chế giới hạn hoặc tắt nhanh
Responsible Product Brief	Bản tóm tắt giá trị, tác hại và governance
Risk Register	Sổ đăng ký rủi ro và xử lý
Control Map	Bản đồ nối requirement, risk, Control và Evidence
Accessibility Acceptance	Tiêu chí chấp nhận khả năng tiếp cận
Go-live Evidence	Bằng chứng sẵn sàng phát hành
Automation Bias	Thiên kiến tin quá mức vào đầu ra tự động
Function Creep	Việc dữ liệu dần bị dùng cho mục đích mới
Review Trigger	Điều kiện bắt buộc mở lại quyết định
Runbook	Hướng dẫn thao tác trong tình huống vận hành hoặc sự cố
Exception	Ngoại lệ được ghi nhận, giới hạn và phê duyệt
Dissent	Ý kiến bất đồng được lưu trong hồ sơ quyết định

Nguồn và giới hạn

NIST Privacy Framework

Đóng góp:

• Quản trị Privacy Risk như rủi ro tổ chức.
• Nối xử lý dữ liệu với tác hại cho con người.
• Hỗ trợ lập hồ sơ hiện tại, mục tiêu và ưu tiên cải thiện.

Giới hạn:

• Không phải luật.
• Không tự xác định cơ sở xử lý hoặc Jurisdiction.
• Legal và Privacy specialist phải xác nhận nghĩa vụ cụ thể.

NIST Cybersecurity Framework 2.0

Đóng góp:

• Sáu chức năng Govern, Identify, Protect, Detect, Respond, Recover.
• Nối Security với governance, chuỗi cung ứng và rủi ro tổ chức.

Giới hạn:

• Không là cấu hình kỹ thuật hoàn chỉnh.
• Không chứng nhận hệ thống an toàn.
• Security architecture, threat model, kiểm thử và incident design cần chuyên gia xác nhận.

NIST AI Risk Management Framework

Đóng góp:

• Bốn chức năng Govern, Map, Measure, Manage.
• Đặt bối cảnh, người bị tác động, độ tin cậy, minh bạch và governance vào vòng đời AI.

Giới hạn:

• Không tự chọn định nghĩa Fairness.
• Không thay đánh giá pháp lý, đạo đức hoặc chuyên môn ngành.
• Data, Legal, Ethics và domain specialist phải xác nhận hệ thống tác động cao.

W3C Web Content Accessibility Guidelines 2.2

Đóng góp:

• Nguyên tắc POUR.
• Tiêu chí thành công có thể chuyển thành Acceptance Criteria.
• Cơ sở kiểm thử nội dung và giao diện web.

Giới hạn:

• Đạt tiêu chí không tự bảo đảm trải nghiệm tốt cho mọi người.
• Automation chỉ phát hiện một phần lỗi.
• Cần kiểm thử thủ công, Assistive Technology và người dùng phù hợp.

OWASP Application Security Verification Standard

Đóng góp:

• Danh mục requirement có thể kiểm chứng cho Security ứng dụng.
• Hỗ trợ chuyển mục tiêu Security thành Acceptance Criteria và test Evidence.

Giới hạn:

• Không thay threat modeling, kiến trúc an toàn hoặc Incident Readiness.
• Không tuyên bố tuân thủ nếu chưa xác định phạm vi, mức áp dụng và Evidence kiểm chứng.

Giới hạn của chương

Chương cung cấp khung quyết định sản phẩm, không phải tư vấn pháp lý, chứng nhận Security, chứng nhận Accessibility, đánh giá Fairness độc lập hoặc quy trình ứng phó sự cố hoàn chỉnh. Nghĩa vụ thay đổi theo sản phẩm, dữ liệu, thị trường, nhà cung cấp và thời điểm. PM phải chuyển câu hỏi phù hợp tới authority có thẩm quyền.

Responsible Product không đạt bằng một lần phê duyệt. Hệ thống phải liên tục:

• Giới hạn dữ liệu.
• Bảo vệ Asset.
• Mở quyền tiếp cận.
• Chứng minh nghĩa vụ.
• Ngăn thao túng.
• Cho phép phản đối.
• Đo tác hại.
• Dừng nhanh khi thực tế khác giả định.
• Mở lại quyết định khi phạm vi, dữ liệu, mô hình, nhà cung cấp hoặc tác động thay đổi.