Năng lực AI trong tổ chức: vì sao có phần mềm và dữ liệu vẫn chưa đủ?

Đăng ngày 27/10/2026

Tóm tắt: tài sản công nghệ chưa phải khả năng làm việc lặp lại

Năng lực AI trong tổ chức là khả năng dùng dữ liệu, mô hình, phần mềm và con người để hoàn thành một việc theo tiêu chí có thể kiểm, rồi duy trì khả năng đó khi điều kiện thay đổi. Có hệ thống thông tin hoặc mua quyền dùng mô hình là những đầu vào. Chúng chưa tự chứng minh tổ chức làm được việc mới, kiểm được lỗi hoặc phân công được người chịu trách nhiệm.

• Hệ thống thông tin giúp ghi nhận và phối hợp; chất lượng ghi nhận vẫn cần được kiểm.
• Dữ liệu cần nghĩa, nguồn, thời điểm, người sở hữu và phạm vi sử dụng phù hợp.
• Năng lực mô hình chỉ là một thành phần của năng lực ứng dụng trong công việc.
• Con người cần biết nhận việc, kiểm kết quả, xử lý ngoại lệ và sửa quy trình.
• Tiến bộ nên được chứng minh bằng việc hoàn thành có chất lượng, thay vì số tài khoản hay số buổi học.

Một doanh nghiệp đã có phần mềm nhưng việc vẫn đi đường vòng

Giả định một doanh nghiệp dịch vụ kỹ thuật tại Việt Nam đã có phần mềm quản lý khách, lưu hồ sơ trên ổ chung và trao đổi công việc qua nhóm chat. Khi khách hỏi lịch sử bảo trì, nhân viên vẫn phải hỏi đồng nghiệp, tìm thư cũ và ghép thông tin. Lãnh đạo muốn bổ sung trợ lý AI. Đây là tình huống tự xây để phân tích, không phải hồ sơ triển khai hay lời kể tư vấn về một doanh nghiệp thật.

Nhìn từ danh mục tài sản, doanh nghiệp có nhiều thứ cần thiết: phần mềm, hồ sơ, người biết việc và ngân sách thử công cụ. Nhưng một yêu cầu cụ thể vẫn chưa có đường xử lý ổn định. Mã thiết bị giữa các nơi có thể khác nhau; biên bản chưa được xác nhận; người giữ kinh nghiệm không luôn sẵn có. Nếu không phân biệt tài sản với khả năng phối hợp, tổ chức dễ mong mô hình tự nối những điều chưa từng được thống nhất.

Công trình Hidden Technical Debt in Machine Learning Systems phân tích những phụ thuộc dữ liệu, cấu hình và vòng phản hồi khiến hệ học máy phải chịu chi phí duy trì ở cấp hệ thống [1]. Luận điểm đó giúp nhìn ngoài phần mã mô hình. Nó không cho một tỷ lệ dự án thất bại để áp vào doanh nghiệp Việt Nam; điều có thể dùng là câu hỏi những phụ thuộc nào chưa có người theo dõi.

Trong tình huống giả định, đích đầu tiên không nên là “mọi nhân viên dùng AI”. Một đích kiểm được hơn là tìm đúng lịch sử của thiết bị được phép xem, chỉ ra hồ sơ còn thiếu và chuyển câu hỏi kỹ thuật cho người phụ trách. Đích như vậy làm rõ phần nào do hệ thống thông tin cung cấp, phần nào do dữ liệu và phần nào do con người quyết định.

Hệ thống thông tin đang ghi nhận điều gì, và bỏ sót điều gì?

Hệ thống thông tin trong phân tích này gồm phần mềm, dữ liệu và cách người làm dùng chúng để ghi nhận, trao đổi hoặc điều phối công việc. Một trường trên biểu mẫu không bảo đảm cùng nghĩa giữa các bộ phận. “Đã xử lý” có thể là đã gọi khách, đã sửa xong hoặc đã chờ nghiệm thu. Trước khi dùng làm đầu vào AI, cần xác định nghĩa mà nghiệp vụ thực sự muốn phản ánh.

