Khi nào nên dùng AI, khi nào chỉ cần automation theo luật?

Hệ thống tiếp nhận của bạn vừa nhận được một yêu cầu hỗ trợ mới. Biểu mẫu gửi về có sẵn các thông tin cơ bản: mã khách hàng, gói dịch vụ đang dùng và thời điểm gửi. Tuy nhiên, ở ô mô tả sự cố, người dùng chỉ viết một câu ngắn: “Trang quản trị lúc vào được lúc không, bên tôi đang chuẩn bị chạy chiến dịch bán hàng tối nay.”

Hệ thống tự động hiện tại có thể kiểm tra ngay xem tài khoản này có còn hạn sử dụng hay không, gói dịch vụ có thuộc diện ưu tiên hỗ trợ hay không và email có đúng định dạng chuẩn hay không. Đây là những thao tác có kết quả trắng - đen rõ ràng. Nhưng với câu mô tả ngắn kia, các điều kiện if/else thông thường bắt đầu lúng túng: Đây là lỗi đường truyền mạng, lỗi máy chủ quá tải hay một sự cố cần kích hoạt quy trình trực khẩn cấp?

Nhiều nhóm kỹ thuật khi đứng trước bài toán này thường chọn cách tiếp cận cực đoan: hoặc cố viết thêm thật nhiều biểu thức chính quy (regex) để bắt từ khóa, hoặc đề xuất thay thế toàn bộ hệ thống phân loại bằng một mô hình AI. Cả hai cách đều khiến việc vận hành trở nên nặng nề. Trong một quy trình thực tế, có những bước bắt buộc phải chạy bằng quy tắc cố định để đảm bảo tính nhất quán, có những bước AI chỉ nên đóng vai trò gợi ý, và có những quyết định dứt khoát phải giữ lại cho con người chịu trách nghiệm.

Muốn xây dựng một quy trình ổn định, bạn cần bóc tách bản chất của từng bước xử lý thay vì đi tìm một công nghệ duy nhất cho toàn bộ hệ thống.

Automation theo luật là lựa chọn tốt nhất khi câu trả lời đã có sẵn trong dữ liệu

Tự động hóa theo quy tắc (rule-based automation) hoạt động dựa trên logic xác định: nhận dữ liệu đầu vào, đối chiếu với các điều kiện đã lập trình và kích hoạt hành động tương ứng. Cùng một dữ liệu đầu vào sẽ luôn cho ra cùng một kết quả ở mọi lần chạy. Đặc tính nhất quán này là yếu tố sống còn ở những khâu hệ thống không được phép có sự suy diễn.

Trong quy trình tiếp nhận yêu cầu hỗ trợ, các thao tác sau hoàn toàn không cần đến AI:

• Kiểm tra tính hợp lệ của địa chỉ email và số điện thoại.
• Đối chiếu mã dịch vụ trong cơ sở dữ liệu để xác định hợp đồng còn hiệu lực hay không.
• Gắn yêu cầu vào tài khoản quản trị dựa trên ID định danh của người gửi.
• Chặn thao tác gán việc nếu bộ phận tiếp nhận đang tạm dừng hoạt động.
• Tự động gửi thông báo nhắc nhở khi một yêu cầu chưa được phản hồi sau khoảng thời gian quy định.

Những bước này không hề đơn giản; một bộ quy tắc phân quyền hoặc tính hạn xử lý (SLA) có thể chứa hàng chục nhánh rẽ phức tạp. Nhưng mấu chốt là dữ liệu đầu vào đã có cấu trúc rõ ràng và người quản trị muốn hệ thống thực thi chính xác 100% logic đã định. Khi xảy ra sai sót, việc kiểm tra cũng rất nhanh: bạn chỉ cần xem lại giá trị của các trường dữ liệu và đối chiếu với nhánh điều kiện trong cấu hình để biết vì sao yêu cầu lại đi vào nhánh đó.

Sự cố chỉ thực sự phát sinh khi người vận hành cố dùng quy tắc cố định để "đọc hiểu" văn bản tự do. Ban đầu, nhóm thêm vào vài từ khóa như "lỗi", "chậm" hay "khẩn cấp" để tăng mức ưu tiên. Chỉ sau vài tháng, danh sách này phình to thành hàng trăm cụm từ phức tạp nhằm bao quát các lỗi chính tả, từ viết tắt và tiếng lóng. Hệ thống bắt đầu hiểu nhầm tai hại khi gặp câu: "Sự cố này không khẩn cấp, để sang tuần xử lý cũng được" – rule thấy xuất hiện từ "khẩn cấp" và lập tức báo động đỏ toàn công ty.

Khi danh sách từ khóa bắt đầu vượt tầm kiểm soát, điều đó không có nghĩa là toàn bộ quy tắc cũ đã lỗi thời. Nó chỉ là dấu hiệu cho thấy bạn đang ép một công cụ xác định phải xử lý một dạng dữ liệu có tính biến thiên quá cao.

AI phát huy hiệu quả khi dữ liệu không nằm gọn trong các trường có sẵn

Mô hình AI hữu ích nhất khi đầu vào là những đoạn văn bản tự do, phản hồi khảo sát hoặc nội dung trao đổi qua lại giữa con người. Thay vì cố gắng lập trình hàng trăm trường hợp để bao quát mọi lỗi diễn đạt, bạn có thể yêu cầu mô hình đọc hiểu ngữ cảnh và chuẩn hóa thông tin thành định dạng có cấu trúc để hệ thống phía sau xử lý tiếp.

Trở lại với câu mô tả ngắn của khách hàng: “Trang quản trị lúc vào được lúc không, bên tôi đang chuẩn bị chạy chiến dịch bán hàng tối nay.” Một mô hình ngôn ngữ có thể trích xuất ra bốn thông tin cốt lõi:

• Triệu chứng: Truy cập chập chờn, không ổn định.
• Thành phần bị ảnh hưởng: Bảng điều khiển quản trị (admin dashboard).
• Yếu tố thời gian: Cần hỗ trợ khẩn trước buổi tối.
• Đề xuất nhóm xử lý: Đội ngũ vận hành ứng dụng hoặc hạ tầng máy chủ.

Kết quả trích xuất này giúp nhân viên trực ca nắm bắt bản chất sự việc trong vài giây mà không cần đọc đi đọc lại bức thư dài. Tuy nhiên, bạn cần nhớ rằng đây chỉ là một phán đoán mang tính xác suất, không phải sự thật đã được kiểm chứng. Khách hàng cảm thấy trang quản trị chập chờn có thể do đường truyền internet của văn phòng họ, hoặc do trình duyệt bị lỗi cache. Việc khách hàng sắp chạy chiến dịch cũng chưa đủ căn cứ kỹ thuật để hệ thống tự động gắn nhãn "sự cố mức độ cao nhất" nếu chưa kiểm tra nhật ký máy chủ.

Sự khác biệt căn bản giữa hai phương pháp nằm ở tính chất kết quả: quy tắc thực thi một logic cố định đã được con người mô tả chi tiết; còn AI đưa ra dự đoán hợp lý nhất dựa trên ngữ cảnh nó nhận được. AI cho phép bạn đọc hiểu linh hoạt hơn rất nhiều so với danh sách từ khóa tĩnh, nhưng đổi lại, bạn phải chấp nhận rằng kết quả đó luôn có một tỷ lệ sai số nhất định và cần cơ chế kiểm tra trước khi sử dụng.

Thiết kế workflow kết hợp: AI đề xuất, quy tắc kiểm tra

Giải pháp tối ưu cho một quy trình tiếp nhận yêu cầu không phải là dỡ bỏ toàn bộ biểu mẫu cũ để thay bằng một chatbot tự động. Biểu mẫu web vẫn là nơi tốt nhất để thu thập các thông tin bắt buộc. Quy tắc tự động vẫn là chốt chặn tin cậy nhất để kiểm tra quyền hạn và phân luồng dữ liệu. AI chỉ nên xuất hiện tại đúng điểm nghẽn mà quy tắc cố định không thể bao quát: bước đọc hiểu văn bản tự do.

Một luồng xử lý phối hợp an toàn thường diễn ra như sau:

1. Hệ thống tiếp nhận biểu mẫu và cấp mã định danh duy nhất cho yêu cầu.
2. Bộ quy tắc kiểm tra tính hợp lệ của email, gói dịch vụ và các trường dữ liệu bắt buộc.
3. AI đọc nội dung mô tả tự do, trích xuất triệu chứng và đề xuất nhóm kỹ thuật phù hợp.
4. Bộ quy tắc đối chiếu kết quả của AI với danh mục nhóm thực tế của công ty để đảm bảo mô hình không bịa ra một bộ phận không tồn tại.
5. Nhân viên trực ca xem xét nhanh gợi ý của AI cùng nội dung thư gốc trước khi bấm nút xác nhận phân công.

Trong thiết kế này, AI không bao giờ có toàn quyền tự tạo ra các luồng xử lý mới. Nếu mô hình trả về nhóm database-team trong khi hệ thống chỉ có ba nhóm hợp lệ là ung-dung, ha-tang và tai-khoan, bộ quy tắc validation phía sau sẽ lập tức từ chối kết quả này và gắn nhãn "không thể phân loại tự động".

Một phản hồi JSON có đầy đủ các trường chỉ chứng minh dữ liệu không làm gãy code của hệ thống phía sau. Việc mô hình hiểu đúng ngữ cảnh và xếp đúng danh mục hay không vẫn cần mắt nhìn của người trực ca. Quy tắc tự động đảm nhận việc xác nhận cú pháp và các trường dữ liệu; con người hoặc các bộ tiêu chí đánh giá chuyên sâu mới có thể xác nhận liệu AI có hiểu đúng ý của khách hàng hay không.

Quan trọng hơn, mô hình kết hợp luôn có sẵn một đường lui (fallback) rất an toàn. Khi dịch vụ AI gặp sự cố mạng, phản hồi quá chậm hoặc trả về kết quả lỗi, yêu cầu hỗ trợ vẫn nằm nguyên trong hàng chờ chung với đầy đủ dữ liệu gốc để nhân viên tiếp quản thủ công. Toàn bộ quy trình có thể chậm lại đôi chút, nhưng không bao giờ bị tê liệt chỉ vì một thành phần trí tuệ nhân tạo bên ngoài ngừng hoạt động.

Chọn công cụ theo bản chất của quyết định, không chạy theo công nghệ mới

Một đoạn code xử lý điều kiện rõ ràng luôn dễ vận hành và kiểm tra lỗi hơn nhiều so với một đoạn prompt mà mỗi lần nhà cung cấp âm thầm cập nhật phiên bản mô hình, bạn lại phải ngồi đo lường và hiệu chỉnh lại từ đầu. Ngược lại, nếu cố chấp dùng biểu thức chính quy để bắt trọn từng cách diễn đạt của con người, hệ thống sẽ sớm biến thành một mớ bòng bong mà chính người tạo ra nó cũng không còn dám sửa đổi.

Bạn có thể dựa vào đặc tính của từng bước công việc để lựa chọn công cụ tương ứng:

Điểm chuyển giao hợp lý xuất hiện khi bộ quy tắc của bạn bắt đầu có dấu hiệu phình to bất thường: danh sách từ khóa ngày càng dài, các điều kiện ngoại lệ phải chen lấn nhau và mỗi lần sửa một dòng lại làm hỏng các trường hợp đang chạy ổn định trước đó. Đó là lúc bạn nên bóc tách riêng phần văn bản nhập liệu tự do đó ra để thử nghiệm AI, trong khi các chốt chặn về phân quyền, trạng thái và ngưỡng an toàn vẫn giữ nguyên ở tầng mã nguồn truyền thống.

Ranh giới thẩm quyền: Việc AI làm được khác với việc được phép quyết định

Khi mô hình AI nhận diện được cụm từ “chuẩn bị chạy chiến dịch bán hàng tối nay”, nó có thể gợi ý mức độ ưu tiên cao để nhân viên trực chú ý xử lý sớm. Gợi ý này rất có ích. Nhưng việc hệ thống tự động phát cảnh báo khẩn cấp tới toàn bộ đội ngũ kỹ thuật hay tự ý cam kết thời gian khắc phục với khách hàng lại là một câu chuyện hoàn toàn khác.

Một yêu cầu có thực sự khẩn cấp hay không còn phụ thuộc vào việc hệ thống có giải pháp dự phòng hay chưa, bao nhiêu người dùng đang bị ảnh hưởng và điều khoản cam kết dịch vụ (SLA) quy định ra sao. Những dữ kiện mang tính nghiệp vụ và pháp lý này không hề nằm trong một câu mô tả ngắn của khách. AI chỉ nên dừng lại ở việc gắn cờ “cần làm rõ thêm thông tin”; người trực ca mới là người có đủ thẩm quyền xác nhận mức độ ưu tiên chính thức.

Quy tắc này áp dụng cho mọi khâu có rủi ro cao trong vận hành:

• AI có thể đọc và tổng hợp hóa đơn công tác, nhưng người quản lý tài chính phải là người bấm nút chi tiền.
• AI có thể phát hiện một địa chỉ IP có hành vi quét cổng bất thường, nhưng chính sách khóa vĩnh viễn tài khoản cần được cấu hình qua các quy tắc bảo mật có ngưỡng đo rõ ràng.
• AI có thể soạn sẵn bản nháp thư trả lời khiếu nại, nhưng nhân viên chăm sóc khách hàng phải đọc lại trước khi bức thư được gửi ra ngoài máy chủ.

Khả năng phân tích của một công cụ không đi kèm với thẩm quyền thực thi. Các bước chỉ phục vụ hiển thị dữ liệu cho nội bộ đọc có thể thử nghiệm AI thoải mái hơn. Còn với những thao tác có tác động trực tiếp ra bên ngoài như gửi email, trừ tiền, phân quyền hay xóa dữ liệu, hệ thống bắt buộc phải có chốt chặn thẩm quyền của con người hoặc các điều kiện kiểm tra nghiêm ngặt của mã nguồn.

Đánh giá ba phương án trên cùng một tập dữ liệu thực tế

Nếu đã có sẵn một hệ thống quy tắc cũ, bạn không cần phải vội vã đập đi xây lại từ đầu. Chính kho dữ liệu cũ là thước đo đối chứng thực tế nhất. Hãy trích xuất khoảng vài trăm yêu cầu hỗ trợ đã xử lý trong quá khứ, xóa toàn bộ thông tin nhạy cảm của khách hàng, rồi cho ba phương án cùng chạy trên tập dữ liệu này:

1. Bộ quy tắc lọc từ khóa hiện tại.
2. Mô hình AI đọc đoạn mô tả tự do để tự gán nhóm xử lý.
3. Mô hình kết hợp: Quy tắc kiểm tra các trường cố định, AI trích xuất nội dung văn bản, nhân viên bấm xác nhận kết quả cuối cùng.

Khi tổng hợp kết quả, hãy phân loại lỗi dựa trên mức độ ảnh hưởng đến vận hành thay vì chỉ nhìn vào một con số phần trăm chính xác chung chung. Nếu hệ thống phân loại nhầm giữa nhóm hỗ trợ ứng dụng và nhóm máy chủ, nhân viên nội bộ có thể chuyển tiếp cho nhau sau vài phút. Nhưng nếu một sự cố sập cơ sở dữ liệu bị xếp nhầm thành một câu hỏi sử dụng thông thường khiến kỹ thuật viên không kịp thời vào cuộc, đó là một lỗi nghiêm trọng. Thử nghiệm cần chỉ ra rõ: phương án nào giúp giảm thời gian đọc của con người nhiều nhất mà vẫn giữ được tỷ lệ an toàn tuyệt đối cho các sự cố khẩn cấp.

Chi phí vận hành cũng là yếu tố cần tính toán kỹ:

• Quy tắc cố định tiêu tốn công sức lập trình và kiểm thử mỗi khi chính sách hỗ trợ thay đổi.
• Mô hình AI phát sinh cước phí gọi API và thời gian nhân viên phải ngồi đối soát lại từng câu từ.
• Mô hình kết hợp đòi hỏi hệ thống ghi nhận lịch sử (log) chi tiết hơn để khi có sự cố, bạn biết ngay lỗi nằm ở khâu tiếp nhận dữ liệu, ở câu trả lời của mô hình hay ở bước kiểm tra nghiệp vụ phía sau.

Sau vài đợt chạy thử, bạn sẽ thấy rõ ranh giới tự nhiên của từng thành phần. Nhiều nhóm nhận ra AI thực sự chỉ cần thiết ở khâu tóm tắt lại nội dung trao đổi cho kỹ thuật viên đọc nhanh, còn việc gán việc vào nhóm nào thì biểu mẫu có sẵn menu chọn lựa đã làm rất tốt. Kết quả thực tế đó giúp quy trình gọn gàng hơn nhiều so với một quyết định chuyển đổi ồ ạt sang AI theo phong trào.

Bảng phân công trách nhiệm cho từng bước trong quy trình

Trước khi đưa quy trình vào vận hành chính thức, hãy lập một bảng theo dõi rõ ràng cho từng chặng xử lý dữ liệu:

Bảng này giúp người tiếp quản hệ thống sau này hiểu rõ bức tranh vận hành: bước nào do code chạy, bước nào do AI gợi ý và bước nào bắt buộc phải có con người ký duyệt. Khi một bộ phận thay đổi quy định, phạm vi cần chỉnh sửa và kiểm thử lại cũng được khoanh vùng rất nhanh.

Bạn có thể chốt phương án cho từng bước bằng hai câu hỏi thực tế: bước này có đòi hỏi kết quả luôn giống hệt nhau ở mọi lần chạy hay không, và nếu xảy ra sai sót thì ai sẽ là người đứng ra chịu trách nhiệm? Dữ liệu có cấu trúc và logic ổn định thuộc về tự động hóa theo luật. Dữ liệu phi cấu trúc cần bóc tách ý nghĩa là đất diễn của AI. Những thao tác tạo ra tác động lớn tới hệ thống hoặc khách hàng luôn cần chốt chặn phê duyệt của con người.

Khi các ranh giới này đã rõ ràng, bạn có thể bắt tay ráp nối từng phần vào một workflow automation hoàn chỉnh. Nếu bản thân quy trình tiếp nhận của bạn vẫn còn thay đổi liên tục mỗi tuần hoặc các phòng ban chưa thống nhất được cách xử lý công việc chung, bài viết khi nào không nên tự động hóa một quy trình sẽ giúp bạn nhận diện những điểm cần chuẩn hóa trước khi áp dụng bất kỳ công nghệ nào.

Nguồn tham khảo

• Google for Developers — Understand the problem
• Google for Developers — Rules of Machine Learning
• Microsoft Azure Well-Architected Framework — AI workloads on Azure
• NIST AI Risk Management Framework Core