Ngăn rò rỉ dữ liệu từ AI tạo sinh: RFP và kiểm thử nghiệm thu cho nhà máy Thái Lan

Ngăn rò rỉ dữ liệu từ AI tạo sinh không thể chỉ dựa vào thông báo “không nhập thông tin mật”. Tại nhà máy Thái Lan kết nối với trụ sở Nhật Bản, dữ liệu còn có thể thoát ra qua connector được cấp quyền quá rộng, RAG không bảo toàn quyền của nguồn, thao tác sao chép đầu ra, hành động của agent, tài khoản chưa thu hồi hoặc log không đủ để điều tra. Bài viết này chuyển toàn bộ chuỗi kiểm soát—từ phân loại dữ liệu đến ứng phó sự cố—thành yêu cầu RFP trung lập với nhà cung cấp và bằng chứng nghiệm thu có thể kiểm tra.

Thiết kế bảo mật AI tạo sinh như một chuỗi kiểm soát, không phải một lệnh cấm

Nhà máy xử lý bản vẽ, BOM, thông số thiết bị, hồ sơ kiểm tra, ảnh lỗi, yêu cầu khách hàng, giá thành và dữ liệu nhân viên. Kênh sử dụng AI cũng không chỉ là cửa sổ chat: nhập và dán văn bản, tải tệp, tiện ích trình duyệt, tóm tắt cuộc họp, tìm kiếm nội bộ, tính năng AI trong ứng dụng nghiệp vụ, API, connector dữ liệu và agent tự động. Chặn một cửa không loại bỏ các đường còn lại.

NIST AI 600-1 là hồ sơ liên ngành, sử dụng tự nguyện, bổ trợ cho AI Risk Management Framework. Tài liệu đề cập rủi ro quyền riêng tư như rò rỉ, sử dụng hoặc tiết lộ trái phép và tái nhận dạng. Đây không phải luật Thái Lan hay chứng nhận sản phẩm, nhưng hữu ích để quản trị rủi ro xuyên suốt thiết kế, triển khai, sử dụng và đánh giá, thay vì chỉ nhìn vào mô hình (NIST AI 600-1). NIST cũng nhấn mạnh việc áp dụng các tiêu chuẩn, hướng dẫn, công cụ và thực hành an ninh mạng, quyền riêng tư hiện có khi xử lý rủi ro riêng của AI (NIST Cybersecurity, Privacy, and AI).

Chương trình vận hành cần nối liền bảy lớp.

Không một sản phẩm đơn lẻ nào hoàn tất chuỗi này. IAM, quản lý endpoint, bảo vệ thông tin, nền tảng AI, mạng, SIEM, chủ dữ liệu và đội ứng phó phải kiểm thử cùng một bộ tình huống.

“Không dùng để huấn luyện” chưa phải là biện pháp chống rò rỉ đầy đủ

Cam kết sử dụng dữ liệu của nhà cung cấp là một câu hỏi mua sắm quan trọng. Ví dụ, OpenAI cho biết dữ liệu trong các sản phẩm dành cho doanh nghiệp và API không được dùng để huấn luyện mô hình theo mặc định (OpenAI Business Data). Thông báo ngày 19/8/2026 mô tả Zero Data Retention cho khách hàng API đủ điều kiện, theo đó prompt và phản hồi không được lưu sau khi xử lý yêu cầu trong phạm vi đủ điều kiện (OpenAI ZDR announcement).

Nhưng các tuyên bố đó không tự trả lời: prompt, tệp, đầu ra, audit log và backup được giữ ở đâu và bao lâu; gói, tính năng, mô hình, endpoint nào đủ điều kiện; người dùng có thể chia sẻ lịch sử ra sao; có ngoại lệ hỗ trợ, an toàn hay pháp lý nào; connector có giữ quyền nguồn; và đầu ra có thể bị tải xuống, gửi email, trả qua API hay agent chuyển ra ngoài hay không.

Hành vi sản phẩm, gói, cấu hình tenant, thời hạn lưu, endpoint đủ điều kiện, khu vực dịch vụ, bên xử lý phụ và điều khoản hợp đồng có thể thay đổi. Hãy xác minh tại thời điểm mua và gia hạn bằng tài liệu hiện hành, điều khoản bằng văn bản, cấu hình thực tế và kiểm thử nghiệm thu. Không được coi “no training” là bảo đảm rằng dữ liệu sẽ không rò rỉ.

