Tự động hóa quy trình bằng AI Agent: 7 lỗi khi vận hành nội bộ

Tự động hóa quy trình bằng AI Agent rất dễ trình diễn. Điều khó là giữ cho nó chạy không cần người trông vào một giờ cố định mỗi ngày, và vẫn nhận biết được khi nó hỏng. Tại TOMAS TECH, chúng tôi vận hành hằng ngày nhiều AI Agent ngay trong hoạt động nội bộ tại Thái Lan, bao gồm email, lịch hẹn, bản ghi âm cuộc họp, báo giá, công việc theo dõi và thông báo nội bộ. Bài viết này ghi lại 7 lỗi chúng tôi thực sự đã gặp, cùng các nguyên tắc thiết kế rút ra từ đó, ở dạng mà doanh nghiệp khác có thể tái sử dụng.

Kết luận: tự động hóa thành công nhờ “nhận ra được là nó đã hỏng”, không phải nhờ mô hình thông minh

Tự động hóa không chỉ dừng vì mô hình thiếu chính xác. Trong vận hành của chúng tôi, những sự kiện thực sự phá hủy giá trị kinh doanh lại rất tầm thường. Một tác vụ kết thúc thành công và báo cáo không có bản ghi nào, trong khi kết nối của nó đã mất từ trước. Cùng một hạng mục được tạo thành công việc mới mỗi sáng. Một bảng tổng hợp đảo ngược kết luận vì các ghi chú nội bộ bị trộn vào mẫu số. Một tệp cấu hình tồn tại ở hai nơi, và bản chúng tôi sửa không phải bản hệ thống đọc.

Không cái nào trong số đó là “AI làm sai”. Chúng đến từ phần xung quanh Agent: tính lành mạnh của đầu vào, tính duy nhất của bản ghi, việc giám sát, và ranh giới phê duyệt của con người. Vì vậy trọng tâm thiết kế cho tự động hóa nội bộ nằm ở 5 điểm sau.

1. Bạn có phân biệt được “không lấy được đầu vào” với “đầu vào rỗng” không?
2. Bạn có định nghĩa được định danh ngăn ghi trùng một sự kiện, một cách độc lập với phần triển khai không?
3. Mọi kết quả đầu ra có kèm mẫu số và khoảng thời gian không?
4. Có ranh giới giữa thao tác cần người phê duyệt và thao tác Agent được tự thực hiện không?
5. Khi hỏng, ai được báo, vào lúc nào, qua kênh nào?

Các phần dưới đây giải thích vì sao từng điểm trở nên cần thiết, theo đúng thứ tự chúng tôi gặp sự cố. Nếu muốn sắp xếp lộ trình áp dụng AI trước, xem lộ trình ứng dụng AI cho doanh nghiệp tại Thái Lan; với góc nhìn mua sắm bao gồm thuê ngoài, xem cách chọn công ty phát triển AI tại Bangkok.

Chúng tôi đã tự động hóa những gì: 9 luồng hậu cần văn phòng chạy hằng ngày

Để có bối cảnh, đây là phạm vi. Tất cả đều là công việc nội bộ, không phải hệ thống của khách hàng.

Hình dạng đều giống nhau: thu thập → chuẩn hóa → ghi nhận → thông báo. AI tạo sinh chủ yếu đảm nhận khâu chuẩn hóa (phân loại, tóm tắt, dịch, đối chiếu). Chúng tôi cố ý ghi vào những nơi mọi người vốn đã xem — cơ sở dữ liệu công việc và biên bản họp, chat công việc, thư mục nháp email — và không dựng màn hình riêng cho Agent. Tự động hóa buộc nhân viên phải học một màn hình mới sẽ không còn ai mở ngay trong tuần đầu vận hành.

Ngoài ra, chúng tôi không giao cho Agent bất kỳ thao tác nào mang tính gửi đi, đăng ký hay quyết định. Email dừng ở bản nháp. Việc kiểm tra lịch hẹn dừng ở phát hiện và thông báo. Cảnh báo thời hạn dừng ở tính toán và tạo việc. Lý do của ranh giới này được trình bày ở phần sau.

Lỗi 1: thất bại ngụy trang thành “0 bản ghi”

Đây là lỗi chúng tôi mất nhiều thời gian nhất mới nhận ra. Tác vụ lấy và ghi email liên tục kết thúc thành công và báo “0 bản ghi trong phạm vi”, dù điều kiện kết nối của nó đã mất. Mọi dòng log đều báo thành công; thông báo ghi “hôm nay không có gì”. Thực tế, suốt 15 ngày không có email nào được lấy về.

