Cách AI Agent tích hợp với hệ thống hiện có của doanh nghiệp: Kiến trúc, quy trình và thực hành bảo mật

Trước hết, làm rõ “tích hợp”: mô hình không nên trực tiếp nắm quyền truy cập hệ thống

Khi doanh nghiệp tích hợp AI Agent với ERP, CRM, OA, hệ thống phiếu hỗ trợ hoặc kho tri thức, trọng tâm không phải là kết nối mô hình với cơ sở dữ liệu, mà là cho phép mô hình truy vấn, đánh giá hoặc thực hiện thao tác trong phạm vi giới hạn thông qua các công cụ được kiểm soát, trên cơ sở ủy quyền rõ ràng. Mô hình có nhiệm vụ hiểu yêu cầu và đề xuất bước tiếp theo; lớp công cụ định nghĩa và kiểm tra tính hợp lệ của thao tác; hệ thống doanh nghiệp vẫn là nguồn dữ liệu và quy tắc nghiệp vụ có thẩm quyền.

Đề xuất của Agent không có nghĩa là hệ thống đã thực thi, và việc gọi công cụ thành công cũng không có nghĩa là kết quả nghiệp vụ chính xác; cả hai đều cần được kiểm chứng. Để tìm hiểu cơ chế gọi công cụ, có thể tham khảo Tài liệu gọi hàm của OpenAI: mô hình tạo thông tin gọi công cụ theo định nghĩa, còn việc thực thi thực tế vẫn do phía ứng dụng xử lý.

Rà soát tác vụ trước, rồi mới quyết định tích hợp hệ thống nào

Hãy bắt đầu từ quy trình nghiệp vụ thay vì các thuật ngữ kỹ thuật. Liệt kê các tác vụ cần xử lý, hệ thống liên quan, dữ liệu đầu vào và đầu ra, các bước thủ công hiện tại, hậu quả khi xảy ra lỗi và những thao tác bắt buộc phải được nhân viên phê duyệt. Sau đó, chọn tình huống triển khai đầu tiên dựa trên giá trị nghiệp vụ, độ nhạy cảm của dữ liệu, mức độ hoàn thiện của giao diện tích hợp, tác động khi xảy ra lỗi và nhu cầu phê duyệt.

Ví dụ, trước tiên hãy đánh giá tình huống “phân luồng phiếu hỗ trợ khách hàng”: Agent đọc phiếu mới và kiến thức nội bộ, rồi đề xuất phân loại và nhóm phụ trách; lớp công cụ kiểm tra tính hợp lệ của mã phiếu, giá trị phân loại và nhóm; với tình huống rủi ro thấp, ban đầu chỉ tạo đề xuất và chờ nhân viên chăm sóc khách hàng xác nhận rồi mới cập nhật phiếu. Ví dụ này không giả định hệ thống có sẵn bất kỳ khả năng cụ thể nào; trước khi triển khai vẫn phải kiểm tra các giao diện tích hợp và quyền truy cập thực tế.

Chọn API, Webhook, gọi hàm hay RPA như thế nào

API phù hợp với các truy vấn và thao tác nghiệp vụ được xác định rõ. Lớp công cụ có thể đóng gói giao diện hệ thống thành các thao tác có phạm vi hẹp và rõ ràng, chẳng hạn như “truy vấn trạng thái phiếu hỗ trợ”, tránh cung cấp khả năng truy vấn tổng quát quá rộng. Cần kiểm tra phương thức xác thực, định nghĩa các trường, phản hồi lỗi và môi trường kiểm thử.

Gọi hàm là phương thức tương tác trong đó mô hình lựa chọn công cụ và điền các tham số đã được định nghĩa, chứ không phải một giao diện mới cho hệ thống doanh nghiệp. Cơ chế này cần kết hợp với việc kiểm tra phía máy chủ: không được mặc định rằng tham số đáng tin cậy hoặc hành động đã được cấp phép chỉ vì mô hình cung cấp tham số. Tài liệu về gọi hàm của OpenAI nêu rõ rằng sau khi mô hình đưa ra yêu cầu gọi công cụ, ứng dụng cần thực thi mã tương ứng và trả kết quả về luồng hội thoại.

Webhook phù hợp với các quy trình tiếp theo được kích hoạt bởi sự kiện nghiệp vụ, chẳng hạn thông báo cho dịch vụ tích hợp khi hệ thống phát sinh một công việc cần xử lý. Việc gửi sự kiện cần tính đến tình trạng trùng lặp, chậm trễ, thứ tự và thử lại khi thất bại; cách thức hoạt động thực tế phụ thuộc vào hệ thống được kết nối. Tài liệu Webhook của GitHub mô tả cách xử lý khi gửi thất bại và gửi lại, có thể dùng làm ví dụ để đối chiếu hành vi của từng nền tảng, chứ không phải sự bảo đảm chung cho mọi dịch vụ.

