Skip to content

Nhân viên tự xây ứng dụng AI: Cơ hội và bài toán quản trị

AI có thể giúp nhân viên biến hiểu biết nghiệp vụ thành công cụ nội bộ nhanh hơn. Nhưng từ bản mẫu đến ứng dụng vận hành, doanh nghiệp vẫn phải kiểm soát dữ liệu, quyền truy cập và trách nhiệm bảo trì.

•6 min read
Chia sẻ:
Cầu nối từ công cụ tự xây tới hệ thống vận hành có kiểm soát

Bkav chia sẻ một thử nghiệm trong đó một kỹ sư dùng AI hoàn thành dự án trong một tuần, so với phương án truyền thống được doanh nghiệp mô tả là cần 10 kỹ sư trong tám tháng. Trường hợp này gợi mở cơ hội để nhân viên tự xây công cụ phục vụ công việc, đồng thời đặt ra câu hỏi: ai chịu trách nhiệm khi công cụ đó truy cập dữ liệu và tham gia quy trình vận hành?

Đây là thông tin do doanh nghiệp tự công bố, không phải kết quả đánh giá độc lập. Nguồn cũng chưa đủ để kết luận nhân viên không có nền tảng kỹ thuật có thể đạt hiệu quả tương tự. Tuy vậy, câu chuyện cho thấy cần phân biệt rõ tốc độ tạo ứng dụng với điều kiện để đưa ứng dụng vào sử dụng.

Từ thử nghiệm của kỹ sư đến cơ hội cho nhân viên nghiệp vụ

Trong bài viết về AI và năng suất trên website Bkav, doanh nghiệp nêu chi phí sử dụng AI của thử nghiệm là ba triệu đồng, đối chiếu với ngân sách ba tỷ đồng của cách làm truyền thống.

Không nên hiểu đây là phép so sánh đầy đủ về tổng chi phí. Bài viết chưa cung cấp chi tiết về phạm vi dự án, tiêu chí nghiệm thu, công sức kiểm thử hay bảo trì. Chi phí công cụ AI không đồng nghĩa với chi phí hoàn thành và vận hành phần mềm.

Cơ hội đáng chú ý nằm ở khả năng rút ngắn khoảng cách giữa người hiểu vấn đề và người tạo giải pháp. Nhân viên nghiệp vụ có thể mô tả một thao tác lặp lại, dùng AI hỗ trợ viết mã rồi thử nghiệm công cụ trước khi đề nghị bộ phận kỹ thuật phát triển tiếp.

Ví dụ giả định là một nhân viên vận hành tạo công cụ chuẩn hóa bảng dữ liệu, hoặc nhân viên hỗ trợ khách hàng xây chức năng tìm kiếm tài liệu nội bộ. Những trường hợp này có phạm vi hẹp, đầu vào và kết quả có thể đối chiếu, phù hợp hơn với thử nghiệm ban đầu.

Ứng dụng do AI hỗ trợ xây không nhất thiết dùng AI khi chạy

Có hai trường hợp cần tách biệt. Thứ nhất, AI hỗ trợ viết mã cho ứng dụng thông thường: biểu mẫu, bộ lọc dữ liệu hoặc công cụ tạo báo cáo. Thứ hai, ứng dụng gọi mô hình AI trong quá trình sử dụng để tóm tắt, phân loại hoặc trả lời câu hỏi.

Trường hợp đầu cần kiểm tra mã nguồn, logic xử lý và bảo mật phần mềm. Trường hợp sau còn phải xem xét dữ liệu gửi tới mô hình, tính biến động của câu trả lời và chi phí mỗi lần gọi. Một ứng dụng có thể thuộc cả hai nhóm.

Phân biệt này ảnh hưởng trực tiếp đến cách nghiệm thu. Công cụ tính toán cần cho kết quả đúng theo quy tắc xác định. Công cụ tóm tắt cần được kiểm tra xem có bỏ sót điều kiện quan trọng hoặc thêm thông tin không có trong tài liệu hay không.

Lợi thế của nhân viên nghiệp vụ là hiểu ngoại lệ trong công việc. Nhưng hiểu quy trình không tự động đồng nghĩa với khả năng phát hiện lỗi phân quyền, bảo vệ khóa truy cập hoặc thiết kế phương án khôi phục dữ liệu.

Khi bản mẫu trở thành một phần của hệ thống