Giả định bộ phận tiếp nhận đóng phiếu sau khi giao kỹ thuật, còn nhóm kỹ thuật đóng sau nghiệm thu. Ghép hai nguồn mà không giữ loại trạng thái có thể làm trợ lý nói công việc hoàn thành sớm. Đây không phải lỗi diễn đạt đơn thuần. Nếu bảng báo cáo hiện tại cũng dùng chung nhãn ấy, cùng sai lệch có thể đã tồn tại trước AI. Bổ sung mô hình làm câu trả lời dễ đọc hơn nhưng không tự sửa định nghĩa.

Một cách rà soát là theo một hồ sơ từ lúc phát sinh đến bàn giao cuối. Ghi mỗi nơi dữ liệu được tạo, ai sửa và người sau dùng nó để quyết định gì. Chú ý các bước sao chép vào bảng riêng, đổi tên thiết bị hoặc nhắn miệng để giải thích ngoại lệ. Đường vòng thường là dấu hiệu có thông tin cần thiết chưa được giữ trong luồng chính, chứ không chỉ là người dùng thiếu kỷ luật nhập liệu.

Kết quả cần là bản mô tả nguồn sự thật cho từng loại sự kiện. Không nhất thiết phải chuyển mọi thứ vào một phần mềm. Có thể giữ hồ sơ kỹ thuật ở nơi phù hợp và dùng mã liên kết đã thống nhất. Điều cần kiểm là khi hai nguồn mâu thuẫn, tổ chức biết mở nguồn nào, hỏi ai và giữ trạng thái chưa xác nhận như thế nào. Đây là nền phối hợp cho trợ lý sau đó.

Dữ liệu nhiều chưa chắc dùng được cho một câu hỏi

Datasheets for Datasets đề xuất mô tả mục đích, thành phần, cách thu thập, xử lý, sử dụng và duy trì dữ liệu [2]. Điểm hữu ích cho doanh nghiệp là làm rõ điều đã biết và chưa biết về tài sản dữ liệu. Mẫu mô tả là phương tiện đặt câu hỏi, không phải bằng chứng dữ liệu đã sạch, phù hợp hoặc có đầy đủ quyền cho mọi cách dùng.

Với lịch sử bảo trì giả định, cần biết một dòng đại diện lần thăm, hạng mục thay thế hay toàn bộ đợt dịch vụ. Cần biết bản ghi nào được kỹ thuật xác nhận, bản nào chỉ là khách tự khai. Nếu thiếu đơn vị quan sát, phép đếm và câu trả lời đều có thể lệch. Tài liệu đúng định dạng vẫn có thể thiếu thông tin quyết định để nối với yêu cầu của người hỏi.

Dữ liệu còn có thời gian. Tên người phụ trách, tình trạng thiết bị và hướng dẫn sử dụng có thể thay đổi. Một bản tổng hợp không giữ thời điểm dễ trộn sự kiện cũ với trạng thái hiện tại. Doanh nghiệp nên mô tả cách nhận biết bản phát hành, cách đánh dấu hồ sơ bị thay thế và cách hỏi lại khi chưa xác nhận hiệu lực. Không cần tự lấp trường thiếu bằng dự đoán chỉ để dữ liệu trông đầy đủ.

Trước khi lập một kho tri thức chung, hãy chọn câu hỏi cụ thể và lần ngược tới chứng cứ cần có. “Thiết bị đã được thay linh kiện nào?” đòi hỏi khác “nhân viên nên hỏi gì khi tiếp nhận?”. Câu thứ nhất cần bản ghi sự kiện; câu thứ hai có thể dựa trên hướng dẫn được duyệt. Năng lực AI trong tổ chức bắt đầu rõ hơn khi dữ liệu được đánh giá theo việc sẽ dùng, thay vì theo số tệp đã tập hợp.

Vì sao lỗi dữ liệu thường trở thành vấn đề phối hợp?