RPA có thể là phương án chuyển tiếp khi thiếu giao diện kết nối khả dụng, bằng cách thao tác trên giao diện của hệ thống cũ. Tuy nhiên, thay đổi giao diện, trạng thái đăng nhập và các cửa sổ bật lên bất thường đều có thể ảnh hưởng đến quy trình. Vì vậy, cần đánh giá độ ổn định, khả năng giám sát vận hành và chi phí bảo trì, đồng thời duy trì cơ chế đối soát cho các thao tác ghi dữ liệu quan trọng. Phần giải thích trong tài liệu UiPath về bộ chọn và nhận diện phần tử giao diện cho thấy bản thân việc định vị trên giao diện cũng cần được xác minh và duy trì trong ứng dụng đích.

Điều phối qua lớp trung gian phù hợp với các tình huống cần kết nối nhiều hệ thống, thống nhất danh tính và quy tắc. Cách tiếp cận này giúp tập trung xử lý việc chuyển đổi, kiểm tra và kiểm toán, nhưng cũng làm tăng số lượng thành phần và trách nhiệm vận hành. Khi lựa chọn, không chỉ cần so sánh tốc độ tích hợp mà còn phải cân nhắc khả năng xác định nguyên nhân sự cố, phân tách quyền truy cập và bảo trì dài hạn.

Kiến trúc đề xuất: tách biệt lập kế hoạch, thực thi và quản trị

1. Lớp Agent: hiểu yêu cầu, tổ chức ngữ cảnh, đề xuất kế hoạch gọi công cụ; không nắm giữ thông tin xác thực cơ sở dữ liệu.
2. Lớp công cụ: xác định mục đích, kiểu tham số, trường bắt buộc, phạm vi cho phép và cấu trúc dữ liệu trả về cho từng hành động; kiểm tra lại ở phía máy chủ.
3. Lớp tích hợp: kết nối các hệ thống ERP, CRM, OA và các hệ thống khác; xử lý xác thực, thích ứng giao thức, thời gian chờ và ánh xạ lỗi.
4. Lớp phân quyền và phê duyệt: liên kết danh tính nhân viên, danh tính dịch vụ và quyền thực hiện hành động; yêu cầu xác nhận đối với các thao tác có tác động lớn.
5. Lớp nhật ký và đánh giá: ghi lại chủ thể thực hiện lệnh gọi, công cụ, bản tóm tắt yêu cầu cần thiết, kết quả và ngoại lệ; hỗ trợ rà soát và thống kê chỉ số.

Cần phân định rõ trách nhiệm: mô hình chịu trách nhiệm “đề xuất việc cần làm”, dịch vụ công cụ chịu trách nhiệm “xác định có được phép hay không và tham số có hợp lệ hay không”, còn hệ thống nghiệp vụ chịu trách nhiệm “xác định trạng thái cuối cùng”. Không để mô hình bỏ qua lớp công cụ và trực tiếp nắm giữ tài khoản cơ sở dữ liệu của môi trường sản xuất. Việc phân lớp là khuyến nghị thiết kế triển khai; ranh giới cụ thể giữa các thành phần cần được xác định dựa trên khả năng của hệ thống và yêu cầu kiểm soát của tổ chức. Có thể tham khảo Giới thiệu về danh tính công việc của tác nhân Gemini cấp doanh nghiệp để hiểu vai trò của danh tính và quyền truy cập trong các tác nhân AI doanh nghiệp; trang này là nội dung giới thiệu sản phẩm, không thay thế cho việc đánh giá kiến trúc tại đơn vị.

Từ thí điểm đến vận hành chính thức: mở rộng từng bước theo mức độ rủi ro

Bước 1: chọn một tình huống có phạm vi hẹp. Xác định rõ điều kiện kích hoạt, tiêu chí hoàn thành và cách xử lý khi thất bại; không lấy việc “kết nối được với hệ thống” làm mục tiêu thay cho mục tiêu nghiệp vụ.

Bước 2: soạn đặc tả công cụ. Với mỗi công cụ, hãy mô tả mục đích, tham số, quyền truy cập, tác động phụ có thể xảy ra, loại lỗi và cách xác minh kết quả. Ưu tiên tách thành các hành động đơn lẻ, tránh để một công cụ đồng thời truy vấn, chỉnh sửa và xóa.

Bước 3: kết nối với môi trường kiểm thử trước. Kiểm thử bằng dữ liệu đầu vào mang tính đại diện, giá trị biên, trường bị thiếu và phản hồi bất thường; kiểm tra xem Agent có hỏi thêm khi thiếu thông tin hay không, thay vì phỏng đoán tham số.

