Ghi chép sự cố AI là thói quen ghi lại mỗi lần hệ thống AI làm sai đủ để đáng chú ý: chuyện gì xảy ra, phát hiện thế nào, vì sao, đã sửa gì, còn rủi ro gì. Đi kèm là buổi họp rút kinh nghiệm không đổ lỗi cho cá nhân. Thói quen này biến những lỗi lặt vặt hôm nay thành dữ liệu để chặn lỗi lớn ngày mai.
Ngành hàng không, ngành y đã đi con đường này từ lâu: họ không an toàn vì không ai mắc lỗi, mà vì mỗi lỗi được ghi lại, phân tích và chia sẻ. Hệ thống AI đang được đưa vào chăm sóc khách hàng, kiểm duyệt nội dung, xử lý hồ sơ ở nhiều doanh nghiệp Việt, và cần đúng loại trí nhớ tổ chức đó.
Vì sao sự cố AI hay bị quên
Một buổi sáng, chatbot của một công ty du lịch ở Nha Trang trả lời khách rằng tour đảo vẫn chạy trong ngày biển động, trong khi lịch đã huỷ. Khách tới bến, bực bội, gọi tổng đài. Nhân viên xin lỗi, hoàn tiền, sửa câu trả lời trong hệ thống. Chiều hôm đó mọi người đã quên. Ba tháng sau, chuyện tương tự xảy ra với lịch tàu đêm.
Sự cố AI dễ bị quên vì nó thường nhỏ, rải rác, và được sửa tại chỗ. Không ai bị thương, công ty chỉ mất một chút tiền và chút uy tín. Nhưng gộp lại, những lần như vậy cho thấy một điểm yếu có hệ thống: chatbot không được cập nhật thông tin theo thời gian thực, và không biết nói "mình không chắc, để mình chuyển cho nhân viên".
Lý do thứ hai là tâm lý giấu lỗi. Người phụ trách chatbot sợ bị trách vì đã đề xuất dùng nó. Nhân viên chăm sóc khách hàng ngại báo vì không biết báo cho ai. Lãnh đạo nghe báo lỗi lại hỏi "ai làm", và lần sau không ai muốn báo nữa.
Lý do cuối là hệ thống AI thay đổi liên tục. Nhà cung cấp cập nhật mô hình, công ty sửa câu lệnh, thêm tài liệu. Không có ghi chép, không ai biết lỗi tháng trước có còn không, hay đã được sửa thật hay chỉ đổi dạng.
Thế nào thì đáng ghi là một sự cố AI
Trả lời sai thông tin quan trọng. Giá, lịch, chính sách, quy định, liều dùng, thời hạn. Sai những thứ khách sẽ hành động theo.
Hứa điều công ty không cam kết. Giảm giá, hoàn tiền, bảo hành ngoài chính sách.
Lộ thông tin. Nhắc tới thông tin của khách khác, thông tin nội bộ không nên công khai.
Ngôn từ không phù hợp. Xúc phạm, phân biệt vùng miền, giới tính, xưng hô thiếu tôn trọng với người lớn tuổi.
Bị dẫn dắt làm điều không nên. Khách khéo léo khiến chatbot nói hoặc làm ngoài phạm vi cho phép.
Hành động sai khi có quyền. Trợ lý gửi nhầm thư, sửa nhầm dữ liệu, đặt nhầm lịch.
Đối xử không đều. Khách viết không dấu, viết giọng địa phương bị trả lời kém hơn rõ rệt.
Cách cư xử thay đổi bất thường. Sau một lần cập nhật, câu trả lời đổi giọng hoặc đổi chất lượng mà không ai chủ động thay đổi.
Gần xảy ra. Nhân viên duyệt kịp chặn một câu trả lời sai trước khi gửi khách. Vẫn nên ghi, vì đó là lỗi suýt lọt.
Khiếu nại liên quan AI. Mọi khiếu nại mà nguồn gốc là câu trả lời hay hành động của AI.
Không cần ghi mọi lỗi nhỏ. Một câu văn hơi vụng không phải sự cố. Đặt ngưỡng rõ để ghi chép không thành gánh nặng.
Mẫu ghi chép ngắn, điền trong mười lăm phút
Thời điểm và nơi xảy ra. Kênh nào, tính năng nào, phiên bản nào nếu biết.
Chuyện gì đã xảy ra. Vài câu mô tả, kèm câu hỏi và câu trả lời thật nếu có, đã xoá thông tin cá nhân.
Phát hiện bằng cách nào. Khách báo, nhân viên thấy, hệ thống giám sát cảnh báo. Biết điều này để cải thiện cách phát hiện.
Ảnh hưởng. Bao nhiêu khách bị ảnh hưởng, thiệt hại ước tính, mức độ nghiêm trọng theo thang của công ty.
Xử lý tức thời. Đã làm gì để dừng thiệt hại: tắt tính năng, sửa câu trả lời, liên hệ khách.
Nguyên nhân trực tiếp. Tài liệu cũ, câu lệnh thiếu, mô hình bịa, quyền quá rộng.
Nguyên nhân sâu hơn. Vì sao nguyên nhân trực tiếp tồn tại: không có quy trình cập nhật, không có bước thử trước, không ai được giao.
Việc sửa lâu dài. Ai làm, hạn khi nào.
Kiểm tra lại. Sau khi sửa, đã thử lại chưa, thêm câu hỏi này vào bộ kiểm tra chưa.
Bài học có thể chia sẻ. Một hai câu mà đội khác hoặc công ty khác cũng nên biết.
Người ghi và người duyệt. Để biết hỏi ai khi cần thêm thông tin.
Họp rút kinh nghiệm không đổ lỗi
Họp không đổ lỗi không có nghĩa là không ai chịu trách nhiệm. Nghĩa là câu hỏi chính của buổi họp là "hệ thống của mình có lỗ hổng gì để chuyện này xảy ra", chứ không phải "ai làm sai". Khi người ta biết mình sẽ không bị phạt vì báo lỗi, họ báo sớm hơn và kể thật hơn.
Một buổi họp như vậy không cần dài. Ba mươi phút, người ghi chép kể lại diễn biến theo thời gian, mọi người hỏi để hiểu rõ, rồi cùng tìm nguyên nhân sâu. Câu hỏi "vì sao" nên được hỏi vài lần liên tiếp: chatbot trả lời sai lịch tàu vì tài liệu cũ; tài liệu cũ vì không ai được giao cập nhật; không ai được giao vì khi triển khai chỉ tính phần dựng, không tính phần vận hành.
Kết quả buổi họp là vài việc cụ thể có người nhận và hạn chót, không phải một lời hứa chung chung "sẽ cẩn thận hơn". Và câu hỏi gây ra sự cố được thêm vào bộ kiểm tra, để lần cập nhật sau tự động kiểm lại.
Với doanh nghiệp Việt, văn hoá giữ thể diện đôi khi làm buổi họp kiểu này khó. Lãnh đạo có thể mở đầu bằng cách tự kể một quyết định sai của mình liên quan tới sự cố. Một lần như vậy làm thay đổi không khí nhiều hơn mọi lời kêu gọi.
Từ sổ sự cố riêng tới bài học chung
Sau vài tháng, sổ sự cố của một công ty bắt đầu cho thấy hình dạng: phần lớn lỗi đến từ thông tin cũ, hay từ những câu hỏi về trường hợp đặc biệt, hay từ một kênh cụ thể. Đây là thứ không có bài báo nào nói được cho công ty bạn, vì nó là dữ liệu của chính bạn.
Ở quy mô rộng hơn, nếu các doanh nghiệp chia sẻ bài học, bỏ đi mọi thông tin nhận diện khách hàng và bí mật kinh doanh, cả cộng đồng sẽ học nhanh hơn. Một hiệp hội ngành du lịch, ngân hàng hay bán lẻ có thể là nơi tập hợp các bài học kiểu "chatbot hay sai ở câu hỏi về lịch huỷ do thời tiết" mà không nêu tên công ty nào.
Việc chia sẻ cần quy tắc rõ để không thành nơi bêu xấu nhau. Bài học được viết dưới dạng khái quát, không có tên khách, không có tên nhân viên, không có số liệu kinh doanh. Doanh nghiệp tự nguyện gửi, và được lợi lại từ bài học của người khác.
Đây là một năng lực mà Việt Nam có thể xây bằng thói quen nhiều hơn bằng tiền: một mẫu ghi chép chung bằng tiếng Việt, vài buổi chia sẻ trong ngành mỗi năm, và sự tin tưởng rằng nói về lỗi là cách để bớt lỗi, không phải để mất mặt.
Câu hỏi thường gặp
Sự cố AI khác lỗi phần mềm thông thường ở đâu?
Lỗi phần mềm thường lặp lại y hệt với cùng đầu vào, dễ tái hiện. Sự cố AI có thể chỉ xảy ra thỉnh thoảng, phụ thuộc cách hỏi, và có thể đổi sau mỗi lần cập nhật mô hình, nên càng cần ghi lại câu hỏi và câu trả lời thật.
Doanh nghiệp nhỏ có cần ghi chép sự cố AI không?
Có, ở dạng gọn nhẹ. Một bảng tính chung với vài cột là đủ, miễn mọi người biết chỗ ghi và có người xem định kỳ.
Ghi chép sự cố có làm lộ thông tin khách hàng không?
Có thể, nếu chép nguyên văn cuộc trò chuyện. Hãy xoá hoặc thay thế thông tin cá nhân trước khi lưu vào sổ sự cố, và giới hạn người được xem bản gốc.
Ai nên chịu trách nhiệm quản lý sổ sự cố AI?
Người phụ trách hệ thống AI hoặc người được giao lo an toàn AI trong công ty. Quan trọng là có một người cụ thể xem các ghi chép mới và đưa vào buổi họp rút kinh nghiệm.
Có nên công khai sự cố AI cho khách hàng không?
Với sự cố ảnh hưởng tới khách, thông báo trung thực và kịp thời thường giữ được lòng tin tốt hơn im lặng. Nghĩa vụ thông báo cụ thể tuỳ quy định, nên hỏi người làm pháp lý.
