Triển khai chatbot tại Thái Lan và ASEAN: hướng dẫn RFP, RAG, PDPA và nghiệm thu

Khi triển khai chatbot cho nhà máy hoặc văn phòng bán hàng tại Thái Lan và ASEAN, tên của mô hình AI không phải quyết định quan trọng nhất. Doanh nghiệp phải xác định bot được phép trả lời gì, nguồn nào là bản chính thức, tiếng Thái xen tiếng Anh được xử lý ra sao, trường hợp nào phải chuyển cho nhân viên và bằng chứng nào đủ để nghiệm thu. Bài viết này giúp ban lãnh đạo, IT, bộ phận nghiệp vụ, mua hàng, pháp chế và DPO xây dựng cùng một cơ sở để phát hành RFP và ra quyết định đầu tư.

Tóm tắt điều hành: 7 quyết định trước khi triển khai chatbot

“Chatbot” có thể là FAQ công khai, giao diện tìm kiếm tài liệu nội bộ hoặc AI agent có quyền cập nhật ERP. Nếu mỗi nhà thầu hiểu phạm vi khác nhau thì báo giá không thể so sánh. Hồ sơ phê duyệt đầu tư cần nêu ít nhất bảy nội dung:

1. Người dùng là nhân viên, đại lý, khách hàng hiện hữu hay công chúng.
2. Công việc là trả lời câu hỏi, tìm tài liệu, hướng dẫn thủ tục hay phân loại sự cố.
3. Kênh là Web, LINE, Microsoft Teams hay cổng nội bộ.
4. Ngôn ngữ và người chịu trách nhiệm thuật ngữ chính thức của từng ngôn ngữ.
5. Nguồn tri thức được phép dùng, dữ liệu cá nhân, cấp độ mật và ranh giới quyền truy cập.
6. Khi nào AI không được trả lời, hàng đợi nhân viên, giờ phục vụ và SLA.
7. KPI về nghiệp vụ, chất lượng, an toàn và chi phí.

Nếu chưa thống nhất được bảy nội dung này, một PoC giới hạn người dùng, tài liệu và kênh sẽ hợp lý hơn việc đàm phán triển khai toàn doanh nghiệp. Có thể đọc thêm hướng dẫn áp dụng AI tạo sinh tại công ty con ở nước ngoài và chi phí, tiêu chí thành công của AI PoC tại Thái Lan.

Go, Conditional Go hay No-Go

Kế hoạch 90 ngày trong bài là khung minh họa, không phải cam kết thời gian giao hàng. Cần điều chỉnh theo tích hợp, rà soát pháp lý, mức sẵn sàng dữ liệu và nguồn lực tại từng cơ sở.

FAQ bot, tìm kiếm, RAG và AI agent khác nhau thế nào?

Trong RFP, hãy mô tả hành vi mong muốn thay vì chỉ ghi tên sản phẩm.

RAG không đơn giản là “huấn luyện AI bằng tài liệu công ty”. Thông thường, hệ thống tìm đoạn liên quan tại thời điểm nhận câu hỏi và đưa chúng cho mô hình làm căn cứ. Vì vậy, phân tích tài liệu, metadata, xếp hạng, lọc quyền, trích dẫn và đồng bộ phiên bản quan trọng không kém chất lượng mô hình.

AI agent bổ sung hành động lên hệ thống nghiệp vụ. Tra cứu tồn kho chỉ đọc khác hẳn tạo đơn mua hoặc sửa dữ liệu khách hàng. Ở giai đoạn đầu, nên tách trả lời/tìm kiếm khỏi thao tác ghi. Chỉ mở quyền ghi sau khi có xác nhận rõ ràng, cấp quyền tối thiểu, tham số được phép, idempotency và nhật ký kiểm toán.

Chọn use case cho dự án triển khai chatbot

Chấm điểm giá trị và khả thi riêng biệt

Không nên ưu tiên chỉ theo số lượng câu hỏi. Hãy đánh giá tần suất, thời gian xử lý, mức chuẩn hóa của câu trả lời, độ sẵn sàng của tri thức, hậu quả khi trả lời sai, độ phức tạp quyền và nhu cầu đa ngôn ngữ.

Nêu phần loại trừ trước danh sách tính năng

Bản phát hành đầu có thể loại trừ quyết định an toàn cuối cùng, đánh giá nhân viên, cam kết giá chưa duyệt, đổi tài khoản thụ hưởng, xóa/phê duyệt không thể hoàn tác và thu thập tự do dữ liệu cá nhân nhạy cảm. Chỉ xem xét lại sau khi có kiểm soát và phê duyệt cụ thể.

Sổ đăng ký use case nên ghi chủ quy trình, người dùng, input mẫu, nguồn, định dạng output, câu trả lời cấm, ngoại lệ, nơi chuyển, tải cao điểm, ngôn ngữ và thời hạn lưu. Đây là cơ sở chung cho phạm vi, báo giá, kiểm thử và vận hành.

Thiết kế chatbot đa ngôn ngữ và tiếng Thái

Đa ngôn ngữ không chỉ là đổi ngôn ngữ giao diện. Phát hiện ngôn ngữ, truy xuất, thuật ngữ, ngôn ngữ trả lời, trích dẫn, chuyển nhân viên và phân tích phải nhất quán.

Tách ba trường locale

• user locale: ngôn ngữ ưu tiên lưu trong hồ sơ hoặc kênh;
• conversation locale: ngôn ngữ đang dùng trong cuộc hội thoại;
• content locale: ngôn ngữ, quốc gia và cơ sở của tài liệu nguồn.

Cần kiểm thử code-switching, ví dụ câu tiếng Thái chứa tên sản phẩm, chữ viết tắt hoặc model bằng tiếng Anh. Không tự động dịch mã nhận diện. Một chính sách hợp lý có thể trả lời bằng ngôn ngữ người dùng nhưng hiển thị nguồn chính thức ở nguyên ngữ và phần tóm tắt được đánh dấu rõ là bản dịch.

Tài liệu hỗ trợ ngôn ngữ của Microsoft Copilot Studio, cập nhật ngày 29/6/2026, liệt kê tiếng Nhật, Thái và Việt Nam cho những khả năng liên quan đến generative answers và user language. Tuy nhiên, mức hỗ trợ khác nhau theo tính năng và primary language không thể đổi sau khi tạo. Cần xác minh trực tiếp tổ hợp tính năng, tenant, region, kênh và ngôn ngữ trước khi ký hợp đồng.

Tài liệu multilingual agents của Microsoft mô tả chuyển ngôn ngữ động trong generative orchestration; classic chatbot dùng một ngôn ngữ và tác giả chịu trách nhiệm dịch topic viết thủ công. Đây là ví dụ của một sản phẩm chứ không phải khuyến nghị nhà cung cấp, nhưng cho thấy RFP phải phân biệt phần tự động hỗ trợ và phần con người phải bảo trì.

Biến thể tiếng Thái và quản trị từ điển

Phân đoạn từ, từ vay mượn viết bằng chữ Thái hoặc tiếng Anh, chữ tắt nội bộ, mã model và mức lịch sự đều ảnh hưởng tìm kiếm. Từ điển nên là dữ liệu có quản trị:

Nghiệm thu bản dịch phải kiểm tra ý nghĩa, điều kiện, phủ định, thời hạn và chủ thể chịu trách nhiệm. Với an toàn, lao động và hợp đồng, nên dùng tài liệu địa phương đã được duyệt làm nguồn thay vì biến bản dịch máy thành bản chính thức.

Kiến trúc tham chiếu cho phát triển chatbot

1. Kênh: bộ nối Web, LINE, Teams và portal.
2. Danh tính/phiên: người dùng, pháp nhân, nhà máy, vai trò và trạng thái hội thoại.
3. Điều phối: ngôn ngữ, intent, truy xuất, tool, từ chối và chuyển tuyến.
4. Tri thức: tài liệu đã duyệt, metadata, index và quản lý phiên bản.
5. Mô hình: sinh nội dung, phân loại, dịch và embedding.
6. Tích hợp: CRM, ERP, MES, ITSM, ticket và notification.
7. Quản trị: log, đánh giá, giám sát, quyền, secret, lưu giữ và xóa.

RFP phải yêu cầu nhà thầu nêu nhà cung cấp từng lớp, quốc gia/region dữ liệu đi qua, nơi lưu, subprocessor, trách nhiệm khi sự cố, thông báo thay đổi và hoàn trả/xóa dữ liệu khi kết thúc. Chứng nhận của một dịch vụ SaaS không mô tả rủi ro của toàn bộ hệ thống ghép từ nhiều thành phần.

Pipeline tri thức RAG

