Khi tác tử AI làm sai, việc đầu tiên là dừng nó lại và cắt quyền, việc thứ hai là xác định phạm vi đã ảnh hưởng, rồi mới đến hoàn tác và tìm nguyên nhân. Thứ tự này quan trọng vì tác tử có thể vẫn đang chạy, và trong lúc bạn loay hoay sửa thư thứ nhất, nó có thể gửi thư thứ mười.
Phần lớn sai sót của tác tử trên email, lịch và tệp đều khắc phục được ở mức chấp nhận: tệp có lịch sử phiên bản, thư xoá còn trong thùng rác một thời gian, lịch mời sai có thể huỷ kèm lời xin lỗi. Thứ khó cứu nhất là thư đã gửi cho người ngoài và dữ liệu đã lộ ra ngoài. Bài này đi qua mười lăm phút đầu, cách hoàn tác theo từng loại, cách báo cho người liên quan và cách sửa quy trình để không lặp lại.
Mười lăm phút đầu tiên
Khi phát hiện tác tử làm sai, làm theo thứ tự dưới đây, đừng nhảy vào sửa ngay việc mình vừa thấy.
- Dừng phiên đang chạy bằng nút dừng của công cụ. Nếu tác tử chạy theo lịch, tắt luôn lịch đó.
- Thu hồi quyền của kết nối liên quan trong trang quản lý tài khoản của dịch vụ email, kho tệp hay lịch, nếu chưa chắc tác tử đã dừng hẳn hoặc nghi bị chèn lệnh.
- Chụp lại hiện trạng: nhật ký phiên, thư đã gửi, tệp đã sửa, trước khi bạn hoàn tác. Đây là dữ liệu để tìm nguyên nhân sau.
- Xác định phạm vi: lọc trong ứng dụng mọi thay đổi trong khoảng thời gian phiên chạy, đặc biệt những gì đi ra ngoài tổ chức.
- Xếp thứ tự xử lý: việc ảnh hưởng đến khách trước, việc nội bộ sau; việc có thời hạn (lịch họp sắp diễn ra) trước việc không gấp.
- Báo cho người phụ trách và người có dữ liệu bị ảnh hưởng, ngắn gọn: chuyện gì, phạm vi đến đâu, đang xử lý gì.
Nếu thấy dấu hiệu tác tử gửi dữ liệu tới địa chỉ lạ hoặc làm việc hoàn toàn ngoài đề bài, coi đó là sự cố an toàn, không chỉ là lỗi vận hành. Đổi mật khẩu tài khoản liên quan và xem các kết nối khác; phần xử lý sự cố bảo mật có trên trang AI Bảo Mật.
Các kiểu sai hay gặp và mức độ nghiêm trọng
Bảng dưới giúp bạn nhận diện nhanh mình đang gặp loại sai nào. Mức độ là gợi ý chung, tuỳ dữ liệu cụ thể có thể khác.
| Kiểu sai | Ví dụ | Mức độ |
|---|---|---|
| Làm thừa | Tạo thêm thư nháp, tệp, sự kiện không được yêu cầu | Thấp, dọn là xong |
| Làm thiếu nhưng báo đã xong | Bỏ sót một nửa số thư nhưng tường trình là đủ | Trung bình, khách có thể bị bỏ quên |
| Ghi đè dữ liệu | Sửa cột giá, cột số lượng trong bảng dùng chung | Trung bình đến cao, người khác có thể đã dùng số sai |
| Xoá nhầm | Xoá thư, chuyển tệp vào thùng rác | Trung bình, thường khôi phục được trong thời hạn |
| Gửi nhầm ra ngoài | Gửi thư nháp chưa duyệt, gửi nhầm người, đính kèm nhầm tệp | Cao, không thu hồi được |
| Tạo lịch mời sai | Mời khách vào cuộc họp nội bộ, sai giờ | Trung bình, cần báo lại ngay |
| Lộ dữ liệu | Chép thông tin khách vào tài liệu chia sẻ công khai | Cao, có thể kéo theo nghĩa vụ pháp lý |
Hai dòng cuối là lý do mọi bài về tác tử đều nhắc điểm duyệt trước thao tác gửi và giới hạn quyền. Những kiểu sai ở nửa trên bảng gây phiền, nửa dưới gây hại.
Hoàn tác theo từng loại
Tệp bị sửa. Hầu hết kho tệp trực tuyến và bảng tính dùng chung có lịch sử phiên bản. Mở lịch sử, tìm phiên bản ngay trước thời điểm tác tử chạy, khôi phục. Nếu người khác đã sửa tiếp sau đó, đừng khôi phục cả tệp mà chép lại đúng phần bị sai từ phiên bản cũ.
Tệp, thư bị xoá. Tìm trong thùng rác của kho tệp và hộp thư. Thời hạn giữ trong thùng rác khác nhau giữa các dịch vụ và gói, nên làm sớm. Với tài khoản tổ chức, quản trị viên đôi khi khôi phục được cả những gì đã xoá hẳn trong một khoảng thời gian.
Thư đã gửi. Một số dịch vụ email có tính năng huỷ gửi trong vài giây, hoặc thu hồi thư trong cùng hệ thống nội bộ, nhưng với người nhận bên ngoài thì gần như không thu hồi được. Cách xử lý thực tế là gửi thư đính chính ngắn, rõ ràng, nói thư trước gửi nhầm và nhờ người nhận bỏ qua hoặc xoá.
Lịch mời sai. Huỷ sự kiện kèm một dòng giải thích, để người được mời nhận thông báo huỷ thay vì cứ thế đến. Nếu lẽ ra có cuộc hẹn thật nhưng sai giờ, tạo lại sự kiện đúng và nhắn riêng cho người liên quan.
Dữ liệu chép sai chỗ. Xoá bản chép, thu hồi quyền chia sẻ của tài liệu đó, rồi xem ai đã truy cập trong thời gian ấy nếu dịch vụ cho xem. Nếu đó là dữ liệu cá nhân của khách và đã lộ ra ngoài, cần hỏi người am hiểu pháp lý về nghĩa vụ thông báo theo quy định hiện hành.
Báo cho khách và đồng nghiệp thế nào
Với khách nhận nhầm thư, lời đính chính nên ngắn, chịu trách nhiệm và không đổ cho máy. Câu kiểu "hệ thống AI tự gửi nhầm" làm khách lo về cách bạn xử lý thông tin của họ nhiều hơn là trấn an. Viết như một nhân viên nhận lỗi: thư trước được gửi nhầm, nội dung đúng là thế này, xin lỗi vì sự bất tiện. Nếu thư nhầm có chứa thông tin của khách khác, đó là chuyện nghiêm trọng hơn: nhờ người nhận xoá, và báo cho khách có thông tin bị lộ.
Với đồng nghiệp, nói rõ phạm vi và việc họ cần làm. Ví dụ: cột số lượng trong bảng tồn kho bị sửa sai từ 9 giờ đến 10 giờ sáng nay, đã khôi phục lúc 11 giờ; ai đã xuất hàng hay báo giá dựa trên bảng trong khoảng đó thì kiểm lại. Thông báo mơ hồ kiểu "bảng có chút trục trặc" khiến người ta hoặc bỏ qua, hoặc lo không cần thiết.
Trong nội bộ, tránh tìm người để trách. Phần lớn sai sót của tác tử bắt nguồn từ đề bài thiếu, quyền rộng hoặc dữ liệu đầu vào lạ, những thứ thuộc về quy trình. Không khí trách móc làm mọi người giấu sai sót, và sai sót bị giấu là sai sót lặp lại.
Tìm nguyên nhân: năm chỗ cần xem
Sau khi đã ổn định, dùng ảnh chụp hiện trạng và nhật ký để tìm nguyên nhân. Thường nguyên nhân rơi vào một trong năm chỗ dưới.
- Đề bài: có chữ nào mơ hồ khiến tác tử hiểu khác? Có thiếu dòng cấm thao tác đó không?
- Quyền: tác tử có quyền làm việc mà nó lẽ ra không cần làm? Nếu không có quyền đó, sai sót có xảy ra không?
- Điểm duyệt: có điểm duyệt ở bước này không? Nếu có, người duyệt có đọc không, hay bấm đồng ý theo thói quen?
- Dữ liệu đầu vào: có gì lạ trong thư, tệp hôm đó: định dạng mới, ngôn ngữ khác, nội dung có câu dạng ra lệnh?
- Công cụ: công cụ có vừa cập nhật, đổi mô hình, đổi cách kết nối không?
Ghi nguyên nhân và cách sửa vào sổ theo dõi. Một sự cố có thể có nhiều nguyên nhân chồng lên nhau: đề bài mơ hồ cộng quyền rộng cộng duyệt cho qua. Sửa cả ba, đừng dừng ở cái dễ sửa nhất.
Ví dụ giả định: tác tử ghi đè cột giá trong bảng dùng chung
Một cửa hàng nội thất nhỏ ở Đồng Nai giao tác tử cập nhật cột tình trạng hàng trong bảng sản phẩm dùng chung, dựa trên thư báo của xưởng. Một hôm xưởng gửi thư báo giá mới kèm bảng đính kèm. Tác tử hiểu đó là thông tin cần cập nhật và ghi đè luôn cột giá bán của mười hai sản phẩm bằng giá nhập của xưởng. Nhân viên bán hàng báo giá cho hai khách theo bảng trong buổi sáng trước khi có người phát hiện.
Cửa hàng xử lý theo thứ tự: dừng việc định kỳ của tác tử, khôi phục cột giá từ lịch sử phiên bản của bảng, báo cho nhóm bán hàng khoảng thời gian bảng sai, rồi gọi lại hai khách để báo giá đúng. Khi tìm nguyên nhân, họ thấy ba chỗ cùng góp phần: đề bài chỉ nói "cập nhật bảng theo thư của xưởng" mà không giới hạn cột; kết nối cho phép ghi toàn bảng; và không có điểm duyệt vì việc vốn được coi là rủi ro thấp.
Bản sửa: đề bài ghi rõ chỉ được ghi cột tình trạng hàng, mọi thông tin khác trong thư xưởng thì liệt kê vào ghi chú cho người xem; tác tử ghi vào một bảng trung gian, một luồng cố định chỉ chép đúng cột tình trạng sang bảng chính; việc hạ về mức có duyệt trong hai tuần. Cột giá từ đó chỉ người phụ trách được sửa.
Sửa quy trình và chuẩn bị cho lần sau
Sau sự cố, hạ mức tự chủ của việc đó ít nhất một bậc và chạy lại với giám sát như lúc mới giao. Đây không phải hình phạt cho tác tử mà là cách kiểm xem bản sửa có hiệu quả không. Khi thấy ổn qua một số lần chạy, mới nới lại.
Một số chuẩn bị làm sẵn giúp lần sau nhẹ hơn nhiều. Bật lịch sử phiên bản cho mọi bảng tính và thư mục tác tử được ghi. Cho tác tử dùng tài khoản riêng để lọc thay đổi trong vài giây. Lưu sẵn cách thu hồi quyền của từng kết nối, ai làm được, làm ở đâu. Soạn sẵn mẫu thư đính chính ngắn để không phải nghĩ câu chữ lúc đang rối. Định kỳ thử khôi phục một tệp từ lịch sử phiên bản để chắc mình biết cách làm.
Cuối cùng, hỏi thẳng một câu: việc này có nên giao cho tác tử không. Nếu sai sót đến từ chỗ việc đòi hỏi độ chính xác tuyệt đối mỗi lần, có thể nó hợp với luồng tự động cố định hơn. Nếu sai sót đến từ chỗ việc cần phán đoán tinh tế về khách, có thể nó nên quay về người làm, tác tử chỉ hỗ trợ ở mức đề xuất.
Câu hỏi thường gặp
Tác tử gửi nhầm thư thì có nên giải thích với khách là do AI không?
Không cần nhấn vào chuyện AI. Khách quan tâm thư nào đúng, thông tin của họ có an toàn không. Nhận lỗi như của doanh nghiệp, đính chính rõ ràng. Nếu khách hỏi về cách bạn xử lý dữ liệu, trả lời trung thực theo chính sách của bạn.
Có nên xoá tác tử và làm lại từ đầu sau sự cố không?
Thường không cần. Đề bài, kết nối và sổ theo dõi đã có là tài sản; sự cố chỉ cho bạn biết chỗ cần sửa. Chỉ làm lại từ đầu khi phát hiện cấu hình quá rối, quyền quá rộng mà khó tách, hoặc nghi tài khoản đã bị chiếm.
Thùng rác giữ thư và tệp bao lâu?
Khác nhau tuỳ dịch vụ và loại tài khoản, thường tính bằng tuần. Kiểm phần trợ giúp của dịch vụ bạn dùng và ghi lại con số đó trong tài liệu nội bộ. Với tài khoản tổ chức, hỏi quản trị viên về khả năng khôi phục sau khi đã xoá khỏi thùng rác.
Làm sao biết tác tử có bị chèn lệnh từ nội dung thư hay không?
Xem trong nhật ký bước ngay trước khi tác tử làm việc lạ: nó vừa đọc thư hay trang nào. Nếu nội dung đó có câu kiểu ra lệnh cho AI, khả năng cao là bị chèn lệnh. Khi đó thu hồi kết nối, đổi mật khẩu, và xem lại các phiên trước có đọc nội dung tương tự không.
Ai chịu trách nhiệm khi tác tử AI làm sai?
Về mặt vận hành, người giao việc và người duyệt chịu trách nhiệm trong nội bộ; với khách, doanh nghiệp chịu trách nhiệm như với mọi sai sót của mình. Điều khoản của nhà cung cấp công cụ thường giới hạn trách nhiệm của họ. Đây là lý do điểm duyệt và quyền hẹp quan trọng.