Nguyên nhân là phần triển khai biểu diễn “kết quả rỗng” và “không thể lấy dữ liệu” bằng cùng một mảng rỗng. Agent nhận mảng rỗng và trung thực báo 0. Không ai nói dối, mà quy trình đã chết 15 ngày.

Hiện nay chúng tôi đưa ba điều sau vào mọi tác vụ.

• Ghi nhận tình trạng kết nối như một tín hiệu tách khỏi số lượng bản ghi. Việc có tiếp cận được nguồn, xác thực có thành công, truy vấn khoảng thời gian có trả về, đều được lưu độc lập với con số 0.
• Coi chuỗi số 0 liên tiếp là bất thường. Email công việc tại một cơ sở quy mô như chúng tôi không thể bằng 0 trong hai ngày làm việc liên tiếp. Hãy giữ bộ đếm số ngày 0 liên tiếp và khi vượt ngưỡng thì báo dưới dạng cảnh báo thay vì thành công.
• Luôn nêu trạng thái nguồn trong báo cáo hoàn thành. Không phải “0 bản ghi” mà là “kết nối OK, cửa sổ 24 giờ, 0 bản ghi khớp”. Người đọc sẽ thấy khác biệt ngay lập tức.

Giám sát tác vụ theo lô thường được thiết kế để báo động khi có lỗi. AI Agent có tính chất ngược lại: nó làm tròn thất bại thành thành công. Hãy đưa cơ chế giám sát dead-man, coi sự im lặng là lỗi, vào ngay từ ngày đầu.

Lỗi 2: khi khóa chống trùng bị đổi, mỗi sáng mọi thứ đều trông như mới

Khi cùng một phép kiểm tra chạy hằng ngày, việc “không tạo lại hạng mục đã tạo” là bắt buộc. Chúng tôi quyết định điều này bằng giá trị băm của một chuỗi biểu diễn duy nhất cho hạng mục — gọi là khóa chống trùng (idempotency key).

Chúng tôi đã sai hai lần. Ký tự phân tách và thứ tự nối chuỗi bị viết lại mỗi lần khóa được triển khai lại. Đổi ký tự phân tách thì giá trị băm đổi hoàn toàn. Kết quả là mọi hạng mục đã tạo từ những ngày trước đều bị coi là mới, và các công việc trùng chất chồng lên nhau. Lần thứ hai gặp phải, chúng tôi đóng băng công thức tính khóa thành một đặc tả viết ra giấy, và cấm phía triển khai tự ghép lại công thức.

Ở dạng có thể tái sử dụng:

• Viết định nghĩa khóa chống trùng bằng lời, tại đúng một nơi, và để mã nguồn tham chiếu tới đó. Ví dụ: “nối ngày với danh sách sự kiện đã sắp xếp bằng |, rồi lấy 12 ký tự đầu của giá trị SHA-1″ — ký tự phân tách là một phần của đặc tả.
• Không bao giờ trộn thời điểm chạy hay môi trường chạy vào nguyên liệu của khóa. Thời gian hiện tại, tên máy chủ và đường dẫn tệp đều biến cùng một sự kiện thành sự kiện khác ở mỗi lần chạy.
• Làm cho kết quả khử trùng nhìn thấy được. In ra “n mới, m cập nhật, k không đổi” ở mỗi lần chạy. Khi tỷ lệ nhảy vọt, bạn sẽ thấy. Nếu tất cả đều là mới, bạn thấy ngay sáng hôm đó.

Lỗi 3: tính năng tìm kiếm bạn tưởng là có lại không dùng được trong môi trường thật

Một truy vấn bạn cho là hiển nhiên khi thiết kế có thể không dùng được trên môi trường vận hành. Trường hợp của chúng tôi là tìm kiếm toàn văn trong nội dung email. Cú pháp lọc tiêu chuẩn làm ứng dụng mất ổn định, toán tử tìm kiếm toàn văn bị vô hiệu hóa ở cấp môi trường, và API tìm kiếm bất đồng bộ không bao giờ báo hoàn tất — ba ràng buộc cùng lúc.

