AI Agent chạy trên cloud hay on-premise khác nhau như thế nào?

Khi bàn đến AI Agent cho bộ phận tài chính, nhân sự hay pháp chế, câu hỏi đầu tiên của nhiều trưởng IT là dữ liệu sẽ đi đâu. Dùng dịch vụ mô hình trên cloud thì nhanh và mạnh, nhưng nội dung câu hỏi, tài liệu nội bộ và kết quả tra cứu sẽ đi qua máy chủ của bên khác. Chạy mọi thứ trên máy chủ trong công ty thì kiểm soát được, nhưng cần phần cứng, người vận hành và chấp nhận mô hình có thể không mạnh bằng.

Thực tế lựa chọn không chỉ có hai đầu. Một AI Agent gồm nhiều thành phần: mô hình ngôn ngữ, kho kiến thức, lớp điều phối, các kết nối tới hệ thống nội bộ, nhật ký. Mỗi thành phần có thể đặt ở nơi khác nhau. Bài viết so sánh cloud và on-premise theo tám yếu tố, rồi đưa ra cách chọn kiến trúc từng bước, bao gồm cả phương án lai.

1. Bản chất của AI Agent cloud và on-premise

Cloud ở đây là khi mô hình ngôn ngữ, và thường cả lớp điều phối, chạy trên hạ tầng của nhà cung cấp dịch vụ; doanh nghiệp gọi qua API. On-premise là khi các thành phần này chạy trên máy chủ doanh nghiệp tự quản lý, trong trung tâm dữ liệu của mình hoặc môi trường riêng tương đương. Khác biệt cốt lõi là ai kiểm soát hạ tầng, dữ liệu nằm ở đâu và ai chịu trách nhiệm cập nhật.

Ba mức việc của agent ảnh hưởng trực tiếp tới lựa chọn. Hỏi đáp trên tài liệu công khai gần như không có lý do phải chạy tại chỗ. Tra cứu dữ liệu thời gian thực trong hệ thống nội bộ đặt ra câu hỏi về đường kết nối từ cloud vào mạng công ty. Hành động ghi vào hệ thống lõi thường được giữ trong mạng nội bộ, để thông tin xác thực của ERP hay hệ thống nhân sự không phải đưa ra ngoài.

2. Các yếu tố cần thiết kế

1. Độ nhạy dữ liệu

Phân loại dữ liệu agent sẽ xử lý thành công khai, nội bộ và nhạy cảm như dữ liệu cá nhân, lương, hồ sơ sức khỏe, hợp đồng. Mỗi loại cần một quyết định rõ: được phép gửi tới mô hình trên cloud hay không, nếu có thì sau khi che những trường nào. Nếu chỉ một phần nhỏ dữ liệu là nhạy cảm, thường có thể giữ phần đó tại chỗ thay vì đưa cả hệ thống về on-premise.

2. Hạ tầng sẵn có

Kiểm tra doanh nghiệp đang có gì: trung tâm dữ liệu, máy chủ có GPU, đội vận hành trực ngoài giờ, hay đã chuyển phần lớn hệ thống lên cloud. Chạy mô hình ngôn ngữ tại chỗ đòi hỏi phần cứng khác hẳn máy chủ ứng dụng thông thường. Nếu hạ tầng hiện tại không đáp ứng, on-premise kéo theo một dự án mua sắm và vận hành riêng.

3. Khả năng mở rộng

Lượng câu hỏi cho agent thường không đều: dồn vào đầu tháng, mùa cao điểm hoặc sau một đợt thông báo. Cloud tăng giảm tài nguyên theo nhu cầu dễ dàng. On-premise phải tính công suất cho lúc cao điểm, nghĩa là phần lớn thời gian tài nguyên để không. Cần ước lượng lượng dùng lúc thấp nhất và cao nhất trước khi quyết định.

4. Độ trễ

Độ trễ của agent đến từ nhiều chặng: gọi mô hình, tìm trong kho kiến thức, gọi API hệ thống nội bộ. Khi mô hình ở cloud nhưng dữ liệu ở trong mạng công ty, mỗi lượt tra cứu phải đi qua lại giữa hai nơi. Nên đo thử độ trễ của từng chặng với luồng thật, thay vì giả định on-premise luôn nhanh hơn.

5. Chi phí đầu tư

