Doanh nghiệp biết AI tốn bao nhiêu — nhưng không biết nó tạo ra gì

Một giám đốc tài chính mở bảng chi phí cuối tháng. Con số cho AI hiện ra rất rõ ràng, rất lớn, và tăng đều mỗi tháng. Bên cạnh nó là một danh sách: bốn mươi mấy “agent” mà các phòng ban đã dựng lên — một trợ lý viết code ở đội kỹ thuật, một bot chăm sóc khách hàng, một công cụ tóm tắt hợp đồng, và vài thứ khác mà bộ phận IT trung tâm còn chưa kịp biết tên. Hóa đơn thì rõ đến từng đồng. Nhưng có một câu hỏi mà cả bảng số kia không trả lời được: trong bốn mươi mấy agent đó, cái nào thực sự đáng tiền, và làm sao để biết?

Đây không phải một câu hỏi giả định. David Tepper — người từng phụ trách chiến lược tiêu thụ gen AI nội bộ của Azure tại Microsoft, nay điều hành Pay-i, một công ty chuyên đo kinh tế của các hệ thống AI — kể rằng mười tám tháng trước, cuộc gọi ông nhận được đến từ một kỹ sư muốn “đo chi phí”. Còn hôm nay, cuộc gọi đến từ một CFO hoặc CIO, và họ không hỏi làm sao để giảm chi phí AI. Họ hỏi làm sao để biện minh cho nó.

Khoảng cách giữa hai câu hỏi đó — “tốn bao nhiêu” và “đáng bao nhiêu” — là chủ đề của bài viết này.

Token là đơn vị thanh toán của nhà cung cấp, không phải đơn vị giá trị của doanh nghiệp. Đo lượng token tiêu thụ mà không đo kết quả công việc, công sức con người bỏ ra để kiểm tra, và chi phí để khắc phục khi agent sai — thì tổ chức không quản lý ROI. Họ chỉ đang quản lý hóa đơn.

Vì sao kinh tế của agent khác phần mềm truyền thống

Phần mềm SaaS được định giá theo người dùng hoặc gói thuê bao. Thêm một người dùng, chi phí biên tăng thêm một khoản gần như dự đoán được. Cả nền kinh tế SaaS được xây trên tính có thể dự báo đó.

Agentic AI phá vỡ giả định này ở gốc. Chi phí không phát sinh theo số người dùng, mà theo mức sử dụng — và tệ hơn cho việc dự báo, theo con đường mà agent tự chọn khi thực hiện nhiệm vụ. Hai lần chạy cùng một yêu cầu có thể dùng model khác nhau, gọi công cụ khác nhau, lặp số vòng khác nhau, nạp lượng context khác nhau. Theo quan sát telemetry của Pay-i, cùng một prompt có thể tạo ra mức chênh lệch chi phí tới ba mươi lần. Chi phí không còn là một con số cố định. Nó trở thành một phân phối.

Trước khi bàn tiếp, cần tách một từ đang bị dùng quá rộng. “Agent” hôm nay được gắn cho ba thứ khác hẳn nhau về kinh tế:

Workflow — phần mềm truyền thống, có AI cắm vào một vài bước. Chi phí bị chặn theo mỗi lần gọi.
Pipeline — một chuỗi bước định sẵn, gọi model nhiều lần theo trình tự cố định. Phần lớn chatbot thực ra là pipeline. Chi phí bị chặn theo số lần gọi đã biết.
Agent thực sự — được giao một mục tiêu rộng, có công cụ và dữ liệu, và tự quyết định gọi cái gì, theo thứ tự nào, trong bao lâu. Chi phí không bị chặn theo nhiệm vụ.

Sự phân biệt này không phải chuyện học thuật. Tepper nói thẳng: phần lớn nhà cung cấp bán cho bạn một “agent” thực ra đang bán một pipeline — điều đó thường đúng là thứ bạn cần, nhưng bạn nên biết mình đang mua gì. Vì workflow và pipeline có chi phí hữu hạn, còn agent thực sự có thể tự mở rộng con đường của nó qua lập kế hoạch, thử lại, kiểm tra và tự sửa. Nói cách khác: automation thực hiện một con đường đã biết; agent lựa chọn con đường trong lúc đang đi. Khi con đường không cố định, chi phí cũng không còn cố định.