Bước 4: Thiết lập biện pháp bảo vệ rồi triển khai từng phần. Bắt đầu với chế độ chỉ đọc hoặc đưa ra đề xuất, sau đó mới cho phép các thao tác ghi có rủi ro thấp đã được phê duyệt. Thiết lập giới hạn số lượt gọi, thời gian chờ và cảnh báo; quy định rõ khi xảy ra lỗi thì cần dừng, thử lại hay chuyển cho con người xử lý.

Bước 5: Đánh giá lại rồi mở rộng phạm vi. Ghi nhận các trường hợp phân loại sai, tham số không hợp lệ, lệnh gọi trùng lặp và lý do con người phải tiếp quản. Chỉ cân nhắc mở rộng phạm vi thao tác khi kết quả có thể kiểm chứng, ranh giới quyền hạn rõ ràng và có quy trình xử lý ngoại lệ.

Lấy việc phân luồng phiếu hỗ trợ làm ví dụ, có thể triển khai theo từng giai đoạn: trước tiên đọc phiếu và đề xuất phân loại; tiếp theo ghi thông tin phân loại sau khi nhân viên xác nhận; cuối cùng mới đánh giá khả năng tự động phân công xử lý các phiếu có quy tắc rõ ràng và có thể hoàn tác. Mỗi giai đoạn đều cần đặt ra điều kiện dừng; khi số trường hợp phân công sai tăng lên hoặc không thể kiểm toán, hãy quay lại bước xác nhận thủ công. Nếu cần đánh giá rủi ro tác tử vượt quá quyền hạn, bạn có thể tham khảo bài thảo luận về sự cố an toàn tác tử trên trang web, đồng thời lấy kết quả kiểm thử hệ thống thực tế làm căn cứ.

Bảo mật và quản trị: Cụ thể hóa các biện pháp kiểm soát thành mục kiểm tra

• Đặc quyền tối thiểu và danh tính riêng biệt: Chỉ cấp cho danh tính dịch vụ của tác tử quyền truy cập các hệ thống và thực hiện các thao tác cần thiết để hoàn thành nhiệm vụ; trước khi đưa vào vận hành, kiểm tra xem thông tin xác thực có được dành riêng, có thể luân chuyển và không kèm quyền ghi không liên quan hay không.
• Kiểm soát các trường dữ liệu nhạy cảm: Chỉ cung cấp cho mô hình thông tin cần thiết để hoàn thành nhiệm vụ; kiểm tra từng trường dữ liệu đầu vào, đầu ra và nhật ký, đồng thời xác minh rằng các quy tắc che giấu dữ liệu nhạy cảm có hiệu lực.
• Phòng chống chèn chỉ dẫn và vượt quyền: Coi văn bản bên ngoài như email, phiếu hỗ trợ và trang web là dữ liệu, không phải chỉ dẫn có thẩm quyền. Sử dụng nội dung kiểm thử có chỉ dẫn dụ thực hiện thêm lệnh gọi hoặc xuất dữ liệu để xác nhận rằng các quy tắc phân quyền vẫn từ chối hoặc yêu cầu xác nhận. Tài liệu bảo mật ứng dụng LLM của OWASP liệt kê chèn chỉ dẫn là một nhóm rủi ro cần lưu ý.
• Bảo vệ thao tác ghi: Thiết lập việc kiểm tra tính hợp lệ của tham số, xem trước tác động, phê duyệt và đọc lại kết quả đối với các thay đổi trên môi trường vận hành thực tế; xác minh rằng nội dung được phê duyệt khớp với nội dung thực sự được gửi đi.
• Tính lũy đẳng và xử lý ngoại lệ: Thiết kế khóa chống trùng lặp hoặc cơ chế kiểm tra trạng thái cho các thao tác có thể được gửi nhiều lần; kiểm thử riêng các trường hợp hết thời gian chờ, thử lại và thành công một phần để xác nhận có thể xác định trạng thái thực tế của hệ thống sau khi xảy ra lỗi.
• Kiểm toán và truy cứu trách nhiệm: Ghi lại thông tin cần thiết về danh tính, thao tác, thời gian, kết quả và phê duyệt, đồng thời kiểm soát quyền truy cập nhật ký; kiểm tra chọn mẫu xem một thay đổi nghiệp vụ có thể được truy vết đến lệnh gọi và căn cứ cấp quyền hay không.

Đối với đặc quyền tối thiểu, cấp quyền và khả năng kiểm toán, bạn cũng có thể đối chiếu với tài liệu về các mối đe dọa và biện pháp giảm thiểu đối với AI tác tử của OWASP, sau đó triển khai kết hợp với các quy định quản lý danh tính và kiểm toán của tổ chức; tài liệu này không thể thay thế việc đánh giá bảo mật cho từng hệ thống cụ thể.

Cách đo lường hiệu quả tích hợp