• Chỉ thu thập nội dung được duyệt từ SharePoint, file server, web hoặc database.
• Chuẩn hóa PDF, bảng, OCR, header/footer và bản trùng.
• Chia chunk mà không cắt đứt thủ tục, phạm vi model hoặc bối cảnh revision.
• Gắn ngôn ngữ, pháp nhân, cơ sở, phòng ban, sản phẩm, cấp mật, ngày hiệu lực/hết hạn.
• Cấu hình lexical/vector search và reranking theo use case.
• Áp quyền trước hoặc trong quá trình retrieval.
• Chỉ trả lời từ bằng chứng; thiếu bằng chứng thì từ chối hợp lý.
• Hiển thị tên nguồn, phiên bản, đoạn và liên kết.
• Theo dõi cập nhật/xóa từ nguồn tới index và cache.

Số lượng tài liệu không phải KPI chất lượng. Revision mâu thuẫn, draft, tài liệu hết hạn và quy định của quốc gia khác dễ tạo câu trả lời trôi chảy nhưng sai nghiệp vụ.

Bảng yêu cầu RFP để nhận báo giá có thể so sánh

Yêu cầu nhà thầu phân loại câu trả lời thành standard feature, configuration, custom development, dịch vụ bên thứ ba, giả định, hạn chế, chi phí thêm và bằng chứng, thay vì chỉ ghi “có hỗ trợ”.

Mọi nhà thầu phải chạy cùng dữ liệu và kịch bản. Demo tự do chỉ cho thấy đường đi mạnh nhất của từng bên. Roadmap phải tách khỏi tính năng hiện hành nếu không có ngày, gói, region và cam kết hợp đồng cụ thể.

Tri thức, quyền và PDPA Thái Lan trong một data flow

Dữ liệu cá nhân có thể xuất hiện trong câu hỏi, lịch sử chat, feedback, ticket nhân viên, analytics, backup và request tới model API, không chỉ trong tài liệu nguồn. Sơ đồ phải ghi điểm thu thập, mục đích, vai trò controller/processor, vị trí, bên nhận, thời hạn lưu, cách xóa và chuyển xuyên biên giới.

Bài viết không phải tư vấn pháp lý; nghĩa vụ PDPA phụ thuộc bối cảnh. Có thể tham khảo GPPC và GPPC PLUS của PDPC Thái Lan về RoPA, quản lý đồng ý khi áp dụng, xử lý vi phạm và yêu cầu của chủ thể dữ liệu. DPO/pháp chế cần xác nhận vai trò, căn cứ xử lý, notice, chuyển dữ liệu, retention, điều khoản processor và quy trình sự cố.

Duy trì quyền cấp tài liệu tới tận câu trả lời

Đăng nhập không có nghĩa được tìm mọi tài liệu nội bộ. Hệ thống phải so khớp thuộc tính người dùng với metadata và duy trì quyết định đó trong kết quả tìm kiếm, nội dung sinh ra và link trích dẫn. Cần tách HR, lương, giá khách hàng, sản phẩm chưa công bố, sự cố chất lượng và hồ sơ audit.

Negative test bao gồm người khác pháp nhân/cơ sở, người không có quyền, nhân viên nghỉ việc, session hết hạn, thiết bị dùng chung và URL đoán được. Cần đo thời gian thu hồi quyền lan tới index và cache.

Kiểm tra điều khoản dữ liệu mô hình theo hợp đồng

OpenAI enterprise privacy nêu chính sách mặc định không dùng business data để huấn luyện mô hình cùng các cam kết khác. Tuy nhiên, retention, logging, dịch vụ đủ điều kiện, region, subprocessor và ngoại lệ phải được xác nhận theo sản phẩm và hợp đồng cụ thể.

Cập nhật Zero Data Retention của OpenAI ngày 19/8/2026 là ví dụ mới cho bên mua quan tâm lưu giữ. Không nên giả định ZDR tự động áp dụng cho mọi API, tính năng, log hay hợp đồng. Phải xác nhận API/tính năng đủ điều kiện, ngoại lệ, thủ tục phê duyệt, câu chữ hợp đồng và cơ chế abuse monitoring. Đây là tiêu chí hỏi mọi ứng viên, không phải khuyến nghị một nhà cung cấp.

Kết nối LINE, Teams và Web

LINE: signature, xử lý bất đồng bộ và sự kiện trùng

Hướng dẫn nhận webhook của LINE đề cập xử lý bất đồng bộ cùng khả năng redelivery và duplicate event. Cần xác minh webhook signature trên raw request body. Nếu parse rồi serialize lại JSON trước khi xác minh, chữ ký có thể không còn hợp lệ.