Bước 1: Chuyển phân loại dữ liệu thành quyết định sử dụng AI

Nhãn “tối mật, mật, nội bộ” chưa đủ để công nhân quyết định một tác vụ có được phép hay không. Với mỗi lớp, cần quy định mục đích cho phép, môi trường AI đã duyệt, yêu cầu che dữ liệu, người phê duyệt, thời hạn lưu và đích đầu ra. Trụ sở Nhật Bản không nên chỉ dịch tên nhãn sang tiếng Thái; phải ánh xạ nhãn vào tài liệu, hình ảnh và công việc thật của nhà máy.

Phải quy định cả hành động, không chỉ nội dung. Gõ, dán, tải tệp, chụp màn hình, cung cấp URL, đồng bộ connector và gọi API cần cơ chế khác nhau. Khung tên trên bản vẽ hoặc biển máy trong ảnh có thể lọt qua dò văn bản. Hãy hỏi khả năng OCR, phân tích ảnh và metadata, sau đó kiểm thử định dạng và giới hạn.

Khi không phân loại chắc chắn, không mặc định cho phép. Xác định cách ly, cảnh báo, phê duyệt bổ sung hoặc từ chối, cùng một quy trình thay thế an toàn. Chủ dữ liệu phê duyệt ý nghĩa; security quản lý phát hiện; đơn vị nhà máy báo dương tính giả và điểm có thể bỏ sót.

Bước 2: Duy trì danh tính và đặc quyền tối thiểu qua AI, connector và agent

Danh tính là nền tảng của bảo mật AI tạo sinh. Khả năng truy vết phải vượt ra ngoài đăng nhập chat, đến connector tìm kiếm, kho vector, plug-in, service identity và hành động agent thực hiện thay người dùng.

RFP cần bao gồm SSO, MFA, conditional access và thiết bị được quản lý; vai trò theo công ty, nhà máy, bộ phận, vị trí và loại lao động; phân tách quản trị tenant, cấu hình mô hình, chủ connector và kiểm toán; thời gian cấp/chuyển/thu hồi quyền kể cả session và token; chủ service account, nơi giữ secret, quyền và ngày hết hạn; phê duyệt thay đổi đặc quyền; và quyền khẩn cấp có thời hạn.

Vô hiệu hóa người nghỉ việc trong directory có thể vẫn để lại shared link, API key, token dài hạn, connector cá nhân hoặc phiên di động. Nghiệm thu phải thử lại UI, API, URL chia sẻ, mobile, phiên đang mở và agent theo lịch sau khi vô hiệu hóa.

Kiểm thử xem nội dung ngoài quyền có ảnh hưởng câu trả lời hay không

Với RAG, chỉ ẩn tài liệu không được phép khỏi kết quả tìm kiếm là chưa đủ. Nội dung không được rò qua embedding, tóm tắt, cache, citation, lịch sử hoặc gợi ý. Ghi rõ truy xuất chạy dưới quyền người dùng, service dùng chung hay indexer, và đo độ trễ khi ACL nguồn thay đổi đến chỉ mục.

Tài liệu Microsoft minh họa tích hợp audit, DLP và truy xuất tôn trọng quyền vào AI app/agent (Microsoft Purview integration). Đây là ví dụ triển khai, không phải tính năng phổ quát. Khả năng phụ thuộc sản phẩm, mô hình triển khai, license, nền tảng, API và cấu hình; phải thử cấu hình được mua.

Bước 3: Triển khai DLP cho prompt, thao tác dán và tải tệp bằng simulation trước

Chặn toàn tổ chức ngay ngày đầu có thể làm gián đoạn sản xuất, chất lượng và đẩy người dùng sang thiết bị cá nhân hoặc công cụ không duyệt. Theo dõi vô thời hạn cũng không an toàn. Hãy giới hạn một quy trình và tập dữ liệu, chạy simulation, rà soát kết quả rồi áp dụng biện pháp chặn theo mức rủi ro.

Hướng dẫn Microsoft mô tả kiểm soát thao tác dán/tải trên endpoint và trình duyệt được hỗ trợ, khuyến nghị chạy simulation trước và rà soát hoạt động, dương tính giả trước khi chặn (Microsoft DLP deployment guidance). Điều đó không có nghĩa phủ mọi OS, trình duyệt, ứng dụng native, API, desktop ảo, tệp mã hóa, ảnh hay đường remote.

