“Nội quy lao động mới nhất là bản nào?” “Phải xin nghỉ trước bao nhiêu ngày?” “Điều kiện phụ cấp của nhân viên Thái và nhân viên biệt phái người Nhật có khác nhau không?” AI tìm kiếm quy định nội bộ có thể giảm câu hỏi lặp lại và là một ứng dụng Generative AI dễ chứng minh giá trị. Nhưng đưa một thư mục PDF vào hệ thống rồi nhận câu trả lời trôi chảy chưa phải là thiết kế vận hành. Cần xác định bản nào được tìm, câu trả lời đúng tại thời điểm nào, người hỏi có quyền gì, bằng chứng nào được trích dẫn và từ đâu phải chuyển sang người phê duyệt. Bài viết chuyển các điểm đó thành yêu cầu RFP, PoC và kiểm thử nghiệm thu cho doanh nghiệp tại Thái Lan và ASEAN.
Xem AI tìm kiếm quy định là công cụ dẫn đường, không phải người ra quyết định
Nhiệm vụ của hệ thống là tìm đoạn liên quan trong tài liệu còn hiệu lực mà người dùng được phép đọc, rồi đưa ra dự thảo câu trả lời kèm bằng chứng. Hệ thống không được tự tạo ngoại lệ hay quyết định vấn đề nhân sự.
“Hạn nộp đơn nghỉ phép là khi nào?” là câu hỏi tra cứu. “Có nên chấp thuận đơn muộn vì hoàn cảnh gia đình không?” là quyết định phê duyệt. Cùng một cửa sổ chat có thể nhận cả hai, nhưng câu đầu phải trả bằng điều khoản; câu sau phải chuyển cho người phụ trách được chỉ định.
Để hiểu cơ chế RAG, tìm kiếm đa ngôn ngữ và các lớp chi phí, xem Xây dựng hệ thống RAG cho nhà máy. Về kênh, ngôn ngữ và lộ trình triển khai, xem Triển khai chatbot đa ngôn ngữ trong nhà máy. Bài này tập trung vào tài liệu được kiểm soát, nơi dùng nhầm phiên bản hoặc rò rỉ quyền truy cập gây hậu quả thực tế.
Vì sao tìm kiếm toàn văn thông thường chưa đủ
Tìm theo từ khóa hiệu quả khi câu hỏi và tài liệu dùng cùng thuật ngữ. Ở một công ty Nhật tại Thái Lan, nhân viên có thể hỏi bằng tiếng Thái trong khi bản chính là tiếng Anh và thông báo bổ sung là tiếng Nhật. Truy xuất theo ngữ nghĩa và phần giải thích do AI tạo giúp xử lý cách diễn đạt khác nhau và câu hỏi xuyên ngôn ngữ.
Nhưng sự trôi chảy cũng khiến nội dung thiếu căn cứ có vẻ đáng tin. Vì vậy, “hội thoại tự nhiên” không thể là tiêu chí nghiệm thu duy nhất. Phải kiểm tra riêng: có lấy đúng tài liệu không, có loại bản hết hiệu lực không, nội dung hạn chế có hoàn toàn vô hình không, trích dẫn có hỗ trợ câu trả lời không, và kết luận có đúng không.
Phần lớn lỗi bắt đầu từ trạng thái tài liệu, không phải mô hình
Một PoC trả lời đúng mười câu trình diễn vẫn có thể không an toàn. Dữ liệu thật thường có bản cũ và mới trong cùng thư mục, thông báo nhà máy chỉ hiệu lực ngắn, ngoại lệ nằm ở chú thích bảng và PDF tiếng Thái bị OCR sai.
Quản lý mỗi tài liệu như một hồ sơ được kiểm soát
| Trường | Ví dụ | Mục đích khi truy vấn |
|---|---|---|
| Mã tài liệu | HR-LEAVE-001 | Theo dõi dù đổi tên tệp |
| Phiên bản | Rev. 4 | Xác định ưu tiên so với bản cũ |
| Ngày hiệu lực | 2026-07-01 | Xác định giá trị tại ngày trả lời |
| Ngày hết hiệu lực | trống hoặc 2026-06-30 | Tách hiện hành và lịch sử |
| Pháp nhân/địa điểm | TH01 / Bangkok HQ | Không trộn quy định khác công ty |
| Đối tượng | nhân viên, nhà thầu, nhân viên biệt phái (người Nhật) | Giới hạn phạm vi áp dụng |
| Ngôn ngữ chính thức | Thai / English | Phân biệt bản chính và bản dịch |
| Người phê duyệt | HR Director | Xác nhận tình trạng kiểm soát |
| Phân loại | Internal / HR Restricted | Đưa vào kiểm soát quyền |
| URL nguồn | liên kết DMS bền vững | Cho phép xem bản gốc |
Một thư mục tên “latest” không thay thế metadata. DMS hoặc SharePoint phải là nguồn chuẩn; chỉ mục tìm kiếm là dữ liệu phái sinh phải theo kịp sửa đổi và hủy bỏ.
Luôn hiển thị thời điểm của câu trả lời
Hiển thị “Tính đến ngày 2/9/2026” và “Dựa trên HR-LEAVE-001 Rev.4, hiệu lực 1/7/2026”. Nếu hỗ trợ tra cứu lịch sử, giao diện phải tách rõ với tìm kiếm hiện hành.
Nhật ký nên lưu thời gian câu hỏi, mã và phiên bản tài liệu, đoạn đã truy xuất, thời điểm cập nhật chỉ mục và phiên bản dịch vụ trả lời. Nhờ đó có thể phân biệt câu trả lời đúng tại thời điểm cũ với lỗi hệ thống.
Thiết kế AI tìm kiếm tri thức với phân quyền trước khi truy xuất
Kiến trúc an toàn tách xác thực, phân quyền, truy xuất, sinh câu trả lời và kiểm toán. Sau đăng nhập, lớp định danh chỉ cung cấp thuộc tính hoặc nhóm cần thiết như pháp nhân, địa điểm, phòng ban, loại hợp đồng và vai trò. Lớp tìm kiếm chỉ chọn tài liệu được phép, rồi mới gửi các đoạn đó đến mô hình.
Tìm tất cả rồi che sau là quá muộn
Khi nội dung hạn chế đã vào mô hình, nó có thể còn trong kết quả, trace, log hoặc cache. Kiểm tra quyền phải diễn ra trước hoặc trong bước truy xuất.
Tài liệu chính thức của Microsoft, cập nhật trong tháng 8/2026, mô tả security filter đối chiếu user/group với quyền trên tài liệu. Tài liệu cũng ghi rõ một số cách ACL/RBAC/Purview trong API 2026-08-01-preview vẫn là preview và thay đổi quyền bên ngoài có thể phản ánh chậm. Kết luận không phải “dùng Azure là tự động an toàn”. Với bất kỳ nền tảng nào, hãy nêu nguồn quyền, chu kỳ đồng bộ, chế độ lỗi và bằng chứng nghiệm thu.
OWASP LLM08:2025 nêu nguy cơ truy cập trái phép, rò rỉ chéo ngữ cảnh và đầu độc dữ liệu trong RAG; biện pháp gồm kho vector nhận biết quyền, xác thực nguồn, phân loại và giám sát. Embedding không phải những con số vô hại; phải quản trị như nội dung nguồn.
Điều kiện nghiệm thu cho security trimming
- Tài liệu không được phép không xuất hiện trong ứng viên, trích dẫn, tóm tắt hay lịch sử hội thoại.
- Chuyển phòng ban và xóa nhóm phải phản ánh trong thời gian đã thỏa thuận.
- Nếu tra cứu định danh/quyền thất bại, phải trả 0 kết quả hoặc lỗi an toàn, không trả toàn bộ.
- Quyền debug của quản trị viên phải tách khỏi dùng thường và được kiểm toán.
- Xóa nguồn phải kéo theo chunk, embedding, cache và dữ liệu liên quan.
Thay “gần thời gian thực” bằng “trong 15 phút”, “0 kết quả khi kiểm tra quyền lỗi” và “từ chối ngay tài khoản đã vô hiệu hóa”.
Thiết kế trích dẫn theo phiên bản và đoạn, không chỉ theo liên kết
Liên kết đến trang đầu của tài liệu 40 trang không đủ để kiểm chứng. Kết quả nên nêu tên, mã, phiên bản, ngày hiệu lực, điều/trang, đoạn hỗ trợ và liên kết nguồn.
| Lớp đánh giá | Câu hỏi | Chỉ số ví dụ |
|---|---|---|
| Retrieval | Có lấy đúng bằng chứng không? | Recall@k, tài liệu đúng trong top k |
| Grounding | Mỗi khẳng định có được nguồn hỗ trợ không? | tỷ lệ hỗ trợ và nhất quán trích dẫn |
| Answer | Có trả lời đúng nhu cầu không? | đúng, một phần, từ chối, sai |
Nếu tài liệu đúng đã được lấy nhưng câu trả lời sai, kiểm tra prompt và cách ghép context. Nếu truy xuất bỏ sót, sửa chunk, metadata, OCR, dịch truy vấn hoặc ranking. Đổi mô hình mà không chẩn đoán chỉ làm lỗi cũ đắt hơn.
“Không xác định được” có thể là kết quả đúng
Nếu không có quy định truy cập được nói về thưởng sau ba năm, câu trả lời an toàn là không xác nhận và chuyển HR. Bộ test phải có câu không có đáp án, thiếu điều kiện và tài liệu mâu thuẫn. Ba kết quả hợp lệ là trả lời, hỏi lại an toàn hoặc chuyển người phụ trách.
Xác định ranh giới phê duyệt cho chatbot nội quy lao động
| Câu hỏi/quy trình | Vai trò AI | Vai trò con người |
|---|---|---|
| Hạn xin nghỉ | Trích điều khoản có hiệu lực | Nêu nơi xin ngoại lệ |
| Điều kiện phụ cấp chung | Xác nhận đối tượng và trích quy định | Chốt áp dụng cá nhân |
| Kỷ luật, sa thải, quấy rối | Chỉ kênh bảo mật và quy định | HR/pháp chế quyết định |
| Số liệu lương cá nhân | Điều hướng sang API xác thực riêng | Duyệt sửa hoặc ngoại lệ |
| Quy tắc an toàn nhà máy | Hiển thị quy trình và nguồn | Quản lý quyết định dừng/chạy |
| Dự thảo sửa quy định | So sánh và nêu tác động | Lao động, pháp chế, quản lý duyệt |
Câu hỏi về kỷ luật, sức khỏe, công đoàn, đánh giá hoặc sa thải có thể khiến log trở nên nhạy cảm. Không giữ toàn bộ hội thoại vô thời hạn với lý do “cải tiến”. Hãy định nghĩa mục đích, người xem, thời hạn, masking và xóa.
Tách ngôn ngữ bản chính và ngôn ngữ giải thích
Người dùng Thái có thể hỏi tài liệu Nhật hoặc Anh. Hiển thị ngôn ngữ nguồn, ngôn ngữ giải thích và trạng thái bản dịch. Bản dịch tham khảo không được trông có giá trị cao hơn bản được phê duyệt. Duy trì bảng thuật ngữ được HR hoặc cố vấn địa phương duyệt cho probation, severance pay và working day.
PDPA của Thái Lan là bài toán luồng dữ liệu, không chỉ là chọn cloud
PDPA của Thái Lan áp dụng với thông tin nhận diện cá nhân trực tiếp hoặc gián tiếp. Nội quy chung có thể không có dữ liệu cá nhân, nhưng phụ lục có tên; người hỏi có thể nhập sức khỏe hay hoàn cảnh gia đình; log có thể gắn employee ID với chủ đề nhạy cảm.
Hãy vẽ luồng dữ liệu: tài liệu đến từ đâu; OCR, embedding, chỉ mục và inference ở đâu; ai xem câu hỏi, câu trả lời, feedback, log và khi nào xóa; processor/subprocessor nào tham gia; dữ liệu có được dùng để cải thiện dịch vụ không. Cơ sở pháp lý, notice, điều khoản xử lý, chuyển ra nước ngoài, retention và quyền chủ thể phải được DPO hoặc cố vấn luật Thái đánh giá theo thiết kế thật. Bài viết này không chứng nhận kiến trúc nào tuân thủ PDPA.
Generative AI Governance Guideline for Organizations của ETDA tháng 8/2024 xem lợi ích, giới hạn, rủi ro, triển khai và quản trị trong cùng một vòng đời. Ngày 1/7/2026, ETDA tiếp tục nhấn mạnh đánh giá, kiểm thử, kiểm toán và cải tiến liên tục. Với tìm kiếm quy định, cần biến chính sách trên giấy thành test rò quyền, rà soát câu trả lời sai và đo thời gian cập nhật phiên bản.
Biến PoC từ demo trả lời thành kiểm thử nghiệm thu
PoC phải giảm bất định trong phạm vi kiểm soát. Chốt phòng ban, tài liệu, người dùng, ngôn ngữ và quyết định bị loại trừ; thống nhất tiêu chí đậu/rớt trước khi xây.
Bộ test phải gồm câu đơn giản, câu nhiều điều kiện, bảng/chú thích/phụ lục, câu tiếng Thái với tài liệu tiếng Nhật, câu mà bản cũ trả lời khác, cặp có quyền/không quyền, câu không có đáp án, việc cần con người quyết định, viết tắt/lỗi chính tả và prompt injection nằm trong tài liệu. Mỗi câu có tài liệu/phiên bản mong đợi, câu chấp nhận, câu cấm, yêu cầu hỏi lại và người nhận chuyển tiếp.
Ví dụ chỉ số nghiệm thu
Các số dưới đây chỉ là thiết kế minh họa cho PoC 100 câu, không phải chuẩn ngành.
| Chỉ số | Ngưỡng ví dụ | Ghi chú |
|---|---|---|
| Tài liệu đúng trong top 5 | ít nhất 95% | đo retrieval |
| Trích dẫn hỗ trợ câu trả lời | ít nhất 95% | chấm từng khẳng định |
| Câu sai nghiêm trọng | 0 | quyền, kỷ luật, an toàn |
| Rò quyền | 0 | một lần là không đạt |
| Xử lý an toàn câu không đáp án | ít nhất 90% | gồm chuyển tiếp |
| Cập nhật phiên bản | trong 30 phút | SLA ví dụ |
| Thời gian P95 | trong 8 giây | điều kiện mạng cố định |
Độ chính xác tổng 95% có thể che năm lỗi nguy hiểm. Phải phân mức độ; lỗi nghiêm trọng và rò quyền là zero tolerance.
NIST AI 600-1 là khung tự nguyện, không phải luật Thái. Có thể chuyển thành chu trình: Govern xác định chủ sở hữu, cấm dùng và thay đổi; Map hiểu người dùng, tài liệu, luồng và tác động; Measure đo câu trả lời, bằng chứng, quyền, từ chối, tốc độ, ngôn ngữ; Manage ưu tiên theo mức độ và quy trình dừng, sửa, test lại. Không chỉ ghi “NIST-aligned”; hãy yêu cầu ai kiểm bằng chứng nào, khi nào.
Yêu cầu nên có trong RFP
| Mảng | Yêu cầu | Bằng chứng nghiệm thu |
|---|---|---|
| Kiểm soát tài liệu | phiên bản, ngày hiệu lực/hết hạn, site, đối tượng | sổ đăng ký và log test cập nhật |
| Phân quyền | quyền nguồn áp dụng khi truy vấn, fail closed | negative test theo vai trò |
| Bằng chứng | điều/trang/phiên bản/URL nguồn | ma trận câu trả lời-trích dẫn |
| Đa ngôn ngữ | đánh giá khi ngôn ngữ hỏi khác nguồn | điểm theo ngôn ngữ và danh sách lỗi |
| Từ chối an toàn | phân biệt thiếu nguồn, thiếu quyền, thiếu ngữ cảnh | kết quả refusal test |
| Kiểm toán | truy dấu phiên bản, truy xuất, câu trả lời, người, thời gian | log mẫu đã masking |
| Vận hành | sửa, xóa, sự cố, đổi mô hình | runbook và diễn tập khôi phục |
| Bảo vệ dữ liệu | vị trí, processor, mã hóa, retention, xóa | data flow và bộ hợp đồng |
“Độ chính xác trên 90%” không so sánh được nếu thiếu tập câu hỏi, cách chấm, ngôn ngữ và độ khó. Với tính năng preview, yêu cầu phương án dự phòng, giả định chi phí thay đổi và giới hạn đồng bộ quyền.
PoC tám tuần và mô hình chi phí minh bạch
Ví dụ giả định một site, ba ngôn ngữ, 300 tệp quy định và 50 người dùng. Đây không phải bảng giá TOMAS TECH hay số liệu thị trường.
| Tuần | Công việc | Điều kiện hoàn tất |
|---|---|---|
| 1 | phạm vi, cấm dùng, chủ sở hữu, data flow | duyệt phạm vi và ranh giới |
| 2 | kiểm kê, metadata phiên bản/quyền | sổ nguồn và danh sách loại trừ |
| 3 | OCR, chunk, glossary, index | tìm được tài liệu đại diện |
| 4 | identity, trimming, giao diện citation | test vai trò đạt |
| 5 | tạo gold set 100 câu | HR duyệt kết quả mong đợi |
| 6 | cải thiện retrieval/answer/refusal | đo đầy đủ lần đầu |
| 7 | rà security, PDPA, operation | ghi rủi ro và khoảng trống |
| 8 | test lại, quyết định RFP/production | ký kết quả và dự toán giai đoạn sau |
Để tránh tạo cảm giác đây là giá thị trường không có căn cứ, hãy so sánh theo tỷ trọng khi tổng ngân sách bằng 100: chuẩn bị tài liệu/OCR 15%, prototype truy xuất/trả lời 35%, identity/quyền 20%, thiết kế và chạy test 20%, vận hành/đào tạo 10%. Đây là mô hình kiểm tra đủ hạng mục, không phải benchmark giá. Giả định có DMS API, không OCR chữ viết tay chuyên biệt và không ghi ngược hệ thống lõi. Tài liệu sạch làm giảm phần chuẩn bị; nhóm quyền phức tạp, quyền ghép từ nhiều hệ thống hoặc tìm kiếm lịch sử làm tăng phần tích hợp và test. Yêu cầu vendor nêu số tài liệu, ngôn ngữ, mẫu quyền, số câu gold set và vòng retest làm cơ sở.
Sau go-live: test lại khi đầu vào được kiểm soát thay đổi
Khi sửa quy định, chủ sở hữu phê duyệt nguồn và ngày hiệu lực; ingestion kiểm số lượng, lỗi và quyền; chạy câu đại diện cùng negative test để bản cũ không xuất hiện; HR rà câu quan trọng trước khi phát hành. Sau khi đổi model hoặc embedding, chạy lại gold set như regression.
KPI không nên chỉ là số người dùng. Theo dõi tỷ lệ tự giải quyết, nhóm câu chuyển tiếp, tỷ lệ mở bằng chứng, số câu trả bản cũ bằng 0, sự cố quyền bằng 0 và SLA cập nhật.
Xác định RACI và log cho từng lần sửa đổi
Người quản lý quy định là Responsible cho đăng DMS và metadata; trưởng bộ phận là Accountable cho hiệu lực; lao động, pháp chế và an ninh thông tin là Consulted; help desk cùng bộ phận sử dụng là Informed. Người vận hành tìm kiếm chỉ phản ánh trạng thái đã duyệt, không tự phê duyệt ý nghĩa. Thông báo khẩn phải có ngày hết hiệu lực, site, mã tài liệu bị thay thế và người duyệt, đồng thời cảnh báo nếu tự hết hạn làm không còn nguồn hợp lệ.
Thiết kế audit log theo mục đích, không theo mong muốn lưu mọi thứ
Tách event truy cập, mẫu cải thiện chất lượng và chi tiết điều tra sự cố theo mục đích. Log thường có thể lưu ID giả danh, thời gian, tài liệu/phiên bản, kết quả allow/deny và correlation ID mà không lưu toàn bộ câu hỏi nhạy cảm. Nếu cần full text để review, phải đặt thời hạn, tỷ lệ lấy mẫu, masking và người được xem.
Diễn tập sửa phiên bản trước go-live
Trước go-live, diễn tập đổi Rev.4 sang Rev.5: trước hiệu lực, sau hiệu lực, tra lịch sử, đổi quyền và thu hồi. Đo thời gian DMS đến index, việc loại bản cũ khỏi câu hỏi hiện tại, giữ đúng bản cũ trong lịch sử, chuyển citation và rollback. Đưa bằng chứng này vào quyết định production.
FAQ
AI tìm kiếm quy định khác enterprise search thế nào?
Enterprise search chủ yếu trả tài liệu. AI có thể hiểu cách diễn đạt và ngôn ngữ khác nhau rồi giải thích đoạn liên quan, nên phải thêm trích dẫn, phiên bản, ngày hiệu lực, từ chối và chuyển tiếp.
AI tìm kiếm tri thức có loại bỏ hoàn toàn câu trả lời sai không?
Không. RAG vẫn có lỗi truy xuất, bản cũ, OCR, tài liệu mâu thuẫn và lỗi sinh câu. Phải đo retrieval, grounding và answer riêng.
Chatbot nội quy có thể đáp ứng PDPA Thái Lan không?
Không thể kết luận từ tên sản phẩm. Cần đánh giá dữ liệu cá nhân trong tài liệu, câu hỏi, câu trả lời, ID và log; mục đích, cơ sở pháp lý, notice, processor, vị trí, retention và quyền cùng DPO hoặc luật sư Thái.
AI tìm tài liệu có giữ quyền theo phòng ban không?
Có, nếu đối chiếu người dùng với quyền tài liệu trước khi truy xuất. Phải test độ trễ đồng bộ, chuyển việc, nghỉ việc, lỗi tra quyền và quyền quản trị, với nguyên tắc fail closed.
Bao nhiêu tệp thì cần RAG?
Số tệp không đủ để quyết định. Cần xét dung lượng, tần suất đổi, quyền, ngôn ngữ, độ trễ và yêu cầu trích dẫn. Tập nhỏ ổn định có thể đơn giản hơn với FAQ được duyệt hoặc fixed context.
Quyết định PoC đạt thế nào?
Thống nhất trước ngưỡng retrieval, citation, lỗi nghiêm trọng, rò quyền, refusal, refresh và latency. Dùng cả bản cũ, không quyền, không đáp án, xuyên ngôn ngữ và câu cần con người quyết định.
Kết luận: sáu quyết định trước khi mời thầu
Hãy chốt tài liệu/phiên bản chính thức, thời điểm câu trả lời, ai được tìm gì, mức chi tiết của trích dẫn, việc AI trả lời hay chuyển người, và negative test để nghiệm thu. Khi đó RFP so sánh thiết kế có thể quản trị, không phải demo nói hay.
TOMAS TECH có thể hỗ trợ cơ sở tại Thái Lan kiểm kê quy định đa ngôn ngữ, lập bản đồ quyền, tạo gold set PoC và chuyển tiêu chí nghiệm thu thành RFP trước khi chọn sản phẩm. Nếu còn ở giai đoạn xác định phạm vi, hãy gửi số lượng tài liệu, ngôn ngữ và nhóm người dùng qua trang liên hệ.
Tài liệu tham khảo
- Thailand Royal Gazette, Personal Data Protection Act B.E. 2562 (2019): https://ratchakitcha.soc.go.th/documents/17082307.pdf
- ETDA, Generative AI Governance Guideline for Organizations (8/2024): https://www.etda.or.th/getattachment/6050a4b7-defd-4dba-8cbc-ff6a444a3d08/20240910_GenerativeAIGovernanceGuideline_Vol1_AIGC.pdf.aspx
- ETDA, AI Governance is a condition for using AI today (1/7/2026): https://www.etda.or.th/th/pr-news/Future_AiGov.aspx
- NIST AI 600-1 (công bố 26/7/2024; trang cập nhật 8/4/2026): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- OWASP LLM08:2025: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
- Microsoft Learn, Document-Level Access Control (truy cập 2/9/2026; áp dụng lưu ý preview): https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
- Microsoft Learn, Security Filter Pattern (cập nhật 24/8/2026): https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search
Bài viết dựa trên thông tin công khai đến ngày 2/9/2026, là hướng dẫn kỹ thuật và vận hành chung, không phải tư vấn pháp lý.
