Nam Nguyen
Ghi chép về AI, sản phẩm và cách doanh nghiệp vận hành

AI-native không bắt đầu từ công nghệ, mà từ cách doanh nghiệp vận hành

#AI#operating model#lãnh đạo

Gần đây, tôi đọc bài The Seven Operating Truths of AI-native Companies của McKinsey và thấy bài viết diễn đạt khá chính xác một điều mà tôi đã suy nghĩ nhiều trong quá trình làm sản phẩm và thiết kế các hệ thống AI cho doanh nghiệp:

Khoảng cách thực sự không còn nằm ở việc doanh nghiệp nào có AI và doanh nghiệp nào chưa có AI.

Hầu hết doanh nghiệp hiện nay đều đã thử ChatGPT, Copilot, chatbot nội bộ hoặc một số công cụ tự động hóa. Theo khảo sát được McKinsey dẫn lại, 88% tổ chức đã sử dụng AI trong ít nhất một chức năng kinh doanh. Tuy nhiên, chỉ khoảng 1% tự đánh giá đã đạt mức trưởng thành đầy đủ, còn gần hai phần ba vẫn chưa thể mở rộng AI ra ngoài những dự án thử nghiệm riêng lẻ.

Điều đó cho thấy việc mua thêm công cụ không tự động biến một doanh nghiệp thành AI-native.

Theo tôi, một doanh nghiệp chỉ thực sự trở thành AI-native khi họ bắt đầu thiết kế lại cách công việc được thực hiện:

  • AI đảm nhiệm vai trò gì?
  • Con người giữ lại những quyết định nào?
  • Tri thức của doanh nghiệp được ghi nhận và cập nhật ra sao?
  • Khi nào AI được phép tự hành động?
  • Ai chịu trách nhiệm khi hệ thống đưa ra quyết định sai?
  • Và quan trọng nhất, AI đang giúp doanh nghiệp làm việc cũ nhanh hơn hay đang giúp doanh nghiệp thực hiện những điều trước đây chưa thể làm?

McKinsey đưa ra bảy “operating truths” sau khi trao đổi với lãnh đạo công nghệ và kinh doanh tại 15 công ty có mức độ ứng dụng AI cao. Tôi không muốn dịch lại từng nội dung của bài viết. Thay vào đó, tôi muốn chia sẻ cách tôi hiểu bảy nguyên tắc này từ góc nhìn của một người làm sản phẩm và vận hành.

1. Đừng chỉ xem AI là công cụ. Hãy xác định vai trò của AI trong đội ngũ

Khi nói về AI, nhiều doanh nghiệp vẫn bắt đầu bằng những câu hỏi như:

  • Công cụ này giúp tiết kiệm được bao nhiêu giờ?
  • Nhân viên có thể viết báo cáo nhanh hơn bao nhiêu?
  • Chúng ta có thể giảm được bao nhiêu công việc thủ công?

Những câu hỏi đó không sai, nhưng chúng mới chỉ nhìn AI như một công cụ nâng cao năng suất cá nhân.

Giá trị lớn hơn xuất hiện khi AI được thiết kế như một thành viên trong hệ thống làm việc: có nhiệm vụ cụ thể, được tiếp cận đúng dữ liệu, biết khi nào phải dừng và biết chuyển công việc cho con người khi vượt quá phạm vi năng lực của mình.

McKinsey ghi nhận rằng tại một số công ty AI-native, các AI agent đã có tên, trách nhiệm, không gian làm việc chung và khả năng thực hiện công việc liên tục. Điều đáng chú ý không phải là AI hoạt động 24/7, mà là các công ty đó đã bắt đầu phân chia lại công việc giữa con người và AI.

Trong quá trình thiết kế sản phẩm AI, tôi cũng ngày càng ít quan tâm đến câu hỏi:

“AI trả lời được gì?”

Thay vào đó, tôi quan tâm nhiều hơn đến các câu hỏi:

“AI đang giữ vai trò gì trong quy trình?” “AI đang đề xuất, đang thực hiện hay đang ra quyết định?” “Ai là người chịu trách nhiệm cuối cùng?”