Điều quan trọng là chấp nhận ràng buộc đó như tiền đề chứ không phải ngoại lệ, rồi thay đổi thiết kế. Chúng tôi từ bỏ tìm kiếm nội dung, thu hẹp ứng viên theo tiêu đề, địa chỉ người gửi và người nhận, cùng khoảng thời gian, rồi chuyển phần phán đoán nội dung sang Agent sau khi đã lấy dữ liệu về. Khối lượng xử lý tăng lên, nhưng việc nó chạy được thì đáng giá hơn.

Khi viết yêu cầu cho tự động hóa quy trình bằng AI, hãy kiểm chứng những điểm sau trên hệ thống thật. Nếu chỉ phán đoán từ tài liệu giới thiệu và tài liệu API, bạn sẽ phải làm lại ở nửa sau giai đoạn triển khai.

• Cú pháp tìm kiếm hoặc lọc có hoàn tất ở khối lượng dữ liệu thật hay không (thử với số lượng cỡ vận hành, không phải mẫu 100 bản ghi).
• API bất đồng bộ có báo hoàn tất hay không. Nếu phải hỏi vòng, điều kiện kết thúc là gì.
• Tệp đính kèm, nội dung hay trường tùy chỉnh có ràng buộc về quyền và giấy phép hay không.
• Hành vi khi chạm giới hạn tần suất gọi. Hãy xác nhận khoảng thời gian thử lại và mức trần trong tài liệu của chính nhà cung cấp — cả Microsoft Graph lẫn Notion API đều công bố giới hạn và hành vi khuyến nghị.

Lỗi 4: không nêu mẫu số thì kết luận tổng hợp sẽ đảo ngược

Một vấn đề khác xuất hiện khi chúng tôi bắt đầu tổng hợp dữ liệu đã tích lũy để tìm xu hướng. Khi thử đếm tần suất tiếp xúc theo từng khách hàng trên cơ sở dữ liệu biên bản họp, chúng tôi thấy trường tên khách hàng bị trống ở gần một nửa số bản ghi, cùng vài trăm ghi chú nội bộ vốn không phải cuộc họp với khách hàng. Bản tóm tắt chỉ tồn tại ở những bản ghi tạo sau một mốc thời gian nhất định.

Tổng hợp nguyên trạng như vậy thì bạn không thể phân biệt “khách hàng ít được tiếp xúc” là ít thật hay chỉ là chưa điền tên. Một bảng tổng hợp không nêu mẫu số còn nguy hiểm hơn một lỗi âm thầm, chính vì nó tạo ra kết luận nghe có vẻ hợp lý.

Các quy tắc chúng tôi chốt lại:

• Mọi bảng tổng hợp phải nêu khoảng thời gian, tổng thể được đếm, điều kiện loại trừ và tỷ lệ thiếu dữ liệu.
• Trường có tỷ lệ thiếu vượt ngưỡng cần có cơ chế bổ sung trước khi đưa vào tổng hợp. Ở trường hợp của chúng tôi, dữ liệu được tự động bổ sung bằng đối chiếu chuẩn hóa với danh mục khách hàng gốc, và không bao giờ ghi đè giá trị đã có.
• Công bố cả hai con số: “tỷ lệ trong số bản ghi có dữ liệu” và “tỷ lệ trên toàn bộ bản ghi”. Chỉ nhìn một con số thì chắc chắn hiểu sai.
• Đánh dấu thời điểm ý nghĩa của dữ liệu thay đổi (thêm trường, đổi quy trình) như một ranh giới, và chú thích mọi tổng hợp bắc qua ranh giới đó.

Điều này không chỉ đúng với AI tạo sinh, nhưng Agent sẽ thực hiện đúng phép tổng hợp được yêu cầu mà không nghi ngờ, rồi trả kết quả dưới dạng văn xuôi khẳng định, nên một mẫu số bị thiếu rất dễ đi kèm một kết luận tự tin quá mức.

Lỗi 5: ngày và giờ lệch âm thầm giữa các môi trường

Với hoạt động trải giữa cơ sở tại Thái Lan và trụ sở tại Nhật Bản, việc xử lý thời gian là nguồn sự cố thường trực. Chúng tôi đã gặp ba trường hợp.

Thứ nhất, một môi trường shell âm thầm bỏ qua thiết lập múi giờ và chạy theo Giờ Phối hợp Quốc tế (UTC). Không có lỗi nào báo ra; chỉ còn lại kết quả bị lệch ngày. Thứ hai, thư từ đối tác ở các cơ sở Nhật Bản được viết theo giờ Nhật trong khi lịch giữ theo giờ Thái, và mọi người tự nhẩm bù khoảng chênh 7 giờ. Thứ ba, chúng tôi tính ngược ngày làm việc trong quá khứ từ thời điểm chạy hiện tại và ra kết quả mâu thuẫn với ngày tạo thực tế.

Biện pháp khắc phục thì đơn giản nhưng cần được thực thi nghiêm.

• Dùng datetime có kèm múi giờ xuyên suốt biểu diễn nội bộ của Agent. Không truyền qua lại các chuỗi ngày trần.
• Quyết định theo từng nơi lưu quy tắc hiển thị theo giờ địa phương của cơ sở, lưu trữ theo thời gian tuyệt đối.
• Không suy đoán ngày trong quá khứ. Hãy đọc từ dữ liệu thật — dấu thời gian sửa đổi, phần đầu thư.
• Ghi thiết lập múi giờ của môi trường vào log lúc khởi động để kiểm tra được ở mỗi lần chạy.

Lỗi 6: bộ nhớ đệm và đồng bộ nằm chen giữa lần ghi và lần đọc

Khi tự động hóa ghi vào hệ thống nội bộ hoặc website của chính công ty, bạn sẽ gặp hiện tượng nội dung đã ghi bị biến mất. Chúng tôi xác nhận được hai biến thể.

Thứ nhất là bộ nhớ đệm biên của mạng phân phối nội dung. Đọc ngay sau khi ghi thì nhận về nội dung cũ; dựng bản cập nhật tiếp theo dựa trên đó thì bạn ghi đè và xóa mất chính thay đổi vừa thực hiện. Cách sửa gồm hai phần: luôn thêm tham số phá đệm khi đọc, và đọc lại sau mỗi lần ghi để xác nhận cái gì thực sự được lưu.

Thứ hai xảy ra khi sản phẩm được tạo ra ngay trong thư mục đồng bộ đám mây. Tệp bị tráo giữa chừng, và sản phẩm hoàn thiện âm thầm thiếu mất các chỉnh sửa. Chúng tôi đã đổi cách làm: chạy quá trình tạo trong vùng làm việc cục bộ, kiểm chứng sản phẩm, rồi mới đặt vào thư mục đồng bộ.

Cả hai đều là loại sự kiện mà nếu không biết nguyên nhân sẽ bị hiểu nhầm thành “Agent không chịu sửa như tôi yêu cầu”. Hãy đưa việc đọc lại và đối chiếu vào cùng một bước kiểm chứng với việc ghi.

Lỗi 7: hai bản gốc, và bản bạn sửa không phải bản được đọc

Khi hoạt động mở rộng, cùng một quy trình sẽ được định nghĩa ở nhiều nơi. Ở chỗ chúng tôi, định nghĩa mà lần chạy theo lịch đọc và định nghĩa mà lần chạy thủ công đọc đã bị nhân bản sang hai thư mục khác nhau. Chúng tôi sửa một bản, và chỉ nhận ra vào sáng hôm sau khi cùng lỗi đó xuất hiện lại.

Đây không phải vấn đề riêng của AI, nhưng nó gây thiệt hại lớn hơn khi vận hành bằng Agent. Agent đọc đúng vị trí được chỉ và thực thi chính xác những gì viết ở đó, nên nó sẽ tự tin chạy đến hết với một định nghĩa cũ. Con người sẽ khựng lại và nghĩ “ơ, mình sửa rồi mà”. Agent thì không dừng.

• Chọn một bản gốc duy nhất và để bản còn lại chỉ dùng để tham chiếu. Nếu buộc phải có bản sao, hãy coi nó là tệp được sinh ra và không bao giờ sửa tay.
• Ghi vào log đường dẫn mà định nghĩa được đọc từ đó.
• Sau khi sửa định nghĩa, chỉ coi là xong khi đã kiểm tra kết quả của lần chạy tự động kế tiếp.

Đặt phê duyệt của con người ở đâu: phân quyền tự chủ theo bậc

Từ các lỗi trên, mức độ tin tưởng dành cho Agent nên được quyết định bằng khả năng đảo ngược của tác động, chứ không bằng cảm tính. Chúng tôi chia thao tác thành các bậc và mở dần từ dưới lên.

Điểm mấu chốt là ranh giới giữa L5 và L6. Quy tắc tự động đến bước thông báo, còn mọi thứ có tác động ra bên ngoài thì để con người đủ đơn giản để không ai ở hiện trường phải cân nhắc. Ranh giới này cũng phòng ngừa thực tế rằng lỗi của AI tạo sinh không hiện ra dưới dạng đọc sai dễ thấy, mà dưới dạng khẳng định nghe hợp lý. Lỗi càng khó phát hiện thì cổng phê duyệt càng phải đặt sớm.

Bản thân việc tự động hóa thông báo cũng có lỗi riêng. Ở chỗ chúng tôi, quyền sử dụng bot thông báo bị giới hạn ở chính người tạo ra nó, nên những thông báo chúng tôi tin là đã gửi tới các đồng nghiệp khác thực ra không đến được ai cả. API gửi vẫn trả về thành công. Với mọi thứ nằm trên đường thông báo, hãy kiểm chứng một lần trên thiết bị thật rằng tin nhắn đã hiện trên màn hình người nhận, chứ không chỉ là đã được gửi đi.

Mức tối thiểu cần có để đưa vào vận hành thật

Đây vẫn là nội dung trên, dưới dạng danh sách yêu cầu tối thiểu cho tổ chức mới bắt đầu. Việc có đủ 7 mục này quan trọng với tính liên tục hơn bất kỳ tính năng cao cấp nào.

Bảy mục này không đòi hỏi nền tảng lớn hay hệ thống quan trắc chuyên dụng. Ngay trong cấu hình của chúng tôi, nơi lưu là các công cụ nghiệp vụ sẵn có, việc chạy là bộ lập lịch hằng ngày, và giám sát là một tin nhắn vào chính kênh chat đó. Thứ cần trước không phải là thêm công cụ, mà là quyết định xem thất bại nên trông như thế nào.

Bắt đầu thế nào: làm nhỏ, và thử cách nó hỏng trước

Nếu bạn đang cân nhắc tự động hóa nội bộ, chúng tôi khuyến nghị thứ tự sau. Về đánh giá và kế hoạch kiểm chứng, xem các hạng mục chi phí và tiêu chí thành công của AI PoC; về năng lực nhân viên, xem bài kiểm tra thực hành cho đào tạo AI tạo sinh.

1. Chọn đúng một luồng. Nó nên diễn ra hằng ngày, chậm trễ không gây thảm họa, và đáp án đúng có thể kiểm chứng được sau đó. Của chúng tôi là việc tích lũy email.
2. Ghi vào công cụ sẵn có. Không dựng màn hình mới. Đặt kết quả ở nơi mọi người vốn đã xem.
3. Dừng ở L4 (bản nháp). Đừng cho gửi ngay từ đầu. Trong một đến hai tuần, để người chấm điểm các bản nháp.
4. Thử cách nó hỏng, trước tiên. Ngắt kết nối, gỡ quyền, làm rỗng đầu vào. Xem thông báo nói gì trong từng trường hợp; nếu không phân biệt được, hãy sửa thiết kế.
5. Thêm cảnh báo chuỗi 0 liên tiếp trước khi chuyển sang chạy không người trông.
6. Đồng bộ định dạng khóa và định dạng nhật ký chạy của luồng thứ hai với luồng thứ nhất. Nếu mỗi luồng tự nghĩ ra quy ước riêng thì cả giám sát lẫn bàn giao đều bất khả thi.
7. Rà soát mẫu số của kết quả đầu ra hằng quý. Thay đổi trong vận hành sẽ âm thầm làm thay đổi ý nghĩa của dữ liệu.

Câu hỏi thường gặp

Tự động hóa quy trình bằng AI Agent cần đội ngũ lớn cỡ nào?

Của chúng tôi do những người hiểu nghiệp vụ dựng lên, trên nền các công cụ nghiệp vụ sẵn có và một bộ lập lịch. Không có đội nền tảng AI chuyên trách. Điều đó khả thi vì đây là công việc nội bộ, không có phạm vi ảnh hưởng ra bên ngoài. Tự động hóa chạm tới hệ thống của khách hàng hoặc thiết bị cần có yêu cầu, kiểm thử và cơ cấu vận hành riêng.

AI tạo sinh cần chính xác tới mức nào mới dùng được trong vận hành thật?

Không có một con số độ chính xác đơn lẻ nào quyết định điều đó. Quan trọng là con người có nhận ra lỗi hay không, và thao tác có hoàn tác được hay không. Thao tác đảo ngược được — ghi nhận, soạn nháp — chịu được một mức lỗi nhất định. Thao tác không đảo ngược được — gửi, đăng ký, quyết định — trên thực tế vẫn nên giữ bước phê duyệt của con người, bất kể độ chính xác đo được cao đến đâu.