Nghiên cứu Data Cascades phỏng vấn người thực hành AI trong các lĩnh vực có hậu quả cao ở Ấn Độ, các nước Đông và Tây Phi cùng Hoa Kỳ. Tác giả mô tả cách vấn đề dữ liệu tích lũy tác động xuống các bước sau [3]. Đây là bằng chứng định tính trong phạm vi mẫu nghiên cứu; bài không dùng tỷ lệ của mẫu để nói mức phổ biến tại Việt Nam.

Trong doanh nghiệp giả định, người tiếp nhận có thể bị yêu cầu đóng phiếu nhanh, trong khi nhóm phân tích cần trạng thái chi tiết. Người nhập dữ liệu không được báo lỗi từ nơi dùng, còn người dùng không biết phải đề nghị ai sửa. Nếu chỉ giao “làm sạch dữ liệu” cho nhóm công nghệ, mâu thuẫn mục tiêu vẫn còn. Cần thống nhất trường nào đủ quan trọng để người tạo dữ liệu có thời gian và trách nhiệm xác nhận.

Một vòng phản hồi nhỏ có thể hữu ích hơn đợt sửa lớn không có người nhận. Khi trợ lý gặp hai mã cùng thiết bị, nhân viên đánh dấu loại mâu thuẫn; chủ dữ liệu xác minh; bản sửa được ghi nguồn và áp dụng cho lần sau. Không để mọi người tự sửa bản sao riêng, vì điều đó tạo nhiều nguồn cạnh tranh. Cũng không mặc định một phản hồi của người dùng luôn đúng; cần người có thẩm quyền xác nhận thay đổi.

Cách phân vai nên đi cùng đường xử lý chậm. Nếu chủ nguồn chưa phản hồi, trợ lý cần biết không kết luận thay. Nếu dữ liệu bị thu hồi, nơi dùng phải nhận được tín hiệu cập nhật. Những điểm nối này là năng lực phối hợp, có thể được ghi thành trách nhiệm và kiểm qua tình huống cụ thể. Mua mô hình mới chưa giải quyết được một yêu cầu sửa dữ liệu không có ai nhận.

Năng lực mô hình và năng lực ứng dụng là hai phép đánh giá

Báo cáo về mô hình nền tảng nhấn mạnh mô hình có thể làm cơ sở thích nghi cho nhiều nhiệm vụ, đồng thời nằm trong một hệ sinh thái lớn hơn [4]. Nhìn theo doanh nghiệp, khả năng tạo văn bản hoặc đọc ảnh là nguyên liệu. Ứng dụng còn phải gắn với nguồn, quyền, giao diện và cách sử dụng. Do đó, đánh giá một mô hình và nghiệm thu một ứng dụng cần có phạm vi riêng.

Giả định mô hình tóm tắt hồ sơ kỹ thuật tốt khi được đưa đủ văn bản chuẩn. Trong ứng dụng, hồ sơ có thể bị thiếu trang, nhận dạng chữ sai hoặc không tìm thấy đúng thiết bị. Kết quả cuối có thể kém dù năng lực tóm tắt không đổi. Nếu chỉ chạy lại ví dụ đầy đủ trong buổi trình diễn, nhóm sẽ bỏ qua sự khác biệt giữa điều kiện thử mô hình và điều kiện vận hành thực tế.

Đề xuất Model Cards gợi ý nêu nhiệm vụ được dự kiến, việc nằm ngoài phạm vi, dữ liệu dùng đánh giá và giới hạn của mô hình [5]. Tổ chức có thể dùng tinh thần đó để hỏi nhà cung cấp và ghi hồ sơ lựa chọn. Tuy nhiên, hồ sơ thành phần không thay bộ thử công việc của mình. Cần biết ứng dụng có trả lời đúng trong tình huống nguồn thiếu, quyền thay đổi và người dùng diễn đạt khác chuẩn hay không.

Cũng nên tách “không làm được” khỏi “không được phép làm”. Mô hình có thể sinh một hướng dẫn nhưng tổ chức không cho phép dùng nó để quyết định kỹ thuật ngoài hiện trường. Ngược lại, một thao tác được phép vẫn có thể vượt năng lực đáng tin của ứng dụng. Chỉ khi cả năng lực và thẩm quyền phù hợp, nhóm mới nên đưa kết quả sang bước có hậu quả.

