Stage 1 sang 2: Từ Ad-Hoc đến Pilot, điểm đình trệ AI phổ biến nhất

Nhóm của bạn đã dùng AI rồi. ChatGPT, Copilot, Gemini, Perplexity, có thể cả chục công cụ khác. Không ai biết chính xác cái nào. Không có policy. Không có ngân sách. Một số người dùng tài khoản cá nhân. Và bạn không biết cái gì đang hoạt động, cái gì đang phơi lộ rủi ro cho công ty, hay liệu bất kỳ thứ gì trong số đó có thực sự đẩy doanh nghiệp tiến lên không. Đó là Stage 1.

Và đó cũng là nơi phần lớn các công ty đang đứng vào năm 2026. McKinsey ghi nhận chỉ 11% công ty đã triển khai gen AI ở quy mô thực sự, và gần hai phần ba chưa vượt qua được vài pilot đầu tiên. Bạn không đi chậm. Bạn đang ở trong đa số.

Quá trình chuyển từ Stage 1 sang Stage 2 không hào nhoáng. Nó không đòi hỏi mua nền tảng mới hay tổ chức all-hands để công bố "AI initiative." Nó chỉ đòi hỏi một quyết định có chủ ý: chọn một use case, đặt tên người chịu trách nhiệm, xác định thành công trông như thế nào, và đo lường nó. Chỉ vậy.

Nhưng đây chính xác là bước mà phần lớn các công ty bỏ qua. Thay vào đó họ công bố thêm pilot, lập ủy ban, hoặc cứ chờ chiến lược AI "đúng" xuất hiện. Kết quả là Stage 1 drag: shadow AI lan rộng, rủi ro compliance tích lũy, và 12 tháng sau Board hỏi công ty thực sự đã làm được gì.

Bài viết này cho bạn playbook cụ thể để thực hiện bước chuyển đó.

Stage 1 thực sự trông như thế nào

Thực tế Stage 1

• 78% knowledge worker dùng AI tool cá nhân tại nơi làm việc mà không có sự phê duyệt chính thức của tổ chức, và hầu hết doanh nghiệp không biết công cụ nào đang chạy trong đội ngũ của mình (Microsoft Work Trend Index, 2024)
• 60% dự án AI thiếu dữ liệu AI-ready sẽ bị khai tử trước năm 2026, cho thấy data readiness audit là hành động có đòn bẩy cao nhất ở Stage 1, trước khi bất kỳ pilot nào được phát động (Gartner, 2025)
• Chỉ 11% công ty đã triển khai generative AI ở quy mô; gần hai phần ba chưa vượt qua vài pilot ban đầu, chứng tỏ Stage 1-sang-2 vẫn là điểm đình trệ phổ biến nhất trong enterprise AI (McKinsey, 2025)

Trước khi thoát khỏi Stage 1, bạn cần nhận ra mình đang ở đó. Dưới đây là các dấu hiệu chẩn đoán.

Nhân viên dùng công cụ chưa được kiểm kê. Nhân viên đang dùng AI tool bạn chưa phê duyệt, một số bạn không hề biết đến. Vài người tự bỏ tiền túi. Số khác dùng tier miễn phí. Không ai bị yêu cầu dừng lại, vì chưa có policy nào cả.

Không có ngân sách AI chính thức. Mọi chi phí AI đều nằm rải rác trong báo cáo chi tiêu cá nhân, gói đăng ký phần mềm, hoặc ngân sách bộ phận không nhãn "AI." CFO không thể cho bạn biết công ty đang chi bao nhiêu cho AI.

IT và Legal lo nhưng không có thẩm quyền. IT nghe nói có dữ liệu đưa vào ChatGPT. Legal lo mơ hồ về IP. Nhưng không nhóm nào có ủy quyền, nhiệm vụ, hay hướng dẫn để hành động.

Không có dữ liệu ROI. Nhân viên nói AI "tiết kiệm thời gian" nhưng không ai định lượng được bao nhiêu hay gắn được với kết quả kinh doanh. Lợi ích năng suất đang ở dạng giai thoại.

Các nhóm đăng ký công cụ trùng nhau. Nhiều nhóm đang đánh giá hoặc dùng thử các công cụ khác nhau cho cùng một bài toán. Sales đang xem xét một AI sales tool. Marketing vừa đăng ký cái khác. Hai bên không trao đổi với nhau.

AI tool chưa qua security review. Các vendor chưa trải qua quy trình review bảo mật mua sắm tiêu chuẩn áp dụng cho các SaaS khác. Họ chỉ nhận được thẻ tín dụng của nhân viên.

Nếu ba hoặc nhiều hơn các điều trên đúng với tổ chức của bạn, bạn đang ở Stage 1. Không sao. Phần lớn các công ty vào năm 2026 đều vậy. Nhưng đây không phải trạng thái ổn định.

Tại sao Stage 1 vừa bình thường vừa rủi ro

Stage 1 không phải là thất bại. Đó là cách AI xâm nhập vào mọi tổ chức. Nhân viên thử nghiệm trước khi lãnh đạo có framework. Điều đó lành mạnh ở giai đoạn đầu. Vấn đề là ở mãi đó.

Rủi ro tích lũy theo ba chiều, và không phải rủi ro lý thuyết. Gartner phát hiện 60% dự án AI thiếu dữ liệu AI-ready sẽ bị khai tử trước năm 2026. Các công ty Stage 1 bỏ qua governance và công việc dữ liệu đang đặt nền móng cho thất bại tốn kém.

Phơi lộ dữ liệu. Nhân viên đang dán nội dung vào AI tool công khai mà không biết nội dung đó có nhạy cảm không. Hồ sơ khách hàng, dự báo tài chính, hợp đồng đang soạn thảo, tài liệu chiến lược nội bộ. Mỗi lần paste là một lần phơi lộ dữ liệu tiềm ẩn. Không có policy định rõ cái gì được và không được đưa vào AI tool, mặc định là "mọi thứ đều vào."

Rủi ro IP và compliance. Khi nhân viên dùng AI để tạo nội dung, code, hoặc phân tích, các câu hỏi về sở hữu IP, thiên kiến, và tuân thủ pháp lý không có câu trả lời chính thức từ công ty. Nhân viên hành động một mình. Công ty chịu hậu quả.

Chi phí cơ hội. Các nhóm thử nghiệm riêng lẻ càng nhiều, tổ chức càng tích lũy ít kiến thức chung. Mỗi nhóm tự mày mò lại cùng một bộ prompt. Không ai chia sẻ điều gì hiệu quả. Công ty trả tiền cho nỗ lực AI mà không thu được giá trị AI.

Tin tốt: bạn không cần giải quyết tất cả những điều này trước khi chuyển sang Stage 2. Bạn chỉ cần giải quyết đủ để một pilot có cấu trúc trở nên khả thi.

Tiêu chí thoát Stage 2

Stage 2 không phải điểm đến. Đó là sàn mới. Ba điều kiện để tự gọi mình là tổ chức Stage 2:

Cả ba phải đồng thời đúng. Có policy nhưng không có pilot thì vẫn là Stage 1 với governance tốt hơn. Có pilot nhưng không có policy thì vẫn là Stage 1 với thử nghiệm tốt hơn. Stage 2 đòi hỏi cả hai.

Cách chọn pilot đầu tiên

Chọn use case là nơi phần lớn bước chuyển Stage 1-sang-2 thất bại. Các nhóm hoặc chọn use case hấp dẫn nhất (đối diện khách hàng, độ phủ cao, bài toán dữ liệu phức tạp nhất), hoặc để bộ phận nói to nhất quyết định. Cả hai đường đều sai.

Framework đúng có ba bộ lọc. Áp dụng theo thứ tự.

Bộ lọc 1: Data readiness. Trước khi chọn bất kỳ use case nào, hỏi xem bạn có dữ liệu sạch, có thể truy cập, và đã được policy cho phép để hỗ trợ nó không. Data readiness là kẻ giết pilot thầm lặng và phổ biến nhất. Một use case hấp dẫn về mặt kinh doanh nhưng data nghèo sẽ thất bại. Một use case ít hấp dẫn hơn nhưng data tốt sẽ dạy bạn điều gì đó thực sự. Bắt đầu với dữ liệu bạn có, không phải dữ liệu bạn ước mình có.

Bộ lọc 2: Risk profile. Với pilot đầu tiên, tránh các khả năng Execute đối diện khách hàng. Các Execute action có hệ quả trực tiếp và rõ ràng: email đã gửi, record đã cập nhật, deal đã thay đổi, phản hồi đã giao. Khi pilot gặp sự cố, bạn muốn ảnh hưởng chỉ ở nội bộ. Đánh giá từng use case theo thang rủi ro đơn giản: thấp (chỉ nội bộ, người kiểm soát output), trung bình (đối diện khách hàng, AI soạn thảo nhưng người gửi), cao (tương tác khách hàng hoàn toàn tự động). Chọn rủi ro thấp cho Pilot 1. Ranh giới Generate vs. Execute giải thích tại sao ranh giới này quan trọng với pilot đầu tiên.

Bộ lọc 3: Impact potential. Trong số các lựa chọn data-ready, rủi ro thấp, chọn cái có tác động kinh doanh rõ ràng nhất: giờ tiết kiệm, tỷ lệ conversion cải thiện, tỷ lệ lỗi giảm. Không cần phải lớn. Cần phải đo được.

Ví dụ cụ thể. Một công ty SaaS 50 người áp dụng framework này và đưa ra ba ứng viên: (1) AI-assisted lead scoring dùng dữ liệu CRM, (2) AI-generated email sequence nháp đầu cho sales development rep, và (3) AI-powered phân loại và định tuyến support ticket.

Lead scoring (lựa chọn 1) bị loại ở Bộ lọc 1. CRM thiếu dữ liệu ở 40% record. Lựa chọn 3 bị loại ở Bộ lọc 2 vì liên quan đến phản hồi khách hàng. Lựa chọn 2 vượt qua cả ba bộ lọc. CRM và hệ thống email có dữ liệu sạch. Phạm vi ảnh hưởng chỉ trong nhóm SDR. Và có thể đo reply rate và meeting booked rate trực tiếp. Pilot 1 là AI-generated SDR email sequence.

Đó là toàn bộ framework lựa chọn.

Xây dựng pilot charter

Sau khi chọn được use case, hãy chuẩn hóa nó thành văn bản. Pilot charter không cần dài. Nó cần tồn tại.

Một pilot charter Stage 2 cần năm yếu tố:

1. Hypothesis. Nêu rõ bạn tin điều gì sẽ xảy ra và tại sao. "Chúng tôi tin email SDR có AI hỗ trợ sẽ tăng reply rate 15% vì rep hiện dành 40% thời gian prospecting để cá nhân hóa email mà AI có thể làm nhanh hơn."

2. Chỉ số thành công. Một chỉ số chính. Không phải năm. Một. Với ví dụ SDR: reply rate trên AI-assisted sequence so với nhóm kiểm soát trong 60 ngày.

3. Đo baseline. Trạng thái hiện tại, đo trước khi pilot bắt đầu. Không đo trước thì không chứng minh được sau. Kéo dữ liệu reply rate hiện tại trước khi chạm vào bất cứ thứ gì.

4. Ranh giới thời gian. Pilot không có ngày kết thúc sẽ chạy mãi mãi. Đặt 60 hoặc 90 ngày. Đến hạn, bạn quyết định: mở rộng quy mô, gia hạn, hoặc dừng. Cả ba đều là kết quả hợp lệ. Chạy vô thời hạn thì không.

5. Người chịu trách nhiệm. Một người duy nhất chịu trách nhiệm về kết quả pilot. Không phải ủy ban. Không phải nhóm làm việc. Một người trình bày kết quả khi đến hạn.

Nếu không điền được cả năm, bạn chưa sẵn sàng bắt đầu pilot.

"Bước chuyển Stage 1-sang-2 chỉ đòi hỏi một thứ: một pilot với hypothesis, baseline có thể đo được, và một người chịu trách nhiệm. Không phải bộ slide chiến lược, không phải ủy ban governance, không phải hợp đồng nền tảng AI enterprise. Một thử nghiệm có giới hạn, có thể đo được. Đó là toàn bộ tiêu chuẩn." (Rework)

Crossing Test Stage 1-sang-2

Chẩn đoán bốn câu hỏi xác nhận tổ chức đã thực sự vượt Stage 1, thay vì chỉ gán nhãn lại các hoạt động Stage 1 cũ. Câu hỏi 1: Có AI use policy bằng văn bản không, và tất cả nhân viên đã xác nhận nhận? Câu hỏi 2: Có đúng một pilot có tên với hypothesis và chỉ số thành công được ghi lại không? Câu hỏi 3: Baseline có đo trước khi pilot bắt đầu không? Câu hỏi 4: Pilot có người chịu trách nhiệm và ngày kết thúc xác định không? Nếu bất kỳ câu trả lời nào là "không," tổ chức vẫn ở Stage 1. Crossing Test cố ý đặt bar cao: dễ tuyên bố Stage 2 dựa trên khối lượng hoạt động. Crossing Test đo governance và cấu trúc, không phải hoạt động.

