Playbook ứng phó sự cố cho AI agent: Hướng dẫn thực tế cho đội production

Playbook ứng phó sự cố cho AI agent cho đội ngũ biết phải làm gì khi một agent hoạt động sai trên production: phát hiện bằng cách nào, nghiêm trọng đến đâu, chặn thiệt hại ra sao, ai quyết định, và cần thay đổi gì trước khi agent chạy lại. Nó quan trọng vì agent hỏng theo cách khác phần mềm thông thường. Một nút bấm lỗi thì lỗi rõ ràng; một agent có vấn đề vẫn tiếp tục chạy và đưa ra những quyết định sai một cách đầy tự tin.

Rủi ro này rất thực tế. Một agent phân loại yêu cầu hỗ trợ chuyển một vấn đề khẩn của khách hàng vào nhầm hàng chờ. Một agent báo cáo phát hành bản tóm tắt dựa trên dữ liệu cũ. Một agent nghiên cứu cứ tiếp tục trích dẫn một nguồn yếu. Trong mỗi trường hợp, đội ngũ cần một đường xử lý có sẵn trước khi agent ảnh hưởng đến khách hàng, báo cáo hay các quyết định phía sau.

Bài viết đi qua các loại sự cố cần lên kế hoạch, các mức độ nghiêm trọng, bảy bước xây playbook, vòng ứng phó và ba ví dụ cụ thể. Đây là bài đi kèm cẩm nang vận hành AI agent và chuyển cấp xử lý cho con người, nơi nói về mô hình vận hành hằng ngày giúp sự cố ít xảy ra.

Playbook gồm những gì

Một kế hoạch ứng phó sự cố truyền thống tập trung vào sự kiện bảo mật, sự cố gián đoạn dịch vụ và lỗi hạ tầng. Hướng dẫn xử lý sự cố bảo mật máy tính của NIST mô tả vòng đời đó từ chuẩn bị đến rút kinh nghiệm, và cấu trúc này vẫn dùng được. Agent mang đến những cách hỏng mới: truy xuất kém, suy luận sai, gọi nhầm công cụ, bỏ lỡ bước chuyển cho người, vi phạm chính sách và những hành động tự động không ai kiểm duyệt.

Với mỗi agent, playbook nên nêu rõ:

• agent được phép làm gì, và đang giữ những công cụ nào
• kết quả hoặc hành động nào được coi là sự cố
• mức độ nghiêm trọng được phân loại ra sao
• những log và dấu vết (trace) nào phải được rà soát
• ai có quyền tạm dừng, giới hạn hoặc cho agent chạy lại
• khi nào con người phải phê duyệt bước tiếp theo
• prompt, công cụ, quyền và bộ đánh giá thay đổi thế nào sau sự cố

Khung quản lý rủi ro AI của NIST coi quản lý rủi ro AI là hoạt động xuyên suốt vòng đời, từ thiết kế, phát triển, sử dụng đến đánh giá. Playbook là nơi vòng đời đó trở nên cụ thể với người đang trực.

Sáu loại sự cố cần lên kế hoạch

Hãy nhóm sự cố theo cách chúng hỏng, rồi tinh chỉnh các nhóm sau những lần rà soát thực tế.

| Loại sự cố | Ví dụ | Tín hiệu phát hiện | Phản ứng đầu tiên | Người phụ trách | | --- | --- | --- | --- | --- | | Đầu vào và prompt | Người dùng yêu cầu agent bỏ qua chính sách | Cờ chính sách, mẫu chỉ dẫn không an toàn | Chặn hoặc chuyển sang kiểm duyệt | Người phụ trách sản phẩm hoặc an toàn | | Truy xuất và chất lượng dữ liệu | Agent dùng dữ liệu khách hàng hoặc nguồn đã cũ | Dấu thời gian của nguồn, kiểm tra trích dẫn thất bại | Dừng kết quả bị ảnh hưởng | Người phụ trách dữ liệu | | Suy luận và quyết định | Agent chọn sai mức ưu tiên hoặc phân loại | Con người ghi đè, bộ đánh giá thất bại | Sửa quyết định, xem lại trace | Người phụ trách quy trình | | Dùng công cụ và hành động | Agent gửi, cập nhật hoặc xóa nhầm mục | Lời gọi công cụ bất thường, quyền không khớp | Thu hồi hoặc thu hẹp quyền dùng công cụ | Người phụ trách kỹ thuật | | Chuyển cấp và bàn giao | Agent cứ làm tiếp thay vì hỏi con người | Độ tin cậy giảm, thử lại nhiều lần | Chuyển sang chỉ con người xử lý | Người phụ trách vận hành | | Báo cáo và giám sát | Agent phát hành một báo cáo tự động sai | Chỉ số lệch nhau, các nguồn mâu thuẫn | Rút báo cáo, gắn nhãn đang rà soát | Người phụ trách BI hoặc phân tích |

Hãy để bảng này ở nơi người vận hành làm việc, đừng cất trong thư mục chính sách. Nó cũng tách playbook khỏi các biện pháp kiểm soát xung quanh: guardrail cố ngăn hành vi không an toàn, bộ đánh giá kiểm tra hành vi trước và sau mỗi lần phát hành, giám sát phát hiện tín hiệu trên production, còn playbook nối cả ba lại khi sự cố vẫn xảy ra.

Xây playbook trong bảy bước

Bắt đầu với một quy trình, một agent và những sự cố gây rủi ro kinh doanh thật, đừng bắt đầu bằng một tài liệu quản trị đồ sộ.

1. Vẽ ra trách nhiệm và hành động được phép. Liệt kê những gì agent được đọc, ghi, đề xuất, phê duyệt, gửi, xóa hoặc chuyển cấp. Quyền dùng công cụ quyết định sự cố có thể tệ đến mức nào.
2. Định nghĩa mức độ nghiêm trọng. Giữ chúng sát với vận hành: thấp, lỗi đầu ra vô hại; trung bình, con người phải sửa trước khi đến tay khách hàng; cao, có thể ảnh hưởng đến quyết định liên quan khách hàng, tài chính, tuân thủ hoặc ban lãnh đạo; nghiêm trọng, tự động hóa phải dừng ngay.
3. Đặt tín hiệu phát hiện. Rà soát đầu ra, log lời gọi công cụ, metadata truy xuất, điểm tin cậy, cờ chính sách, lần con người ghi đè, số lần thử lại và phản ánh từ phía sau.
4. Chuẩn bị hành động khoanh vùng. Quyết định trước khi nào tạm dừng agent, giới hạn một công cụ, bắt buộc chế độ kiểm duyệt, hoàn tác một hành động, rút một báo cáo hoặc chuyển quy trình sang chỉ con người xử lý.
5. Chỉ định người phụ trách. Mỗi mức độ cần một người phụ trách có tên và một người dự phòng. "Đội AI" không phải là người phụ trách; trưởng nhóm hỗ trợ, người phụ trách dữ liệu, người phụ trách kỹ thuật hay người rà soát tuân thủ mới là.
6. Thiết kế vòng kiểm duyệt của con người. Hành động rủi ro cao nên dừng lại trước khi trở nên khó hoàn tác, không phải được rà soát sau. Xem cách thiết kế AI agent có vòng kiểm duyệt của con người.
7. Khép vòng rút kinh nghiệm. Mỗi sự cố phải thay đổi một điều gì đó: prompt, nguồn truy xuất, quyền công cụ, ca kiểm thử trong bộ đánh giá, dashboard, quy tắc chuyển cấp hoặc việc đào tạo người vận hành.

Khoanh vùng từ khâu thiết kế: các hệ thống của chúng tôi làm gì

Sự cố rẻ nhất là sự cố mà kiến trúc khiến nó không thể xảy ra hoặc vô hại. Bốn cách làm từ các hệ thống agent chúng tôi đã xây:

• Ngưỡng tin cậy giữ lại kết quả. Với Zeno, chương trình tập do AI tạo bị giữ lại sau ngưỡng tin cậy 85% trước khi đến tay người dùng. Kết quả có độ tin cậy thấp bị giữ lại thay vì hiển thị kèm lời cảnh báo, nên cả một nhóm sự cố không bao giờ lên đến production.
• Cô lập ở tầng dữ liệu. Với OBJX Intelligence, việc cô lập giữa các tenant được thực thi bằng mô hình phân quyền năm cấp ở tầng dữ liệu, không phải bằng chỉ dẫn cho agent. Một đòn prompt injection không thể làm lộ dữ liệu của tenant khác, vì agent không hề giữ quyền đó.
• Trace cho mọi lần chạy. alice/ai ghi vết các lần chạy agent trong LangSmith. Khi supervisor chuyển một yêu cầu qua hơn 70 công cụ kết nối bằng MCP, chính trace biến câu "agent làm gì đó lạ" thành một lời gọi công cụ cụ thể cần sửa.
• Dữ liệu chạy lại an toàn. Agent đọc dữ liệu từ pipeline sẽ thừa hưởng sự cố của pipeline. Pipeline thị trường điện của chúng tôi ghi mỗi báo cáo năm phút theo kiểu idempotent, nên sau một sự cố ở nguồn, cách sửa chỉ là chạy lại, không có dòng trùng lặp nào chảy vào báo cáo hay agent.

Vòng ứng phó

Vòng ứng phó phải đủ ngắn để làm theo khi đang chịu áp lực: phát hiện tín hiệu, phân loại mức độ, khoanh vùng hành vi của agent, chuyển cho người phụ trách, rà soát log và bằng chứng, sửa prompt, dữ liệu, công cụ hoặc quy trình, kiểm chứng bằng test, rồi chạy lại có giám sát. Các quy tắc quyết định giúp không ai phải chần chừ ở những thời điểm quan trọng:

| Quyết định | Quy tắc | | --- | --- | | Tạm dừng agent | Hành động có thể ảnh hưởng đến khách hàng, tiền, tuân thủ, quyền truy cập hoặc báo cáo cho ban lãnh đạo | | Tiếp tục có giám sát | Agent được soạn nháp hoặc đề xuất, nhưng con người phê duyệt mọi hành động | | Chuyển sang chỉ con người | Log không đầy đủ, chưa rõ nguyên nhân gốc, hoặc lỗi lặp lại sau khi khoanh vùng | | Trở lại chế độ bình thường | Bản sửa qua được bộ đánh giá, người phụ trách duyệt cho chạy lại và giám sát đang bật |

Vòng ứng phó cũng bảo vệ chi phí và độ trễ. Một agent đang lỗi có thể đốt token vào các lần thử lại, làm chậm hàng chờ và dồn việc kiểm duyệt, nên playbook phải nói rõ khi nào hệ thống ngừng thử và chuyển cho người. Với quy trình báo cáo, hãy gắn bước này với các biện pháp kiểm soát của agentic BI và báo cáo: kiểm tra nguồn, đối soát chỉ số, ghi chú trên dashboard và phê duyệt trước khi phát hành.

Các biện pháp giúp xử lý sự cố dễ hơn

• Mức độ nghiêm trọng đơn giản. Người vận hành phải biết cần làm gì mà không phải tranh luận về nhãn.
• Log đầy đủ. Ghi lại đầu vào, đầu ra, nguồn đã truy xuất, lời gọi công cụ, quyền, dấu thời gian, quyết định kiểm duyệt và các lần ghi đè. Thiếu chúng, phân tích nguyên nhân gốc chỉ là đoán.
• Tách phát hiện khỏi xử lý. Người nhận ra kết quả sai chưa chắc là người sửa được phần truy xuất hay quyền công cụ; playbook làm rõ bước bàn giao đó.
• Diễn tập. Giả lập một nguồn xấu, một prompt rủi ro, một trường API bị thiếu, một lỗi phân quyền và một quyết định có độ tin cậy thấp, rồi kiểm tra đội có phát hiện, khoanh vùng, chuyển cấp và kiểm chứng được mà không phải ứng biến hay không.

Trước khi trao thêm quyền tự chủ cho agent, hãy kiểm tra:

| Khía cạnh | Câu hỏi cần trả lời | | --- | --- | | Chi phí | Agent có dừng trước khi các lần thử lại hoặc vòng kiểm duyệt trở nên lãng phí không? | | Độ trễ | Việc chuyển cấp có đủ nhanh so với nhu cầu nghiệp vụ của quy trình không? | | Ngân sách token | Ngữ cảnh dài và lời gọi công cụ lặp lại có được giám sát không? | | Khả năng quan sát | Người duyệt có dựng lại được đầu vào, nguồn, lời gọi công cụ và quyết định không? | | Gánh nặng kiểm duyệt | Con người đang duyệt đúng hành động, hay duyệt quá nhiều kết quả ít rủi ro? | | Phục hồi sau lỗi | Đội có hoàn tác, sửa và chạy lại an toàn được không? |

Với các rủi ro thiên về bảo mật như prompt injection, xử lý đầu ra thiếu an toàn và lộ thông tin nhạy cảm, OWASP Top 10 cho ứng dụng LLM 2025 là một danh sách kiểm tra hữu ích. Hãy gắn mỗi rủi ro với một hành động khoanh vùng cụ thể.

Những sai lầm thường gặp

• Coi sự cố của agent như lỗi phần mềm thông thường. Agent hỏng qua suy luận, truy xuất, phân quyền, sự mơ hồ và thiết kế quy trình; một bản vá code có thể không đủ.
• Chỉ ghi log kết quả cuối. Thiếu prompt, nguồn, lời gọi công cụ và lịch sử kiểm duyệt thì không ai giải thích được chuyện gì đã xảy ra.
• Trông chờ người dùng phát hiện lỗi. Phàn nàn của khách là tín hiệu muộn. Lấy mẫu, giám sát và kiểm duyệt bắt lỗi trước khi chúng lan rộng.
• Cấp quyền rộng trước khi có quy tắc chuyển cấp. Chỉ mở rộng quyền công cụ khi việc khoanh vùng và kiểm duyệt đã được chứng minh là hoạt động.
• Bỏ qua buổi postmortem. Hướng dẫn của Google SRE về văn hóa postmortem xoay quanh các nguyên nhân góp phần thay vì đổ lỗi. Postmortem cho agent cũng nên như vậy: cải thiện hệ thống.

Ba sự cố, xử lý từ đầu đến cuối

Phân loại yêu cầu hỗ trợ. Một agent phân loại chuyển vấn đề của một khách hàng có nguy cơ không gia hạn vào hàng chờ chung. Một lần con người ghi đè và trạng thái tài khoản không khớp làm lộ ra lỗi. Mức độ cao, vì chậm trễ có thể làm mất khách. Khoanh vùng bằng cách tạm dừng định tuyến tự động cho các tài khoản tương tự; trưởng nhóm hỗ trợ nhận ticket và đội kỹ thuật kiểm tra bước tra cứu tài khoản. Bản sửa cập nhật quy tắc định tuyến và thêm trường hợp này vào bộ đánh giá. Định tuyến hẹp giúp ích ở đây: trong SeaSure, mỗi câu hỏi được chuyển đến agent của đúng một hệ thống con trên tàu, giúp quyết định của từng agent dễ kiểm tra hơn.

Bản tóm tắt nghiên cứu. Một agent nghiên cứu đưa bằng chứng yếu về đối thủ vào bản tóm tắt hằng tuần, và người duyệt phát hiện một nhận định không có căn cứ. Mức độ trung bình, trừ khi bản tóm tắt dẫn dắt quyết định của ban lãnh đạo. Khoanh vùng bằng cách đánh dấu bản tóm tắt đang rà soát và dừng phân phối; người phụ trách nghiên cứu kiểm tra nguồn, quy tắc trích dẫn và prompt tóm tắt, và bản sửa thêm bước kiểm tra chất lượng nguồn. Căn cứ mà người duyệt kiểm chứng được sẽ ngăn loại sự cố này: trong Yōjin, mỗi khuyến nghị đều nêu được nghĩa vụ mà nó phục vụ.

Agentic BI. Một agent báo cáo giải thích biến động doanh thu bằng dữ liệu pipeline đã cũ, bị phát hiện nhờ dashboard lệch với hệ thống nguồn. Mức độ cao nếu ban lãnh đạo lập kế hoạch từ báo cáo này. Khoanh vùng bằng cách rút bản tóm tắt, thêm ghi chú trên dashboard và chuyển agent sang chế độ chỉ soạn nháp. Người phụ trách dữ liệu sửa kết nối nguồn, người phụ trách BI thêm bước đối soát, và một pipeline idempotent cho phép chạy lại dữ liệu đã sửa một cách sạch sẽ.

Bắt đầu từ đâu

Bắt đầu với một quy trình. Viết ra agent được làm gì, điều gì có thể sai, ai phụ trách ứng phó và khi nào tự động hóa phải dừng, rồi diễn tập với các tình huống lỗi thực tế trước khi mở rộng quyền tự chủ. Mục tiêu không phải là một agent không có rủi ro, mà là những sự cố nhìn thấy được, khoanh vùng được, rà soát được và được sửa dứt điểm. Nếu bạn muốn một đội thiết kế agent theo cách này ngay từ commit đầu tiên, đó là cách các dự án phát triển AI agent của chúng tôi vận hành.