Con người cần năng lực nào ngoài viết câu lệnh?

Nhân viên cần biết mô tả việc, chọn thông tin được dùng, nhận ra chỗ thiếu chứng cứ và kiểm sản phẩm trước khi bàn giao. Người quản lý cần chốt tiêu chí, quyền quyết định và cách giải quyết ngoại lệ. Nhóm kỹ thuật cần làm rõ trạng thái cùng lỗi của công cụ.

Nghiên cứu hướng dẫn tương tác người và AI của nhóm Microsoft cùng cộng sự xem xét cách làm rõ khả năng hệ thống và hỗ trợ người dùng điều chỉnh khi kết quả không phù hợp [6]. Xuất xứ hãng cần được ghi rõ; đây là công trình hướng dẫn thiết kế, không phải bằng chứng mọi nhân viên dùng giao diện theo hướng dẫn đều đạt mức năng suất cụ thể. Doanh nghiệp phải kiểm khả năng sử dụng trong công việc của mình.

Trong ca giả định, một nhân viên có thể viết câu lệnh rất hay nhưng không biết hồ sơ nào là bản đã nghiệm thu. Một kỹ thuật viên hiểu thiết bị lại có thể cần mẫu để ghi điều chưa xác nhận rõ ràng. Chương trình học nên xuất phát từ những khoảng trống khác nhau đó. Dạy cùng một bộ mẹo câu lệnh cho mọi vai khó cho biết ai làm được bước nào sau buổi học.

Phép kiểm nhân sự có thể là một hồ sơ giả lập chứa thông tin mâu thuẫn. Người học cần tìm nguồn, chỉ ra giới hạn, tạo bản nháp và nêu điểm phải hỏi chuyên viên. Đánh giá sản phẩm cùng cách bàn giao sẽ gần năng lực công việc hơn hỏi nhớ tên công cụ. Đây là đề xuất thực hành của bài, chưa có số liệu cho thấy nó vượt một chương trình đào tạo khác trong bối cảnh Việt Nam.

Năng lực tổ chức thể hiện khi người hoặc điều kiện thay đổi

Một ứng dụng chỉ chạy khi chuyên viên giỏi nhất ngồi cạnh có thể là bản thử hữu ích, nhưng chưa chứng minh khả năng làm việc lặp lại. Cần thử khi người đó nghỉ, khi có nhân viên mới hoặc khi hồ sơ tới từ chi nhánh khác. Điều cần tìm không phải mọi người cho câu trả lời giống hệt nhau, mà là họ giữ được tiêu chí và biết chuyển ngoại lệ đúng nơi.

Tổ chức cũng cần nơi sở hữu quy trình sửa lỗi. Nếu đầu ra sai, ai phân loại nguyên nhân? Ai có quyền đổi nguồn hoặc cấu hình? Ai kiểm lại trước khi đưa thay đổi vào công việc? Câu trả lời nên gắn với vai có người nhận, không dừng ở tên một ban. Việc lập một nhóm AI chưa tự tạo đường xử lý nếu các phòng vẫn không thống nhất trách nhiệm của dữ liệu và quyết định.

Có thể kiểm năng lực bằng một cuộc bàn giao có quan sát. Một người khác dùng hướng dẫn hiện có để xử lý hồ sơ giả định, ghi chỗ phải hỏi thêm và phần chưa thể xác nhận. Sau đó nhóm sửa tài liệu hoặc công cụ ở đúng điểm thiếu. Không cần coi mọi trở ngại là lỗi người mới. Khả năng giải thích công việc cho người khác chính là một phép thử sự rõ ràng của quy trình đang được hỗ trợ.

Vì sao khoản đầu tư vào năng lực dễ bị bỏ khỏi dự toán?

