Tự xây hay thuê đơn vị triển khai AI Agent: Nên chọn phương án nào?

Tự xây hay thuê AI Agent: so năng lực đội nội bộ, tốc độ, quyền sở hữu mã nguồn, chi phí nhân sự và bảo trì để chọn tự làm, giao đơn vị hay kết hợp.
Sau khi đã chọn được bài toán cho AI Agent, câu hỏi tiếp theo của nhiều doanh nghiệp là ai sẽ làm. Đội IT nội bộ đã quen hệ thống và muốn tự làm. Ban giám đốc lại lo đội IT đang quá tải và chưa từng đưa một mô hình ngôn ngữ vào vận hành thật. Đơn vị bên ngoài thì làm nhanh hơn, nhưng doanh nghiệp sợ bị phụ thuộc.
Đây là câu hỏi về năng lực và tổ chức, khác với câu hỏi nên xây riêng hay dùng nền tảng có sẵn. Câu hỏi đó đã được phân tích ở bài nên xây AI Agent riêng hay dùng nền tảng có sẵn. Ở đây giả sử doanh nghiệp đã chọn làm giải pháp tùy chỉnh, và đang cân nhắc giữa ba cách: đội nội bộ tự làm, giao toàn bộ cho đơn vị triển khai, hoặc kết hợp hai bên.
Bài viết đưa ra tám yếu tố để so sánh, cách ra quyết định theo từng bước và cách chia việc khi chọn mô hình kết hợp.
1. Bản chất của việc tự xây hay giao đơn vị triển khai
Một dự án AI Agent cần nhiều loại kỹ năng cùng lúc: hiểu nghiệp vụ để viết quy tắc và tình huống, xử lý dữ liệu để dựng kho kiến thức, tích hợp hệ thống, thiết kế prompt và kiểm thử hành vi của mô hình, rồi vận hành lâu dài. Hiếm doanh nghiệp nào có đủ tất cả trong đội hiện tại. Vì vậy câu hỏi thực chất không phải “tự làm hay không”, mà là phần việc nào nên giữ trong nhà, phần nào nên giao ra ngoài.
Mức độ phức tạp của agent cũng ảnh hưởng tới lựa chọn. Agent chỉ hỏi đáp trên tài liệu có thể do đội nội bộ làm nếu có người hiểu dữ liệu. Agent tra cứu dữ liệu thời gian thực đòi hỏi kinh nghiệm tích hợp và xử lý lỗi kết nối. Agent có hành động ghi vào hệ thống cần thêm thiết kế phê duyệt, chống lặp và nhật ký, là phần dễ sai nhất nếu làm lần đầu.
2. Các yếu tố cần thiết kế
1. Năng lực nội bộ
Đánh giá thật những gì đội hiện tại đã từng làm, không phải những gì họ có thể học. Đội đã tích hợp API với CRM, ERP chưa, đã vận hành hệ thống có người dùng bên ngoài chưa, có ai hiểu cách kiểm thử một hệ thống có kết quả không cố định không. Nếu câu trả lời phần lớn là chưa, tự làm đồng nghĩa với vừa học vừa làm trên hệ thống thật.
2. Tốc độ triển khai
Đơn vị đã làm nhiều dự án tương tự có sẵn quy trình, mẫu tài liệu và kinh nghiệm về các lỗi thường gặp, nên thường đi nhanh hơn ở giai đoạn đầu. Đội nội bộ đi chậm hơn nhưng không mất thời gian tìm hiểu nghiệp vụ. Nếu có hạn chót kinh doanh rõ ràng, tốc độ nên có trọng số cao; nếu không, năng lực tích lũy lâu dài có thể quan trọng hơn.
3. Quyền sở hữu mã nguồn
Khi giao ra ngoài, cần làm rõ doanh nghiệp sở hữu những gì: mã nguồn riêng của dự án, cấu hình, prompt, kho kiến thức, dữ liệu hội thoại. Phần nào dựa trên nền tảng hoặc thư viện của đơn vị triển khai thì hỏi rõ điều kiện sử dụng khi ngừng hợp tác. Tự làm thì sở hữu đầy đủ, nhưng cũng tự chịu toàn bộ trách nhiệm bảo trì.
4. Chi phí nhân sự
Tự làm không miễn phí: cần tính lương người tham gia, thời gian họ rời khỏi việc khác, chi phí tuyển nếu thiếu người và chi phí khi người đó nghỉ việc giữa chừng. Giao ra ngoài có chi phí hợp đồng rõ ràng nhưng doanh nghiệp vẫn phải bố trí người nội bộ làm việc cùng. So sánh công bằng phải tính cả hai phía.
5. Rủi ro tích hợp
Phần tích hợp với hệ thống lõi là nơi sai sót gây hậu quả lớn nhất, ví dụ tạo đơn trùng hay ghi sai trạng thái khách hàng. Đội nội bộ hiểu hệ thống nhưng có thể thiếu kinh nghiệm thiết kế thao tác ghi an toàn cho agent. Đơn vị bên ngoài có kinh nghiệm nhưng cần được cấp quyền và tài liệu. Dù chọn cách nào, phần này cần môi trường thử và người nội bộ duyệt thiết kế.
6. Bảo trì
Agent cần được cập nhật mỗi khi chính sách, giá, sản phẩm hay hệ thống thay đổi, và cần người đọc nhật ký để phát hiện câu trả lời sai. Hỏi rõ sau khi bàn giao ai làm việc này, trong bao lâu, với chi phí nào. Nếu giao ngoài mà không có kế hoạch bảo trì, agent sẽ xuống cấp dần sau vài tháng. Các việc bảo trì định kỳ được trình bày ở bài bảo trì AI Agent.
7. Mức tùy chỉnh
Quy trình càng đặc thù thì người hiểu nghiệp vụ càng phải ngồi gần người làm kỹ thuật. Với các luồng phổ biến như hỏi đáp chính sách hay tra cứu đơn hàng, đơn vị bên ngoài thường có sẵn cách làm. Với quy trình riêng, nhiều ngoại lệ, dù giao ngoài vẫn cần người nội bộ tham gia hằng tuần, không thể chỉ gửi yêu cầu rồi chờ kết quả.
8. Lộ trình dài hạn
Nếu doanh nghiệp định dùng AI Agent ở nhiều bộ phận trong vài năm tới, xây dựng năng lực nội bộ là khoản đầu tư có ý nghĩa. Nếu chỉ cần giải quyết một bài toán cụ thể, giao ngoài và giữ một người nội bộ nắm hệ thống thường hợp lý hơn. Lộ trình này nên được viết ra trước khi chọn, vì nó quyết định có nên đưa người nội bộ vào dự án đầu tiên hay không.
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
Mô tả bài toán đầu tiên và các bài toán dự kiến sau đó, kèm kết quả cần đạt và hạn chót nếu có. Đầu ra là bảng liệt kê các loại việc của dự án: khảo sát, dữ liệu, tích hợp, kiểm thử, vận hành. Ban giám đốc và trưởng IT cùng xác nhận bảng này.
Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập
Với từng loại việc, đánh dấu đội nội bộ đã làm được, làm được nếu có hỗ trợ, hay chưa làm được. Đồng thời xác định dữ liệu và hệ thống nào có thể cấp quyền cho bên ngoài, dữ liệu nào bắt buộc giữ trong nhà. Đầu ra là bảng năng lực và bảng ràng buộc dữ liệu, dùng làm căn cứ chia việc.
Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt
Từ hai bảng trên, chọn mô hình: tự làm, giao ngoài hay kết hợp. Nếu kết hợp, viết rõ bên nào làm phần nào, ai duyệt thiết kế tích hợp, ai duyệt hành động ghi, ai giữ tài khoản quản trị. Nếu cần gửi yêu cầu cho nhiều đơn vị, dùng cấu trúc ở bài cách viết RFP cho dự án AI Agent.
Bước 4: Kiểm thử vận hành rồi cải thiện theo log
Trong giai đoạn thử, người nội bộ trực tiếp chạy bộ tình huống, đọc nhật ký và tự sửa vài lỗi nội dung dưới sự hướng dẫn của đơn vị triển khai. Đầu ra là danh sách việc đội nội bộ đã tự làm được và việc còn phụ thuộc bên ngoài. Danh sách này quyết định thời điểm chuyển giao vận hành.
4. Ví dụ giả định
Một công ty giữ đội dữ liệu nội bộ nhưng giao đơn vị bên ngoài làm phần tích hợp ban đầu, sau đó tiếp nhận tài liệu và vận hành theo mô hình kết hợp.
Bài học từ mô hình này là chuyển giao phải được kiểm chứng bằng việc làm, không chỉ bằng tài liệu. Các ca thử cho giai đoạn chuyển giao nên gồm: đội nội bộ tự cập nhật một chính sách mới và kiểm tra agent trả lời đúng, tự xử lý một lỗi kết nối giả lập, và tự thêm một tình huống vào bộ kiểm thử hồi quy. Ca nào đội nội bộ chưa làm được thì kéo dài thời gian hỗ trợ cho đúng phần đó.
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
Tự làm có rủi ro phụ thuộc vào một hai người: khi họ nghỉ, không ai hiểu hệ thống. Giao ngoài có rủi ro phụ thuộc vào đơn vị bên ngoài và rủi ro cấp quyền rộng cho bên thứ ba. Mô hình kết hợp có rủi ro ranh giới trách nhiệm mờ, sự cố xảy ra thì hai bên đổ cho nhau. Với cả ba, cách giảm rủi ro giống nhau: tài liệu hóa, phân quyền tối thiểu và ghi rõ trách nhiệm bằng văn bản.
6. Phân chia trách nhiệm vận hành
Trong mô hình kết hợp phổ biến, doanh nghiệp giữ quyền sở hữu nghiệp vụ, nội dung kho kiến thức, quyết định về phạm vi và tài khoản quản trị. Đơn vị triển khai chịu trách nhiệm kiến trúc, tích hợp, kiểm thử kỹ thuật và hỗ trợ sự cố trong thời gian cam kết. Người nội bộ được chỉ định làm đầu mối kỹ thuật, tham gia mọi buổi thiết kế và dần nhận việc vận hành.
Mọi thay đổi về prompt, mô hình, nguồn dữ liệu hay quyền cần được ghi lại, dù bên nào thực hiện. Khi có sự cố, doanh nghiệp phải là bên có quyền tạm dừng agent và chuyển về quy trình thủ công, không phụ thuộc vào việc liên lạc được với đơn vị bên ngoài.
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
Ngoài chất lượng của agent, nên theo dõi tỷ lệ thay đổi đội nội bộ tự thực hiện được so với số thay đổi phải nhờ bên ngoài, và thời gian xử lý sự cố theo từng bên. Hai chỉ số này cho biết mô hình đang chọn có thực sự xây được năng lực hay doanh nghiệp vẫn phụ thuộc như ngày đầu.
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
Công ty chưa có kỹ sư AI có tự làm AI Agent được không? Có thể làm những bản thử nhỏ, nhưng đưa vào vận hành thật thì khó nếu không có người hiểu tích hợp, phân quyền và kiểm thử mô hình ngôn ngữ. Phương án hợp lý hơn thường là giao phần dựng ban đầu cho đơn vị có kinh nghiệm, đồng thời cử người nội bộ tham gia từ đầu để tiếp nhận.
Nên bắt đầu đánh giá phương án từ đâu? Bắt đầu bằng việc liệt kê những việc dự án cần: khảo sát nghiệp vụ, chuẩn bị dữ liệu, tích hợp, kiểm thử, vận hành. Sau đó đánh dấu việc nào đội hiện tại làm được, việc nào phải tuyển hoặc giao ra ngoài. Bảng này thường tự cho thấy phương án phù hợp.
Giao đơn vị bên ngoài thì doanh nghiệp có bị phụ thuộc không? Có nguy cơ nếu hợp đồng không nói rõ quyền sở hữu và bàn giao. Cần thống nhất trước doanh nghiệp nhận được gì: cấu hình, prompt, kho kiến thức, tài liệu tích hợp, quyền quản trị và mã nguồn nếu có, cùng thời gian hỗ trợ chuyển giao.
Khi nào nên chuyển từ giao ngoài sang tự vận hành? Khi agent đã ổn định, số thay đổi mỗi tháng chủ yếu là cập nhật nội dung và quy tắc, và đội nội bộ đã tự xử lý được vài sự cố dưới sự hỗ trợ của đơn vị triển khai. Chuyển sớm hơn thì rủi ro gián đoạn cao.
Kết luận
Không có đáp án chung cho câu hỏi tự làm hay giao ngoài. Doanh nghiệp có đội kỹ thuật mạnh và lộ trình dài có thể tự làm; doanh nghiệp cần kết quả sớm nên giao ngoài; phần lớn sẽ hợp với mô hình kết hợp, miễn là chuyển giao được kiểm chứng bằng việc làm thật. Nếu còn băn khoăn nên đặt hệ thống ở đâu, xem bài AI Agent chạy trên cloud hay on-premise.
Trao đổi với Naventic để đánh giá năng lực nội bộ và chọn cách chia việc phù hợp. Đọc thêm: Dịch vụ.