Nên tự động hóa cái gì trước?

Việc diễn ra hằng ngày, có thể kiểm chứng tính đúng đắn sau đó, và chậm trễ không gây thảm họa. Ngược lại, việc phát sinh hằng tháng, không ai kiểm chứng được, và gây thiệt hại ngay khi chậm, là mục tiêu đầu tiên rất tệ.

Làm sao biết một quy trình tự động đã dừng?

“Báo động khi thất bại” là chưa đủ. Hãy giám sát các lần chạy trả về 0 bản ghi liên tiếp, và cả những lần chạy không hề diễn ra (giám sát dead-man). Mọi sự cố kéo dài mà chúng tôi từng gặp đều xuất hiện dưới dạng “thành công, 0 bản ghi”.

Có được đưa dữ liệu nội bộ cho AI tạo sinh không?

Điều đó phụ thuộc vào phân loại thông tin và các điều khoản hợp đồng của bạn. Tối thiểu, hãy xác nhận từ điều khoản dịch vụ và thiết lập sản phẩm xem dữ liệu nào được truyền đi, lưu ở đâu, và có được dùng để huấn luyện hay không. Nếu liên quan tới dữ liệu cá nhân của người tại Thái Lan, hãy xác nhận phạm vi PDPA với chuyên gia và thiết kế để chỉ truyền đi lượng dữ liệu tối thiểu cần thiết.

Có nên để Agent gửi email không?

Chúng tôi thì không. Chúng tôi tự động hóa tới bản nháp và người sẽ gửi. Một lần gửi sai không thể thu hồi và ảnh hưởng trực tiếp tới quan hệ. Ngay cả khi mở rộng sau này, trước hết vẫn cần có giới hạn người nhận, bước xác nhận trước khi gửi, và nhật ký gửi kiểm toán được.

Tóm lại: tự động hóa được đánh giá qua cách nó hỏng trong im lặng

Điều chúng tôi học được khi vận hành tự động hóa bằng AI Agent là phần khó không nằm ở năng lực của mô hình tạo sinh mà ở mọi thứ xung quanh nó. Một kết nối đã mất nhưng được báo là thành công. Một định danh thay đổi biến cùng một hạng mục thành hạng mục khác. Một bảng tổng hợp không mẫu số đưa ra kết luận đầy tự tin. Bộ nhớ đệm và đồng bộ nuốt mất một thay đổi. Một định nghĩa bị nhân bản khiến bản cũ vẫn sống. Không cái nào là sự cố kịch tính; tất cả đều âm thầm bào mòn giá trị kinh doanh.

Vì vậy thứ tự thiết kế là quyết định xem nó sẽ hỏng ra sao, và dựng nên hình hài của thất bại, trước khi thêm tính năng. Ghi tính lành mạnh của đầu vào tách khỏi số lượng, đóng băng khóa chống trùng thành đặc tả, gắn mẫu số vào mọi đầu ra, và giữ các thao tác có tác động ra ngoài cho con người. Có bốn điều đó ngay từ đầu, hoạt động của chúng tôi đã không đổ vỡ dù số luồng ngày càng tăng.

Nếu bạn đang thiết kế tự động hóa hậu cần văn phòng cho một cơ sở tại Thái Lan, hoặc tự động hóa nội bộ tích hợp với hệ thống lõi, hãy liên hệ qua trang liên hệ của TOMAS TECH. Khi đã biết phạm vi công việc và các hệ thống sẵn có, chúng tôi có thể cụ thể hóa nên bắt đầu từ đâu và nên giữ phê duyệt ở chỗ nào.

Tài liệu tham khảo

• NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• OWASP, Top 10 for Large Language Model Applications 2025: https://genai.owasp.org/llm-top-10/
• ISO, ISO/IEC 42001:2023 Artificial intelligence management system: https://www.iso.org/standard/42001
• Microsoft Learn, Microsoft Graph throttling guidance: https://learn.microsoft.com/en-us/graph/throttling
• Notion, API request limits: https://developers.notion.com/reference/request-limits
• ETDA, AI Governance Practice Center (AIGPC): https://www.etda.or.th/th/Our-Service/AIGC/index.aspx
• PDPC Thailand, Personal Data Protection Committee: https://www.pdpc.or.th/