Bản tóm lược nghiên cứu J-curve của nhóm tác giả tại MIT giải thích vai trò đầu tư bổ sung vô hình, như đổi quy trình và phát triển năng lực con người, trong việc hiện thực hóa công nghệ có mục đích chung [7]. Đây là lập luận và mô hình kinh tế, không phải lời bảo đảm doanh nghiệp đầu tư đủ sẽ có lợi nhuận sau một khoảng thời gian cố định.

Với trợ lý hồ sơ giả định, chi phí nhìn thấy có thể là phí dịch vụ và tích hợp. Phần ít hiện rõ gồm thời gian thống nhất mã, kiểm tài liệu, tạo bộ tình huống, sửa hướng dẫn và hỗ trợ người mới. Nếu không dự kiến các việc này, nhóm triển khai có thể gọi chúng là phát sinh rồi giảm phạm vi kiểm. Dự toán nên ghi công việc cùng người thực hiện, thay vì chỉ một khoản chung cho “đào tạo và dữ liệu”.

Cần đồng thời tránh dùng đầu tư bổ sung làm lý do kéo dài thử nghiệm vô hạn. Mỗi việc phải gắn với giả thuyết: thống nhất mã có giảm nhầm thiết bị không, hiện vị trí nguồn có giúp người duyệt sửa nhanh hơn không? Nếu sau thay đổi vẫn không đạt tiêu chí, cần xem lại lựa chọn tác vụ. Thừa nhận một phạm vi không đáng tiếp tục là một phần năng lực ra quyết định, không phải bằng chứng tổ chức chống công nghệ.

Đo thay đổi ở người dùng và ở kết quả công việc

Generative AI at Work bản QJE phân tích triển khai trợ lý hỗ trợ khách hàng và ghi nhận tác động khác nhau giữa nhóm kinh nghiệm [8]. Phạm vi đó cho thấy cần chú ý người sử dụng cùng hoàn cảnh làm việc. Nó không xác nhận tác động cho mọi vai, mọi phần mềm hay tổ chức Việt Nam. Bài dùng kết quả để đặt câu hỏi đánh giá, không chuyển mức tác động sang ca dịch vụ kỹ thuật.

Đối với ca giả định, nhóm có thể theo dõi hồ sơ tìm đúng nguồn, thời gian người duyệt sửa và yêu cầu phải mở lại. Song song, hỏi nhân viên đang mất thời gian ở chỗ nào: kiểm nguồn, hiểu giao diện hay xử lý ngoại lệ. Một câu trả lời hài lòng không thay số đo chất lượng; một số đo nhanh hơn cũng không cho biết người dùng phải chịu tải kiểm mới ra sao. Hai loại thông tin nên được đọc cùng nhau.

Phân nhóm kết quả cần có lý do nghiệp vụ và bảo vệ thông tin người tham gia. Có thể bắt đầu bằng nhóm nhiệm vụ hoặc mức quen quy trình, thay vì thu nhiều thông tin cá nhân không cần thiết. Khi so trước và sau, phải ghi những thay đổi khác có thể cùng ảnh hưởng, như lượng hồ sơ hay chính sách. Nếu chưa có thiết kế đủ mạnh, báo đó là quan sát trong thử nghiệm, tránh tuyên bố quan hệ nhân quả.

Áp dụng theo quy mô: giữ ít vai nhưng đủ trách nhiệm

Hộ kinh doanh hoặc đội rất nhỏ có thể dùng một người phụ trách nghiệp vụ và một người kiểm thay phiên, với hồ sơ giả lập để học trước. Chưa cần dựng ban AI. Cần tránh để người tạo bản nháp là người duy nhất xác nhận mọi kết quả có hậu quả. Nếu không đủ chuyên môn để kiểm phần kỹ thuật, nên thu hẹp việc được hỗ trợ, chẳng hạn chỉ sắp xếp câu hỏi và tài liệu cần xem.

Doanh nghiệp vừa có thể chọn một luồng hồ sơ, một nhóm nguồn và một đầu mối xử lý mâu thuẫn. Nhiều nơi đã có nhân sự dữ liệu hoặc công nghệ kiêm nhiệm, nên phải dành thời gian cụ thể cho công việc mới. Nếu chỉ bổ sung trách nhiệm mà không giảm việc khác, số phiếu sửa tồn đọng có thể làm trợ lý tiếp tục dùng dữ liệu cũ. Khi đó vấn đề là cách tổ chức nguồn lực, không chỉ chất lượng mô hình.

