SLA cho AI Agent nên bao gồm những chỉ số và cam kết nào?

Khi AI Agent bắt đầu trả lời khách hay tạo phiếu thay nhân viên, câu hỏi “nếu nó ngừng thì sao” không còn là chuyện riêng của đội kỹ thuật. Một buổi tối agent im lặng trên kênh chat có thể khiến hàng loạt khách không được phản hồi. Một lỗi ghi trùng vào CRM có thể mất nhiều ngày mới dọn xong.

SLA của phần mềm thông thường chủ yếu nói về thời gian hệ thống hoạt động. AI Agent phức tạp hơn: nó phụ thuộc vào dịch vụ mô hình ngôn ngữ, kho kiến thức, API nội bộ và kênh nhắn tin của bên thứ ba, và có thể vẫn “đang chạy” nhưng trả lời sai. Khi so sánh các đơn vị, bản dự thảo SLA cũng là một bằng chứng quan trọng, như đã nói trong bài cách đánh giá nhà cung cấp AI Agent.

Bài viết đi qua từng chỉ số nên có trong SLA, cách định nghĩa để hai bên cùng đo được, và những phần bên vận hành không thể cam kết thay cho người khác.

1. Bản chất của SLA AI Agent

SLA là thỏa thuận giữa doanh nghiệp và bên vận hành về mức dịch vụ: hệ thống cần sẵn sàng thế nào, khi lỗi thì ai phản hồi, trong bao lâu, và được đo bằng gì. Với AI Agent, thỏa thuận cần bao cả hai kiểu hỏng: hỏng hẳn, khi agent không phản hồi; và hỏng ngầm, khi agent vẫn trả lời nhưng lấy sai nguồn hoặc gọi sai công cụ.

Ba mức việc của agent nên có cam kết khác nhau. Phần hỏi đáp từ tài liệu thường chấp nhận tạm dừng ngắn nếu có thông báo và kênh liên hệ thay thế. Phần tra cứu thời gian thực, như trạng thái đơn hay lịch trống, phụ thuộc hệ thống nguồn, nên SLA phải nói rõ khi nguồn lỗi thì agent báo gì với người dùng. Phần ghi, như tạo phiếu hay cập nhật CRM, cần cam kết chặt nhất về chống ghi trùng, nhật ký và khả năng khôi phục, vì lỗi ở đây để lại hậu quả trong dữ liệu.

2. Các chỉ số và cam kết cần có

1. Thời gian sẵn sàng

Cần định nghĩa “sẵn sàng” trước khi bàn con số: agent trả lời được tin nhắn, hay trả lời được và tra cứu được dữ liệu thật. Nên đo từ phía người dùng, bằng các lượt kiểm tra tự động gửi câu hỏi mẫu theo chu kỳ, thay vì chỉ xem máy chủ còn chạy. Mức cam kết cụ thể tùy tầm quan trọng của quy trình và hạ tầng đã chọn, và các khung bảo trì đã báo trước nên được loại trừ rõ.

2. Thời gian phản hồi sự cố

Đây là khoảng từ lúc sự cố được ghi nhận đến lúc có người bắt đầu xử lý, khác với thời gian khắc phục xong. SLA nên nêu cả hai và nói rõ đồng hồ bắt đầu tính từ khi nào: lúc cảnh báo tự động phát ra hay lúc doanh nghiệp gửi báo lỗi. Nếu chỉ ghi “phản hồi trong giờ hành chính” trong khi agent chạy cả cuối tuần, khoảng trống đó phải được viết ra để hai bên cùng biết.

3. Mức độ nghiêm trọng

Phân mức sự cố giúp thời gian phản hồi có ý nghĩa. Một cách chia dễ dùng: nghiêm trọng khi agent ngừng hẳn hoặc ghi sai dữ liệu hàng loạt; cao khi một tích hợp chính lỗi hoặc agent trả lời sai về giá, chính sách; trung bình khi một nhóm câu hỏi bị ảnh hưởng; thấp với lỗi hiển thị hay yêu cầu cải tiến. Mỗi mức cần ví dụ theo đúng quy trình của doanh nghiệp để hai bên không tranh cãi khi phân loại.

4. RTO và RPO