Governance tối thiểu khả thi cho Stage 2

AI policy của bạn ở Stage 2 không cần là tài liệu pháp lý 40 trang. Nó cần bao gồm năm điều.

Danh sách công cụ được phê duyệt. Các AI tool cụ thể nhân viên được phép dùng, kèm điều kiện sử dụng. Bắt đầu từ những gì mọi người đã đang dùng và chuẩn hóa chúng. Thêm tiêu chí phê duyệt cho công cụ mới.

Hạn chế dữ liệu. Các loại dữ liệu không được đưa vào AI tool bên ngoài nếu không có phê duyệt rõ ràng. Tối thiểu: PII khách hàng, dự báo tài chính, nội dung M&A, và hợp đồng bảo mật. Quyết định đơn lẻ này loại bỏ phần lớn rủi ro compliance ở Stage 1.

Quy trình yêu cầu công cụ mới. Cách nhân viên đề xuất dùng AI tool mới. Giữ đơn giản: một form, một người review có tên (IT hoặc Legal), và thời hạn xử lý 5 ngày làm việc. Mục tiêu không phải chặn adoption. Mà là tạo ra hồ sơ.

Báo cáo sự cố. Nhân viên cần làm gì nếu AI tool tạo ra kết quả sai: output sai gửi đến khách hàng, dữ liệu vô tình bị phơi lộ, mô hình tạo nội dung phân biệt đối xử. Ngay cả một quy tắc đơn giản "email [tên] ngay lập tức" cũng tạo ra accountability.

Vùng không cho AI tự quyết. Các quyết định AI không được đưa ra mà không có người xem xét. Các quyết định pháp lý (tín dụng, tuyển dụng, y tế) là baseline. Thêm vào bất kỳ điều gì đặc thù cho ngành của bạn.

Policy này không cần được legal sign-off để có hiệu lực. Nó cần tồn tại và được phổ biến. Bạn tinh chỉnh dần khi học được thêm.

Building Your AI Use Policy đề cập vấn đề này đầy đủ, với hướng dẫn từng phần.

Kiểm tra data readiness trước khi cam kết

Phần lớn các công ty Stage 1 ngạc nhiên khi nhận ra dữ liệu của mình chưa sẵn sàng cho AI pilot đến mức nào. Trước khi cam kết với một use case, hãy chạy qua năm câu hỏi audit này.

1. Bạn có thể truy cập dữ liệu AI cần ngay hôm nay không, không cần dự án IT kéo dài nhiều tuần?
2. Các trường quan trọng có ít nhất 70% được điền không, hay còn khoảng trống null đáng kể?
3. Dữ liệu có đủ cập nhật để phản ánh thực tế kinh doanh hiện tại không?
4. Có một nguồn uy quyền duy nhất không, hay nhiều hệ thống cạnh tranh với các record mâu thuẫn?
5. Legal hoặc bộ phận security đã xác nhận loại dữ liệu này được dùng trong AI tool bên ngoài chưa?

Nếu bạn trả lời "không" hoặc "không rõ" cho hai câu hoặc nhiều hơn, use case đó có dependency data readiness sẽ nổi lên thành failure khi pilot chạy. Hãy sửa dữ liệu trước, hoặc chọn use case khác. Bài viết Data Readiness cung cấp framework audit đầy đủ.

Các failure mode phổ biến Stage 1-sang-2

Failure mode 1: Chọn sai pilot đầu. Use case nổi bật và hấp dẫn nhất hầu như không bao giờ là pilot đầu đúng đắn. Đối diện khách hàng, rủi ro cao, data nghèo. Chọn nhàm chán và đo được còn hơn hấp dẫn và phức tạp.

Failure mode 2: Bỏ qua baseline. "Tính ROI sau pilot" chỉ tạo ra tranh luận, không phải bằng chứng. Luôn đo trước khi thay đổi bất cứ thứ gì. Nếu đã quên đo trước và pilot đang chạy rồi, dừng lại và đo ngay. Baseline nào cũng tốt hơn không có.

Failure mode 3: Bị policy paralysis. Một số tổ chức cố viết AI policy hoàn hảo trước khi khởi động bất kỳ pilot nào. Họ tham vấn Legal, IT, Compliance, HR. Quy trình review kéo sáu tháng. Trong thời gian đó, shadow AI lan rộng thêm. Bản nháp hoạt động với các khoảng trống đã biết vẫn tốt hơn policy hoàn hảo chưa tồn tại.

Failure mode 4: Quá nhiều pilot. "Chạy năm pilot song song để học nhanh hơn." Sai. Năm pilot không có người chịu trách nhiệm duy nhất, không có nhóm kiểm soát, và không có hạ tầng chung tạo ra năm điểm dữ liệu không kết luận được gì. Một pilot chạy tốt với measurement đúng tạo ra một câu trả lời thực sự.

Failure mode 5: Đổi chỉ số giữa chừng. Khi pilot không tạo ra kết quả như kỳ vọng, sức cám dỗ là đổi chỉ số. Đừng làm vậy. Chỉ số đã đặt trong charter. Nếu pilot thất bại theo chỉ số ban đầu, đó là thông tin có giá trị. "AI email sequence không cải thiện reply rate" là một phát hiện thực sự. Chuyển sang chỉ số khác giữa chừng để cứu pilot đang thất bại chỉ tạo ra dữ liệu gây hiểu nhầm.

Stage 2 thực sự cảm giác như thế nào

Một tổ chức Stage 2 có policy được đăng ở đâu đó (shared drive, company handbook), một pilot với charter và người chịu trách nhiệm, ngày bắt đầu, lịch read-out kết quả, và baseline measurement được lưu. Thực sự chỉ vậy.

Nó không cảm giác như transformation. Nó cảm giác như một dự án nhỏ được quản lý đúng cách. Đó chính là ý nghĩa của nó.

Transformation xảy ra vì pilot đơn lẻ này, nếu chạy tốt, tạo ra dữ liệu thực sự để xây dựng luận điểm cho Stage 3. Các công ty bứt lên Stage 3 mà không có nền móng Stage 2 sẽ thấy mình có nhiều AI tool, không có hạ tầng chung, và không có bằng chứng nào cho thấy bất cứ thứ gì hoạt động. Họ xây độ phức tạp của Stage 3 trên nền tảng dữ liệu Stage 1.

Rework Analysis: Dựa trên các pattern chuyển đổi enterprise AI, thời gian trung bình để một công ty mid-market hoàn thành Crossing Test Stage 1-sang-2 là 8-14 tuần khi CEO đặt rõ mandate. Nguyên nhân chậm phổ biến nhất là yêu cầu đo baseline: các nhóm phát hiện mình không thể dễ dàng kéo chỉ số trước-pilot nhận ra có vấn đề data readiness phải giải quyết trước khi pilot bắt đầu. Sự chậm trễ này thực ra có giá trị. Nó bộc lộ khoảng trống dữ liệu trước khi nó phá hỏng pilot, không phải sau.

Stage 2 không hào nhoáng. Hãy làm nó dù vậy.

Bước tiếp theo

Khi pilot đầu tiên hoàn thành và bạn đã ra quyết định mở rộng/gia hạn/dừng, bạn sẵn sàng nghĩ đến việc chuyển từ pilot sang sản xuất thực sự. Bước chuyển đó, sang Stage 3, có bộ yêu cầu, quyết định hạ tầng, và failure mode riêng. Đây là bước khó nhất trong toàn bộ đường cong maturity.

Đọc: Stage 2 sang 3: Từ Pilot đến Scaled để xem production deployment checklist và các yêu cầu hạ tầng.

Đọc: 5 Stages of AI Maturity để hiểu bước chuyển này nằm ở đâu trong mô hình maturity đầy đủ.

Và nếu bạn đang tự hỏi liệu transformation của mình có bền vững không: Why Most AI Transformations Fail trình bày các lý do cấu trúc khiến phần lớn tổ chức bị mắc kẹt giữa các stage.

Xem thêm:

• The 18-Month CEO AI Agenda: Phase 1 (Assess and Govern) ánh xạ như thế nào đến bước chuyển Stage 1-sang-2
• The ACE Framework: bộ từ vựng capability mà pilot charter của bạn nên dùng khi xác định nhiệm vụ AI