Trong 12 tháng qua, tôi đã có cơ hội trò chuyện với hơn 100 lãnh đạo cấp C-suite tại những công ty lớn nhất nước Mỹ. Cuộc trò chuyện gần như lúc nào cũng diễn ra theo cùng một kịch bản: họ đã chi hàng triệu USD để đưa AI vào doanh nghiệp — từ việc mua thêm license phần mềm đến đổ tiền trực tiếp cho các nhà cung cấp model thông qua token usage.
Ban lãnh đạo liên tục nói về việc “AI-first”, nhưng khi bị hỏi điều gì thực sự thay đổi trong vận hành hằng ngày, câu trả lời thường là… không có gì đáng kể.
Đội AP vẫn làm AP theo cách cũ. Month-end close vẫn mất hơn 20 ngày. Sales rep vẫn struggle để đạt quota. CRM vẫn xuống cấp dữ liệu giống hệt vài năm trước.
Tôi muốn nói về lý do tại sao chuyện này xảy ra, vì sao model AI không phải vấn đề, và điều gì tôi đã thấy ở những doanh nghiệp triển khai AI thành công thật sự.
Để có thêm bối cảnh: tôi điều hành Varick Agents — công ty chuyên triển khai AI vào enterprise để xử lý công việc thực tế mà không buộc khách hàng phải thực hiện những cuộc migration khổng lồ khỏi hệ thống hiện tại.
Model AI đã đủ tốt từ lâu
Điều đầu tiên cần nói rõ: model AI hiện tại đã đủ tốt.
Đã hơn một năm rưỡi kể từ GPT-o3 — model đầu tiên mà tôi có thể giao một tác vụ thực tế mà không cần babysit output quá nhiều. Sau đó là Opus 4, GPT-5 và Gemini 3. Giờ chúng ta đã có Opus 4.7 và GPT 5.5.
Trong khoảng thời gian đó, giá giảm mạnh, context window mở rộng đáng kể và tool calling trở nên chính xác hơn rất nhiều.
Các “harness” cũng trưởng thành nhanh không kém. Hai năm trước, khái niệm này gần như chỉ là copy prompt trên Twitter. Giờ đây nó đã trở thành recursive context engineering, eval pipeline và những tool stack thực sự hoạt động ổn định trong production.
Anthropic từng viết một tài liệu gần như canonical về chủ đề này — “Building Effective Agents”. Kết luận cốt lõi của họ rất đơn giản:
“Hãy tìm giải pháp đơn giản nhất có thể, chỉ tăng độ phức tạp khi thực sự cần thiết.”
Và đó cũng là điều tôi thấy trong thực tế. Phần lớn production agent hoạt động tốt ngày nay chủ yếu là code, chỉ có một hoặc hai lần gọi model ở những điểm thực sự cần thiết. Nghe khá nhàm chán, nhưng đó lại chính là lý do chúng hiệu quả.
Nhưng enterprise vẫn thất bại hàng loạt
Theo báo cáo MIT NANDA GenAI Divide tháng 8/2025, chỉ khoảng 5% AI pilot tích hợp thực sự tạo ra giá trị lớn. 95% còn lại gần như không có gì để chứng minh.
Điều đáng chú ý là hàng loạt tổ chức nghiên cứu khác nhau đều đưa ra kết quả tương tự. BCG nói chỉ 4% doanh nghiệp đạt AI value ở quy mô lớn. Deloitte cho biết chỉ 6% đạt ROI AI trong vòng một năm. RAND báo cáo hơn 80% dự án AI thất bại — cao gấp đôi dự án IT thông thường. IBM cho biết 75% sáng kiến AI không đạt ROI kỳ vọng. McKinsey thì phát hiện phần lớn doanh nghiệp đã dùng AI thường xuyên nhưng gần như không tạo ra tác động EBIT đáng kể.
Điều thú vị hơn nữa là những con số này gần như không thay đổi qua mọi thế hệ model.
GPT-3, GPT-4, GPT-5. Claude 2 đến Claude 4.7. Gemini 1 đến Gemini 3.
Model ngày càng mạnh hơn, nhưng tỷ lệ thất bại trong enterprise gần như đứng yên.
Điều đó cho thấy bottleneck chưa bao giờ nằm ở model.
AI đang hoạt động cực kỳ tốt cho developer
Có một nhóm duy nhất đang thật sự hưởng lợi ở quy mô lớn từ AI hiện tại: software engineer.
Đây cũng là nhóm ít phụ thuộc vào business logic nhất.
Người thắng lớn nhất sau 18 tháng AI bùng nổ chính là các kỹ sư viết code bằng Cursor, Claude Code hay Codex.
Nghiên cứu GitHub năm 2024 cho thấy người dùng Copilot hoàn thành task nhanh hơn khoảng 55%. Anthropic thực hiện nghiên cứu nội bộ trên hơn 100 kỹ sư và kết luận AI giúp giảm khoảng 80% thời gian hoàn thành task lập trình. Sundar Pichai cũng cho biết đầu năm 2026 rằng khoảng 75% code mới tại Google được AI tạo ra và kỹ sư phê duyệt — tăng mạnh so với năm trước.
Đúng là AI vẫn chưa thật sự giỏi ở những bài toán khó như distributed systems phức tạp, security review hay debugging rất đặc thù. Nhưng với phần lớn công việc viết code hằng ngày, mức tăng năng suất là quá rõ ràng.
Trong khi đó, các bộ phận khác gần như không thay đổi
Sales ops có Agentforce của Salesforce. HubSpot có Breeze. Ngoài kia có hàng trăm startup CRM “AI-native” đang quảng bá về “cái chết của Salesforce”.
Nhưng các chỉ số bán hàng thực tế gần như không đổi.
Sales rep vẫn chỉ dành một phần nhỏ thời gian để bán hàng. Tỷ lệ đạt quota vẫn thấp. Forecast accuracy vẫn lẹt đẹt như vài năm trước.
Finance cũng tương tự. Mọi nền tảng kế toán đều tung ra “AI cho AP/AR”. Mọi AI-native ERP đều hứa hẹn rút ngắn close-cycle. Nhưng quy trình đóng sổ kế toán trung bình hầu như không thay đổi.
Marketing có vô số AI content tool mới. Marketer nói họ tiết kiệm được một ít thời gian mỗi tuần, nhưng đóng góp thực tế vào pipeline thì gần như giữ nguyên.
Operations thậm chí còn tệ hơn. Mọi workflow tool đều cố gắng gắn thêm LLM vào sản phẩm cũ. Đội vận hành giờ vừa phải làm việc như cũ, vừa phải tìm cách ép AI vào những quy trình rất đặc thù của công ty mình.
Vì sao AI hiệu quả với engineer nhưng thất bại ở enterprise?
Là một cựu software engineer, tôi nghĩ engineering có bốn đặc tính mà hầu hết công việc enterprise khác không có.
Công việc lập trình thường có ranh giới rõ ràng. Một function nhận input và trả output. Một bug thường nằm trong một file hoặc module cụ thể.
Nó cũng dễ kiểm tra. Compiler cho biết code parse được hay không chỉ trong vài mili giây. Test cho biết code chạy đúng không. Type system bắt được nhiều lỗi trước cả runtime.
Hệ nền của software engineering cũng cực kỳ có cấu trúc. Code nằm trong file, có version control, có deterministic build pipeline. Bạn có thể replay gần như mọi trạng thái.
Và cuối cùng, output của engineering rất dễ xác minh. Reviewer chỉ cần nhìn pull request trong vài phút là có thể đánh giá đúng sai khá rõ ràng.
Khi AI được áp dụng vào loại công việc vừa bounded, vừa structured, vừa checkable như vậy, leverage tạo ra là cực lớn. Cursor và Claude Code là minh chứng rõ ràng nhất.
Nhưng finance và operations thì hỗn loạn hơn nhiều
Một finance close thực tế không chỉ là vài bước kế toán đơn giản.
Nó liên quan đến AP, AR, intercompany reconciliation, FX, accrual, journal entry và hàng loạt exception handling khác nhau. Workflow trải dài qua NetSuite, Concur, nhiều ngân hàng, nhiều ERP cũ từ các công ty được mua lại, custom form nội bộ và cả Slack channel nơi controller đánh dấu những “case kỳ lạ”.
SOP gần như không bao giờ phản ánh đúng thực tế.
Sales ops cũng tương tự. CRM, outbound tool, calendar, notes platform, attribution tool và Slack thường không share state sạch với nhau. Mỗi rep có cách qualify lead khác nhau, thậm chí ngay trong cùng một team.
Đó là trạng thái mà Varick nhìn thấy ở gần như mọi doanh nghiệp từng audit. Không có gì bounded hay deterministic như software engineering cả.
Kết quả thường là ROI âm
Khi bạn đưa generic AI vào những workflow như vậy, kết quả thường không phải tăng năng suất mà là tăng thêm việc.
Người vận hành ban đầu xử lý task trong 30 phút. Giờ họ mất thêm thời gian để kiểm tra và sửa lỗi AI.
Đó là lý do rất nhiều sản phẩm “AI for [department]” đều đi theo cùng một vòng đời: demo cực kỳ ấn tượng cho startup, gọi vốn thành công, sau đó thất bại âm thầm khi triển khai cho enterprise.
Sai lầm lớn nhất: build trước khi hiểu workflow
Trong 18 tháng triển khai AI cho doanh nghiệp doanh thu từ hàng trăm triệu đến hàng tỷ USD, tôi thấy failure mode phổ biến nhất là mọi người build trước khi thật sự hiểu workflow.
Hầu như công ty nào cũng nghĩ họ đã hiểu quy trình của mình. Nhưng khi audit thực tế, luôn xuất hiện hàng loạt bước không hề có trong SOP.
Có những spreadsheet bí mật mà nhân viên luôn kiểm tra trước. Có những workaround bằng email vì notification system không hoạt động. Có những exception type chỉ người lâu năm mới biết cách xử lý.
Nếu build theo SOP, bạn thường chỉ tự động hóa được khoảng 70% workflow. Và chính 30% còn lại mới là nơi gây ra chaos.
Một sai lầm khác: dùng LLM cho mọi thứ
LLM rất hấp dẫn. Một khi đã có nó, mọi vấn đề đều trông như bài toán dành cho LLM.
Extract value? Gọi model.
Compare number? Gọi model.
Routing logic? Gọi model.
Kết quả là một hệ thống vừa chậm, vừa đắt, vừa hallucinate ở những nơi không được phép sai.
Những production system hoạt động tốt thường rất “boring”. Phần lớn là code thông thường. LLM chỉ xuất hiện ở những nơi thực sự cần judgment, ví dụ như đọc dữ liệu từ invoice không cấu trúc hoặc phân loại exception khó.
Agent sprawl đang trở thành cơn ác mộng mới
Một vấn đề khác bắt đầu xuất hiện mạnh sau vài tháng triển khai là agent sprawl.
Mỗi nhân viên giờ đều có thể tự tạo agent cho riêng mình bằng Lovable, Cursor hay các no-code AI tool khác.
Kế toán tạo invoice agent. FP&A lead tạo workflow variance report. Marketing tạo content agent. Recruiting tạo candidate screening agent.
Ban đầu điều này trông rất tích cực. Nhưng sau vài tháng, doanh nghiệp có hàng chục hoặc hàng trăm workflow AI riêng biệt, mỗi cái dùng một kiểu architecture, một kiểu logging, một kiểu model config và một kiểu prompt khác nhau.
Không có shared memory. Không có orchestration layer. Không có governance.
Đến lúc model bị deprecated, API thay đổi hoặc nhân viên nghỉ việc, engineering team suddenly phải đi “dọn rác AI” cho toàn công ty.
Sai lầm cuối cùng: xem AI như một side-project
Rất nhiều công ty triển khai AI như software thông thường: lập kế hoạch, build, deploy rồi tuyên bố thành công.
Nhưng AI không hoạt động như phần mềm truyền thống.
Mỗi quý đều có thay đổi lớn. Model mới xuất hiện. Pricing thay đổi. Rate limit thay đổi. Chất lượng model thay đổi. Vendor thay đổi chiến lược.
Anthropic từng phải công khai xin lỗi vì Claude Code bị degrade hiệu năng hơn một tháng do lỗi engineering nội bộ. Những workflow production phụ thuộc vào nó cũng bị ảnh hưởng theo.
Những deployment AI thành công thật sự đều xem AI như infrastructure sống — thứ cần được tối ưu và điều chỉnh liên tục.
Điều 5% doanh nghiệp thành công làm khác biệt
Những công ty thật sự triển khai AI thành công thường có một pattern rất giống nhau.
Họ audit trước khi build. Họ dành nhiều tuần để quan sát workflow thực tế thay vì chỉ đọc SOP.
Họ cố biến càng nhiều phần của workflow thành deterministic càng tốt, chỉ dùng LLM ở nơi thực sự cần judgment.
Họ xây một orchestration layer duy nhất thay vì để mỗi phòng ban tự tạo agent riêng.
Họ giữ kiến trúc model-agnostic để không bị khóa vào một vendor duy nhất.
Và quan trọng nhất: họ xem AI là infrastructure evolving liên tục, chứ không phải một side-project sáu tháng rồi bỏ đó.
“Models got smart” đã không còn là câu chuyện chính nữa
Chương “models got smart” thực ra đã kết thúc rồi.
Enterprise không nên tiếp tục ngồi chờ AGI nữa.
Thập kỷ tiếp theo sẽ thuộc về những công ty xây dựng được lớp vận hành nằm bên dưới model — thay vì tiếp tục đổ frontier AI lên một mớ workflow hỗn loạn rồi tự hỏi vì sao chẳng có gì thay đổi.