Một chatbot chỉ đưa ra câu trả lời chưa chắc đã tạo ra nhiều giá trị. Nhưng nếu câu trả lời đó được liên kết với nguồn, phản hồi của người dùng, khoảng trống tri thức, người chịu trách nhiệm và một hành động tiếp theo, nó bắt đầu trở thành một phần của hệ thống vận hành.

Tôi thường hình dung chuỗi giá trị đó như sau:

AI Answer → Source → Feedback → Knowledge Signal → Recommended Action

AI không nên tồn tại như một ô chat đứng riêng biệt. Nó cần được đặt vào đúng workflow và có đường chuyển giao rõ ràng giữa máy và người.

Thước đo quan trọng vì thế không chỉ là số giờ được tiết kiệm. Một thước đo thú vị hơn là:

Nhờ AI, doanh nghiệp có thể làm được điều gì mà trước đây họ không đủ người, thời gian hoặc năng lực để thực hiện?

2. Chỉ tự xây những gì thực sự tạo nên sự khác biệt

AI đang làm cho việc tạo ra phần mềm nội bộ trở nên nhanh và rẻ hơn rất nhiều.

Một người không phải lập trình viên chuyên nghiệp cũng có thể dùng AI để tạo dashboard, tự động hóa một quy trình hoặc xây một agent đơn giản. Điều này dễ tạo ra cảm giác rằng doanh nghiệp có thể — và nên — tự xây mọi thứ.

Tôi cho rằng đây là một suy nghĩ nguy hiểm.

Làm ra một công cụ không có nghĩa là doanh nghiệp đã sẵn sàng sở hữu nó lâu dài.

Sau khi công cụ được tạo ra, vẫn còn hàng loạt vấn đề:

  • Ai sẽ bảo trì?
  • Ai cập nhật khi quy trình thay đổi?
  • Ai chịu trách nhiệm về bảo mật?
  • Điều gì xảy ra khi nhân sự tạo ra công cụ rời công ty?
  • Các công cụ riêng lẻ có thể kết nối với nhau hay không?
  • Chi phí vận hành trong hai hoặc ba năm sẽ như thế nào?

McKinsey đưa ra một nguyên tắc tương đối rõ: doanh nghiệp nên tự xây những năng lực tạo ra lợi thế khó sao chép, đặc biệt khi lợi thế đó được hình thành từ dữ liệu, chuyên môn hoặc tài sản trí tuệ riêng. Những năng lực phổ thông hơn có thể được mua hoặc tích hợp từ bên ngoài.

Tôi đồng ý với nguyên tắc này, nhưng sẽ diễn đạt theo một cách khác:

Hãy tự xây phần tạo nên trí tuệ riêng của doanh nghiệp, không nhất thiết phải tự xây toàn bộ công nghệ bên dưới nó.

Phần tạo nên sự khác biệt thường không phải là model AI.

Đó có thể là:

  • Dữ liệu riêng của doanh nghiệp.
  • Cách doanh nghiệp đánh giá một tình huống.
  • Logic đưa ra khuyến nghị.
  • Workflow đã được đúc kết qua nhiều năm.
  • Mối liên hệ giữa dữ liệu, con người và quyết định.
  • Những tiêu chuẩn mà đối thủ không dễ sao chép.

Model, hạ tầng và các công cụ phổ thông nên được thiết kế để có thể thay thế khi cần.

Vì vậy, “build hay buy” không chỉ là một quyết định về chi phí. Đó là quyết định về việc phần nào doanh nghiệp cần sở hữu để duy trì lợi thế và phần nào doanh nghiệp chỉ cần quyền sử dụng linh hoạt.

3. Nút thắt thường không nằm ở model, mà nằm ở tri thức của doanh nghiệp

Đây là luận điểm tôi đồng ý nhất trong toàn bộ bài viết của McKinsey.