RTO là thời gian tối đa chấp nhận được để khôi phục dịch vụ; RPO là lượng dữ liệu tối đa chấp nhận mất, tính bằng khoảng thời gian. Với AI Agent, thứ cần khôi phục không chỉ là cơ sở dữ liệu hội thoại mà còn kho kiến thức, cấu hình prompt, danh sách công cụ và quyền. Trong SLA, hai chỉ số này nên được đặt theo từng thành phần; cách chuẩn bị để đạt được chúng có ở bài kế hoạch khôi phục sự cố AI Agent.

5. Giới hạn phụ thuộc

Agent thường dựa vào dịch vụ mô hình ngôn ngữ, nền tảng nhắn tin, CRM hay ERP của chính doanh nghiệp. Bên vận hành agent không thể cam kết thay cho những dịch vụ họ không kiểm soát. SLA nên liệt kê từng phụ thuộc, ai chịu trách nhiệm, và điều bên vận hành vẫn cam kết khi phụ thuộc đó lỗi: phát hiện, thông báo, chuyển agent sang chế độ dự phòng.

6. Bảo trì định kỳ

Bảo trì gồm cập nhật kho kiến thức, nâng phiên bản mô hình, sửa prompt và vá thư viện. Mỗi việc đều có thể làm câu trả lời của agent thay đổi, nên SLA cần quy định lịch bảo trì, thời gian báo trước, và việc chạy lại bộ kiểm thử trước khi đưa lên môi trường thật. Bảo trì khẩn ngoài lịch cần một người phía doanh nghiệp đồng ý.

7. Báo cáo

Báo cáo định kỳ nên có thời gian sẵn sàng thực tế, danh sách sự cố theo mức, thời gian phản hồi và khắc phục của từng sự cố, cùng các thay đổi đã triển khai trong kỳ. Với AI Agent, nên thêm chỉ số chất lượng như tỷ lệ từ chối đúng hay số câu bị chuyển người. Báo cáo chỉ nêu số hội thoại thì không đủ để biết SLA có được giữ hay không.

8. Quy trình escalation

Escalation là đường nâng cấp khi sự cố xử lý chậm hoặc vượt thẩm quyền người đang xử lý. SLA cần danh sách đầu mối theo từng cấp ở cả hai phía, kèm kênh liên lạc và điều kiện chuyển cấp. Nếu sự cố nghiêm trọng đã quá thời gian cam kết mà chưa có hướng xử lý, người có thẩm quyền phía doanh nghiệp phải được báo và có quyền yêu cầu tạm dừng agent.

3. Quy trình xây dựng SLA thực tế

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

Liệt kê những gì SLA bao gồm: kênh nào, chức năng nào, khung giờ nào. Với từng chức năng, ghi hậu quả kinh doanh nếu nó ngừng trong một giờ hoặc một ngày. Đầu ra là bảng chức năng xếp theo mức quan trọng, do người sở hữu nghiệp vụ duyệt; bảng này quyết định mức cam kết cho từng phần.

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

Thống nhất nguồn số liệu dùng để đo SLA: công cụ giám sát nào, nhật ký nào, múi giờ nào. Cả hai bên cần xem được cùng một dữ liệu; nếu chỉ bên vận hành giữ số liệu, doanh nghiệp không có cách kiểm chứng. Quyền xem bảng giám sát của người phụ trách phía doanh nghiệp được ghi rõ trong phụ lục.

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

Với mỗi phụ thuộc, thiết kế hành vi của agent khi nó lỗi: báo khách thế nào, yêu cầu được ghi nhận ở đâu, ai xử lý tay. Viết thêm danh sách trường hợp loại trừ khỏi SLA và quy trình phê duyệt bảo trì khẩn. Đội kỹ thuật hai bên soạn, người sở hữu nghiệp vụ duyệt, vì đây là trải nghiệm khách sẽ nhận khi có sự cố.

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

Trước khi ký chính thức, chạy thử quy trình sự cố: tắt một tích hợp trong môi trường thử, xem cảnh báo có phát ra không, ai nhận, bao lâu có phản hồi. Sau vài kỳ báo cáo, xem lại những sự cố bị xếp sai mức hoặc chỉ số không phản ánh trải nghiệm thật, rồi điều chỉnh SLA thành phiên bản mới có ngày hiệu lực.

4. Ví dụ giả định

SLA tách lỗi chatbot, lỗi CRM và lỗi nhà cung cấp kênh, tránh quy trách nhiệm sai khi một dịch vụ bên thứ ba ngừng hoạt động.