Phần đắt nhất không phải là tạo ra câu trả lời

Có một trực giác sai mà gần như ai cũng mắc: nghĩ rằng phần tốn kém nhất của một agent là lúc nó tạo ra output. Dữ liệu cho thấy điều ngược lại.

Một nghiên cứu về agentic software engineering — phân tích 20 luồng coding agent thực tế — phát hiện khoảng 59% lượng token được tiêu ở giai đoạn kiểm tra và tinh chỉnh câu trả lời, không phải ở lần tạo mã đầu tiên. Nói cách khác, gần hai phần ba chi phí nằm ở việc rà lại, sửa, và xác nhận. Con số cụ thể này đến từ coding agent nên không nên bê nguyên sang chăm sóc khách hàng hay marketing; nhưng cơ chế đằng sau nó — kiểm tra tốn hơn tạo ra — thì có khả năng đúng rộng hơn nhiều.

Vì sao? Tepper đưa ra một quan sát sắc: khi một agent thất bại, nó gần như không bao giờ thất bại ở bước cuối. Nó sai ở ba bước trước đó, đôi khi theo cách mà bước cuối che lấp đi. Nếu bạn chỉ chấm output cuối cùng, bạn đang chấm phần được dọn dẹp, không phải phần sai. Output cho biết agent kết thúc ở đâu. Con đường nó đi mới cho biết nó đã tạo ra rủi ro và chi phí như thế nào để đến đó.

Đây là chỗ bài này nối trực tiếp với một bài trước — “Khi human-in-the-loop chỉ còn là một nút Approve”. Bài đó hỏi: con người có thực sự kiểm soát agent không? Bài này hỏi thêm một tầng: chi phí để con người kiểm soát agent đó có đang được tính vào ROI không? Thời gian một chuyên viên ngồi rà lại việc agent làm không phải là chi phí vô hình. Nó là một khoản có thật, và thường không nằm trên bất kỳ hóa đơn nào.

Bốn lớp kinh tế của một agent

Nếu hóa đơn token chỉ trả lời được câu “chúng ta đã tiêu bao nhiêu”, thì cần một khung đầy đủ hơn để trả lời câu “nó có đáng không”. Có thể xếp kinh tế của một agent thành bốn lớp, mỗi lớp trả lời một câu khác nhau.

Lớp 1 — Consumption: agent đã dùng bao nhiêu tài nguyên? Token vào và ra, reasoning token, model nào, số lần gọi công cụ, context nạp vào, độ trễ, compute. Đây là lớp doanh nghiệp nhìn thấy dễ nhất vì nó xuất hiện thẳng trên hóa đơn. Nhưng nó mới chỉ trả lời một câu: đã tiêu bao nhiêu.

Lớp 2 — Performance: agent làm việc thế nào? Tỷ lệ hoàn thành nhiệm vụ, xác suất thành công, số lần thử lại, số bước trong con đường, độ ổn định giữa các lần chạy. Điểm mấu chốt: chỉ đánh giá qua output cuối sẽ bỏ sót lỗi phát sinh ở các bước trước — cần đo con đường, không chỉ đích đến.

Lớp 3 — Human overhead: tổ chức phải bù thêm bao nhiêu công sức? Thời gian kiểm tra, thời gian cung cấp thêm context, escalation, sửa output, làm lại, xử lý hậu quả. Một agent tạo ra kết quả trong hai phút nhưng cần một giờ để con người kiểm tra chưa chắc đã hiệu quả hơn việc con người tự làm trong bốn mươi lăm phút. Thời gian agent tiết kiệm không phải là thời gian xử lý đã loại bỏ. Đó là thời gian xử lý đã loại bỏ, trừ đi thời gian kiểm tra và khắc phục mà agent tạo thêm.

Lớp 4 — Business outcome: rốt cuộc, KPI kinh doanh nào thực sự thay đổi? Doanh thu, chi phí, thời gian xử lý, tỷ lệ chuyển đổi, tỷ lệ sai sót, retention. ROI không phải một KPI — nó là con số được tính từ các KPI kinh doanh và toàn bộ chi phí liên quan. Nhiều tổ chức triển khai hàng chục use case nhưng không xác định ngay từ đầu mỗi agent phải làm thay đổi chỉ số nào, rồi cố gắn KPI vào sau khi hệ thống đã chạy — một việc gần như luôn thất bại.

Bốn lớp gộp lại thành một câu: Consumption cho biết agent đã tiêu gì. Performance cho biết nó đã làm gì. Human overhead cho biết tổ chức phải bù thêm gì. Business outcome cho biết tất cả những điều đó có đáng hay không.

Phép toán quyết định có nên dùng agent hay không

Tepper rút gọn quyết định triển khai một agent về một bất đẳng thức: một agent tạo ra giá trị khi xác suất thành công của nó lớn hơn thời gian con người cần để kiểm tra chia cho thời gian con người cần để tự làm. Viết gọn: P(thành công) > T(kiểm tra) / T(tự làm).

Con số ví dụ khiến bất đẳng thức này mạnh hơn người ta tưởng. Một việc con người mất hai giờ để làm nhưng chỉ mất sáu phút để kiểm tra: T(kiểm tra)/T(tự làm) = 6/120 = 5%. Nghĩa là agent chỉ cần thành công 5 trên 100 lần là đã có lời. Với một lớp lớn công việc doanh nghiệp — nơi việc làm thì lâu nhưng kiểm tra thì nhanh và sai thì bỏ đi được — ngưỡng để agent hữu ích thấp hơn nhiều so với cảm giác trực giác.

Nhưng bất đẳng thức gọn kia chỉ đúng khi cái sai không để lại hậu quả. Một agent xử lý tài liệu tạo ra một bản nháp sai — bạn bỏ đi, không tổn thất gì. Một agent chăm sóc khách hàng nói với khách rằng họ được hoàn một khoản tiền vốn không thể hoàn — bây giờ môi trường đã thay đổi, và bạn có thêm một chi phí khắc phục nằm trên cả chi phí gốc. Có người gọi phần chi phí kiểm tra cộng làm lại này là agency tax. Trong vận hành thực tế, phần làm lại hiếm khi bằng không.

Đây là lý do nên phát triển bất đẳng thức gọn của Tepper thành một công thức thực dụng hơn cho việc ra quyết định:

Giá trị ròng kỳ vọng = P(thành công) × Giá trị outcome − Chi phí AI − Chi phí kiểm tra − P(thất bại) × Chi phí khắc phục.

Công thức này giải thích được một điều tưởng nghịch lý: một agent có độ chính xác chưa cao vẫn có thể rất hữu ích — miễn là việc nó làm mất nhiều thời gian, kiểm tra nhanh, sai thì dễ bỏ, và không làm thay đổi môi trường thực. Ngược lại, một agent cần độ tin cậy rất cao khi nó hành động: khi hành động khó đảo ngược, tạo cam kết với khách hàng, di chuyển tiền, thay đổi dữ liệu quan trọng, hoặc tạo nghĩa vụ pháp lý. Sai một bản nháp tạo ra rework. Sai một hành động tạo ra recovery. Hai loại sai đó không thể dùng chung một ngưỡng ROI.

Điều này cũng lý giải vì sao chọn một model mạnh hơn, đắt hơn trên mỗi token vẫn có thể là quyết định hợp lý: một model giỏi hơn vừa nâng P(thành công) vừa rút ngắn thời gian kiểm tra. Nếu nó kéo thời gian kiểm tra từ mười phút xuống hai phút, phần năng suất thu được thường nuốt trọn khoản token đắt thêm. Chi phí của một use case gen AI, vì thế, không còn là một con số — nó là một phân phối với kỳ vọng và các phần trăm.

Đo lường là một bài toán tổ chức, không phải một dashboard

Điểm sâu nhất của vấn đề không nằm ở FinOps hay ở một dashboard đẹp. Nó nằm ở chỗ ai chịu trách nhiệm về cái gì.