Khi một AI agent không thể trả lời một câu hỏi, phản ứng đầu tiên thường là:

  • Model chưa đủ thông minh.
  • Chúng ta cần chuyển sang một model mạnh hơn.
  • Cần viết prompt tốt hơn.

Nhưng trong nhiều trường hợp, model không phải là vấn đề.

Câu trả lời có thể chưa từng được ghi lại. Nó nằm trong đầu của một nhân viên lâu năm, trong một cuộc họp không được ghi âm, trong một file không ai biết là phiên bản mới nhất hoặc trong hàng nghìn đoạn chat không thể tìm kiếm hiệu quả.

McKinsey gọi đây là vấn đề “tribal knowledge”: tri thức tồn tại trong tổ chức nhưng không được chuyển thành tài sản mà hệ thống có thể tiếp cận và sử dụng. Khi AI không tìm thấy câu trả lời, nó chỉ làm cho một vấn đề quản trị tri thức vốn đã tồn tại trở nên rõ ràng hơn.

Tôi đã thấy nhiều doanh nghiệp muốn triển khai AI trong khi:

  • Tài liệu không có người sở hữu.
  • Một chính sách có nhiều phiên bản khác nhau.
  • Không ai biết tài liệu nào còn hiệu lực.
  • Quyết định quan trọng chỉ tồn tại trong email hoặc tin nhắn.
  • Khi một nhân sự nghỉ việc, phần lớn kiến thức của họ cũng rời đi.
  • Nhân viên mới phải hỏi lại những câu hỏi mà hàng chục người trước đó đã từng hỏi.

Trong điều kiện đó, việc kết nối một model mạnh hơn chỉ giúp hệ thống trả lời sai một cách thuyết phục hơn.

Một Knowledge Bot tốt vì thế không thể chỉ là công cụ tìm kiếm tài liệu bằng ngôn ngữ tự nhiên.

Nó phải trả lời được cả những câu hỏi phía sau câu trả lời:

  • Thông tin này đến từ đâu?
  • Nguồn có còn hiệu lực không?
  • Ai là người sở hữu nội dung?
  • Người đang hỏi có quyền xem thông tin này không?
  • Hệ thống tự tin đến mức nào?
  • Người dùng có xác nhận câu trả lời hữu ích không?
  • Những câu hỏi nào đang lặp lại nhưng chưa có câu trả lời tốt?
  • Khoảng trống tri thức đó cần được chuyển thành FAQ, tài liệu, khóa học hay hành động của quản lý?

Khi đó, chatbot không chỉ trả lời câu hỏi. Nó giúp doanh nghiệp phát hiện nơi tri thức đang thiếu, cũ hoặc không nhất quán.

Theo tôi, đây mới là giá trị chiến lược của AI đối với quản trị tri thức.

4. Thiết kế để có thể thay đổi, không phải để phụ thuộc

AI đang thay đổi với tốc độ rất nhanh.

Model tốt nhất hôm nay có thể không còn là lựa chọn tốt nhất sau sáu tháng. Một nhà cung cấp đang có lợi thế về chất lượng có thể bị một nhà cung cấp khác vượt qua về chi phí, tốc độ, khả năng bảo mật hoặc mức độ phù hợp với một loại công việc cụ thể.

Vì vậy, đặt toàn bộ hệ thống vào một model hoặc một nhà cung cấp duy nhất là một rủi ro chiến lược.

McKinsey khuyến nghị doanh nghiệp nên thiết kế một lớp quản trị chung, kết nối các thành phần tốt nhất nhưng vẫn giữ chúng ở trạng thái có thể thay thế. Lớp ổn định của hệ thống phải bao gồm identity, permission, security, data classification và governance, thay vì bị gắn chặt vào một model cụ thể.

Đây cũng là cách tôi nhìn nhận kiến trúc AI cho doanh nghiệp.

Phần cần ổn định không nhất thiết là model.

Phần cần ổn định là:

  • Danh tính người dùng.
  • Quyền truy cập.
  • Phân loại dữ liệu.
  • Cấu trúc tri thức.
  • Workflow.
  • Evidence và audit trail.
  • Quy tắc phê duyệt.
  • Cách hệ thống ghi nhận phản hồi.
  • Cách trách nhiệm được chuyển từ AI sang con người.

Model nên là một thành phần có thể thay thế.

Điều này không có nghĩa là doanh nghiệp phải thay model liên tục. Nó có nghĩa là doanh nghiệp không nên tự đặt mình vào tình thế không thể thay đổi.

Tôi cho rằng trong kỷ nguyên AI, khả năng thay thế công nghệ mà không phải xây lại toàn bộ hệ thống sẽ trở thành một năng lực cạnh tranh quan trọng.

5. AI chỉ nên được tự chủ sau khi đã tạo dựng được niềm tin

Có một sự khác biệt lớn giữa ba hành động:

  1. AI đưa ra đề xuất.
  2. AI thực hiện hành động sau khi được con người phê duyệt.
  3. AI tự quyết định và tự hành động.

Nhiều doanh nghiệp muốn đi thẳng từ bước một đến bước ba vì tự động hóa toàn phần nghe hấp dẫn hơn. Nhưng quyền tự chủ của AI không nên được quyết định bởi mức độ hào hứng với công nghệ.

Nó phải được quyết định bởi rủi ro của công việc và bằng chứng về độ tin cậy của hệ thống.

McKinsey gọi cách tiếp cận này là “progressive autonomy”: ban đầu AI tạo ra nội dung hoặc đề xuất, con người đánh giá; hệ thống chỉ được trao thêm quyền tự chủ sau khi đã chứng minh được chất lượng trong một workflow cụ thể.

Tôi không tin vào việc áp dụng một mức “human in the loop” giống nhau cho mọi tình huống.

Viết bản nháp cho một bài đăng, tổng hợp tài liệu nội bộ, đánh giá hiệu suất nhân viên, gửi email cho khách hàng và ký một hợp đồng là những loại công việc có mức độ rủi ro hoàn toàn khác nhau.

Một số công việc có thể chấp nhận kết quả đúng 80% vì con người dễ dàng kiểm tra và sửa lại.

Một số công việc đòi hỏi độ chính xác gần như tuyệt đối vì một sai sót nhỏ có thể dẫn tới hậu quả pháp lý, tài chính hoặc ảnh hưởng trực tiếp đến con người.

Do đó, mỗi workflow AI cần trả lời rõ:

  • AI được phép làm đến bước nào?
  • Trường hợp nào bắt buộc có phê duyệt?
  • Ai là người phê duyệt?
  • Evidence nào phải được hiển thị?
  • Khi độ tin cậy thấp, hệ thống sẽ làm gì?
  • Khi phát hiện ngoại lệ, công việc được chuyển cho ai?
  • Phản hồi của con người có được dùng để cải thiện hệ thống không?

Tôi đặc biệt coi trọng việc AI phải đưa ra nguồn hoặc evidence cho những quyết định quan trọng.

Niềm tin không được tạo ra bằng cách nói với người dùng rằng “AI rất thông minh”. Niềm tin được tạo ra khi người dùng có thể kiểm tra AI đã dựa vào đâu, hiểu giới hạn của nó và biết rằng luôn có một đường escalation rõ ràng khi hệ thống không chắc chắn.

6. Quản trị nền tảng tập trung, nhưng để từng bộ phận sở hữu bài toán

Việc triển khai AI thường thất bại khi doanh nghiệp đi vào một trong hai cực.

Ở cực thứ nhất, mọi người được tự do sử dụng bất kỳ công cụ nào. Kết quả là dữ liệu nhạy cảm bị đưa lên các hệ thống không được phê duyệt, nhiều công cụ trùng lặp xuất hiện và không ai có cái nhìn tổng thể về rủi ro.

Ở cực thứ hai, mọi quyết định đều phải đi qua một nhóm AI trung tâm. Mỗi bộ phận có một nhu cầu mới lại phải viết yêu cầu, chờ đánh giá, chờ phát triển và chờ triển khai. Đến khi giải pháp hoàn thành, quy trình kinh doanh có thể đã thay đổi.

McKinsey cho rằng mô hình phù hợp hơn là tập trung quyền quản trị nền tảng nhưng phân tán quyền giải quyết vấn đề. Nhóm nền tảng chịu trách nhiệm về kiến trúc, bảo mật, quyền truy cập và guardrail; còn các đơn vị kinh doanh sở hữu bài toán và quyết định AI cần hỗ trợ workflow của họ như thế nào.

Tôi cho rằng đây là một nguyên tắc rất quan trọng.

Không một “AI department” nào có thể hiểu sâu toàn bộ hoạt động của sales, HR, operations, finance, legal và customer support cùng lúc.

Người hiểu rõ nhất điểm nghẽn của một workflow thường là người đang thực hiện workflow đó mỗi ngày.

Mô hình phù hợp hơn là:

Quản trị tập trung, sáng tạo phân tán.

Doanh nghiệp cần cung cấp một nền tảng chung với:

  • Identity và permission rõ ràng.
  • Quy tắc bảo mật thống nhất.
  • Danh sách model và công cụ được phê duyệt.
  • Khả năng ghi nhận hoạt động.
  • Cơ chế approval và audit.
  • Các thành phần có thể tái sử dụng.
  • Guardrail đủ rõ để các nhóm tự thử nghiệm an toàn.

Trên nền tảng đó, từng bộ phận được quyền giải quyết những pain point cụ thể của mình.

Tuy nhiên, phân quyền không có nghĩa là mỗi nhóm tạo ra một hệ thống biệt lập. Các thử nghiệm thành công cần được chia sẻ, chuẩn hóa và tái sử dụng để giá trị được cộng dồn trên toàn tổ chức.

7. Adoption không phải một đợt triển khai, mà là một vòng quay văn hóa

Nhiều doanh nghiệp triển khai AI giống như triển khai một phần mềm mới:

  • Mua license.
  • Tổ chức một buổi đào tạo.
  • Gửi tài liệu hướng dẫn.
  • Yêu cầu nhân viên bắt đầu sử dụng.
  • Sau vài tháng, đánh giá adoption qua số lượt đăng nhập.

Cách tiếp cận này thường không tạo ra thay đổi lâu dài.

McKinsey mô tả adoption như một vòng quay gồm bốn thành phần hỗ trợ lẫn nhau: lãnh đạo làm gương, chia sẻ các trường hợp thành công, đo lường việc sử dụng và tuyển dụng những người có tư duy thử nghiệm với AI.

Tôi đồng ý rằng lãnh đạo phải sử dụng AI trước.

Rất khó thuyết phục nhân viên thay đổi cách làm việc nếu chính lãnh đạo vẫn yêu cầu mọi tài liệu, báo cáo và quyết định được thực hiện theo cách cũ.

Tuy nhiên, tôi không cho rằng adoption có thể được tạo ra chỉ bằng KPI, leaderboard hoặc yêu cầu nhân viên “phải dùng AI”.

Con người không sử dụng một công cụ lâu dài chỉ vì công ty yêu cầu. Họ sử dụng khi công cụ đó giải quyết được một vấn đề thực sự.

Thay vì bắt đầu bằng câu hỏi:

“Làm thế nào để mọi người dùng AI nhiều hơn?”

Doanh nghiệp nên bắt đầu bằng:

“Công việc nào đang lặp đi lặp lại?” “Việc gì đang khiến nhân viên mất thời gian nhất?” “Quy trình nào đang tạo ra nhiều frustration nhất?” “Thông tin nào mọi người phải tìm kiếm hoặc hỏi lại mỗi ngày?” “Công việc nào nhân viên thực sự không muốn tiếp tục làm thủ công?”

Khi AI giải quyết đúng nỗi đau, adoption sẽ trở thành một kết quả tự nhiên.

Một trường hợp thành công nhỏ nhưng cụ thể thường có sức thuyết phục lớn hơn một chiến dịch truyền thông quy mô lớn về “chuyển đổi AI”.

Khi một nhân viên chia sẻ rằng họ đã rút ngắn một công việc từ ba giờ xuống còn 20 phút, những người khác sẽ muốn tìm hiểu. Khi workflow đó được đóng gói để tái sử dụng, lợi ích bắt đầu lan rộng. Khi doanh nghiệp đo lường được tác động thực tế, niềm tin tiếp tục tăng lên.

Vòng quay adoption khi đó diễn ra như sau:

Giải quyết pain point → tạo kết quả → chia sẻ kết quả → tái sử dụng workflow → tạo thêm niềm tin → mở rộng adoption.

Doanh nghiệp cũng cần nhớ rằng thay đổi quá nhanh có thể khiến nhân viên lo lắng hoặc kiệt sức.

AI không nên chỉ được giới thiệu như một công cụ giúp công ty yêu cầu nhiều hơn từ nhân viên. Nó cũng phải giúp con người giảm bớt những công việc lặp lại, tiếp cận tri thức dễ hơn và dành nhiều thời gian hơn cho những việc cần sự phán đoán, sáng tạo và tương tác con người.

Khoảng cách lớn nhất là khoảng cách về operating model

Sau khi đọc bảy nguyên tắc trên, điều tôi thấy đáng chú ý nhất là chúng không tồn tại độc lập.

Khi xem AI như một thành viên trong đội ngũ, doanh nghiệp phải xác định rõ vai trò và trách nhiệm của nó. Khi muốn xây AI agent, doanh nghiệp phải quyết định phần nào nên tự xây và phần nào nên mua. Khi agent cần thực hiện công việc, nó phải tiếp cận được tri thức phù hợp. Khi kết nối với nhiều nguồn dữ liệu, doanh nghiệp phải có kiến trúc, permission và governance rõ ràng. Khi AI bắt đầu hành động, doanh nghiệp phải xác định mức độ tự chủ và những điểm bắt buộc có con người phê duyệt. Khi muốn mở rộng trên toàn tổ chức, doanh nghiệp phải phân chia đúng trách nhiệm giữa nhóm nền tảng và các bộ phận kinh doanh. Và để tất cả những điều trên tồn tại lâu dài, AI phải trở thành một phần của văn hóa làm việc chứ không chỉ là một dự án công nghệ.

McKinsey cho rằng khoảng cách giữa các công ty đã vận hành theo những nguyên tắc này và các công ty mới triển khai chatbot đầu tiên không phải là khoảng cách công nghệ. Đó là khoảng cách về mô hình vận hành — và khoảng cách này đang ngày càng mở rộng.

Tôi đồng ý.

AI-native không phải là một danh hiệu dành cho những công ty sử dụng model mới nhất hoặc mua nhiều công cụ nhất.

Đó là khả năng liên tục thiết kế lại công việc:

  • Phần nào nên giao cho AI?
  • Phần nào con người phải giữ?
  • Tri thức được ghi nhận và cập nhật ra sao?
  • Quyền quyết định được phân bổ thế nào?
  • Hệ thống học hỏi từ phản hồi như thế nào?
  • Và tổ chức có thể thay đổi công nghệ mà không mất đi năng lực cốt lõi hay không?

Công nghệ AI chắc chắn sẽ tiếp tục thay đổi rất nhanh.

Nhưng lợi thế lâu dài có lẽ sẽ không thuộc về doanh nghiệp chọn đúng một model tại một thời điểm.

Nó sẽ thuộc về những doanh nghiệp xây dựng được một operating model trong đó con người và AI có thể phối hợp, học hỏi, tạo dựng niềm tin và liên tục mở rộng những điều tổ chức có khả năng thực hiện.

Đó, theo tôi, mới là ý nghĩa thực sự của một doanh nghiệp AI-native.


Bài viết được gợi mở từ “The Seven Operating Truths of AI-native Companies”, do McKinsey & Company công bố ngày 11/6/2026. Nội dung trên là cách diễn giải và quan điểm cá nhân của tác giả.

← Về trang chính