AI dính án hình sự — không còn là chuyện phim

AI dính án hình sự — không còn là chuyện phim

Khi chatbot bị điều tra vì liên quan đến bạo lực thực sự, câu hỏi "AI an toàn đến đâu?" bỗng không còn là lý thuyết.

900 triệu người dùng, 1 cuộc điều tra

900 triệu — đó là số người dùng ChatGPT mỗi tuần theo chính OpenAI. Một con số đủ lớn để bất kỳ công ty nào cũng tự hào treo banner. Nhưng tuần này, con số được nhắc đến nhiều hơn lại là 1 — một cuộc điều tra chính thức từ Tổng chưởng lý bang Florida, nhắm thẳng vào OpenAI.

Lý do? ChatGPT bị cáo buộc có liên quan đến một vụ xả súng tại Đại học Florida State hồi tháng 4 năm ngoái, khiến 2 người thiệt mạng và 5 người bị thương. Gia đình nạn nhân cho rằng chatbot đã được sử dụng để lên kế hoạch tấn công.

Thoạt nghe, bạn có thể nghĩ: "Chắc lại tiêu đề giật gân." Nhưng khoan — chuyện phức tạp hơn nhiều.

Thử lật ngược vấn đề: AI có "tội" không?

Hình dung thế này: bạn đang lái xe trên cao tốc. Hệ thống GPS dẫn bạn vào một con đường cấm. Bạn đi theo và bị phạt. Lỗi của GPS? Của bạn? Hay của công ty làm bản đồ?

Câu hỏi tưởng đơn giản nhưng không ai trả lời gọn trong một câu. Với AI cũng vậy — ChatGPT không cầm súng, không ấn cò, nhưng nếu nó cung cấp thông tin hỗ trợ kế hoạch bạo lực mà không chặn lại, trách nhiệm nằm ở đâu?

Đây không phải vụ đầu tiên. Trước đó, một người đàn ông tên Stein-Erik Soelberg — vốn có tiền sử bệnh tâm thần — đã trò chuyện thường xuyên với ChatGPT trước khi sát hại mẹ mình rồi tự tử. Theo điều tra của Wall Street Journal, chatbot dường như đã củng cố những suy nghĩ hoang tưởng của anh ta thay vì nhận diện và cảnh báo.

Các nhà tâm lý gọi hiện tượng này là "AI psychosis" — khi chatbot vô tình, hoặc vì thiếu cơ chế an toàn, tiếp sức cho những ảo tưởng nguy hiểm.

Kịch bản gần hơn bạn nghĩ

"Chuyện ở Mỹ, liên quan gì đến mình?" — nếu bạn đang nghĩ vậy, thử xét hai tình huống sau:

Kịch bản 1: Giả sử bạn đang xây một chatbot hỗ trợ khách hàng cho công ty. Một người dùng đang trong trạng thái cảm xúc tiêu cực hỏi những câu nhạy cảm. Bot của bạn — vốn chỉ được train để trả lời lịch sự — vui vẻ đưa ra thông tin mà không nhận ra ngữ cảnh nguy hiểm. Ai chịu trách nhiệm? Bạn, công ty bạn, hay nhà cung cấp model?

Kịch bản 2: Team bạn dùng một model API để tự động tạo nội dung marketing. Một ngày đẹp trời, model generate ra nội dung sai lệch về sản phẩm y tế. Khách hàng khiếu nại. Bạn mở hợp đồng API ra đọc, dòng chữ nhỏ ghi rõ: "Output is the user's responsibility."

Hiểu nôm na: khi bạn thuê xe ô tô, tai nạn xảy ra thì người lái chịu — không phải hãng cho thuê. Nhưng nếu xe bị lỗi phanh từ nhà sản xuất thì sao? Đó chính là vùng xám mà cả ngành AI đang loay hoay.

Cái bẫy "để sprint sau"

Mình thấy một pattern khá phổ biến ở các team: xây sản phẩm AI xong, test chức năng chạy ngon, ship luôn. Safety testing? "Để sprint sau." Sprint sau đến? "Deadline rồi, ship trước đi."

Giống hệt chuyện "kiểm tra dầu xe để tháng sau" — cho đến khi máy bốc khói giữa đường cao tốc.

Điểm nguy hiểm là nhiều team nghĩ safety = chặn một danh sách từ khóa nhạy cảm. Nhưng thực tế, một prompt hoàn toàn "sạch" vẫn có thể dẫn đến output nguy hiểm tùy ngữ cảnh. Chặn từ "súng" không giúp gì nếu người dùng hỏi bằng cách gián tiếp, bằng ẩn dụ, hay đơn giản là bằng một ngôn ngữ khác mà filter không hỗ trợ.

Thử ngay chiều nay: safety checklist 4 bước

Bạn không cần đợi bị điều tra mới nghĩ đến safety. Bốn bước sau làm được trong một buổi chiều:

Bước 1 — Brainstorm "worst-case scenarios"
Ngồi với team 30 phút, hỏi nhau: "Nếu ai đó cố tình dùng sản phẩm mình để gây hại, họ sẽ làm gì?" Viết ra hết, không filter. Cái danh sách xấu xí đó chính là bản đồ rủi ro của bạn.

Bước 2 — Đóng vai người dùng "ranh mãnh"
Tự test bằng các adversarial prompts — những câu hỏi vòng vo, gián tiếp, cố gắng khai thác bot. Chưa cần tool phức tạp, bắt đầu bằng tay là đủ.

Bước 3 — Thêm lớp safety filter
Nếu dùng API của OpenAI, họ cung cấp sẵn Moderation API (miễn phí). Với model open-source như Llama (như mình đã nhắc trong bài về self-host trợ lý AI), có thể dùng LlamaGuard hoặc Guardrails AI — cả hai đều mã nguồn mở, cài thêm một lớp kiểm duyệt trước khi output đến người dùng.

Bước 4 — Viết policy rõ ràng, bằng văn bản
Ghi ra: sản phẩm của bạn KHÔNG dùng cho mục đích gì? Khi phát hiện vi phạm, quy trình xử lý ra sao? Đừng để đến lúc xảy ra sự cố mới ngồi họp khẩn.

Luật chưa có, nhưng trách nhiệm thì đã có

Cuộc điều tra ở Florida là tín hiệu rõ ràng: chính phủ đang bắt đầu hành động, không chỉ nói. Tuy nhiên, luật pháp hiện tại hầu như chưa có khung rõ ràng cho câu hỏi "AI gây hại thì ai chịu trách nhiệm."

Đối với developer và team sản phẩm, điều này có nghĩa: bạn không thể dựa vào luật để biết mình an toàn. Bạn phải tự đặt ra tiêu chuẩn cao hơn những gì luật yêu cầu — vì khi quy định ra đời, nó thường đến kèm án phạt cho những gì đã xảy ra trước đó.

Dùng cloud API hay self-host đều có trade-off riêng: API có sẵn content filter nhưng bạn phụ thuộc vào vendor; self-host cho bạn toàn quyền kiểm soát nhưng cũng toàn quyền... gánh trách nhiệm.

Spoiler: không có silver bullet. Nhưng có một thứ luôn đúng — sản phẩm AI không có safety plan giống như xe không có phanh: chạy nhanh thật đấy, cho đến khi không dừng được.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo