Khi AI pilot biến cách làm cũ thành code

Một hiện tượng tôi để ý thấy lặp lại ở nhiều nơi: những thứ chạy được bằng AI trong doanh nghiệp ngày càng ít khi đi ra từ một dự án. Chúng chỉ đơn giản là xuất hiện. Một người nào đó dựng một cái gì đó cho phần việc của mình, nó chạy, vài tuần sau cả nhóm dùng nó, và không ai nhớ được thời điểm công ty quyết định làm theo cách ấy.

Asmus Komm, Bryan Hancock và Sandra Durth, trong một bài mới của McKinsey về HR trong kỷ nguyên agentic, mô tả rất gọn cái ngưỡng đã làm cho chuyện này xảy ra: một payroll specialist hay một recruiter bây giờ có thể cấu hình một agent chạy được trong một buổi chiều, bằng công cụ low-code. Không cần một dự án lớn. Không cần ngân sách riêng. Không cần chờ một dự án IT. Và nhiều khi cũng chưa cần ai phê duyệt — vì tổ chức chưa có quy trình quy định rằng việc đó phải được phê duyệt.

Agent chạy được. Nó tiết kiệm vài giờ mỗi tuần. Vài người bên cạnh bắt đầu dùng theo. Đến đây, gần như không tổ chức nào đặt câu hỏi đúng: thứ vừa được tạo ra là một công cụ, hay là một quyết định?

McKinsey gọi hiện tượng này là pilot trap — tổ chức đạt tốc độ ở cấp tác vụ nhưng dần lệch hướng ở cấp operating model. Khi việc tạo ra một agent rẻ và nhanh đến mức đó, thử nghiệm nhỏ không còn là một hoạt động trung tính. Mỗi agent đang âm thầm mã hóa một cách làm việc, một bộ quyền hạn và một cách phân chia trách nhiệm.

Tôi cho rằng đây là chỗ bài của McKinsey đi xa hơn lời khuyên quen thuộc “start small and learn”, và cũng là lý do tôi muốn viết lại nó theo góc của người vận hành:

Một AI pilot không chỉ kiểm chứng công nghệ. Nó mã hóa các giả định về workflow, decision rights, dữ liệu, quyền truy cập, ngoại lệ và trách nhiệm. Nếu tổ chức chưa xác định operating model đích, tổng của những pilot thành công sẽ trở thành một operating model ngoài ý muốn.

Các tác giả đặt sự khác biệt vào một câu mà tôi cho là câu sắc nhất trong bài: ở những lần chuyển đổi trước, đi mà không có blueprint thì cái mất là thời gian; lần này, cái mất là chính bản blueprint. Tốc độ triển khai ngay tại frontline có thể khiến những thiết kế cục bộ trở thành dependency trước khi lãnh đạo kịp thống nhất kiến trúc chung.

Và họ nói thẳng một điều mà tôi nghĩ nhiều ban lãnh đạo vẫn còn tránh: “start small” bây giờ vẫn xảy ra dù lãnh đạo có cho phép hay không. Câu hỏi duy nhất còn lại là những nỗ lực đó diễn ra bên trong một thiết kế có chủ đích, hay thay cho một thiết kế.

Điều nguy hiểm không phải là pilot thất bại

Một pilot thất bại thường dễ xử lý. Dừng lại. Đổi công nghệ. Thu hẹp use case. Sửa dữ liệu. Thử lại. Chi phí của nó gần như chỉ là chi phí đã bỏ ra.

Pilot nguy hiểm hơn nhiều là pilot thành công vừa đủ. Vì khi nó thành công vừa đủ, những việc sau sẽ xảy ra gần như tự động: người dùng bắt đầu phụ thuộc vào nó; workflow được điều chỉnh quanh nó; data integration được xây riêng cho nó; KPI được thiết lập theo nó; ngân sách được cấp tiếp; một nhóm người trở thành owner không chính thức; và những agent khác bắt đầu sao chép cùng một pattern vì đó là pattern duy nhất đang chạy được trong công ty.

Đến lúc đó, pilot không còn là thử nghiệm. Nó đã trở thành tiền lệ.

Một pilot thành công cục bộ có thể tạo ra chi phí quay đầu trước khi doanh nghiệp kịp biết mình có thực sự muốn mở rộng cách làm đó hay không.

Cơ chế này có thể mô tả bằng một chuỗi năm bước, và tôi nghĩ ban lãnh đạo nên nhìn nó như một chuỗi chứ không phải như từng sự kiện rời rạc:

Pilot — giải quyết một pain point cục bộ. Pattern — cách làm đó được lặp lại ở những nơi khác vì nó đã “có sẵn”. Dependency — workflow, dữ liệu và con người bắt đầu phụ thuộc vào nó. Architecture — nhiều dependency ghép lại thành một hệ thống. Operating model — hệ thống đó quyết định cách tổ chức thực sự vận hành.

Vấn đề không phải doanh nghiệp có quá nhiều thử nghiệm. Vấn đề là các thử nghiệm đang tự kết nối thành một hệ thống mà không ai chủ động thiết kế.

Operating model luôn xuất hiện. Câu hỏi duy nhất là nó được lãnh đạo thiết kế có chủ đích, hay được hình thành từ tổng của những quyết định cục bộ.

Năm quyết định mỗi pilot đang âm thầm đưa ra

Nếu chấp nhận rằng một pilot là một quyết định chứ không chỉ là một công cụ, thì câu hỏi tiếp theo là: nó đang quyết những gì? Theo tôi có năm nhóm, và cả năm đều thuộc về operating model chứ không thuộc về công nghệ.

Nói ngay một chỗ dễ nhầm: bài gốc cũng có một mục năm quyết định, nhưng đó là năm quyết định một CHRO phải chủ động đưa ra khi khởi hành. Năm nhóm dưới đây là chuyện ngược lại — năm quyết định đang được đưa ra rồi, trong từng pilot, bởi những người không được giao nhiệm vụ quyết chúng.

1. Workflow — công việc sẽ được tổ chức như thế nào

Một agent được tạo ra để xử lý một bước cụ thể thường mặc nhiên giả định rằng bước đó vẫn cần tồn tại, input hiện tại là hợp lý, handoff hiện tại phải được giữ lại, output hiện tại vẫn có giá trị, và những bước trước sau sẽ không thay đổi.

Năm giả định đó không hề nhỏ. Khi thiết kế lại end-to-end, tổ chức có thể nhận ra cả bước ấy nên được loại bỏ hoàn toàn, hoặc hấp thụ vào một workflow khác. McKinsey đưa ra chính cảnh báo này: doanh nghiệp có thể bỏ rất nhiều công để tối ưu những bước mà operating model tương lai sẽ xóa bỏ.

Một bước có thể tự động hóa không có nghĩa đó là một bước đáng được giữ lại.

2. Decision rights — agent được quyền quyết định điều gì

Pilot cũng đang trả lời một loạt câu hỏi mà phần lớn tổ chức chưa từng viết ra thành văn bản: agent chỉ đề xuất hay được hành động? Khi nào cần con người phê duyệt? Ai xử lý ngoại lệ? Quyết định nào có thể đảo ngược? Ai có quyền dừng agent? Trường hợp nào bắt buộc escalation?

Nếu những câu này được trả lời riêng lẻ theo từng use case, tổ chức sẽ có hàng chục định nghĩa khác nhau về human oversight và mức tự chủ — mỗi định nghĩa hợp lý trong bối cảnh của nó, và không định nghĩa nào áp được cho cái còn lại.

Mức tự chủ không nên là một thuộc tính của sản phẩm. Nó phải là một quyết định của operating model.

Đây cũng là chỗ nối thẳng vào bài tôi viết về human-in-the-loop: thêm một nút Approve không phải là thiết kế quyền kiểm soát. Nếu mỗi pilot tự định nghĩa lấy điểm dừng của con người, cái tổ chức thu được cuối cùng không phải oversight, mà là một tập hợp các nút bấm rời rạc.

3. Architecture — agent sẽ sống trên nền tảng nào

Ở đây bài đặt ra một tension rất thật giữa HR và IT, và tôi nghĩ nó đúng với mọi function chứ không riêng HR. Agent thuộc về workflow của bộ phận nghiệp vụ, nhưng nền tảng vận hành nó lại liên quan tới identity, security, integration và orchestration của toàn doanh nghiệp. Nếu IT sở hữu hoàn toàn, bộ phận nghiệp vụ phải xếp hàng chờ và mất đúng cái tốc độ vốn là lý do họ làm pilot. Nếu bộ phận nghiệp vụ tự xây, doanh nghiệp có nguy cơ hình thành một tầng công nghệ song song nằm ngoài quản trị chung.

Cách đặt vấn đề đúng, theo tôi, không phải “ai sở hữu công nghệ”, mà là phân chia rành mạch giữa: nền tảng tập trung, product được xây tập trung, agent được cấu hình tại frontline, chuẩn kiến trúc chung, và quyền tùy biến cục bộ. Tập trung toàn bộ sẽ làm mất tốc độ. Phân tán toàn bộ sẽ làm mất tính nhất quán. Không có phương án nào tránh được việc phải vẽ ra ranh giới — chỉ có phương án vẽ nó có chủ đích và phương án để nó tự hình thành.

4. Accountability — ai sở hữu agent sau pilot

Trong giai đoạn thử nghiệm, agent thường được chăm sóc bởi một nhóm dự án hoặc vài người nhiệt tình. Nhưng sau pilot, phải có người sở hữu chất lượng, chi phí, permission, performance drift, ngoại lệ, cập nhật chính sách, quyết định mở rộng hoặc thu hồi, và cả việc cho agent ngừng hoạt động khi workflow thay đổi.

McKinsey dự báo một phần đáng kể công việc HR trong tương lai sẽ là agentic capability management: cấu hình, kiểm thử, theo dõi, điều chỉnh và cho agent nghỉ hưu. Đây là công việc gần với product management và technology management hơn là xử lý case truyền thống — nghĩa là một loại năng lực mà phần lớn function nghiệp vụ hiện chưa có, và cũng chưa có ai được giao.

Agent không kết thúc vòng đời khi pilot được approve. Đúng lúc đó, vòng đời vận hành của nó mới bắt đầu.

5. Workforce — con người sẽ học và trưởng thành bằng cách nào

Đây là quyết định ít được nhìn thấy nhất, và theo tôi là quyết định có hậu quả dài nhất. McKinsey đặt nó thành một tension rất gọn: automating work và accelerating people không tự động đi cùng nhau. Nếu agent tiếp quản phần việc entry-level, judgment của thế hệ tiếp theo không còn hình thành tự nhiên qua apprenticeship nữa. Nó phải được thiết kế có chủ đích, hoặc nó sẽ không xuất hiện.

Một pilot tuyển dụng có thể rút ngắn thời gian screening. Nhưng cùng lúc, nó cũng đang trả lời: recruiter trẻ còn được đọc bao nhiêu hồ sơ? Họ học cách phân biệt ứng viên tốt bằng cách nào? Ai kiểm tra logic xếp hạng của agent? Judgment được hình thành ở đâu? Lộ trình từ operator lên strategist còn tồn tại không?

Mỗi task được agent hấp thụ cũng lấy đi một nơi con người từng học nghề.

Tôi đã viết riêng một bài về hình dạng này — AI tăng năng suất nhưng có thể làm suy yếu năng lực dài hạn — và điểm mới ở đây là: quyết định đó không nằm ở cấp chiến lược nhân sự. Nó đang được đưa ra trong từng pilot, bởi những người không được giao nhiệm vụ nghĩ về nó.

“North Star back” không có nghĩa là lập kế hoạch tới năm 2030

Đề xuất của McKinsey là doanh nghiệp nên xác định trước human–agent operating model đích, rồi làm ngược lại để quyết định: pilot nào nên triển khai, theo thứ tự nào, capability nào phải xây trước, governance nào phải có, công nghệ nào có tính nền tảng, và quyết định nào có thể đảo ngược.

Tôi biết phản xạ đầu tiên với chữ “North Star” thường là hoài nghi, vì nó gợi đến những bản kế hoạch dài hạn viết ra rồi để đó. Nhưng North Star ở đây không đòi hỏi lãnh đạo dự đoán chính xác công nghệ năm 2030. Nó chỉ đòi hỏi trả lời một nhóm câu hỏi ổn định hơn nhiều so với công nghệ:

• HR — hoặc function đang bàn tới — sẽ tạo ra giá trị gì cho doanh nghiệp?
• Con người sẽ giữ loại judgment nào?
• Agent được giao loại execution nào?
• Workflow nào sẽ biến mất hoàn toàn, chứ không phải được tối ưu?
• Ai sở hữu các human–agent system?
• Năng lực con người mới được hình thành ra sao?
• Điều gì được cá nhân hóa để phục vụ nhân viên, và điều gì sẽ bị xem là surveillance?

Các tác giả chốt bằng một câu đáng nhớ: một North Star chưa có lập trường rõ về cả ba tension — platform ownership, investment versus surveillance, automating work versus accelerating people — thì chưa phải là một North Star.

Tôi đồng ý, và chỉ thêm một quan sát về cách đọc: ba tension đó là ba câu phải trả lời, không phải ba rủi ro để theo dõi. Một tài liệu chiến lược né cả ba vẫn có thể được trình bày rất tốt — nó chỉ chưa quyết được gì.

Hai chiều phải chạy song song

Điều tôi đánh giá cao ở bài này là nó không phủ nhận bottom-up experimentation. McKinsey đề xuất hai dòng công việc cùng tồn tại: bottom-up experimentation để tạo quick win, evidence và momentum; và structural redesign để bảo đảm các thử nghiệm cùng hướng về một operating model nhất quán.

Cách đặt vấn đề này giúp tránh hai cực đoan mà tôi đều đã nhìn thấy trong thực tế.

Chỉ có North Star. Tổ chức tạo ra một bản thiết kế đẹp, trình bày tốt, nhưng không có evidence, không có năng lực thực thi, và không ai trong đó từng chạm vào một agent thật.

Chỉ có pilot. Tổ chức có hàng chục use case hữu ích, mỗi cái đều bảo vệ được, nhưng cộng lại không tạo thành một hệ thống có thể mở rộng, quản trị và học hỏi.

North Star không thay thế thử nghiệm. Nó quyết định thử nghiệm nào xứng đáng trở thành tương lai.

Vì sao HR là ca khó nhất

Bài của McKinsey đặt trọng tâm vào HR, và tôi nghĩ đó là lựa chọn đúng — không phải vì HR quan trọng hơn các function khác, mà vì HR là nơi mâu thuẫn lộ ra rõ nhất.

HR có một dual mandate. Thứ nhất, tự thiết kế lại chính mình thành một human–agent function. Thứ hai, giúp toàn doanh nghiệp thiết kế lại công việc, vai trò, workforce và cách con người phát triển.

Hai nhiệm vụ này ràng buộc nhau chặt hơn nhiều người nghĩ. Nếu HR chỉ triển khai chatbot, tự động hóa payroll hoặc screening nhưng vẫn giữ nguyên workflow và talent model cũ, họ sẽ mất tính chính danh vào đúng lúc cần nó nhất — lúc yêu cầu các function khác tái thiết sâu hơn. McKinsey diễn đạt khá thẳng: một HR function chuyển đổi chậm hơn tổ chức mà mình đang tư vấn, hoặc chỉ tự động hóa task trong khi kêu gọi người khác redesign workflow, sẽ đánh mất uy tín để dẫn dắt.

HR không thể hướng dẫn doanh nghiệp xây workforce cho kỷ nguyên agent bằng chính operating model của kỷ nguyên ERP.

Tôi để dành một lưu ý ở đây, vì nó liên quan tới cách đọc bài gốc. Bài dự báo rằng tới năm 2030, khoảng hai phần ba hoạt động HR hiện nay có thể được tự động hóa hoàn toàn, hoặc được agent thực thi toàn bộ trong khi con người vẫn sở hữu chính sách, kết quả và các trường hợp ngoại lệ. Bài cũng phác một sơ đồ tổ chức HR tương lai theo mô hình product và platform. Cả hai đều đáng tham khảo để hình dung quy mô thay đổi. Nhưng tôi không khuyên đặt bài toán của mình quanh những con số đó: chúng là phân tích định hướng, phụ thuộc mạnh vào công nghệ, quy định, dữ liệu và mức chấp nhận của từng tổ chức, và một sơ đồ tổ chức mẫu thì không nên biến thành prescription phổ quát.

Luận điểm bền hơn nằm ở chỗ khác, và chính bài gốc đã đặt nó rất đúng:

Câu hỏi không phải là có con người tham gia hay không, mà là judgment của con người nằm ở đâu trong một workflow mà agent thực hiện phần lớn execution.

Tôi chỉ thêm một vế. Bất kể tỷ lệ automation cuối cùng là bao nhiêu, câu hỏi đó vẫn phải được trả lời — và trên thực tế nó đang được trả lời trong từng pilot, chứ không phải trong tài liệu chiến lược.

Vòng vận hành nên có

Nếu phải mô tả cỗ máy đúng, tôi vẽ nó thành một vòng lặp có tám mắt xích:

Xác định North Star → đặt architectural principles → chọn entry point → chạy pilot có kiểm soát → thu thập evidence → thiết kế lại workflow end-to-end → mở rộng những pattern dùng chung → quay lại hiệu chỉnh North Star.

Trong nhiều tổ chức tôi quan sát, vòng lặp này bị rút xuống còn ba mắt xích: chọn chỗ dễ, làm pilot và đo kết quả. Ba mắt xích đầu và hai mắt xích cuối — vốn là phần biến một tập hợp thử nghiệm thành một năng lực — thường không có ai sở hữu.

Hệ quả cụ thể nhất nằm ở cách chấm điểm một pilot. Nếu pilot chỉ được đánh giá bằng thời gian tiết kiệm, số case xử lý, hoặc mức độ hài lòng của người dùng, thì mọi thứ tôi viết ở trên đều vô hình. Một pilot còn phải trả lời được:

• Nó kiểm chứng giả thuyết nào về operating model tương lai?
• Điều gì trong đó có thể dùng chung cho nơi khác?
• Điều gì chỉ hợp với context cục bộ và không nên nhân bản?
• Quyết định nào của nó đang tạo ra dependency?
• Năng lực con người nào phải được xây song song?

Năm câu hỏi này không cần một dự án phân tích. Chúng cần được đưa vào đúng biểu mẫu đánh giá pilot mà tổ chức đang dùng.

Phép thử dành cho lãnh đạo

Tôi đề nghị hai câu hỏi. Cả hai đều trả lời được trong một cuộc họp.

Câu thứ nhất: pilot này đang kiểm chứng một phần của operating model tương lai — hay chỉ đang biến quy trình hiện tại thành code?

Câu thứ hai, và tôi thích câu này hơn: nếu 50 pilot đang chạy trong công ty đều thành công, chúng sẽ hợp lại thành loại tổ chức nào?

Tôi chọn con số 50 không phải để cho có. Bài gốc kể về một tổ chức đã triển khai đúng 50 use case — từ chatbot trả lời câu hỏi của nhân viên, tới tự động tổng hợp cuộc họp, tới learning và quản trị hiệu suất — mỗi cái đều có giá trị ở quy mô nhỏ, và cộng lại đã tạo ra tiết kiệm chi phí đáng kể cùng cải thiện thật về mức độ phục vụ. Nghĩa là tình huống trong câu hỏi trên không phải một giả định: 50 pilot cùng thành công là chuyện đã xảy ra rồi. Và điều các tác giả cảnh báo ngay sau đó cũng chính là điều tôi muốn nhấn — tác động của cách làm ấy vẫn có thể bị giới hạn, nếu từng use case không được nối vào một thiết kế lại tổng thể về workflow, vai trò và năng lực.

Đó là lý do tôi thích câu thứ hai: nó không thể trả lời bằng thành tích của từng pilot. Kể cả khi cả 50 cái đều thắng, câu hỏi vẫn còn nguyên. Muốn trả lời được, người ta buộc phải nhìn vào tổng thể. Nếu không ai trong phòng trả lời nổi, thì tổ chức đang thử nghiệm công nghệ, chứ chưa thực sự thiết kế transformation.

Kết

Bài này nối vào một mạch tôi đã đi qua trong nhiều bài, và lần này nó chạm vào phần gốc nhất. Một tính năng AI không phải là một năng lực doanh nghiệp — feature chỉ trở thành capability khi được đặt trong workflow và operating model. Nhân viên đã sẵn sàng nhưng doanh nghiệp thì chưa — thử nghiệm cục bộ có thể chạy nhanh hơn khả năng thay đổi của tổ chức. Chuyển đổi vẫn thất bại khi không ai làm sai — mỗi pilot hợp lý cục bộ vẫn có thể tạo ra một kiến trúc phi lý ở cấp doanh nghiệp.

Điểm mới của bài này là chiều thời gian. Những bài trước nói về việc tối ưu cục bộ tạo ra kết quả sai ở cấp tổng. Bài này nói thêm rằng cái sai đó đông cứng lại: nó tự tạo ra dependency, tiền lệ và chi phí quay đầu, và mỗi tuần trôi qua thì tháo ra lại đắt hơn.

Nguy cơ của pilot trap không phải là doanh nghiệp thử nghiệm quá nhiều. Nguy cơ là mỗi thử nghiệm đang đưa ra một phần quyết định về operating model, trong khi không ai chịu trách nhiệm thiết kế tổng thể.

Và nếu chỉ giữ lại một câu:

Một AI pilot có thể chỉ mất một buổi chiều để xây. Nhưng nếu nó biến cách làm cũ thành code, tổ chức có thể mất nhiều năm để tháo nó ra.

---

Bài viết được gợi mở từ “Escaping the pilot trap: Building HR for the agentic era” của Asmus Komm, Bryan Hancock và Sandra Durth (McKinsey & Company, People & Organizational Performance Practice, tháng 8/2026).

Thuộc về bài gốc: khái niệm pilot trap — “tốc độ ở cấp tác vụ, lệch hướng ở cấp thiết kế”; chính câu đã đặt tên cho bài này, rằng mỗi agent thiếu quản trị lại đóng cứng một mảnh của operating model cũ thành code; ví dụ một payroll specialist hay một recruiter có thể cấu hình agent trong một buổi chiều bằng công cụ low-code; cảnh báo rằng doanh nghiệp có thể tối ưu những bước mà operating model tương lai sẽ xóa bỏ; câu “ở những lần chuyển đổi trước, đi mà không có blueprint thì mất thời gian; lần này, cái mất là chính bản blueprint”; nhận định rằng “start small” vẫn xảy ra dù lãnh đạo có cho phép hay không, và câu hỏi chỉ là nó diễn ra bên trong một thiết kế hay thay cho một thiết kế; ca một tổ chức triển khai 50 use case cùng cảnh báo kèm theo; cách tiếp cận North Star back cùng ba tension và câu “chưa có lập trường rõ về cả ba thì chưa phải là một North Star”; căng thẳng HR–IT về platform ownership và rủi ro hình thành một tầng công nghệ song song; agentic capability management; dual mandate của HR cùng cảnh báo về tính chính danh; hai dòng bottom-up và structural redesign chạy song song; câu hỏi judgment của con người nằm ở đâu trong một workflow mà agent thực hiện phần lớn execution; dự báo tới năm 2030 khoảng hai phần ba hoạt động HR có thể được tự động hóa hoàn toàn, hoặc được agent thực thi toàn bộ trong khi con người vẫn giữ chính sách, kết quả và ngoại lệ; và mô hình tổ chức HR theo product–platform.

Chỗ giáp ranh giữa hai bên đã được nói thẳng trong thân bài: bài gốc có mục năm quyết định dành cho CHRO, và cũng có bốn lớp chuyển đổi (workflow; tổ chức và nhân sự; công nghệ và dữ liệu; quản trị chuyển đổi) phủ lên phần lớn cùng địa hạt với năm nhóm ở đây. Khác biệt nằm ở chiều: bên đó là những quyết định lãnh đạo phải chủ động đưa ra trước, bên này là những quyết định đang được đưa ra sẵn mà không ai bấm nút.

Của tác giả: chuỗi pilot → pattern → dependency → architecture → operating model; lập luận rằng một pilot “thành công vừa đủ” nguy hiểm hơn một pilot thất bại vì nó tạo ra tiền lệ và chi phí quay đầu; vòng vận hành tám mắt xích; hai phép thử dành cho lãnh đạo; cùng các câu chốt in nghiêng trong thân bài.