Doanh nghiệp lớn cần nối vai tại đơn vị với dịch vụ chung. Nhóm nền tảng có thể quản lý thành phần kỹ thuật; chủ nghiệp vụ vẫn phải giữ nghĩa chỉ tiêu và tiêu chí chấp nhận. Khung NIST gợi ý phân định vai trong phát triển, triển khai, vận hành và kiểm đánh giá [9]. Tham khảo này không thay cơ cấu riêng của doanh nghiệp. Nên chọn cách phân vai có thể kiểm qua một sự cố và một lần thay đổi thật.

Những khác biệt theo quy mô trên là phân tích của bài, chưa phải khảo sát cơ cấu doanh nghiệp Việt Nam. Trước khi áp dụng, cần xác nhận điều kiện nhân lực, dữ liệu và phạm vi quyền hiện có. Một đội nhỏ có tài liệu rõ có thể thử một việc ổn định sớm hơn đơn vị lớn có nhiều nguồn mâu thuẫn. Quy mô không phải thang điểm năng lực và không thể thay bằng chứng về công việc đã hoàn thành.

Hỏi đáp về năng lực AI trong tổ chức

Có cần có đủ dữ liệu mới bắt đầu AI không? Không có mốc đủ chung cho mọi việc. Hãy chọn công việc hẹp có nguồn được phép dùng và người kiểm được kết quả. Đừng chọn nhiệm vụ đòi hỏi lịch sử đầy đủ khi lịch sử ấy chưa tồn tại. Ghi phần thiếu và giữ phạm vi phù hợp, thay vì để mô hình tạo cảm giác tổ chức đã biết.

Làm sao chứng minh tổ chức đang tiến bộ? Hãy xem hồ sơ đã thử, lỗi đã phân loại, nguồn đã sửa và phép kiểm đã chạy lại. Kèm theo là người nhận trách nhiệm cùng đường bàn giao khi họ vắng mặt. Các tài sản đó giúp duy trì công việc. Số tài khoản, lượt hỏi và buổi học mô tả hoạt động, nhưng chưa đủ chứng minh khả năng làm việc đã tăng.

Đội nhỏ có cần lập bộ phận AI riêng không? Chưa nhất thiết. Một người có thể kiêm nhiều vai, nhưng vẫn cần chỉ rõ ai giữ nghĩa dữ liệu, ai kiểm đầu ra và ai quyết định ngoại lệ. Nếu không đủ chuyên môn để kiểm kết quả có hậu quả cao, hãy thu hẹp việc trợ lý được làm. Tên bộ phận không thay được người thực sự nhận và xử lý vấn đề.

Chỉ chọn một việc đầu tiên thì nên chọn gì? Chọn một câu hỏi có thật và lần theo nó từ người hỏi tới nguồn, kết quả và người nhận. Ghi chỗ không rõ thành việc cụ thể, sửa một điểm rồi thử lại. Cách làm này không hứa lịch hoàn vốn cố định; nó giúp phân biệt đang thiếu phần mềm, dữ liệu, kỹ năng hay khả năng phối hợp trước khi đầu tư tiếp.

Nguồn và phương pháp

Bài được tổng hợp và phân tích có hỗ trợ AI, viết lại bằng lời và cấu trúc riêng, không phải bản dịch. Đã đọc các phần được ghi trong hồ sơ nguồn ngày 27/10/2026; nguồn Data Cascades dùng đúng phạm vi tóm tắt của tác giả, J-curve dùng bản research brief. Có công trình do nhóm nghiên cứu thuộc hãng thực hiện, được nêu xuất xứ. Ca doanh nghiệp và các phép thử là giả định; chưa có khảo sát Việt Nam hoặc thẩm định chuyên gia, không dùng làm kết luận pháp lý hay tỷ lệ hiệu quả.