Tách các bước nhận, xác minh chữ ký, acknowledge, queue, deduplicate, xử lý AI và trả lời. Tạo idempotency key từ event để redelivery không tạo ticket hoặc thao tác ghi lần hai. Redelivery không đảm bảo hành động nghiệp vụ đã hoàn tất; phải có giám sát trạng thái và queue reprocess có kiểm soát.

Teams và Web có độ tin cậy danh tính khác nhau

Teams hoặc portal nội bộ có thể cung cấp danh tính tổ chức, group và điều kiện thiết bị; public web thường ẩn danh. Phải có policy riêng và không nâng quyền từ URL parameter hoặc lời tự khai.

Nếu dùng backend chung, chuẩn hóa conversation, user, channel, entity, locale, consent và trạng thái phục vụ con người nhưng vẫn giữ giới hạn riêng từng kênh. Khả năng truy vết không đồng nghĩa cho nhân viên analytics xem dữ liệu cá nhân không cần thiết.

Bảo mật: kết hợp rủi ro GenAI và kiểm soát ứng dụng thông thường

OWASP Top 10 for LLM Applications 2025 bao gồm Prompt Injection và Sensitive Information Disclosure. NIST AI 600-1 Generative AI Profile hỗ trợ đưa rủi ro GenAI vào quản trị rủi ro AI. Cần chuyển các tham chiếu này thành threat model của use case, không chỉ ghi tên tiêu chuẩn trong RFP.

Không thể chống prompt injection bằng một câu cấm

Phải kiểm thử lệnh trực tiếp và lệnh gián tiếp ẩn trong trang web, PDF, email hoặc attachment được truy xuất.

• Phân biệt system instruction, user input, retrieved content và tool output.
• Không coi lệnh trong tài liệu là policy đáng tin.
• Áp least privilege, tham số cho phép, giới hạn và xác nhận cho từng tool.
• Không đưa secret và dữ liệu mật không liên quan vào context.
• Kiểm tra output theo đích trước khi dùng làm SQL, HTML, email hoặc đối số API.
• Chạy lại attack/regression test sau thay đổi model, prompt hoặc retrieval.

Không ghi API key, webhook secret, connection string hay dữ liệu cá nhân trong prompt template. Secret phải lấy lúc chạy từ kho phù hợp, đồng thời mask trong log, lỗi và analytics. Điều khoản “không dùng để huấn luyện” khác với việc ứng dụng có lưu log hay không.

Webhook ngoài phải kiểm tra signature, thời gian, người gửi và retry. API ghi phải idempotent. Với mua hàng, hoàn tiền hoặc đổi dữ liệu khách hàng, AI có thể chuẩn bị đề xuất nhưng con người/policy engine phải duyệt và lưu audit.

Chuyển cho nhân viên là một quy trình vận hành

Phải xác định ai nhận, khi nào, nhận thông tin gì, ngôn ngữ nào và bot làm gì sau chuyển. Trigger bao gồm người dùng yêu cầu gặp người; thiếu hoặc mâu thuẫn bằng chứng; dữ liệu cá nhân, hợp đồng, giá, khiếu nại, an toàn, chất lượng; thử lặp lại không giải quyết; ngôn ngữ rủi ro; hoặc tích hợp fail, timeout, access denied.

Chỉ chuyển thông tin cần thiết và phù hợp với sự đồng ý: tóm tắt, câu hỏi, bước đã thử, nguồn, ngôn ngữ, mã khách hàng/máy liên quan và độ khẩn cấp. Mask thông tin không cần. Câu trả lời của nhân viên không được tự động trở thành tri thức vĩnh viễn nếu chưa qua quy trình duyệt.

Hiển thị giờ phục vụ, ngôn ngữ, queue, kỳ vọng xác nhận và phương án ngoài giờ. Hợp đồng có thể dùng ví dụ “xác nhận trong thời gian đã thỏa thuận trong giờ làm việc” hoặc “thông báo ngay queue critical”, nhưng thời gian thực phải căn cứ nhân lực, kênh, mức độ và SLA hiện có.

Dữ liệu kiểm thử và tiêu chí nghiệm thu

Không dùng một con số accuracy duy nhất

Mỗi câu hỏi cần expected facts, mandatory evidence, nội dung cấm, biến thể chấp nhận, chuyển tuyến mong đợi, quyền và ngôn ngữ.

Các số 0 và 100% là ví dụ về gate nghiệm thu nghiêm ngặt cho quyền, dịch thuật critical và chuyển tuyến critical; không phải số liệu vận hành hay bảo đảm không có sự cố tương lai. Doanh nghiệp phải xác định tập mẫu, mức chấp nhận rủi ro và phê duyệt giá trị riêng. Chất lượng câu hỏi thường và response time cũng phải được hiệu chỉnh bằng baseline tự đo.

Xây test set đa ngôn ngữ bản địa

Không chỉ dịch máy bộ tiếng Nhật hoặc tiếng Anh. Hãy thu thập chữ tắt, lỗi gõ, cách nói lịch sự/khẩu ngữ, tiếng Anh xen kẽ, model, đơn vị và định dạng ngày từ người dùng Thái và Việt. Gắn concept ID cho câu tương đương rồi so sánh kết luận giữa các ngôn ngữ.

Bộ kiểm thử cần có câu bình thường, mơ hồ, nhiều intent, không có nguồn, nguồn cũ/mâu thuẫn, thiếu quyền, dữ liệu cá nhân, prompt injection, input dài, attachment, tích hợp lỗi, event trùng và human transfer. Bổ sung lỗi production vào regression set và chạy lại khi đổi tri thức, prompt, model, search hoặc connector.

TCO và so sánh báo giá

Chi phí ban đầu thấp có thể tăng do chuẩn bị dữ liệu, dịch, đánh giá, giám sát, nhân viên và usage. Hãy so sánh cùng một kỳ đầu tư, chẳng hạn ba năm.

Cung cấp cùng giả định về conversation/tháng, turn, input/output trung bình, khối lượng/tần suất đổi tài liệu, concurrent usage, evaluation traffic và human transfer. Xác nhận tiền tệ, thuế, tỷ giá, thay đổi model, cache, cảnh báo ngân sách và hành vi khi vượt hạn mức.

Đặt khác biệt giả định cạnh giá. Nếu một bên gồm chuẩn bị tài liệu, bên khác bắt khách hàng làm và bên thứ ba loại trừ dịch thuật thì tổng tiền không tương đương. Hãy đánh giá TCO đáp ứng bắt buộc, khả năng thay đổi, data portability và trách nhiệm vận hành.

Kế hoạch triển khai chatbot 90 ngày minh họa

Ngày 1–15: yêu cầu và ranh giới dữ liệu

Bổ nhiệm sponsor, process owner, information owner, DPO/pháp chế, IT và reviewer ngôn ngữ địa phương. Thống nhất use case, loại trừ, kênh, ngôn ngữ, KPI. Lập data flow, quyền, retention, chuyển dữ liệu. Kiểm kê nguồn với version, owner, classification và tạo test set từ câu hỏi thật.

Ngày 16–35: RFP, chọn và thiết kế

So sánh bằng cùng scenario. Xem demo citation, access denial, escalation và log. Đàm phán SLA, security, data term, TCO và exit. Đưa acceptance và change control thành deliverable hợp đồng.

Ngày 36–65: xây dựng và đánh giá

Giới hạn tài liệu, người dùng và kênh đại diện. Cấu hình từ điển/style JA/EN/TH/VI. Kiểm thử normal, refusal, access, attack, integration fail và escalation. Phân loại lỗi thành knowledge, retrieval, access, model, UX hoặc operation.

Ngày 66–80: pilot có kiểm soát

Giới hạn phòng ban/cơ sở. Giải thích giới hạn AI và cách chuyển người. Rà mẫu hàng ngày về unsupported answer, retrieval failure, unresolved và ngôn ngữ. Giữ tính năng rủi ro sau feature flag. Xác nhận đội địa phương vận hành queue và duyệt tri thức được.

Ngày 81–90: nghiệm thu và quyết định

Chạy acceptance set cố định, phân tích pilot, báo cáo residual risk, ngoại lệ, chi phí và việc tồn. Quyết định Go, Conditional Go, kéo dài hoặc dừng. Nếu mở rộng, mở quốc gia, phòng ban, kênh và write permission theo giai đoạn.

Sai lầm thường gặp