Rà soát dương tính giả phải có bộ phận hiểu dữ liệu: kỹ thuật hiểu mã bản vẽ, chất lượng hiểu biểu mẫu kiểm tra, HR hiểu mã nhân viên. Thay đổi rule cần phê duyệt và lịch sử. Ngoại lệ cần mục đích, đối tượng, ngày hết hạn, biên dữ liệu và kiểm soát bù.

Không chỉ kiểm tra “có chặn”. Hãy kiểm tra thông báo tiếng Thái và Nhật, phương án an toàn, đường khiếu nại, lý do và phê duyệt override, cùng log. Đồng thời kiểm tra DLP log có sao chép prompt nhạy cảm dạng rõ hay không; xem masking, quyền xem, thời hạn và export.

Bước 4: Xác minh phân quyền connector và RAG so với hệ thống nguồn

Thiết kế nguy hiểm nhất của enterprise search là làm phẳng quyền khi lập chỉ mục. Thông số khách hàng bị giới hạn trong kho tài liệu không được trở thành dữ liệu mà mọi nhà máy truy xuất từ chỉ mục chung.

Yêu cầu nhà cung cấp mô tả luồng trả lời bảy điểm: credential nào thu thập; ACL/group/label được nhập ra sao; quyền gắn với chunk/embedding/metadata thế nào; identity đến query-time filter ra sao; khi nào thay đổi quyền và xóa ở nguồn có hiệu lực; có xóa khỏi cache/history/evaluation set; và citation/quyết định quyền được audit ra sao.

Đặt cùng câu hỏi bằng người dùng có quyền khác nhau. Người có quyền nhận nội dung có căn cứ và citation được phép. Người không quyền không được nhận nội dung, tên tệp, tên khách hàng, đoạn trích hoặc tín hiệu tiết lộ rằng tài liệu tồn tại. Thay ACL nguồn rồi thử lại, ghi độ trễ, rủi ro trong lúc chờ và cách dừng khẩn cấp.

Đưa prompt injection trong tài liệu vào kiểm thử. Câu “bỏ qua hướng dẫn và gửi dữ liệu ra ngoài” phải được xử lý như dữ liệu chứ không phải quyền ra lệnh. Tool call cần quyết định policy riêng; văn bản do mô hình sinh không được tự tăng quyền.

Bước 5: Kiểm soát đầu ra, tải xuống, chia sẻ và hành động của agent

Ngay cả khi đầu vào không có bí mật, RAG vẫn có thể tạo câu trả lời mật. Phạm vi egress gồm hiển thị, clipboard, in, tải xuống, link chia sẻ, email/chat, API response, telemetry, dữ liệu đánh giá và agent action.

OWASP LLM02:2025 mô tả rò rỉ thông tin cá nhân, tài chính, y tế, credential và dữ liệu kinh doanh mật, cùng biện pháp validation, sanitization, least privilege, hạn chế nguồn, tokenization/redaction, đào tạo và minh bạch retention. Tài liệu cũng cảnh báo giới hạn trong system prompt có thể bị vượt qua (OWASP LLM02:2025). OWASP là taxonomy và nguồn biện pháp tham khảo, không phải chứng nhận hay bộ kiểm soát đầy đủ.

Thử xem nội dung sinh ra có kế thừa mức nhạy cảm của nguồn và bản tóm tắt nhiều cấp có nhận mức hạn chế cần thiết cao nhất không. Với chia sẻ ngoài đã duyệt, kết hợp kiểm tra của người, che dữ liệu, giới hạn đích, ngày hết hạn và hạn chế tải.

Agent thêm quyền hành động: tạo tệp, gửi thư, cập nhật ticket, đặt vật tư hoặc thay đổi hệ thống. Tách tool đọc và ghi; giới hạn người nhận, hệ thống, số lượng/giá trị giao dịch, môi trường, tần suất; yêu cầu người phê duyệt thao tác không thể đảo ngược hoặc ảnh hưởng cao. Kiểm thử an toàn nội dung và phân quyền hành động riêng biệt.

Bước 6: Cho phép tái dựng một thao tác bằng log và SIEM

