Danh sách kiểm tra trách nhiệm AI lấy cảm hứng từ Timnit Gebru: ghi chép dữ liệu, giới hạn và nguy cơ gây hại cho người dùng để quyết định xem tính năng có nên phát hành không.
Bắt đầu ngay trước khi bạn phát hành, khi người dùng thực sự sẽ bắt đầu dựa vào kết quả.\n\nNếu bạn đợi đến sau khi ra mắt, bạn sẽ đang ghi lại các sự cố thay vì ngăn chặn chúng, và bạn sẽ có ít thời gian (và ít lựa chọn) để thêm biện pháp bảo vệ hoặc thu hẹp phạm vi.
Trách nhiệm nghĩa là bạn có thể chỉ ra các quyết định viết ra về:\n\n- Hệ thống dùng để làm gì (và không dùng để làm gì)\n- Dữ liệu nó dùng (đào tạo và thời gian chạy)\n- Giới hạn và các chế độ lỗi đã biết\n- Ai có thể bị tổn hại và như thế nào\n- Bạn sẽ làm gì khi nó hỏng (giám sát, leo thang, rollback)\n\nNếu bạn không thể trình bày những quyết định đó và người chịu trách nhiệm, thì bạn chưa có trách nhiệm.
Bất kỳ tính năng nào mà đầu ra của mô hình có thể thay đổi những gì mọi người thấy, làm, hoặc cách họ bị đối xử.\n\nĐiều này bao gồm các tính năng “nhỏ” như tóm tắt hoặc trả lời gợi ý nếu ai đó có thể hành động theo chúng (gửi tới khách hàng, từ chối một yêu cầu, thay đổi thứ tự ưu tiên). Nếu nó ảnh hưởng tới một quyết định, hãy coi nó như một bề mặt sản phẩm thực với rủi ro thực.
Có một tập "tối thiểu" cần có bằng văn bản:\n\n- Mục đích và người dùng (kể cả các cách dùng ngoài phạm vi)\n- Dữ liệu và nguồn (đào tạo/điều chỉnh, truy xuất, logs, lưu trữ)\n- Giới hạn đã biết (với ví dụ đầu ra xấu)\n- Rủi ro tổn hại người dùng (riêng tư, thiên vị, lời khuyên không an toàn, tin cậy quá mức)\n- Giám sát + kế hoạch sự cố (cảnh báo, leo thang, ngưỡng rollback)\n\nGiữ ngắn gọn, nhưng mỗi khẳng định phải có thể kiểm thử được.
Ghi đủ để ai đó có thể trả lời các câu hỏi khó nhanh:\n\n- Mỗi dataset đến từ đâu, ai kiểm soát, tần suất cập nhật\n- Nó dùng cho hành vi nào trong sản phẩm\n- Các trường nhạy cảm tồn tại và giả định chấp thuận là gì\n- Các bước làm sạch/gán nhãn (và hướng dẫn nếu có người gán nhãn)\n- Những gì còn thiếu (ngôn ngữ, vùng, loại người dùng, các edge case)\n\nViết phần thiếu hụt rõ ràng (ví dụ: “chủ yếu tiếng Anh Mỹ; ít ví dụ từ người bán nhỏ”).
Bắt đầu với một câu: mô hình làm gì. Rồi thêm phần “không dùng cho”.\n\nBao gồm một danh sách ngắn:\n\n- Các đầu vào làm nó bối rối (yêu cầu mơ hồ, lẫn lộn ngôn ngữ, thiếu ngữ cảnh)\n- Tình huống nó hiểu sai (mỉa mai, giỡn, giận dữ)\n- Các mẫu lỗi đã biết (bịa chính sách, sai thực thể, sai ngày)\n- Các cách lạm dụng (prompt injection, cố lấy dữ liệu riêng tư)\n- Hạn chế vận hành (độ trễ/chi phí, timeout, giới hạn cửa sổ ngữ cảnh)\n\nThêm 3–5 ví dụ đầu ra xấu để người không phải kỹ sư cũng hiểu rõ cạnh méo.
Tách lỗi khỏi tổn hại:\n\n- Lỗi: đầu ra mô hình sai (tóm tắt tệ, cảnh báo sai).\n- Tổn hại: điều gì xảy ra vì lỗi đó (mất tiền, bị loại khỏi dịch vụ, lộ thông tin riêng tư).\n\nRồi viết vài kịch bản ngắn: người dùng là ai, họ hỏi gì, mô hình có thể trả lời ra sao, và hành động tiếp theo là gì. Đánh giá mỗi kịch bản theo mức độ nghiêm trọng và khả năng xảy ra, rồi gán chủ sở hữu cho mỗi biện pháp giảm thiểu.
Dùng một luồng có các cổng từ prototype đến phát hành:\n\n1. Xác định quyết định mà AI ảnh hưởng.\n2. Soạn sẵn ghi chú dữ liệu + giới hạn sớm (trước khi hoàn thiện UI).\n3. Kiểm thử với các trường hợp lộn xộn, edge và nhạy cảm.\n4. Thêm biện pháp bảo vệ: từ chối, “cần kiểm tra”, fallback, báo cáo dễ dàng.\n5. Định nghĩa giám sát và kế hoạch sự cố, gồm ngưỡng rollback.\n\nNếu một bước khó, thường chính là nơi rủi ro nằm.
Các lỗi thường gặp:\n\n- Lấy điểm số offline làm quyết định ra mắt\n- Ép phải một câu trả lời tự tin thay vì cho phép “tôi không biết” hoặc “cần kiểm tra”\n- Chỉ test với prompt do đội viết, bỏ qua đầu vào lộn xộn của người dùng thực\n- Viết docs sau khi ra mắt rồi không bao giờ cập nhật\n- Phát hành mà không có đường lui (rollback)\n\nSửa thực tế: giữ checklist trách nhiệm trong spec sản phẩm và yêu cầu ký duyệt trước khi phát hành.
Tốc độ không miễn trừ trách nhiệm. Nếu bạn xây với công cụ chat như Koder.ai, giữ kỷ luật giống nhau:\n\n- Dùng chế độ lập kế hoạch để viết mục đích, giới hạn và vùng cấm từ đầu.\n- Kiểm tra tính năng sinh ra với prompt lạm dụng và nhạy cảm (prompt injection, dữ liệu nhạy cảm, yêu cầu mâu thuẫn).\n- Làm cho rollback thực sự: snapshot/versioning và công tắc tắt nhanh.\n- Gán một người chịu trách nhiệm giữ tài liệu cập nhật khi prompt, mô hình, hoặc chính sách thay đổi.\n\nLặp nhanh không sao miễn là bạn có thể giải thích những gì đã phát hành và cách phản ứng khi nó hỏng.