1. Nhầm demo trôi chảy với chính xác: phải kiểm nguồn, revision, quyền và refusal.
2. Nạp mọi PDF: phải quản owner, hiệu lực, classification và deletion.
3. Giao tiếng Thái hoàn toàn cho dịch máy: reviewer địa phương phải kiểm chữ tắt, code-switching và chỉ dẫn critical.
4. Không có lối ra khi AI không trả lời: refusal phải nối với quy trình có nhân viên thật.
5. PoC dùng FAQ vô hại nhưng production có dữ liệu cá nhân/ERP: phải đánh giá lại data flow và permission.
6. Bỏ usage và chi phí con người: cần evaluation, monitoring, translation, update và reprocess.
7. Đổi model không change control: phải version, approve, regression test và rollback.

Câu hỏi thường gặp về triển khai chatbot

Nên so sánh chi phí triển khai chatbot như thế nào?

Dùng cùng giả định tải và tính setup, licence, model/search usage, data preparation, translation, security, monitoring, knowledge maintenance, human service và exit. Quy đổi phần loại trừ và việc khách hàng tự làm thành tiền hoặc ngày công.

Phát triển chatbot có nên bắt đầu bằng RAG không?

RAG phù hợp khi câu trả lời nằm trong tài liệu duyệt và cần hỏi xuyên nguồn. FAQ cố định đủ cho hướng dẫn ổn định. Thao tác ghi cần thêm API authorization, confirmation, idempotency và audit.

Một mô hình có đủ cho chatbot đa ngôn ngữ không?

Hỗ trợ ngôn ngữ của model chỉ là một lớp. Phải kiểm retrieval, embedding, OCR, voice, topic, UI, analytics và human queue ở từng ngôn ngữ. Reviewer nghiệp vụ địa phương cần nghiệm thu thuật ngữ và thủ tục critical.

Nghiệm thu chatbot tiếng Thái cần chú ý gì?

Bao gồm tiếng Thái tự nhiên, chữ tắt và mã model tiếng Anh, biến thể, khẩu ngữ/lịch sự, câu ngắn và lỗi gõ. Kiểm phủ định, điều kiện, deadline, chủ thể, đơn vị và nguồn đúng pháp nhân, cơ sở, revision.

Đặt accuracy bao nhiêu phần trăm?

Không có một số chung. Tách critical question, FAQ thường, retrieval, refusal, access và language rồi đặt threshold từ test set nội bộ. Có thể yêu cầu 0 rò rỉ trong negative test như gate, nhưng đó không phải tuyên bố production sẽ không bao giờ có sự cố.

Chứng nhận cloud có đủ cho PDPA Thái Lan không?

Không đủ để trả lời toàn bộ bối cảnh. DPO/pháp chế cần xác nhận purpose, role, notice, transfer, retention, deletion, DSAR, breach và processor term trên input, log, knowledge và integration.

Làm sao tránh LINE thực hiện trùng?

Xác minh signature trên raw request, acknowledge sớm, xử lý async và lưu idempotency key. Event lặp lại không được tạo thêm ticket hoặc thực hiện lại cập nhật nghiệp vụ.

Kết luận

Triển khai chatbot tại Thái Lan và ASEAN phải bắt đầu từ phạm vi nghiệp vụ, nguồn chính thức, chủ sở hữu ngôn ngữ, quyền, data flow PDPA, chuyển nhân viên và nghiệm thu đo được, chứ không phải tên mô hình. Hãy so nhà thầu bằng một RFP, một test set và cùng cơ sở TCO. Thiết kế RAG như hệ thống bằng chứng và quyền; chỉ mở hành động agent khi có least privilege, phê duyệt, idempotency và audit.

TOMAS TECH có thể hỗ trợ xác định quy trình, lập RFP, thiết kế RAG đa ngôn ngữ, tích hợp LINE/Teams/Web và xây dựng nghiệm thu cho cơ sở tại Thái Lan, Việt Nam và ASEAN ngay cả khi chưa chọn sản phẩm. Nếu doanh nghiệp cần làm rõ ranh giới dữ liệu hoặc so báo giá trên cùng điều kiện, hãy liên hệ với chúng tôi.

Tài liệu tham khảo

• Microsoft Copilot Studio: Language support
• Microsoft Copilot Studio: Configure multilingual agents
• NIST AI 600-1: Generative Artificial Intelligence Profile
• OWASP Top 10 for LLM Applications 2025
• OpenAI Enterprise Privacy
• OpenAI: Our commitment to Zero Data Retention
• LINE Developers: Receiving webhook events
• LINE Developers: Verify webhook signature
• Thailand PDPC: GPPC
• Thailand PDPC: GPPC PLUS