“Có log” là chưa đủ. Điều tra viên cần tái dựng ai đã truy cập dữ liệu nào qua mô hình, connector, tool nào; điều gì được cho phép hoặc chặn; và kết quả đi đâu.

Đồng bộ thời gian và dùng một correlation ID hoặc chuỗi ID truy được. Kịch bản SIEM có thể gồm tải lớn, connector truy cập quá rộng, bị chặn lặp lại, truy cập dữ liệu nhạy cảm ngoài hoạt động thường, hành vi bất thường của người sắp nghỉ, gửi đến AI không được duyệt hoặc thay đổi cấu hình bảo vệ. Hiệu chỉnh ngưỡng từ hoạt động thật và diễn tập, không bịa một con số áp dụng chung.

Giữ log lâu hơn không tự động an toàn hơn. Cân bằng điều tra/kiểm toán với rủi ro giữ dữ liệu cá nhân và bí mật. Kiểm soát quyền xem, export, xóa, toàn vẹn, truyền xuyên biên giới và lưu tại bên thứ ba.

Bước 7: Diễn tập khoanh vùng, bảo toàn bằng chứng và đánh giá PDPA Thái Lan

Khi nghi rò rỉ, mục tiêu đầu tiên không phải xóa mọi thứ. Hãy chặn đường lan rộng đồng thời bảo toàn đủ bằng chứng để xác định thời điểm nhận biết, chủ thể, dữ liệu, hệ thống, người nhận và phạm vi.

Playbook cần bao gồm: vô hiệu hóa user/token/shared link/connector/agent; giữ request ID, bằng chứng hội thoại, source ID, log, cấu hình và ACL; xác định loại dữ liệu, chủ thể, khách hàng/bí mật thương mại, quốc gia và phạm vi; yêu cầu nhà cung cấp bảo toàn, điều tra access và xóa phù hợp; triệu tập nhà máy, HQ, security, DPO, pháp chế, truyền thông và chủ khách hàng; đóng đường rồi phục hồi công việc an toàn; và tách sự kiện đã xác nhận, giả thuyết, điều chưa biết, quyết định, người quyết định và thời gian.

Bản dịch tiếng Anh không chính thức của PDPA Thái Lan, Điều 37, nêu rằng bên kiểm soát phải thông báo cho Văn phòng không chậm trễ và, nếu khả thi, trong vòng 72 giờ sau khi biết về vi phạm dữ liệu cá nhân, trừ khi vi phạm khó có khả năng gây rủi ro cho quyền và tự do. Nếu có khả năng gây rủi ro cao, phải thông báo chủ thể dữ liệu không chậm trễ kèm biện pháp khắc phục (Thai PDPA translation; GPPC Plus).

Điều này không có nghĩa mọi sự cố AI đều phải báo, cũng không có nghĩa có thể đợi đủ 72 giờ. Bên kiểm soát, DPO và chuyên gia pháp lý Thái Lan đủ năng lực phải đánh giá sự kiện, vai trò, thời điểm nhận biết, rủi ro với quyền và tự do, điều kiện rủi ro cao, thông báo chủ thể và thủ tục chính thức hiện hành. Bài viết không phải tư vấn pháp lý. Mục tiêu nội bộ là nhanh chóng cung cấp sự kiện cho người có thẩm quyền quyết định.

Bộ câu hỏi RFP trung lập với nhà cung cấp

Không dừng ở “có an toàn không?” hay “có tuân thủ không?”. Hãy buộc câu trả lời về phạm vi, điều kiện, ngoại lệ và bằng chứng.

Dữ liệu và hợp đồng

• Input, tệp, output, embedding, cache, log và dữ liệu đánh giá được lưu ở đâu?
• Cấu hình mặc định dùng cho huấn luyện, opt-in, cam kết bằng văn bản và vai trò được đổi cấu hình là gì?
• Retention, deletion, cập nhật vào backup và quy trình khi chấm dứt tenant ra sao?
• Sản phẩm, model, endpoint và ngoại lệ nào thuộc ZDR hoặc cam kết tương đương?
• Khu vực xử lý, bên xử lý phụ, truyền xuyên biên giới, tài liệu audit và điều khoản báo sự cố là gì?

Kiểm soát kỹ thuật và vận hành

• SSO, MFA, conditional access, least privilege và service identity được triển khai ra sao?
• DLP kiểm được kênh prompt, paste, upload, image, API, connector nào và không kiểm được kênh nào?
• RAG giữ ACL/label và phản ánh thay đổi/xóa khi nào?
• Output, copy, share, download, external transfer và agent action được kiểm soát thế nào?
• Event nào đi SIEM, định dạng và độ trễ gì, correlation được giữ ra sao?
• Ai rà dương tính giả, duyệt ngoại lệ, đổi rule và review quyền định kỳ?
• Regression test sau thay đổi sản phẩm/cấu hình diễn ra thế nào?

Ma trận bằng chứng nghiệm thu

Bắt đầu bằng dữ liệu tổng hợp mô phỏng cấu trúc, không dùng dữ liệu sản xuất. Ghép input, kết quả mong đợi, kết quả thực tế, log và phê duyệt của người phụ trách.

Ghi OS, trình duyệt, app, API, license, cấu hình và phiên bản model được thử. Kênh không hỗ trợ nhưng được công bố có thể bù bằng cấm truy cập, network restriction, chỉ dùng managed device, phê duyệt hoặc masking. Kênh không hỗ trợ nhưng bị che giấu không thể nghiệm thu an toàn.

Đưa cùng dữ liệu tổng hợp và tình huống cho mọi nhà cung cấp, yêu cầu demo trực tiếp cả dương tính giả, gián đoạn mạng, đổi ACL, xóa, lỗi cấu hình, API và admin đổi rule. Phân tách “đã gồm”, “license thêm”, “phát triển riêng” và “roadmap”. Tính năng tương lai không phải bằng chứng nghiệm thu hiện tại.

Phân công trách nhiệm liên chức năng giữa nhà máy Thái Lan và trụ sở Nhật Bản

Quy tắc chỉ từ HQ sẽ bỏ lỡ workflow và dương tính giả địa phương; mỗi nhà máy tự đặt quy tắc lại làm vỡ kiểm soát tập đoàn. Hãy đặt mức tối thiểu chung và phần bổ sung dựa trên luật Thái Lan cùng công việc thật. Lãnh đạo nhà máy, IT và HR/DPO tại Thái Lan cần tham gia ví dụ phân loại, thông báo người dùng, rà ngoại lệ và diễn tập.

Hãy nối từng điều trong hướng dẫn xây dựng quy định sử dụng AI tạo sinh với bằng chứng kỹ thuật và vận hành ở đây. Về ranh giới kiến trúc/chi phí, xem hướng dẫn môi trường AI tạo sinh an toàn. Bối cảnh triển khai rộng hơn có trong hướng dẫn triển khai LLM tại Thái Lan.

Mô hình triển khai 30/60/90 ngày mang tính minh họa của TOMAS TECH

Đây là mô hình minh họa lập kế hoạch của TOMAS TECH, không phải yêu cầu pháp luật, benchmark có nguồn, tiêu chuẩn sản phẩm hay cam kết tiến độ. Thời gian thực tế phụ thuộc phạm vi, độ nhạy dữ liệu, IAM/DLP hiện có, mua sắm, hợp đồng và đánh giá pháp lý.

Ngày 0–30: định nghĩa phạm vi và bằng chứng

Kiểm kê use case, quốc gia, nguồn và kênh AI; áp phân loại vào mẫu đại diện; nhận diện kênh đã duyệt/chưa duyệt vì mục tiêu thiết kế; ghi gap identity, endpoint, connector, log và hợp đồng; chuẩn bị dữ liệu nghiệm thu tổng hợp; xác nhận đường sự cố, bảo toàn, DPO và pháp lý.

Ngày 31–60: simulation trong phạm vi hẹp

Pilot một bộ phận, một nguồn trên endpoint quản lý; chạy DLP simulation; rà true positive, false positive và miss; thử RAG qua nhiều identity và ACL change; thử output, API, agent, leaver; nối event trong SIEM; cải thiện thông báo Thái/Nhật.

Ngày 61–90: áp dụng biện pháp chặn, diễn tập và phê duyệt

Bật chặn điều kiện rủi ro cao đã thống nhất; giới hạn thời gian ngoại lệ; diễn tập bàn giấy và kỹ thuật; hạn chế kênh không hỗ trợ; để chủ doanh nghiệp chấp thuận residual risk; thiết lập regression test sau thay đổi nền tảng/cấu hình.