Để thực sự quản lý kinh tế của agent, tổ chức phải trả lời được một loạt câu hỏi sở hữu: Ai sở hữu KPI kinh doanh của agent? Ai sở hữu chi phí kỹ thuật? Ai đo thời gian kiểm tra của con người? Ai định giá hậu quả của một lần thất bại? Và câu quan trọng nhất — ai có quyền dừng một agent không tạo đủ giá trị?

Nếu những trách nhiệm này không rõ, mỗi bộ phận chỉ nhìn thấy một mảnh: tài chính thấy chi phí, kỹ thuật thấy hiệu năng model, kinh doanh thấy vài output hấp dẫn. Không ai nhìn thấy unit economics của toàn bộ workflow. AI observability, theo nghĩa đầy đủ, không chỉ là thấy hệ thống đang chạy thế nào — mà là thấy nó đang tạo ra giá trị gì, với chi phí và rủi ro nào.

Điều này biến vòng lặp vận hành thành trục của quản trị: định nghĩa outcome trước khi triển khai, không gắn KPI vào sau; đo consumption, performance và human overhead; đối chiếu với business outcome; và kết thúc mỗi vòng bằng một quyết định thật — mở rộng, thiết kế lại, hay dừng. Một vòng đo lường không dẫn tới được khả năng dừng thì chỉ là báo cáo, không phải quản trị.

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

Nếu chỉ giữ lại một câu hỏi từ toàn bộ bài này, hãy giữ câu này, và hỏi nó cho từng agent đang chạy trong tổ chức:

Nếu tắt agent này vào ngày mai, KPI kinh doanh nào sẽ xấu đi, và xấu đi bao nhiêu?

Nếu không trả lời được, thì agent đó chưa được nối với giá trị — nó mới chỉ được nối với hóa đơn. Và một khoản chi không nối được với kết quả, dù nhìn có vẻ hiện đại đến đâu, vẫn chỉ là một khoản chi.

Kết

Giai đoạn đầu của gen AI, câu hỏi của doanh nghiệp là “AI có đáng không?” — hỏi một cách trừu tượng. Giai đoạn tiếp theo, câu hỏi sắc hơn nhiều: trong số các agent của tôi, cái nào đáng, và làm sao tôi biết? Trả lời được câu đó đòi hỏi một thứ mà phần lớn tổ chức chưa xây: một kiến trúc đo lường gắn mỗi agent với một kết quả kinh doanh, tính đủ cả chi phí kiểm tra và khắc phục, và trao cho một con người cụ thể quyền dừng.

Token cho bạn biết đã tiêu bao nhiêu. Nó không cho biết bạn có nên tiêu hay không. Toàn bộ khoảng cách giữa hai điều đó — giữa hóa đơn và kết quả — chính là nơi ROI thật sự được quyết định. Đo được khoảng cách đó không phải là một bài toán kỹ thuật. Nó là một quyết định về vận hành.

Bài viết được gợi mở từ cuộc phỏng vấn “Cost versus value: Managing agentic AI system performance” (McKinsey Quarterly, 7/2026), trong đó McKinsey Senior Partner Lari Hämäläinen trao đổi với David Tepper, CEO của Pay-i — một công ty cung cấp giải pháp đo lường kinh tế của hệ thống AI. Vì đây là cuộc phỏng vấn với người có lợi ích trong chính lĩnh vực được bàn, các nhận định nên được dùng để phát triển luận điểm, không nên coi mọi con số là kết luận phổ quát. Các số liệu được dẫn tên nguồn: tỷ lệ ~59% token dành cho kiểm tra và tinh chỉnh đến từ nghiên cứu “Tokenomics” (Salim và cộng sự, arXiv, 1/2026, phân tích 20 luồng coding agent); con số agentic task tiêu gấp khoảng 1.000 lần token so với chat/reasoning đến từ nghiên cứu của Microsoft/Stanford và Bai và cộng sự (arXiv). Bất đẳng thức P(thành công) > T(kiểm tra)/T(tự làm) và khái niệm “agency tax” thuộc về người được phỏng vấn. Khung “bốn lớp kinh tế của một agent” và công thức giá trị ròng kỳ vọng mở rộng — có tính cả chi phí khắc phục — trong bài là cách diễn giải và phát triển của tác giả.