Cloud chủ yếu là chi phí theo mức dùng, dễ bắt đầu nhưng tăng theo lưu lượng. On-premise cần khoản đầu tư ban đầu cho phần cứng, phần mềm và nhân sự, sau đó chi phí biến đổi thấp hơn. So sánh cần tính cả chi phí điện, làm mát, sao lưu và thay thế phần cứng, không chỉ giá máy chủ. Cách lập ngân sách tổng thể có ở bài lập ngân sách AI Agent.

6. Cập nhật mô hình

Trên cloud, nhà cung cấp cập nhật mô hình định kỳ; doanh nghiệp được hưởng cải tiến nhưng cũng có thể gặp thay đổi hành vi không báo trước. Tại chỗ, doanh nghiệp tự quyết định khi nào nâng cấp, nhưng phải tự tải, thử và triển khai phiên bản mới. Dù ở đâu, mỗi lần đổi mô hình đều cần chạy lại bộ kiểm thử hồi quy.

7. Giám sát

Cần theo dõi cùng lúc tình trạng hạ tầng, chất lượng câu trả lời, lỗi kết nối và chi phí. Trên cloud, một phần số liệu có sẵn từ nhà cung cấp nhưng nằm ở hệ thống của họ. Tại chỗ, doanh nghiệp phải tự dựng công cụ giám sát. Với kiến trúc lai, nhật ký từ hai nơi nên được gom về một chỗ để truy vết được một yêu cầu từ đầu đến cuối.

8. Khôi phục sự cố

Hỏi trước: nếu dịch vụ mô hình trên cloud gián đoạn thì agent làm gì, nếu máy chủ tại chỗ hỏng thì mất bao lâu để chạy lại. Phương án tối thiểu là agent báo đang bảo trì và chuyển người dùng về kênh thủ công. Phương án cao hơn là có mô hình dự phòng hoặc máy chủ dự phòng, kèm quy trình chuyển đổi đã được thử.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Chọn luồng đầu tiên và mô tả dữ liệu nó cần, lượng người dùng dự kiến, yêu cầu về thời gian phản hồi. Đầu ra là bảng yêu cầu phi chức năng: độ trễ chấp nhận được, thời gian hoạt động mong muốn, loại dữ liệu xử lý. Người sở hữu nghiệp vụ và trưởng IT cùng xác nhận.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Phân loại từng nguồn dữ liệu theo mức nhạy cảm và ghi quyết định: được gửi ra cloud, chỉ gửi sau khi che, hay bắt buộc ở lại trong nhà. Đầu ra là bảng phân loại dữ liệu có chữ ký của người phụ trách an toàn thông tin. Bảng này là căn cứ chính để chọn kiến trúc, trước mọi yếu tố chi phí.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Vẽ sơ đồ luồng dữ liệu cho phương án được chọn, đánh dấu mọi điểm dữ liệu đi qua ranh giới mạng công ty. Với mỗi điểm, ghi dữ liệu nào đi qua, được mã hóa thế nào, ai cấp quyền. Thiết kế luôn phương án khi một phía mất kết nối. Đội hạ tầng và bộ phận an toàn thông tin duyệt sơ đồ này.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Chạy thử với luồng thật ở quy mô nhỏ, đo độ trễ từng chặng, theo dõi chi phí và kiểm tra nhật ký xem có dữ liệu nào đi ra ngoài ngoài dự kiến. Giả lập mất kết nối tới cloud và hỏng một máy chủ để thử phương án khôi phục. Kết quả đo là căn cứ để giữ nguyên hay điều chỉnh kiến trúc trước khi mở rộng.

4. Ví dụ giả định

Doanh nghiệp chọn kiến trúc lai: dữ liệu nhạy cảm ở hệ thống nội bộ, lớp điều phối dùng cloud với dữ liệu tối thiểu.

Điểm cần kiểm chứng trong kiến trúc này là “dữ liệu tối thiểu” có thực sự tối thiểu hay không. Ca thử nên gồm: một câu hỏi về chính sách chung, một câu hỏi cần tra số liệu lương của chính người hỏi, và một câu hỏi cố tình yêu cầu dữ liệu của người khác. Với mỗi ca, đối chiếu nhật ký ở cả hai phía để xác nhận phần gửi lên cloud chỉ gồm những gì bảng phân loại cho phép, và câu hỏi thứ ba bị chặn ngay ở hệ thống nội bộ.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Với cloud, rủi ro chính là gửi quá nhiều dữ liệu lên mô hình vì tiện, và phụ thuộc vào chính sách lưu trữ của nhà cung cấp. Với on-premise, rủi ro là hệ thống không được vá lỗi, không có người trực và mô hình tụt hậu so với thị trường. Với kiến trúc lai, rủi ro nằm ở đường kết nối giữa hai nơi và thông tin xác thực đặt sai chỗ. Nguyên tắc chung về kiểm soát dữ liệu có ở bài bảo mật dữ liệu AI Agent.

6. Phân chia trách nhiệm vận hành

Đội hạ tầng chịu trách nhiệm máy chủ, mạng, sao lưu và kết nối giữa hai môi trường. Bộ phận an toàn thông tin sở hữu bảng phân loại dữ liệu và duyệt mọi thay đổi về luồng dữ liệu ra ngoài. Người phụ trách ứng dụng quản lý cấu hình agent, phiên bản mô hình và bộ kiểm thử. Người sở hữu nghiệp vụ xác nhận chất lượng câu trả lời sau mỗi lần thay đổi.

Khi nhà cung cấp cloud đổi điều khoản, đổi khu vực lưu trữ hoặc ra phiên bản mô hình mới, cần có người được giao đọc thông báo và đánh giá ảnh hưởng. Với hệ thống tại chỗ, lịch vá lỗi và nâng cấp phải được lên kế hoạch như mọi hệ thống lõi khác, có cửa sổ bảo trì và phương án quay lại phiên bản cũ.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Với câu hỏi cloud hay on-premise, nên tách độ trễ theo từng chặng, chi phí theo từng thành phần và số lần gián đoạn theo từng môi trường. Thêm một chỉ số riêng: số yêu cầu có dữ liệu nhạy cảm bị chặn trước khi rời mạng nội bộ. Nếu con số này bằng không trong thời gian dài, cần kiểm tra lại xem bộ lọc có thực sự hoạt động.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

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

Doanh nghiệp vừa và nhỏ có nên chạy AI Agent on-premise không? Thường là không, trừ khi có yêu cầu bắt buộc về dữ liệu. Chạy mô hình ngôn ngữ tại chỗ cần máy chủ phù hợp, người vận hành và kế hoạch cập nhật. Với phần lớn doanh nghiệp, cloud kết hợp phân loại và giảm thiểu dữ liệu gửi đi là cách thực tế hơn.

Nên bắt đầu chọn kiến trúc từ đâu? Bắt đầu từ việc phân loại dữ liệu agent sẽ chạm: dữ liệu công khai, nội bộ và nhạy cảm. Sau đó xem mỗi loại được phép đi đâu. Hạ tầng hiện có và năng lực vận hành là yếu tố xét tiếp theo, không phải điểm khởi đầu.

Kiến trúc lai có phức tạp hơn nhiều không? Phức tạp hơn một môi trường đơn lẻ vì có thêm đường kết nối giữa hai nơi, hai lớp quyền và hai nơi cần giám sát. Đổi lại, doanh nghiệp giữ dữ liệu nhạy cảm trong nhà mà vẫn dùng được mô hình mạnh. Cần vẽ rõ luồng dữ liệu để biết chính xác phần nào đi ra ngoài.

Chạy on-premise có nghĩa là dữ liệu an toàn tuyệt đối không? Không. On-premise giúp kiểm soát nơi dữ liệu nằm, nhưng an toàn còn phụ thuộc phân quyền, vá lỗi, sao lưu và giám sát. Một hệ thống nội bộ không được cập nhật có thể rủi ro hơn một dịch vụ cloud được cấu hình tốt.

Kết luận

Cloud và on-premise không phải lựa chọn tất cả hoặc không có gì. Bắt đầu từ bảng phân loại dữ liệu, đặt từng thành phần của agent ở nơi phù hợp với độ nhạy của dữ liệu nó xử lý, rồi đo thực tế trước khi mở rộng. Nếu yêu cầu chính là dữ liệu phải nằm trong một khu vực nhất định, xem thêm bài data residency khi triển khai AI Agent.

Trao đổi với Naventic để vẽ luồng dữ liệu và chọn kiến trúc cho AI Agent nội bộ. Đọc thêm: AI Agent nội bộ.