Ranh giới quản trị thay đổi khi công cụ không còn chỉ dùng dữ liệu giả lập. Một bản mẫu chạy trên tệp thử nghiệm khác với ứng dụng đọc hồ sơ khách hàng, cập nhật hệ thống bán hàng hoặc gửi email ra ngoài.

Nếu nhân viên tự kết nối bằng tài khoản cá nhân, doanh nghiệp có thể khó xác định ứng dụng nào đang giữ quyền truy cập. Khi người tạo chuyển vị trí hoặc nghỉ việc, công cụ vẫn có thể được sử dụng nhưng không còn người bảo trì rõ ràng.

Rủi ro cũng đến từ nội dung đầu vào. Với ứng dụng đọc tài liệu hoặc email bằng AI, văn bản được xử lý có thể chứa chỉ dẫn đánh lừa mô hình. Vì vậy, dữ liệu đọc được không nên trở thành căn cứ tự động để mở rộng quyền hoặc thực hiện hành động nhạy cảm.

Nguyên tắc quan trọng là tách phần AI đưa ra đề xuất khỏi phần hệ thống cho phép hành động. Bài viết về lớp kiểm soát quyền hành động của AI giúp làm rõ hướng tiếp cận này. Với công cụ nội bộ, quyền đọc dữ liệu không nên mặc nhiên bao gồm quyền sửa hoặc xóa dữ liệu.

Quản trị theo mức rủi ro thay vì một cửa duyệt chung

Bài toán không chỉ là cho phép hay cấm nhân viên tự xây ứng dụng. Một cơ chế phù hợp cần phân biệt thử nghiệm ít rủi ro với công cụ có tác động trực tiếp đến khách hàng, tài chính hoặc dữ liệu nhạy cảm.

Công cụ cá nhân dùng dữ liệu giả lập có thể được thử trong môi trường tách biệt. Khi chia sẻ cho cả nhóm hoặc kết nối dữ liệu thật, cần có chủ sở hữu, phạm vi truy cập và người hỗ trợ kỹ thuật. Khi ứng dụng được quyền ghi dữ liệu hoặc gửi thông tin ra ngoài, yêu cầu kiểm thử và phê duyệt phải chặt hơn.

Bộ phận công nghệ thông tin vì thế vẫn giữ vai trò thiết yếu: cung cấp môi trường được phép sử dụng, quản lý thông tin xác thực và kiểm tra các kết nối quan trọng. Nhân viên nghiệp vụ xác định yêu cầu, kiểm tra kết quả thực tế và báo cáo ngoại lệ.

Kiểm thử cần bao gồm cả tình huống thất bại: tệp thiếu cột, dữ liệu trùng, tài liệu mâu thuẫn hoặc người dùng không có quyền. Góc nhìn về kiểm thử bằng tài khoản riêng cũng hữu ích khi tách môi trường thử nghiệm khỏi hoạt động thật.

Hiệu quả vận hành vẫn là phần cần chứng minh

Thông tin Bkav công bố chưa giải đáp đầy đủ độ ổn định, khả năng mở rộng hay chi phí duy trì của dự án. Do đó, không thể dùng trường hợp này để suy ra mức tiết kiệm chung cho mọi doanh nghiệp hoặc mọi nhóm nhân viên.

Với ứng dụng tự xây, thước đo hữu ích không chỉ là thời gian tạo bản mẫu. Cần tính cả thời gian kiểm tra đầu ra, sửa lỗi, hỗ trợ người dùng và xử lý sự cố. Một công cụ tạo báo cáo nhanh nhưng phải đối chiếu lại từng dòng có thể chưa tiết kiệm công sức.

Chi phí vận hành còn bao gồm lưu trữ, kết nối dịch vụ và việc chuyển giao cho người bảo trì tiếp theo. Đây cũng là khoảng cách giữa tạo được giải pháp và triển khai được giải pháp, được bàn thêm trong bài AI và nút thắt thực thi.

Cơ hội cho nhân viên tự xây ứng dụng nằm ở việc tận dụng hiểu biết nghiệp vụ để thử giải pháp nhanh hơn. Còn khả năng sử dụng lâu dài phụ thuộc vào bằng chứng kiểm thử, quyền truy cập có giới hạn và trách nhiệm vận hành rõ ràng, những yếu tố không thể thay thế chỉ bằng tốc độ viết mã.

Bài viết liên quan

Gợi ý đọc thêm

Chia sẻ: