PDPL 2025 — khi bot AI của bạn gửi số điện thoại khách sang một model ở Mỹ
Con bot CSKH bạn vừa dựng cho một cái spa đang làm một việc mà ít người để ý: nó gom số điện thoại, tên, lịch sử nhắn tin của khách, rồi nhét tất cả vào một câu prompt và gửi sang một model đặt ở Mỹ. Trước đây đó là chuyện kỹ thuật. Từ 2026, nó là chuyện pháp lý.
Bản tin AI tuần này có một chi tiết dễ lướt qua trong mục "Góc nhìn VN": cùng lúc với việc cộng đồng bàn về lỗ hổng tuồn dữ liệu của ChatGPT for Google Sheets (promptarmor, 01.06.2026), xu hướng giữ dữ liệu on-prem được nhắc tới như một lối thoát cho doanh nghiệp Việt — gắn thẳng với luật bảo vệ dữ liệu cá nhân, PDPL 2025 (nguồn: bản tin AI nội bộ tôi theo dõi hằng ngày, 01.06.2026).
Hai mẩu tin tưởng rời nhau, nhưng với người đang bán bot thì chúng là một: add-on AI có thể âm thầm tuồn dữ liệu ra ngoài, và bây giờ có một bộ luật quy trách nhiệm cho việc đó.
Tóm tắt cho người bận
- PDPL 2025 đổi câu hỏi. Không còn là "bot trả lời đúng không" mà là "khi dữ liệu khách đi qua model, ai chịu trách nhiệm". Câu trả lời: doanh nghiệp thu thập dữ liệu — tức bạn, hoặc cái spa bạn bán bot cho — chứ không phải hãng model.
- Add-on AI là điểm rò. Vụ ChatGPT for Sheets cho thấy một công cụ AI tiện lợi có thể tuồn dữ liệu ra URL ngoài chỉ bằng một câu lệnh giấu trong data. Mỗi lần bạn gửi prompt chứa dữ liệu khách lên dịch vụ ngoài là một lần dữ liệu rời tầm kiểm soát của bạn.
- Đây không phải gánh nặng — đây là điểm bán. "Bot của tôi không tuồn dữ liệu khách lung tung" là một lời hứa khách doanh nghiệp sẵn sàng trả tiền. Phần lớn việc tuân thủ là quyết định kiến trúc, không phải tính năng đắt tiền.
Lưu ý: tôi không phải luật sư. Bài này nói ở mức nguyên tắc thiết kế, không phải tư vấn điều khoản cụ thể. Khi triển khai thật, hãy hỏi luật sư về phạm vi PDPL áp cho trường hợp của bạn.
Điều thực sự đổi: trách nhiệm chuyển về người build
Trước khi có luật, mô hình tư duy của hầu hết người làm bot là: "tôi gọi API của OpenAI, dữ liệu khách họ xử, lỗi gì là chuyện của họ." Sai từ gốc.
Logic của một luật bảo vệ dữ liệu cá nhân kiểu PDPL gần như luôn xoay quanh một điểm: bên quyết định thu thập và dùng dữ liệu là bên chịu trách nhiệm chính. Cái spa thuê bạn dựng bot là bên đó. Còn bạn — người thiết kế hệ thống quyết định dữ liệu nào được gửi đi đâu — là người dựng nên rủi ro hoặc dập nó.
OpenAI hay Anthropic chỉ là "bên xử lý theo lệnh". Họ không phải người đứng ra trả lời khi một khách hàng hỏi "tại sao số điện thoại của tôi lại nằm trên log của một công ty Mỹ". Người trả lời là chủ spa. Và người để chuyện đó xảy ra là bạn.
Đó là sự dịch chuyển quan trọng nhất: bot không còn là sản phẩm "chạy được thì xong". Nó là một đường ống dẫn dữ liệu cá nhân, và bạn là người chịu trách nhiệm cho đường ống đó.
Góc builder: ba quyết định kiến trúc tôi đã làm
Tôi đang chạy thật một bot CSKH cho spa. Nó có một bảng leads chứa số điện thoại, tên, và lịch sử quan tâm của khách; có luồng đặt lịch, có chăm sóc sau. Đúng kiểu dữ liệu mà PDPL nhắm tới. Đây là cách tôi thiết kế để không biến nó thành quả bom.
1. Tối thiểu hoá dữ liệu gửi lên model
Nguyên tắc số một, và rẻ nhất: model không cần biết những gì nó không cần biết.
Khi bot soạn câu trả lời, nó cần ngữ cảnh hội thoại và kiến thức về dịch vụ — nó không cần số điện thoại thật của khách nằm trong prompt. Số điện thoại được lưu ở database của tôi, gắn với phiên, và chỉ dùng khi đặt lịch (gọi tool nội bộ). Nó không bao giờ phải là một dòng text trôi lên model nước ngoài.
Hỏi từng trường một câu: "model có thật sự cần cái này để trả lời không?" Phần lớn câu trả lời là không. Mỗi trường bạn giữ lại dưới đất là một rủi ro bạn không tạo ra.
2. Không nhét dữ liệu nhạy cảm vào prompt
Đây là nơi vụ ChatGPT for Sheets dạy một bài thẳng: khi dữ liệu nhạy cảm đi vào cùng dòng với chỗ AI đọc, một câu lệnh giấu trong data có thể khiến nó tuồn ra ngoài. Với bot, nguyên tắc là tách dữ liệu định danh ra khỏi nội dung gửi cho model.
Cụ thể trong bot của tôi: hội thoại đẩy lên model là nội dung chăm sóc, tư vấn dịch vụ — đã được tách khỏi định danh khách. Việc khớp "phiên này là khách nào" nằm ở tầng ứng dụng của tôi, không nằm trong prompt. Nếu một ngày log của hãng model bị lộ, thứ rò ra là "có người hỏi về liệu trình da", không phải "chị Lan, 09xx, từng hỏi về xoá xăm".
3. Cân nhắc tự host cho dữ liệu thực sự nhạy
Với phần lớn spa, gửi nội dung tư vấn (đã ẩn danh) lên model thương mại là chấp nhận được. Nhưng có những ngành — y tế, tài chính — mà bản thân nội dung đã là dữ liệu nhạy cảm. Khi đó câu hỏi "giữ data on-prem" trở thành thật, và một model mở chạy trên máy của khách là lựa chọn đáng cân.
Tôi không cổ vũ ai cũng tự host — nó là một quyết định đánh đổi (tôi đã viết riêng về kiến trúc tự host). Điểm ở đây hẹp hơn: PDPL biến "dữ liệu này có được rời khỏi VN không" thành một câu hỏi bạn phải trả lời được trước khi chọn model, chứ không phải sau khi đã deploy.
Vì sao đây là điểm bán, không phải chi phí
Đa số người dựng bot bán "bot trả lời nhanh, 24/7". Ai cũng bán được thế. Thứ khó sao chép hơn là một câu: "Bot của tôi tôn trọng dữ liệu khách của anh — tôi gửi tối thiểu, không để lộ định danh, và tôi giải thích được dữ liệu đi đâu."
Với một chủ spa vừa nghe loáng thoáng về luật dữ liệu mới và đang lo, câu đó đáng giá. Nó biến bạn từ "thằng code bot" thành "người hiểu rủi ro của tôi". Đó là khác biệt giữa một deal bán một lần và một hợp đồng trả phí hằng tháng.
Tuân thủ dữ liệu không phải phần phụ để thêm vào sau. Nó là một trong những thứ phân biệt "viết được con bot demo" và "bán được con bot cho doanh nghiệp" — đúng phần tôi dạy kỹ trong mini-course miễn phí, bắt đầu từ việc dựng con bot đầu tiên vừa chạy được vừa không biến dữ liệu khách thành rủi ro cho chính bạn.
Nguồn tham khảo (qua bản tin AI nội bộ tôi theo dõi hằng ngày): promptarmor.com (01.06.2026) và góc nhìn VN về PDPL 2025 trong bản tin 01.06.2026. Phần pháp lý chỉ nói ở mức nguyên tắc — không thay tư vấn của luật sư.