Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

AI Ethics & "Khi nào KHÔNG dùng"

Ethics

Judgment để biết khi nào AI là sai công cụ — kỹ năng quyết định ranh giới giữa "có thể" và "nên".

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng PM cho Sản phẩm AI — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Ethics, không chỉ kỹ năng này.

Làm bài đánh giá

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/4 mục · còn khoảng 6 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Tại sao kỹ năng này càng quan trọng trong thời đại AI?

Câu hỏi 2020: "AI có thể làm việc này không?" — câu trả lời thường là "chưa". Câu hỏi 2026: "AI có nên làm việc này không?" — câu trả lời cần judgment, không phải tech. PM nào không có khung tư duy này sẽ vô tình ship feature gây hại: hallucination trong y tế, bias trong tuyển dụng, lộ data user, hoặc đơn giản là làm user mất lòng tin.

VN regulatory đang siết: Nghị định 13/2023 về data privacy, dự thảo Luật AI 2025, GDPR ảnh hưởng tới VN export market. PM phải biết khi nào KHÔNG dùng AI trước cả khi luật buộc — vì khi luật buộc thì đã muộn (đã ship, đã có khủng hoảng PR).

Quan trọng hơn: trust một khi mất rất khó lấy lại. 1 hallucination trong chatbot y tế của bạn có thể khiến 100,000 user rời app. AI ethics không phải nice-to-have — nó là risk management.

Framework / Mental model

Khung "Should we use AI?" gồm 4 chiều phải đánh giá:

  • Data sensitivity: Data có chứa PII, sức khỏe, tài chính, vị trí, trẻ em không?
  • Decision impact: Nếu AI sai, ai bị tổn hại? Reversible không?
  • User awareness: User có biết họ đang nói chuyện với AI không? Có consent không?
  • Human override: Có path để human review/override không?

Cây quyết định:

flowchart TD
    A[Đề xuất dùng AI
cho feature X] --> B{Data có PII /
sức khỏe /
tài chính / trẻ em?} B -->|Có| C{Có consent rõ ràng
+ encryption +
data minimization?} B -->|Không| D{AI sai → có ai
bị tổn hại thực không?
(tiền, sức khỏe, danh tiếng)} C -->|Chưa đủ| K[KHÔNG dùng AI
hoặc làm rule-based] C -->|Đủ| D D -->|Tổn hại nặng,
khó rollback| E{Có human-in-loop
cho mỗi decision?} D -->|Tổn hại nhẹ /
rollback dễ| F{User có biết
đó là AI?} E -->|Không| K E -->|Có| F F -->|Không| G[Phải disclose
"This is AI-generated"] F -->|Có| H[Pass — dùng AI
với guardrails:
logging, eval,
fallback] G --> H

Quy luật bổ sung: "Default human cho high-stakes, default AI cho low-stakes." Nếu không chắc, treat as high-stakes.

Ví dụ thực tế

Case 1 — Chatbot hỗ trợ sức khỏe ở 1 startup VN: Startup muốn build chatbot AI tư vấn triệu chứng cho user. Đi qua framework: data sensitivity = SỨC KHỎE (high), decision impact = nếu sai user có thể không đi bác sĩ kịp (high, irreversible), user awareness = user có thể tin AI như bác sĩ. Quyết định: KHÔNG dùng AI cho diagnosis. Thay vào đó, dùng AI để: (1) triage symptom theo rule-based, (2) suggest specialist phù hợp, (3) luôn có disclaimer "Đây không phải tư vấn y khoa. Hãy gặp bác sĩ."

Case 2 — AI screening CV tự động: Một HR-tech VN muốn build AI score CV để filter. Đi qua framework: data có PII, decision impact = ảnh hưởng nghề nghiệp người ta (high), bias risk = AI có thể bias về giới tính/tuổi (đã có nhiều case ở Amazon, đã bị fail). Quyết định: AI chỉ rank, không filter. Human recruiter phải review top 30, AI không tự reject ai. Audit log mỗi tháng để check bias.

Case 3 — Chatbot customer support cho e-commerce: Đi qua framework: data sensitivity = thấp (order info), decision impact = thấp (sai thì user chỉ phải hỏi lại), reversible = có. Quyết định: AI fine, với guardrails: (1) disclose "Tôi là AI assistant", (2) escalate đến human khi user yêu cầu hoặc khi confidence thấp, (3) không bao giờ confirm refund/cancel mà không có human approve.

Luyện tập hàng ngày

  • Bài 1 (5 phút/ngày — "AI vs not"): Mỗi feature/idea bạn xem hôm nay, hỏi: "Cái này có nên dùng AI không? Hay rule-based đủ?". Lý do để default rule-based: deterministic, explainable, không hallucination, không cần eval. AI chỉ khi rule-based thực sự không khả thi.
  • Bài 2 (15 phút/tuần — "Risk register"): Cho mỗi AI feature đang ship, viết: top 3 cách AI có thể sai, top 3 cách user có thể bị hại, mitigation hiện tại. Update register này weekly.
  • Bài 3 (1 buổi/tháng — "Red team session"): Tổ chức 60 phút với eng + design + legal. Mỗi người cố tìm cách "break" AI feature: prompt injection, edge case, demographic bias, abuse. Document và fix top 3.

Sai lầm phổ biến

Pitfall 1 — "AI is the answer" mindset: Mỗi feature mới = thử dùng LLM. Sai. LLM không phải búa cho mọi đinh. Hỏi: rule-based có đủ không? Search có đủ không? Khi nào thực sự cần LLM?
Pitfall 2 — Bỏ qua disclosure: User nghĩ đang chat với người thật, thực ra là AI. Ngắn hạn = conversion cao, dài hạn = trust collapse khi vỡ. Disclose từ ngày 1.
Pitfall 3 — Không có fallback: AI down hoặc rate limit → feature chết → user mất trust. Mọi AI feature production cần graceful degradation tới rule-based hoặc human.
Pitfall 4 — Coi ethics là "việc của legal": Sai. Legal review một lần khi launch không đủ. PM phải tự own ethics thinking, update khi data/feature/regulatory đổi.

Dấu hiệu bạn đã master

  • Bạn đã kill ít nhất 1 AI feature proposal vì ethics — và team tôn trọng quyết định đó.
  • Mỗi AI feature bạn ship đều có: disclosure, fallback, human-in-loop path, audit log.
  • Bạn có thể trả lời câu hỏi của legal/compliance trong 5 phút mà không hoảng — vì đã pre-empt.
  • Khi 1 AI competitor có scandal (bias, leak, hallucination), team của bạn không panic — vì bạn đã có guardrails.

Tài nguyên thêm

  • Sách: Cathy O'Neil — Weapons of Math Destruction. Case study về AI bias trong tuyển dụng, credit, criminal justice — đọc 1 lần là tỉnh ngộ.
  • Sách: Brian Christian — The Alignment Problem. Foundation cho AI safety thinking cho non-researcher.
  • Bài viết: Anthropic — Responsible Scaling Policy (anthropic.com/rsp). Framework công nghệ tier-based.
  • Bài viết: Google PAIR — People + AI Research Guidebook (pair.withgoogle.com/guidebook). Foundation cho human-AI UX patterns.
  • Luật VN: Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân. Bắt buộc đọc nếu làm AI product ở VN.
  • Video: Stuart Russell — "Provably Beneficial AI" TED talk + UC Berkeley course slides. Foundation triết học.

Hiccups thường gặp và cách xử lý

HiccupVì sao xảy raXử lý
Bàn đạo đức sau khi đã xây xongCoi đó là khâu rà soát cuốiĐưa câu hỏi "có nên làm không" vào lúc chốt phạm vi, cùng buổi với câu "làm được không"
Không ai nêu lo ngạiNgười nêu bị coi là cản trở tiến độTạo một mục cố định trong buổi rà soát, để việc nêu không cần dũng cảm
Dựa vào "luật chưa cấm"Nhầm tuân thủ với đạo đứcLuật là sàn, không phải trần. Hỏi thêm: nếu việc này lên báo thì sao?
Thiên lệch chỉ được kiểm một lần trước ra mắtCoi là bài kiểm tra vượt qua rồi thôiĐo định kỳ theo nhóm người dùng; thiên lệch xuất hiện lại khi dữ liệu thay đổi
Không biết dừng ở đâuKhông có ranh giới viết sẵnViết trước danh sách việc sẽ không làm, kèm lý do — trước khi có áp lực thương mại
Trách nhiệm không thuộc về aiAi cũng nghĩ có người khác loChỉ định một người chịu trách nhiệm cho mỗi tính năng có rủi ro

Vì sao vai trò của bạn cần cái này

Vai tròBạn dùng nó để
Product Owner / PMBạn là người duy nhất có thể đặt câu hỏi "có nên" đúng lúc còn rẻ để dừng
Head of Product / CPOBạn viết ranh giới trước khi có áp lực thương mại buộc phải vượt qua nó
Business AnalystBạn phát hiện nhóm người dùng bị ảnh hưởng mà không ai nghĩ tới
EngineerBạn thường là người đầu tiên thấy dữ liệu có vấn đề
Pháp chế / tuân thủBạn nêu sàn pháp lý; phần trên sàn vẫn là quyết định sản phẩm

Definition of done

  • Câu hỏi "có nên làm không" được đặt cùng lúc với "làm được không", không đặt sau.
  • Có danh sách việc sẽ không làm, viết trước khi có áp lực thương mại.
  • Thiên lệch được đo định kỳ theo nhóm người dùng, không chỉ một lần trước ra mắt.
  • Mỗi tính năng có rủi ro đều có một người chịu trách nhiệm được chỉ định.
  • Có mục cố định trong buổi rà soát để nêu lo ngại mà không cần dũng cảm.

Tự kiểm 3 câu

Đọc xong rồi thì thử xem — đúng cả ba là đạt.
1. Một HR-tech muốn AI chấm điểm CV để lọc ứng viên. Thiết kế nào đúng tinh thần của kỹ năng này?
2. Đồng nghiệp nói: “Luật chưa cấm thì cứ làm.” PM nên đáp thế nào?
3. Câu hỏi “có nên dùng AI cho việc này không” nên được đặt vào lúc nào?

Khóa học liên quan (6)

Sử dụng trong vai trò

Thảo luận & tài liệu thêm 0

Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.

Hãy là người đầu tiên chia sẻ kinh nghiệm cho kỹ năng này.

Kiểm tra kỹ năng này

Bài kiểm tra của các khóa dạy kỹ năng này
1 Chẩn đoán

Đánh giá Kỹ năng PM cho Sản phẩm AI

Chấm riêng từng chiều của kỹ năng này.

chưa ai làm
Làm bài này
2 Quiz

Bài thi tổng kết: Quản trị, Tuân thủ & Rủi ro cho Agent Doanh nghiệp

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này
3 Quiz

Chương 2: Nền tảng kỹ thuật AI cho PM: LLM, Prompt, Tool Use, RAG

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này
4 Quiz

Kiểm tra Module 6: Khung quản trị AI

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này

Học kỹ năng này ở đâu?

Có 6 khóa dạy đúng phần này, miễn phí và bằng tiếng Việt.

Bắt đầu học