Từ ví dụ này có thể dựng ba ca diễn tập: kênh nhắn tin ngừng nhận tin, CRM trả lỗi khi agent tạo lead, và agent vẫn trả lời nhưng lấy nhầm bảng giá cũ. Mỗi ca ghi rõ lỗi thuộc bên nào, ai được báo, agent phản ứng ra sao và sự cố được xếp mức nào. Ca thứ ba đáng chú ý nhất: hệ thống vẫn “sẵn sàng” theo mọi công cụ giám sát, nên SLA phải có cách ghi nhận lỗi chất lượng chứ không chỉ lỗi ngừng hoạt động.

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

Rủi ro phổ biến là SLA đẹp trên giấy nhưng không đo được, hoặc đo bằng số liệu chỉ một bên nắm. Rủi ro thứ hai là cam kết thời gian sẵn sàng cao nhưng bỏ ngỏ chất lượng câu trả lời, khiến agent trả lời sai nhiều ngày vẫn không vi phạm gì. SLA cũng không thay được thiết kế an toàn: quyền tối thiểu, người duyệt cho thao tác quan trọng và nhật ký vẫn phải có từ đầu, SLA chỉ quy định ai phản ứng và trong bao lâu khi các lớp đó bị vượt qua.

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

Bên vận hành agent chịu trách nhiệm giám sát, phát hiện sự cố, khắc phục phần mình kiểm soát và gửi báo cáo định kỳ. Đội IT của doanh nghiệp chịu trách nhiệm các hệ thống nội bộ mà agent kết nối, và phải báo trước khi đổi API hay quyền. Người sở hữu nghiệp vụ duyệt cách phân mức sự cố, xác nhận nội dung thông báo cho khách và quyết định khi nào chuyển sang xử lý thủ công.

SLA cũng cần một người phía doanh nghiệp đọc báo cáo và đối chiếu với trải nghiệm thật, thường là quản lý chăm sóc khách hàng hoặc quản lý vận hành. Khi SLA bị vi phạm lặp lại, người này đưa vấn đề vào buổi rà soát định kỳ giữa hai bên thay vì chỉ để nó nằm trong báo cáo.

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

Chỉ số trong SLA nên tách hai lớp. Lớp dịch vụ gồm thời gian sẵn sàng, thời gian phản hồi và khắc phục theo từng mức sự cố. Lớp chất lượng gồm tỷ lệ trả lời đúng, từ chối đúng và chuyển người đúng theo từng loại yêu cầu. Chỉ nhìn lớp đầu, doanh nghiệp dễ hài lòng với một agent luôn bật nhưng thường xuyên trả lời sai.

8. Checklist trước khi ký SLA

• 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ó thể áp dụng SLA cho AI Agent ngay từ giai đoạn thí điểm không? Có thể áp một bản nhẹ, tập trung vào kênh báo lỗi, đầu mối hai bên và cách tạm dừng agent. Các mức cam kết nên chốt sau khi đã có số liệu vận hành thật từ đợt thí điểm, thay vì đặt theo cảm tính.

Nên bắt đầu soạn SLA cho AI Agent từ đâu? Bắt đầu từ bảng chức năng xếp theo mức quan trọng và danh sách các hệ thống agent phụ thuộc. Hai bảng này cho biết phần nào cần cam kết chặt, phần nào chấp nhận gián đoạn, và lỗi nào thuộc trách nhiệm bên nào.

Khi nào sự cố AI Agent cần người có thẩm quyền quyết định? Khi sự cố ở mức nghiêm trọng, khi phải tạm dừng agent trên kênh khách hàng, hoặc khi agent đã ghi sai dữ liệu vào hệ thống. Những quyết định này ảnh hưởng tới khách và dữ liệu nên không để người trực kỹ thuật tự quyết.

SLA có nên cam kết độ chính xác câu trả lời không? Nên có chỉ số chất lượng, nhưng đo trên bộ câu hỏi kiểm thử đã thống nhất và tách theo nhóm chủ đề. Một con số chính xác chung cho mọi câu hỏi khó kiểm chứng và dễ gây tranh cãi giữa hai bên.

Kết luận

SLA cho AI Agent tốt là bản mà cả hai bên đều đo được và hiểu giống nhau. Ngoài thời gian sẵn sàng và phản hồi sự cố, nó cần phân mức rõ, tách trách nhiệm theo từng phụ thuộc và có chỉ số chất lượng cho những lỗi mà công cụ giám sát không tự thấy.

Trao đổi với Naventic để thống nhất phạm vi vận hành và cam kết hỗ trợ cho AI Agent. Đọc thêm: Dịch vụ.