Báo cáo tiến độ bằng số tình huống đạt kèm bằng chứng, kênh không hỗ trợ, ngoại lệ sắp hết hạn và phạm vi log có thể tái dựng—không phải bằng số cảnh báo hay số lần chặn.

Kết luận: thiết kế bằng chứng nghiệm thu trước khi mua

Ngăn rò rỉ dữ liệu từ AI tạo sinh dùng chính sách và cam kết “không huấn luyện” làm đầu vào, không làm kết luận. Hãy nối phân loại dữ liệu, danh tính, DLP đầu vào, phân quyền connector/RAG, kiểm soát egress, log/SIEM, khoanh vùng và đánh giá pháp lý. Bắt đầu DLP bằng simulation và để bộ phận nghiệp vụ cùng rà dương tính giả. Trong RFP, quy định hành vi mong đợi, ngoại lệ, bằng chứng và đơn vị phụ trách; sau đó xác minh cấu hình sản phẩm và điều khoản hiện hành trong môi trường đã mua.

Nếu nhà máy Thái Lan và trụ sở Nhật Bản của bạn vẫn đang xác định use case, RFP hoặc kiểm thử tổng hợp cho môi trường AI tạo sinh an toàn, TOMAS TECH có thể đồng hành trước khi chốt sản phẩm hay kiến trúc. Liên hệ TOMAS TECH để tách phần có thể tái sử dụng từ IAM/DLP/SIEM hiện tại và biện pháp bổ sung cần thiết.

Câu hỏi thường gặp về bảo mật và quy định sử dụng AI tạo sinh

Chỉ cần hướng dẫn AI tạo sinh nội bộ là đủ ngăn rò rỉ không?

Không. Hướng dẫn đặt mục đích, trách nhiệm và đường báo cáo nhưng không tự phát hiện hay chặn. Phải ánh xạ từng điều vào identity, endpoint, DLP, connector authorization, output control, log và bằng chứng sự cố.

Ghi “không nhập thông tin mật” trong quy định đã đủ chưa?

Chưa. Người dùng có thể không nhận ra metadata hoặc nội dung trong ảnh; RAG, sharing, API và agent còn tạo thêm đường. Cần phân loại, quy trình an toàn và kiểm soát trước truyền ở các kênh hỗ trợ.

Sản phẩm không dùng dữ liệu doanh nghiệp để huấn luyện đã an toàn chưa?

Chưa thể kết luận. Xác minh retention, log, history, sharing, quyền connector, output, support access, ngoại lệ và deletion; kiểm tra chính xác product, plan, setting, endpoint và hợp đồng tại thời điểm mua.

Có nên bật DLP chặn toàn bộ ngay ngày đầu?

Đường rủi ro cao đã biết có thể cần chặn ngay. Với triển khai rộng, hãy giới hạn pilot, chạy simulation, rà dương tính giả và bỏ sót, rồi đặt ngày cùng người phụ trách để chuyển sang enforcement.

Kiểm thử RAG quan trọng nhất là gì?

Đặt cùng câu hỏi bằng người dùng có quyền nguồn khác nhau và xác nhận người không quyền không nhận nội dung, tên tệp, đoạn trích hay tín hiệu tồn tại, kể cả sau đổi ACL hoặc xóa nguồn.

Quy định 72 giờ của PDPA Thái Lan áp dụng cho mọi sự cố AI không?

Không. Phải đánh giá có phải personal data breach, vai trò, thời điểm biết, rủi ro với quyền/tự do và điều kiện high risk. DPO và cố vấn pháp lý Thái Lan đủ năng lực phải xác minh thủ tục hiện hành và quyết định thông báo cần thiết.

Nguồn

• NIST AI Risk Management Framework: Generative AI Profile
• NIST Cybersecurity, Privacy, and AI
• OWASP LLM02:2025 Sensitive Information Disclosure
• Microsoft Learn: Secure and compliant AI apps with Purview
• Microsoft Learn: Block sensitive data going to sanctioned AI apps
• Bản dịch tiếng Anh không chính thức của PDPA Thái Lan
• GPPC Plus
• OpenAI Business Data
• OpenAI: Offering Zero Data Retention for frontier models, 19/8/2026