Đừng chỉ đánh giá câu trả lời có trôi chảy hay không. Về kỹ thuật, có thể theo dõi tỷ lệ hoàn thành nhiệm vụ, tỷ lệ tham số không vượt qua kiểm tra tính hợp lệ, tỷ lệ lỗi lệnh gọi, độ trễ phản hồi, số lần thực thi trùng lặp và tỷ lệ con người tiếp quản; về vận hành, hãy theo dõi thời gian xử lý, biến động khối lượng công việc tồn đọng, khối lượng công việc kiểm tra lại và chi phí gọi công cụ trên mỗi nhiệm vụ. Cần định nghĩa rõ cách tính các chỉ số ngay từ đầu, chẳng hạn “hoàn thành” nghĩa là công cụ trả về kết quả thành công, hay trạng thái trong hệ thống nghiệp vụ đã được xác nhận bằng cách đọc lại?

Trước khi thí điểm, hãy ghi nhận số liệu cơ sở của quy trình hiện tại, sau đó so sánh trên cùng phạm vi nhiệm vụ và phân biệt lỗi phán đoán của mô hình, sự cố giao diện tích hợp và thay đổi quy tắc nghiệp vụ. Nếu tự động hóa làm tăng gánh nặng kiểm tra thủ công, thì ngay cả khi tỷ lệ gọi thành công khá tốt, cũng không nên đơn giản kết luận rằng đã có sự cải thiện. Đừng đặt trước tỷ lệ lợi ích kỳ vọng; trước hết hãy dùng dữ liệu vận hành thực tế của doanh nghiệp để quyết định có mở rộng phạm vi hay không.

FAQ

Hệ thống cũ không có API, Agent vẫn có thể tích hợp được không? Có thể cân nhắc thông qua lớp trung gian được kiểm soát, nền tảng tích hợp hiện có hoặc RPA, nhưng trước tiên cần xác nhận độ ổn định của thao tác, khả năng quan sát và trách nhiệm bảo trì. Nếu quy trình có thao tác ghi rủi ro cao, nên giữ bước xác nhận của con người; không nên xem tự động hóa giao diện là tương đương với API ổn định.

Tích hợp Agent có bắt buộc phải sửa đổi hệ thống hiện có không? Không nhất thiết. Nếu hệ thống đã có API hoặc cơ chế sự kiện phù hợp, thường có thể xây dựng lớp công cụ và phân quyền bên ngoài hệ thống trước; nếu giao diện tích hợp chưa đáp ứng, hãy đánh giá việc bổ sung giao diện chỉ đọc, bộ chuyển đổi tích hợp hoặc sửa đổi cục bộ theo từng tác vụ. Nên kiểm chứng kịch bản bằng những thay đổi tối thiểu cần thiết.

Làm thế nào để tránh Agent thao tác sai hoặc vượt quyền? Giới hạn mục đích sử dụng, tham số và đối tượng có thể truy cập của từng công cụ, sử dụng danh tính dịch vụ riêng và quyền tối thiểu; đặt yêu cầu phê duyệt hoặc xác nhận cho các thao tác ghi trên môi trường vận hành thực tế, đồng thời ghi lại chủ thể gọi, đầu vào, kết quả và ngoại lệ. Cũng cần kiểm thử các tình huống chỉ dẫn độc hại hoặc nội dung không đáng tin cậy dụ Agent gọi công cụ.

Những tác vụ nào không nên tự động thực hiện ngay từ đầu? Các tác vụ có hậu quả khó đảo ngược, quy tắc không rõ ràng, phụ thuộc nhiều vào phán đoán ngầm hoặc thiếu phương thức xác minh đáng tin cậy không phù hợp để triển khai đầu tiên mà không có người giám sát. Có thể để Agent đưa ra đề xuất trước, nhân viên rà soát lại, rồi quyết định có mở rộng phạm vi tự động hóa hay không dựa trên loại lỗi và rủi ro kinh doanh.

Kết luận: Bắt đầu từ những thao tác nhỏ có thể kiểm chứng

Điểm mấu chốt khi tích hợp AI Agent với hệ thống hiện có của doanh nghiệp là thiết lập ranh giới năng lực rõ ràng: mô hình đề xuất kế hoạch, công cụ được kiểm soát kiểm tra và thực thi, cơ chế phân quyền và kiểm toán hạn chế rủi ro, còn hệ thống nghiệp vụ xác nhận kết quả cuối cùng. Bắt đầu từ các kịch bản chỉ đọc hoặc đưa ra đề xuất có rủi ro thấp và có thể kiểm chứng, sau đó từng bước đưa vào các thao tác ghi có phê duyệt, sẽ giúp đội ngũ phát hiện vấn đề về giao diện tích hợp, phân quyền và quản trị trong quy trình thực tế, thay vì giao ngay toàn bộ thao tác rủi ro cao cho tự động hóa.