Khi một nhà máy muốn dùng AI để nhập email đơn hàng, công việc không chỉ là sao chép chữ từ tệp. Khách hàng gửi email kèm PDF, Excel hoặc ảnh; bên nhận phải xác định đó là đơn đặt hàng đã xác nhận hay chỉ là câu hỏi, kiểm tra khách hàng, mã hàng, số lượng, giá và ngày giao rồi tạo đơn bán hàng trong ERP của chính nhà máy. Câu “như lần trước”, tệp đính kèm sửa đổi hoặc hai ngày giao mâu thuẫn không thể để OCR tự quyết định. Bài viết trình bày phạm vi, thiết kế dữ liệu, xử lý ngoại lệ, yêu cầu RFP và kiểm thử FAT/SAT cho doanh nghiệp sản xuất có cơ sở tại Thái Lan.
Xác định ranh giới: đơn khách hàng gửi đến, không phải nghiệp vụ mua hàng
Điểm bắt đầu là khách hàng gửi yêu cầu mua tới doanh nghiệp. Đầu vào là hộp thư của bộ phận bán hàng/tiếp nhận đơn và tệp đính kèm; đầu ra là đơn bán hàng trong ERP. Tài liệu của khách có thể ghi “Purchase Order”, “PO” hoặc “đơn đặt hàng” vì từ góc nhìn của họ đó là đơn mua. Với nhà máy nhận đơn, đó là dữ liệu đầu vào của đơn bán. OCR PO do doanh nghiệp phát hành cho nhà cung cấp, so sánh báo giá mua, nhận hàng và xử lý hóa đơn là các quy trình khác. Gộp chúng sẽ gây nhầm chủ công việc, đối tượng ERP, dữ liệu gốc và KPI.
Có thể xem hướng dẫn chọn hệ thống quản lý đơn bán và mua để hiểu ranh giới, còn bài OCR đơn đặt hàng đến kiểm nhận đi sâu phía mua hàng. Bài này tập trung vào cửa tiếp nhận của bên bán. Nếu khách đã gửi dữ liệu có cấu trúc qua EDI hoặc API, thông thường không cần OCR thêm. Nhóm phù hợp để bắt đầu là email, PDF, Excel hoặc ảnh mà nhân viên còn phải đọc và gõ vào ERP. Yêu cầu báo giá hoặc hỏi ngày giao không được biến thành đơn bán chỉ vì có mã sản phẩm.
Bảy bước tự động hóa email đơn hàng khách hàng
- Nhận và lưu chứng cứ. Lưu ID email, ID tệp, thời điểm nhận, người gửi và chuỗi trao đổi. Microsoft Graph hỗ trợ delta query để theo dõi thay đổi thư, nhưng cách áp dụng thực tế còn phụ thuộc quyền hộp thư, quy tắc chuyển tiếp, lưu trữ và nền tảng thư đang dùng.
- Phân loại ý định. Tách đơn mới, sửa đổi, hủy, yêu cầu báo giá, câu hỏi thông thường và thư rác. Đừng quyết định chỉ vì thấy chữ “PO”.
- Trích xuất giá trị ứng viên. Đọc khách hàng, số PO khách, ngày đặt, nơi giao, tiền tệ, mã hàng, phiên bản, số lượng, đơn vị, đơn giá và ngày giao mong muốn. Giữ dấu vết tới đoạn email, trang PDF hoặc ô Excel của từng giá trị.
- Chuẩn hóa. Ánh xạ mã hàng khách sang mã nội bộ, đơn vị sang đơn vị ERP, tên khách sang mã khách đã xác thực. AI được đề xuất; bảng ánh xạ được duyệt hoặc người có quyền mới xác nhận.
- Đối chiếu. Kiểm giá hợp đồng, cỡ lô, sản phẩm được bán, nơi giao, hạn mức tín dụng và đơn đã tồn tại. Độ tin cậy trích xuất cao không thể bỏ qua quy tắc nghiệp vụ không đạt.
- Người kiểm và phê duyệt. Hiển thị giá trị chưa chắc chắn cạnh bản gốc, chỉ định người xử lý, quyền duyệt và cách hỏi lại khách. AI không phải người duyệt cam kết thương mại.
- Ghi một lần và phản hồi. Tạo đúng một đơn ERP và gắn số ERP với email, tệp và lịch sử xét duyệt. Xác nhận đã nhận và cam kết ngày giao là hai quyết định khác nhau; chỉ dùng thông tin được duyệt.
Tự động hóa không đồng nghĩa mọi đơn đều được ghi không cần kiểm. Nhóm ổn định, rủi ro thấp có thể đi thẳng; giá, số lượng hoặc phiên bản mâu thuẫn phải vào hàng chờ. Tài liệu Microsoft Document Intelligence mô tả việc dùng độ tin cậy từng trường để chuyển trường hợp quan trọng cho người xét. “Đọc ra giá trị” và “giao dịch hợp lệ” là hai phép kiểm độc lập.
Tách phần đầu, dòng hàng và chứng cứ trong mô hình dữ liệu
| Tầng | Trường tối thiểu | Nơi kiểm | Lý do giữ lại |
|---|---|---|---|
| Đầu đơn | Mã khách, PO khách, ngày, tiền tệ, nơi giao | Danh mục khách và hợp đồng | Khách không rõ, sai tiền tệ |
| Dòng hàng | Mã khách, mã nội bộ, lượng, đơn vị, giá, ngày giao | Danh mục hàng, giá, tồn và kế hoạch | Hàng ngừng bán, đổi đơn vị chưa định nghĩa |
| Chứng cứ | ID email, hash tệp, phiên bản, vị trí nguồn, người duyệt | Kho thư, tài liệu, audit log | Không dựng lại được nguồn |
Số PO khách không phải lúc nào cũng duy nhất. Khách có thể giữ số khi sửa, thêm dòng sau hoặc dùng một chuỗi số ở nhiều nhà máy. Thiết kế khóa kiểm trùng tạm từ mã khách, PO, nơi giao và phiên bản, có biến thể theo khách. Phát hiện thư gửi lại bằng ID và hash tệp. Nếu ERP đã ghi thành công nhưng phản hồi mạng bị mất, tìm theo khóa nghiệp vụ trước khi thử lại. POST thêm ngay có thể tạo hai đơn.
Quy định độ ưu tiên giữa thân email và tệp khi mâu thuẫn. Một số khách coi tệp đã ký là đơn chính thức, người khác sửa tệp bằng câu trong email. Không để AI đoán một quy tắc cho mọi khách. Nếu có hai tệp đều có vẻ là bản mới nhất, chuyển cho người xét. Địa chỉ thuộc miền công ty khách cũng không tự chứng minh người gửi có quyền phát hành đơn.
Đo chất lượng hiểu email và AI-OCR tài liệu riêng nhau
PDF quét và ảnh cần OCR và tái tạo bảng. Thân email không cần OCR nhưng những câu “tuần tới”, “điều kiện như lần trước”, “chỉ đổi dòng ba” cần ngữ cảnh. Excel có dòng ẩn, nhiều sheet, công thức, giá trị hiển thị và đơn vị nằm ngoài dòng hàng. Một điểm “độ chính xác đọc” chung sẽ che mất các lỗi khác nhau.
Đánh giá riêng phân loại tài liệu, trích xuất đầu đơn, trích xuất dòng, ánh xạ mã hàng, phân loại ý định và ghi ERP. Tài liệu đánh giá Google Cloud Document AI giải thích precision, recall và ảnh hưởng của ngưỡng tin cậy tới báo nhầm và bỏ sót. Tuyên bố “chính xác 99%” không đủ nếu thiếu bộ kiểm thử có nhãn chia theo khách, mẫu, ngôn ngữ, chất lượng ảnh và trạng thái sửa đổi.
Giả sử 99 trong 100 dòng đúng nhưng dòng cuối ghi 100 chiếc thay vì 10, thiệt hại có thể lớn. Ngược lại, tên sản phẩm viết khác nhưng ánh xạ danh mục duy nhất thì ít ảnh hưởng. Xếp lỗi theo hậu quả và khả năng phát hiện, ưu tiên mã hàng, giá, tiền tệ, lượng và ngày giao. Lưu sửa đổi của người để cải thiện quy tắc và mô hình. Không kết luận đạt chỉ từ trung bình khi nhóm quan trọng còn lỗi.
Kết nối đối tượng đơn bán ERP trước khi tự động bấm màn hình
So sánh API ERP, nhập chuẩn, giao diện mở rộng rồi mới tới robot thao tác màn hình. Ví dụ Business Central có API chính thức để tạo salesOrders. Sự tồn tại của API không chứng minh hệ thống triển khai tại doanh nghiệp có thể ghi đủ trường tùy biến, thuế, kho, điều kiện khách và dòng hàng. Kiểm phiên bản ERP, giấy phép, quyền API và môi trường thử rồi tạo cả đầu đơn và dòng ở đó.
Giữ hai trạng thái “ứng viên” và “đơn bán đã chốt” tách biệt. Đặt dữ liệu AI trong vùng tạm; chỉ gửi phiên bản được duyệt và qua các quy tắc. Lưu số đơn ERP, thời điểm, trạng thái phản hồi. Quy trình email cần phân biệt rõ đã nhận, chờ xét, đã ghi và thất bại. Khi timeout, phải xác minh ERP đã ghi hay chưa trước khi gửi lại. Đây là yêu cầu vận hành cốt lõi.
Phải có người sở hữu bảng ánh xạ mã hàng. ABC-100 của khách thường có thể là P-001 nội bộ, nhưng sửa phiên bản hoặc kích thước có thể là mã khác. Hiện các ứng viên và giữ lại nếu chưa duy nhất, ghi log mọi thay đổi. Nếu kế hoạch sản xuất phụ thuộc đơn, hãy bắt đầu công việc sau khi ERP xác nhận, không lấy email mới nhận làm lệnh sản xuất. Xem thêm thiết kế quản lý đơn tồn của nhà máy.
Không trộn sửa đổi và hủy với đường tạo đơn mới
Điều khó thường là email thứ hai: “đổi dòng ba thành 50”, “dùng tệp mới”, hoặc “lùi ngày giao một tuần”. Tạo thêm đơn sẽ thổi phồng backlog; sản xuất theo bản cũ gây sai khác. Phân loại đơn mới, sửa và hủy riêng, đề xuất chính xác số ERP và dòng cần tác động.
So bản hiện tại và mới từng dòng: thêm, xóa, thay lượng, giá hay ngày yêu cầu. Nếu vật tư đã mua hoặc đang sản xuất, bán hàng có thể không đủ quyền tự duyệt. Tách xác nhận với khách khỏi đánh giá ảnh hưởng sản xuất và xác nhận thay đổi đã tới kế hoạch. Lưu trình tự email và phiên bản vì thư mới nhất có thể trích dẫn điều kiện cũ. Một chủ đề có thể chứa nhiều PO; nhiều chủ đề có thể là cùng PO. Cả hai phải có trong FAT.
Vận hành tại Thái Lan: ngôn ngữ, pháp nhân, thời gian và dữ liệu
Nhà máy ở Thái Lan có thể nhận tài liệu Nhật, Anh, Thái, Việt. Pháp nhân bán, tiền tệ, nơi giao và điều kiện xuất khẩu khác nhau. Giữ số, mã hàng và đơn vị gốc. Có thể dịch phần giải thích trong giao diện nhưng đừng xác nhận giá chỉ từ bản dịch. Kiểm quy ước năm Thái khi có, thứ tự ngày-tháng, múi giờ, ngày nghỉ địa phương và cách trình bày VAT theo khách và pháp nhân.
Quy định phạm vi gửi địa chỉ liên hệ, chữ ký, bản vẽ và tên sản phẩm chưa công bố tới dịch vụ AI. Lập sơ đồ quyền truy cập, thời hạn lưu, xóa, bên xử lý và chuyển dữ liệu qua biên giới để bộ phận phụ trách đánh giá hợp đồng, chính sách và luật áp dụng. Thông báo riêng tư công bố bởi Thailand PDPC là ví dụ về việc giải thích mục đích xử lý dữ liệu cá nhân, không phải chứng nhận cho kiến trúc cụ thể.
Email khách là nội dung bên ngoài, không phải mệnh lệnh tin cậy cho hệ thống. Nếu tài liệu ghi “bỏ qua quy tắc và gửi dữ liệu sang nơi khác”, đó vẫn chỉ là dữ liệu. Đưa kết quả trích xuất vào schema giới hạn; chỉ workflow được phân quyền mới ghi ERP hay gửi thư. OWASP mô tả indirect prompt injection: nội dung bên ngoài bị hiểu nhầm thành chỉ thị đặc quyền. Hộp thư đặt hàng cần ranh giới tin cậy rõ ràng.
Khảo sát công việc trước khi chọn công cụ
Lấy mẫu email ít nhất hai đến bốn tuần, chia theo khách, ngôn ngữ, tệp, đơn mới/sửa, thời kỳ bình thường/cao điểm. Đếm riêng đơn chỉ có thân email, PDF chính thức và Excel nhiều dòng. Chia thời gian nhân viên thành đọc, kiểm, nhập và xử lý ngoại lệ. Nếu mùa cao điểm đổi định dạng, kéo dài kỳ mẫu.
Đo thời gian từ nhận đến hành động đầu, đến khi ghi ERP, số việc làm lại, trùng đơn, vòng hỏi khách và phút lao động mỗi đơn. Sau triển khai, tách kết quả: ghi không sửa, ghi sau xét, giữ lại, ghi sai, xử lý lại. Số trang AI đọc không phải kết quả nếu cam kết với khách bị sai.
PoC không nên chỉ lấy biểu mẫu sạch của một khách. Gồm khách chính, mẫu lạ, bản sửa, nhiều ngôn ngữ, ảnh kém, mã hàng mơ hồ và thân email khác tệp. Tách mẫu phát triển khỏi mẫu nghiệm thu. Lập nhãn đúng từ quy trình bán hàng của chính doanh nghiệp, không sao chép dữ liệu nhãn của OCR mua hàng. Khi nhân viên chuyên môn cũng bất đồng, ghi quyết định và lý do trước khi cho đó là lỗi AI.
Tính hiệu quả từ ngoại lệ và chi phí sai sót
| Nhóm | Cần tính | Dễ bị bỏ quên |
|---|---|---|
| Đầu tư | Kết nối thư, trích xuất, danh mục, ERP, kiểm thử | Quy tắc khách, quyền, chuyển đổi |
| Vận hành | API, cloud, giám sát, hỗ trợ, cập nhật mô hình | Mẫu mới và người xử lý ngoại lệ |
| Lợi ích | Bớt nhập, kiểm, làm lại và rút ngắn chu kỳ | Ít đơn sai, phản hồi khách tốt hơn |
| Rủi ro | Ghi sai/trùng, trễ hẹn, lộ dữ liệu | Sửa và thông báo khách |
Cách tính khởi điểm: số đơn đủ điều kiện mỗi tháng nhân phút xử lý hiện tại và chi phí nhân công, trừ thời gian giám sát đơn tự động, thời gian xét đơn còn lại, giải quyết ngoại lệ và dịch vụ hàng tháng. Dùng phân bố theo khách và thời điểm. Nếu 600/1.000 đơn trông chuẩn nhưng cả 600 đều cần người duyệt giá, nói “tự động 60%” sẽ phóng đại lợi ích. Ngược lại, xử lý nhanh đợt cuối tháng có thể cải thiện trả lời ngày giao hơn phần tiết kiệm giờ. Dùng số đo tại nhà máy, không mượn ROI tổng quát như sự thật.
So tổng chi phí thay vì giá OCR theo trang. Gồm kết nối email, đọc bảng, giao diện xét, kỹ thuật ERP, giám sát và định dạng mới của khách. Nhà cung cấp có thể tính theo trang, tài liệu hoặc dòng. Nêu khối lượng, số dòng trung bình, loại tệp, đỉnh tải, thời hạn lưu và ngôn ngữ trong RFP để so sánh cùng điều kiện.
Các yêu cầu nên ghi trong RFP
Phạm vi nghiệp vụ và quyền quyết định
Liệt kê hộp thư, khách, ngôn ngữ, tệp, cách xử lý mới/sửa/hủy, người xét, người duyệt và thông báo sau ERP. Yêu cầu sơ đồ cho biết điều kiện nào tự ghi, điều kiện nào giữ. Không cho AI sửa danh mục mã hàng và giá trong ERP.
Dữ liệu, an ninh và hỗ trợ
Hỏi nơi lưu bản gốc, giới hạn kích thước, tệp có mật khẩu, quét malware, ẩn dữ liệu cá nhân, vùng xử lý, có dùng dữ liệu huấn luyện không, thời hạn log và cách chia sẻ mẫu mật. Yêu cầu đường nhập tay khi dịch vụ AI ngừng. Hỏi thư chờ nằm ở đâu và chạy lại thế nào để không trùng.
Tích hợp và chứng cứ nghiệm thu
Yêu cầu nêu API/CSV/RPA lựa chọn, thứ tự tạo đầu đơn và dòng, xử lý lỗi, rollback, khóa idempotency và nơi trả số ERP. Kiểm thử gửi lại, bản sửa, lượng bằng không, đơn vị sai, hàng ngừng bán, tiền tệ sai, mất mạng và ERP bảo trì. Một màn trình diễn API với ví dụ đẹp không đủ.
FAT và SAT: đạt khi đơn đúng đã nằm trong ERP
FAT chạy mẫu đã ẩn danh theo thỏa thuận qua phân loại, trích xuất, chuẩn hóa, ERP thử và audit log. SAT kiểm đường email thực, quyền địa phương, danh mục khách, giờ Thái Lan, màn hình nhân viên và khôi phục sau lỗi. Thống nhất tiêu chí đạt trước khi kiểm.
| Tình huống | Kết quả mong đợi | Bằng chứng |
|---|---|---|
| Gửi lại email và tệp | Không tăng đơn ERP, nối hồ sơ cũ | ID, khóa, số ERP |
| PO khách sửa | Thấy khác biệt, chưa chốt nếu chưa duyệt | Bản, diff, log duyệt |
| Giá/lượng không chắc | Người xét, không tự ghi | Vị trí nguồn và log xét |
| ERP timeout | Tra đơn đã có trước khi thử lại | Log gửi, tra, kết quả |
| Không phải đơn hoặc không có quyền | Không tạo đơn bán | Phân loại và lý do giữ |
Đặt ngưỡng số theo từng dự án và nêu số mẫu, thời gian quan sát. “Không có lỗi nghiêm trọng” vô nghĩa nếu thiếu mẫu số. Theo dõi lỗi ghi nghiêm trọng, thời gian giải quyết ngoại lệ, ngăn trùng và thông báo xuống công đoạn sau cùng tỷ lệ tự ghi. NIST AI RMF tự nguyện nhóm việc theo Govern, Map, Measure, Manage; đây là khung quản trị sau triển khai, không phải đảm bảo pháp lý.
Mở rộng theo khách, định dạng và mức rủi ro
Bắt đầu từ khách có đủ lượng, định dạng ổn định và ánh xạ mã rõ, nhưng vẫn giữ tài liệu khó trong tập đánh giá. Giai đoạn shadow, AI đề xuất và người kiểm mọi trường hợp, so với nhập tay hiện có, ghi chênh lệch và chỉnh ngưỡng. Giai đoạn hai chỉ giảm kiểm hoặc cho tự ghi trong đúng tổ hợp khách, định dạng, loại đơn, danh mục đã xác minh, kiểm trùng và phản hồi ERP đạt tiêu chí. Có công tắc quay về người xét khi lỗi hay ngoại lệ tăng. Sau đó mở rộng khách và trường hợp sửa đổi, chạy regression test khi đổi quy tắc hoặc mô hình.
Người vận hành xem hàng chờ lỗi và chưa xử lý mỗi ngày. Hàng tuần xem tỷ lệ từng khách, nguyên nhân trả lại và sửa ánh xạ. Hàng tháng kiểm tác động đổi giá, mã hàng và bản mô hình. Đừng trông AI tự cải thiện nếu không có dữ liệu sửa và người chịu trách nhiệm.
Bảng quyết định và kế hoạch khôi phục khi chạy thật
PoC trích xuất được vẫn có thể thất bại nếu không ai quản hàng chờ ngoại lệ. Đặt bốn tuyến theo khách: tự ghi, ghi sau xét, hỏi khách và ngoài phạm vi. Một ứng viên tự ghi cần khách đã biết, ý định đơn mới rõ, mã hàng duy nhất, giá và tiền tệ khớp, ngày giao hợp lệ và không có khóa trùng. Thiếu điều kiện nào thì giữ với mã lý do. Đây là quy tắc ví dụ, không phải ngưỡng phổ quát. Màn xét hiện đoạn email, trang PDF hoặc ô Excel nguồn cạnh giá trị AI, kết quả kiểm danh mục ERP và chênh lệch phiên bản. Lưu trước/sau, lý do, thời gian, người duyệt cho từng sửa; phân biệt AI đọc sai, tài liệu khách thiếu, danh mục cũ và lỗi duyệt.
Nếu ERP ngừng, giữ ứng viên đã duyệt trong hàng có thứ tự, tra đơn cũ trước khi chạy lại. Nếu nhận thư ngừng, đối soát ID cuối và khoảng truy xuất thay vì chỉ dựa cờ chưa đọc. Khi ghi sai, kiểm ảnh hưởng giao hàng, sản xuất, hóa đơn trước khi đảo chứng từ theo quyền ERP; chủ bán hàng quyết định báo khách. Hằng ngày xem tuổi hồ sơ tồn, lý do ngoại lệ, trường hợp ERP đã ghi nhưng không trả số và sửa chữa; chỉ định người thay và thời điểm leo thang.
Nghiệm thu theo khách và mức nghiêm trọng
Trước chạy thật, hiện mẫu số và lỗi theo khách, định dạng, ngôn ngữ, đơn mới/sửa và trường trọng yếu. Điểm chung có thể che lỗi dòng Excel. Giữ một đơn mơ hồ có thể là kiểm soát đúng, nhưng giữ thừa cũng tốn công. Sửa biểu mẫu khách hoặc bảng ánh xạ mã nếu đó là gốc lỗi. Khi có khách mới, bảng giá, API ERP hay mô hình mới, kiểm lại mẫu liên quan và tắt tự ghi chỉ ở phạm vi bị ảnh hưởng. Nhận yêu cầu khách, duyệt đơn ERP và cam kết ngày giao là ba sự kiện riêng. Hiện đã nhận, đang xét, đã ghi và đã xác nhận ngày giao thành trạng thái riêng.
Câu hỏi thường gặp
AI có thể tự ghi mọi email đơn khách vào ERP không?
Thao tác ghi ERP có thể làm được về kỹ thuật, nhưng đơn có ý định mơ hồ, nguồn mâu thuẫn, mã hàng không chắc, giá thay đổi hay bản sửa không rõ phải giữ lại. Đánh giá hậu quả đơn sai và chỉ tự động hóa giao dịch qua điều kiện được viết rõ.
Chỉ triển khai AI-OCR tài liệu là hết việc nhập đơn bán?
OCR đề xuất giá trị từ tài liệu. Vẫn phải ánh xạ khách/hàng, kiểm giá và ngày, quyết định phiên bản, duyệt, kết nối ERP và chống trùng. Đánh giá demo đọc tài liệu riêng với demo tạo đơn bán đúng từ đầu đến cuối.
Khác OCR PO của bộ phận mua như thế nào?
PO do khách tạo là đầu vào đơn bán của doanh nghiệp. PO doanh nghiệp gửi nhà cung cấp thuộc mua hàng. Chủ quy trình, danh mục, chứng từ ERP và KPI khác nhau.
RFP và FAT/SAT tối thiểu cần gì?
Nêu khách, định dạng, ngôn ngữ, trường trọng yếu, sửa/hủy, người xử lý ngoại lệ, ERP, log, bảo mật và hỗ trợ. FAT kiểm mẫu đại diện cùng tình huống lỗi; SAT kiểm đường thư và người dùng thật. Theo từng hồ sơ tới số đơn ERP.
Kết luận
AI nhập email đơn hàng sản xuất là thiết kế một tuyến có kiểm soát từ thông điệp của khách đến đơn bán ERP. Những điểm quyết định là ý định đặt hàng, chứng cứ truy xuất, đối chiếu mã/giá/ngày, xử lý sửa và gửi lại, người duyệt, ghi đúng một lần và giám sát sau triển khai. Hãy bắt đầu bằng phân nhóm hộp thư và thử toàn bộ tuyến với đơn thực tế.
Nếu đang khảo sát email đơn khách, AI-OCR hay tích hợp ERP cho cơ sở tại Thái Lan, doanh nghiệp có thể trao đổi với TOMAS TECH ngay từ bước lập danh sách định dạng và thao tác nhập hiện tại. Mức tự động phù hợp cần dựa trên đơn hàng và quy tắc ERP thực của doanh nghiệp.
Nguồn tham khảo
- Microsoft Graph: message delta query — theo dõi thay đổi thư.
- Microsoft Azure Document Intelligence: confidence and accuracy — độ tin cậy trường và người kiểm.
- Google Cloud Document AI: Evaluate performance — precision, recall và ngưỡng.
- Microsoft Business Central: Create salesOrders — ví dụ API đơn bán.
- NIST AI RMF Core — quản trị rủi ro AI liên tục.
- OWASP Top 10 for LLM Applications — rủi ro prompt injection.
- Thailand PDPC GPPC privacy notice — ví dụ thông báo dữ liệu cá nhân.
