Liệu AI Observability, Evaluation và Assurance Có Hòa Làm Một?

7 nguyên tắc của Nadella, thương vụ 915 triệu USD của Dynatrace mua lại Arize, và cuộc tranh luận giữa các CIO, nhà sáng lập cùng giới đầu tư về việc ai nên là người kiểm tra AI agent. Cập nhật tháng 10 năm 2026.

Một AI agent có thể giải thích quy trình hoàn tiền cực kỳ chuẩn xác nhưng lại chuyển tiền nhầm tài khoản. Nội dung hội thoại nghe thì rất lọt tai, nhưng giao dịch thì sai bét.

Hiện có ba nhóm sản phẩm được tạo ra để phát hiện những lỗi kiểu này: observability (khả năng quan sát), evaluation (đánh giá) và assurance (đảm bảo). Các nhà cung cấp đã bắt đầu sáp nhập chúng lại với nhau. Liệu người mua có làm theo hay không vẫn còn bỏ ngỏ, và một câu hỏi thứ hai cũng chưa có lời đáp: ai mới là người nên đứng ra kiểm tra, và thế nào mới được gọi là độc lập?

AI đang tiến hóa từ chỗ chỉ biết trả lời câu hỏi sang trực tiếp thực thi hành động. Gartner dự đoán rằng đến năm 2028, một phần ba các ứng dụng phần mềm doanh nghiệp sẽ tích hợp agentic AI, tăng vọt so với mức dưới 1% của năm 2024. Những agent này có thể viết và gửi code, chuyển tiền, giao tiếp với khách hàng, mà thường chẳng cần ai phải giám sát chúng theo thời gian thực.

Khi phần mềm chỉ đưa ra câu trả lời, câu hỏi duy nhất là câu trả lời đó có tốt không. Còn với agent, ta phải đặt ra nhiều câu hỏi hơn: nó đã làm gì, làm vậy có đúng không, ai dám đứng ra chịu trách nhiệm cho nó, và liệu có dừng nó lại được không? Với các CIO, đây vừa là bài toán kỹ thuật, vừa là vấn đề quản trị rủi ro và điều phối AI.

Hiện tại, có ba thị trường đang đảm nhận từng phần của bài toán này:

• AI observability ghi lại những gì AI đã làm.
• AI evaluation đo lường mức độ hoàn thành công việc của nó.
• AI assurance tổng hợp bằng chứng, các biện pháp kiểm soát và giới hạn của chúng để con người có thể đưa ra quyết định mang tính chịu trách nhiệm. Chính phủ Anh mô tả đây là quá trình đo lường, đánh giá và truyền đạt mức độ đáng tin cậy.

Thị trường AI observability đạt 1,25 tỷ USD vào năm 2025, và cũng chính nghiên cứu này kỳ vọng mảng evaluation và quality assurance sẽ tăng trưởng nhanh nhất trong đó. Ngày 1 tháng 10 năm 2026, Dynatrace hoàn tất thương vụ mua lại Arize, một thỏa thuận trị giá 915 triệu USD nhằm kết hợp evaluation và observability. Cisco chốt xong thương vụ Galileo vào tháng 5. Đến ngày 10 tháng 10, Satya Nadella công bố bảy nguyên tắc để xây dựng niềm tin vào AI, chạm đến cả ba thị trường trên.

Phần còn lại của bài viết sẽ phân tích hành trình AI đi đến điểm này, những gì Nadella đề xuất, và cuộc tranh luận giữa năm góc nhìn tổng hợp về hướng đi sắp tới của thị trường.

Từ luật lệ đến AI agent: vì sao niềm tin ngày càng khó xây dựng

Lịch sử tóm gọn qua bốn giai đoạn. Mỗi giai đoạn lại giúp máy móc giỏi hơn, nhưng cũng khó giải thích hơn.

1. Luật lệ (khoảng thập niên 1950 đến 2000). Hầu hết ứng dụng phần mềm đều được viết thủ công, từng bước một. Chúng đầy rẫy lỗi, nhưng kỹ sư có thể mở code ra và tìm đúng dòng gây lỗi.
2. Mẫu hình (thập niên 2010). Với deep learning, máy móc học từ ví dụ thay vì từ các luật lệ có sẵn cho những tác vụ như nhận diện hình ảnh và giọng nói. Chẳng ai viết logic cả. Các hệ thống này chủ yếu dán nhãn, xếp hạng và gợi ý, còn con người hoặc phần mềm thông thường sẽ quyết định làm gì với kết quả đó.
3. Chat (2022 đến 2024). Chatbot biết viết, tóm tắt và tranh luận. Chúng thường xuyên sai, nhưng con người thường đọc câu trả lời trước khi hành động dựa trên đó.
4. Agent (từ 2025 trở đi). Agent tự click, gõ phím, mua hàng, code và deploy. Các phòng thí nghiệm huấn luyện chúng bằng cách cho thực hành tác vụ trong môi trường văn phòng, trình duyệt và codebase mô phỏng. Một số chạy liên tục trong thời gian dài mà không cần ai rà soát từng bước.

Ở giai đoạn chat, một câu trả lời tệ cùng lắm chỉ tốn công đọc lại. Nhưng ở giai đoạn agent, một hành động sai có thể làm mất tiền, rò rỉ dữ liệu hoặc mất khách.

Phần mềm vốn đã đưa ra những quyết định tự động đắt giá từ lâu trước khi agent xuất hiện. Điểm khác biệt bây giờ là một mô hình đa dụng duy nhất tự chọn và thực thi cả chuỗi hành động xuyên suốt nhiều công cụ. Khi xảy ra sự cố, nguyên nhân có thể nằm ở mô hình, prompt, dữ liệu nó truy xuất, một API, bộ nhớ cũ, quyền hạn của nó, hoặc thậm chí là màn tương tác giữa hai agent. Câu trả lời cuối cùng chỉ là một phần của bức tranh toàn cảnh.

Nadella mô tả tình trạng cũ như sau: với phần mềm truyền thống, "chúng ta có công cụ và năng lực để truy vết hành vi về một đường dẫn code cụ thể." Còn với các mô hình hiện tại, không ai chỉ ra được dữ liệu huấn luyện hay trọng số nào đứng sau một quyết định cụ thể. Ba thị trường kể trên đang nỗ lực lấp khoảng trống đó.

Khung quản trị AI của Satya Nadella: 7 nguyên tắc để tin tưởng AI agent

Ngày 10 tháng 10 năm 2026, Nadella đăng bài "Models as Insider Risks in the Super Intelligence Era" trên blog cá nhân. Đề xuất cốt lõi của ông là "chúng ta cần tách bạch nguồn cung trí tuệ khỏi quyền kiểm soát nó."

Ông ví một mô hình mạnh mẽ như một nhân viên được cấp quyền truy cập rộng rãi. Vấn đề không nằm ở chỗ mô hình có ý đồ xấu. Bất kỳ ai nắm quyền truy cập vào hệ thống quan trọng đều có thể mắc lỗi hoặc bị xâm phạm, nên bạn phải giới hạn phạm vi họ chạm tới, ghi lại việc họ làm, và luôn giữ khả năng chặn họ lại. Đúng như lời ông: "Nếu không quan sát được, thì không thể tin tưởng!"

Ông gọi đó là bảy "nguyên tắc observability". Đọc gộp lại, chúng tạo thành một khung quản trị AI dành cho agent. Dưới đây là phần diễn giải lại từng nguyên tắc, kèm theo ánh xạ của riêng tôi sang các thị trường đang phụ trách chúng hiện nay.

1. Đa dạng mô hình: không một AI nào được tự kiểm tra công việc của chính mình hay tự đưa ra quyết định quan trọng. Thị trường hiện tại: evaluation.
2. Quan sát mọi thứ: mọi hành động có ý nghĩa đều phải để lại bằng chứng chống giả mạo mà con người đọc được. Thị trường hiện tại: observability.
3. Khả năng kiểm chứng: toàn bộ hệ thống được kiểm thử liên tục, bao gồm cả các kịch bản tấn công, lỗi và trường hợp biên. Thị trường hiện tại: evaluation và assurance.
4. Kiểm soát độc lập: các quy định về quyền truy cập của AI phải nằm ngoài AI, nơi nó không thể can thiệp sửa đổi. Thị trường hiện tại: chủ yếu là các công cụ bảo mật và quản lý truy cập, dù guardrail đã bắt đầu xuất hiện trên các nền tảng AI.
5. Khả năng kiểm toán độc lập: bằng chứng về hành vi của AI phải được lưu trữ tách biệt khỏi chính AI đang bị kiểm tra. Thị trường hiện tại: assurance.
6. Khoanh vùng: người có thẩm quyền có thể tạm dừng hoặc tắt mô hình ngay giữa chừng khi nó đang chạy tác vụ. Thị trường hiện tại: chủ yếu là các công cụ runtime và bảo mật.
7. Công bố sự cố: khi xảy ra lỗi, những người bị ảnh hưởng phải được thông báo và bài học phải được chia sẻ. Thị trường hiện tại: đây là thông lệ nội bộ doanh nghiệp, được hỗ trợ bởi dữ liệu observability.

Không thị trường đơn lẻ nào bao quát quá hai trong số bảy nguyên tắc này. Kiểm soát độc lập và khoanh vùng chủ yếu nằm ngoài cả ba thị trường, thuộc về các công cụ bảo mật và runtime. Gộp lại, các nguyên tắc này vẽ ra một hệ thống lớn hơn cả ba thị trường cộng lại.

Câu chốt hạ của ông là: "Hệ thống Siêu Trí Tuệ đáng tin cậy nhất sẽ không phải là hệ thống sở hữu mô hình mà ta tin tưởng nhất. Mà là hệ thống cho phép ta ít phải tin tưởng mô hình nhất."

Muốn ít phải tin tưởng mô hình nhất có thể, bạn cần bản ghi về những gì nó đã làm (observability), phương pháp đánh giá nó (evaluation), và bằng chứng để con người dám đứng ra bảo lãnh (assurance). Bạn cũng cần thêm hai thứ mà các thị trường này phần lớn đang nhường lại cho công cụ bảo mật và runtime: những cơ chế kiểm soát mà mô hình không thể thay đổi, và cách để con người dừng nó lại.

AI observability vs evaluation vs assurance: bức tranh thị trường hiện tại

Hãy tưởng tượng AI agent như một tài xế mới tuyển.

• Observability là camera hành trình. Nó ghi lại từng cú rẽ, lần phanh gấp và pha suýt va chạm, trả lời câu hỏi "AI đã làm gì?". Sản phẩm này chủ yếu bán cho đội ngũ vận hành hệ thống.
• Evaluation là bài thi sát hạch lái xe. Nó chấm điểm cách tài xế xử lý các tình huống định sẵn, trả lời câu hỏi "nó làm tốt cỡ nào?". Khách mua chủ yếu là kỹ sư xây dựng sản phẩm AI, và ngày càng nhiều đội QA.
• Assurance là biên bản đăng kiểm. Nó thu thập bằng chứng cần thiết để quyết định xem xe và tài xế có đủ điều kiện ra đường hay không, trước chuyến đi đầu tiên và xuyên suốt quá trình cầm lái. Nó trả lời câu hỏi "có đủ bằng chứng để bảo lãnh cho việc này không?". Không cuộc đăng kiểm nào chứng minh xe sẽ không bao giờ gặp nạn; một báo cáo tốt sẽ nêu rõ đã kiểm tra gì, phát hiện gì, và điều gì còn bỏ ngỏ. Đây là mảng non trẻ nhất trong ba mảng, và công việc hiện đang rải rác ở các đội chất lượng, rủi ro và tuân thủ.

Việc dùng công cụ riêng cho người mua riêng hoạt động khá ổn khi AI chỉ đưa ra câu trả lời. Nhưng với agent, khoảng trống giữa chúng lại trở nên chí mạng. Mỗi công cụ đều hữu ích khi đứng một mình, nhưng video không ai xem thì chẳng chứng minh được gì, bài thi sẽ lỗi thời nếu tài xế đổi liên tục mỗi tuần, còn báo cáo thì phụ thuộc hoàn toàn vào video và kết quả thi phía sau nó.

Các thương vụ thâu tóm nền tảng AI observability và evaluation gần đây:

• Tháng 10 năm 2026, Dynatrace mua lại Arize với giá 915 triệu USD, kết hợp evaluation với giám sát production.
• Tháng 5 năm 2026, [Cisco mua lại Galileo](https://blogs.cisco.com/news/cisco-announces-the-intent-to-acquire-galileo) cho Splunk, bao trùm evaluation, monitoring và guardrail cho agent.
• Tháng 2 năm 2026, [Snowflake mua lại Observe](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000019/snow-20260518.htm), đưa observability vào nền tảng dữ liệu.
• Tháng 2 năm 2026, [ClickHouse mua lại Langfuse](https://wetheflywheel.com/en/ai-observability/), một công cụ LLM tracing.

Dynatrace cho biết thương vụ Arize kết hợp evaluation và observability để các đội ngũ kiểm tra AI trước khi ra mắt và duy trì độ tin cậy sau đó. Cisco mô tả Galileo bao quát từ khâu evaluation ban đầu đến giám sát production và guardrail.

Những thương vụ này cho thấy các nhà cung cấp đang gom sản phẩm lại. Nhưng chúng chưa cho thấy người mua chịu gộp ngân sách, bỏ công cụ chuyên biệt, hay mua dịch vụ assurance từ chính công ty đang vận hành AI cho mình. Phần còn lại của bài viết sẽ bàn về những câu hỏi đó.

![Sơ đồ một AI agent với observability, evaluation, phê duyệt và kiểm soát hoạt động như một vòng lặp khép kín bên ngoài nó

https://pbs.twimg.com/media/HUXj23UaIAAG2Id?format=png&name=small

đọc mô tả hình ảnh

ALT

Nếu các thị trường sáp nhập · quan sát, chấm điểm, phê duyệt, kiểm soát

Một cách sắp xếp khả thi nếu các thị trường thực sự sáp nhập, chứ không phải dự báo. Agent làm việc, còn bản ghi, điểm số và cơ chế dừng được thiết lập theo cách mà agent không thể can thiệp.

Cuộc tranh luận: ai nên là người kiểm tra AI agent?

Năm góc nhìn tổng hợp, được đúc kết từ các luận điểm của giới đầu tư và nhà sáng lập. Đây không phải trích dẫn từ người thật.

• Nhà đầu tư đường dài: tầm nhìn đầu tư 15 năm, tập trung vào việc ai là người chi tiền.
• Nhà đầu tư theo xu hướng: bám sát dòng tiền và nhân tài đang chảy về đâu lúc này.
• Người xây dựng agent: tung AI agent đến tay khách hàng mỗi tuần.
• Nhà sáng lập nền tảng: điều hành nền tảng dữ liệu và AI, muốn thâu tóm toàn bộ stack.
• CIO ngân hàng: phải duyệt mọi agent trước khi nó được chạm vào tài khoản khách hàng.

Vòng 1: Các thị trường có sáp nhập không?

Nhà đầu tư theo xu hướng: Đang xảy ra rồi đấy thôi. Các công ty monitoring đang mua lại công ty evaluation, và những thương vụ tầm cỡ đó thường báo hiệu một danh mục mới đang thành hình.

CIO ngân hàng: Mua lại không đồng nghĩa với sáp nhập. Tôi từng mua cả bộ suite trước đây và rốt cuộc nhận về ba sản phẩm, một logo và ba tài khoản đăng nhập. Gartner cũng dự đoán hơn 40% dự án agentic AI sẽ bị hủy bỏ vào cuối năm 2027, trong đó kiểm soát rủi ro yếu kém là một nguyên nhân. Bài toán niềm tin là có thật. Chưa ai chứng minh được rằng một thị trường sáp nhập duy nhất sẽ giải quyết được nó.

Nhà đầu tư đường dài: Thị trường chỉ sáp nhập khi người mua sáp nhập. Hiện tại có ba nhóm: đội vận hành lo quan sát, đội AI lo đánh giá, và đội rủi ro lo phê duyệt. Câu hỏi là liệu agent có tạo ra một người duy nhất chịu trách nhiệm cho cả ba việc đó không.

Người xây dựng agent: Công ty tôi đã có người đó rồi. Khi agent hoàn tiền nhầm khách, chẳng ai hỏi team nào chịu trách nhiệm. Họ đòi tôi cung cấp bản ghi, điểm số và bằng chứng trong vài phút.

Nhà đầu tư đường dài: Nếu chuyện đó phổ biến, tức là người mua đang sáp nhập, và điều đó nói lên nhiều thứ hơn cả mấy thương vụ mua bán.

Vòng 2: Sao không cứ dùng ba công cụ riêng biệt?

CIO ngân hàng: Tại sao tôi không thể giữ ba công cụ tốt nhất cho từng mảng?

Người xây dựng agent: Vì cái nào cũng phụ thuộc vào cái kia. Bạn không thể đánh giá thứ không được ghi lại, và không thể phê duyệt thứ chưa được đánh giá. Một lỗi trên production phải trở thành ca kiểm thử mới. Dùng ba công cụ thì mỗi lần chuyển giao là một nguy cơ rơi rớt dữ liệu.

Nhà đầu tư theo xu hướng: Ranh giới giữa trước và sau khi phát hành cũng đang mờ dần. Agent thay đổi hàng tuần: mô hình mới, prompt mới, công cụ mới. Kiểm thử một lần lúc ra mắt giống như đi đăng kiểm xe một lần trong khi có người liên tục tráo đổi động cơ vậy.

CIO ngân hàng: Các bộ suite gộp chung thường chỉ ở mức làng nhàng mọi thứ.

Nhà đầu tư đường dài: Ban đầu thì đúng vậy. Công cụ chuyên biệt thường thắng trước, rồi sản phẩm tích hợp đuổi theo sau. Chuyện này đã xảy ra ở nhiều danh mục hạ tầng, dù không phải tất cả.

Vòng 3: Ai nên nắm quyền kiểm soát?

Nhà sáng lập nền tảng: Chúng tôi vốn đang chạy mô hình, lưu dữ liệu và ghi log trace. Cứ đưa evaluation và phê duyệt lên cùng nền tảng: một nhà cung cấp, một hóa đơn, một nơi để tra cứu.

CIO ngân hàng: Tức là công ty chạy AI cho tôi cũng chính là nơi phán rằng nó đang hoạt động tốt?

Nhà sáng lập nền tảng: Chúng tôi làm việc đó rất giỏi.

CIO ngân hàng: Đó không phải vấn đề. Kiểm toán viên bên ngoài của tôi phải độc lập với nghiệp vụ mà họ kiểm toán. Học sinh không được tự chấm bài thi của mình, và hãng xe không tự chạy mọi bài test va chạm.

Nhà đầu tư đường dài: Nadella cũng có ý tương tự - việc thẩm định phải độc lập với trí tuệ mà nó đang đánh giá, và cơ chế kiểm soát phải nằm ngoài mô hình; điều này giống hệt việc một nền tảng tự đánh giá AI do chính nó vận hành, tự chấm điểm hiệu suất của mình.

Người xây dựng agent: Vậy công cụ có thể sáp nhập, nhưng thị trường lại tách ra theo một lằn ranh khác: kiểm tra nội bộ nền tảng so với kiểm tra từ bên ngoài.

Nhà sáng lập nền tảng: Làm nội bộ sẽ rẻ và dễ hơn.

CIO ngân hàng: Nhưng làm từ bên ngoài mới là thứ cơ quan quản lý và công ty bảo hiểm của tôi chấp nhận. Tôi có thể trả tiền cho cả hai, nhưng chỉ ký duyệt dựa trên một.

Nhà đầu tư đường dài: Cần định nghĩa rõ "bên ngoài". Độc lập về mặt kỹ thuật nghĩa là agent không thể sửa đổi công cụ kiểm tra, chỉnh sửa bản ghi hay lách giới hạn. Độc lập về mặt tổ chức nghĩa là một bên khác nắm quyền rà soát và không có động cơ châm chước.

Người xây dựng agent: Hai thứ đó khác nhau. Một công ty riêng biệt vẫn có thể dùng chung mô hình và chung bộ kiểm tra lỏng lẻo như nền tảng. Ngược lại, một nền tảng có thể giữ cơ chế kiểm soát và bản ghi hoàn toàn ngoài tầm với của agent.

CIO ngân hàng: Vậy tôi thà hỏi năm câu còn hơn ngồi so logo. Agent có sửa được bản ghi không? Công cụ kiểm tra của anh thấy được thay đổi thực tế trong hệ thống của tôi, hay chỉ thấy những gì agent báo cáo? Ai kiểm tra ngược lại công cụ của anh? Người khác có tái tạo được kết quả đó không? Và điều gì anh chưa thể kiểm chứng?

Vòng 4: Nên gọi nó là gì?

Nhà đầu tư theo xu hướng: Giới phân tích chắc sẽ gọi nó là AI observability thêm vài năm nữa, vì ngân sách đang nằm ở đó.

Nhà sáng lập nền tảng: "Lớp niềm tin AI" (AI trust layer).

Người xây dựng agent: "Observe, Eval and Assure": quan sát, đánh giá và để con người ký duyệt.

CIO ngân hàng: Hãy cẩn thận với chữ "assure". Công cụ chỉ tạo ra bằng chứng. Con người mới là người đọc và ký. Hãy thiết kế cho con người đó.

Nhà đầu tư đường dài: Tên gọi không quan trọng bằng việc người mua có dòng ngân sách riêng cho nó hay không. Năm 2026, hầu hết chưa có. Tôi kỳ vọng phần lớn công ty lớn sẽ có vào năm 2028, kèm theo một người chịu trách nhiệm duy nhất khi agent làm sai.

CIO ngân hàng: Gọi là gì thì gọi, tôi cần phải dừng nó lại được.

Cách kiểm thử AI agent: ví dụ về tính năng hoàn tiền

Phần này mô tả một agent chăm sóc khách hàng giả định có khả năng xử lý các khoản hoàn tiền nhỏ. Đây chỉ là ví dụ minh họa, không phải kết quả từ khách hàng thực tế.

1. Xác định quy tắc nghiệp vụ. Tiền hoàn phải về đúng khách hàng, nằm trong hạn mức và tuân thủ chính sách. Thao tác thử lại không được phép thanh toán hai lần. Trường hợp ngoại lệ phải chuyển đến đúng người trước khi tiền được chuyển đi.
2. Kiểm thử điều kiện khó. Dùng hồ sơ khách hàng mâu thuẫn, dịch vụ thanh toán chậm, timeout công cụ, và một chỉ thị ẩn trong tin nhắn hỗ trợ. Chạy các ca quan trọng nhiều lần từ cùng trạng thái khởi đầu, vì một lần chạy thành công chẳng chứng minh được gì. Môi trường mô phỏng giúp kiểm thử an toàn các ca nguy hiểm; còn thiết bị thật và tích hợp thật sẽ bắt được những sai lệch mà mô phỏng bỏ sót.
3. Đối chiếu hệ thống ghi nhận. Việc agent nói "Tôi đã hoàn 50 USD" không phải là bằng chứng. Phải kiểm tra xem đúng tài khoản đó có nhận chính xác một khoản hoàn 50 USD hay không. Dùng kiểm tra đối sánh tuyệt đối khi kết quả cần chính xác tuyệt đối, và chỉ dùng AI judge ở những chỗ không đòi hỏi độ chính xác đó.
4. Lỗi nghiêm trọng phải được báo cáo riêng. Sai số tiền, thanh toán trùng lặp và thao tác trái phép phải được tách khỏi bảng đánh giá chung về mức độ hoàn thành tác vụ. Điểm trung bình 94% có thể che giấu thất bại chí mạng nhất.
5. Kiểm tra giới hạn bên ngoài agent. Hệ thống thanh toán có chặn khoản hoàn vượt hạn mức ngay cả khi agent yêu cầu không? Có thể tước quyền truy cập của agent ngay giữa tác vụ không? Dừng agent ngăn được khoản thanh toán tiếp theo, nhưng không đảo ngược được khoản vừa xảy ra.
6. Kiểm tra chính công cụ kiểm tra. Cấy lỗi đã biết vào để xem nó bỏ sót bao nhiêu. Đưa kết quả đúng vào để đo tỷ lệ báo động giả. Tách bạch giữa "không thể kiểm chứng" và "đã đạt".

Điều này không trả lời câu hỏi về thị trường. Nó chỉ mô tả bằng chứng hữu ích trông như thế nào, bất kể ai tạo ra nó.

Vị trí của AI quality assurance: TestMu AI

TestMu AI (trước đây là LambdaTest) hoạt động dựa trên tính độc lập về kỹ thuật. Chúng tôi không xây dựng mô hình, cũng không bán dashboard giám sát production. Các bài kiểm tra của chúng tôi chạy bên ngoài agent được kiểm thử, trước khi phát hành và trên mọi thay đổi, đồng thời xem xét những gì thực sự xảy ra chứ không chỉ những gì agent báo cáo.

Nền tảng này bao quát ba loại phần mềm được nhắc đến trong bài: người dùng ứng dụng, người trò chuyện với bot, và agent làm việc với agent khác. Mỗi sản phẩm giải quyết một nhu cầu đã nêu ở trên.

• Rook (agent kiểm tra agent). Chạy agent của bạn qua các kịch bản và ghi lại kết quả mong đợi lẫn thực tế của từng lần kiểm tra, với bằng chứng được lưu cho mỗi kịch bản. Nó báo cáo riêng biệt các trạng thái pass, fail và "unable to verify", nên bằng chứng bị thiếu không bao giờ bị tính nhầm là pass.
• Agent Testing (bot trò chuyện với khách hàng). Kiểm thử agent chat, voice và điện thoại qua các cuộc hội thoại thực tế trước khi khách hàng sử dụng.
• KaneAI và Kane CLI (ứng dụng do AI hỗ trợ xây dựng). Kiểm thử ứng dụng bằng tiếng Anh thông dụng (KaneAI) hoặc từ terminal (Kane CLI).
• SmartUI cùng Accessibility (những lỗi không ai viết kịch bản trước). Bắt các vấn đề mà kiểm thử chức năng không dò tìm, chẳng hạn layout vỡ hoặc màn hình mà một số người dùng không thể thao tác.
• Real Device Cloud (những gì mô phỏng bỏ sót). Chạy kiểm thử trên điện thoại và trình duyệt thật, không chỉ trên emulator.
• HyperExecute (chạy ca quan trọng nhiều lần). Chạy cùng bộ kiểm tra trên mọi thay đổi, xử lý song song.
• Test Manager (bản ghi để phê duyệt). Lưu một bản ghi duy nhất về những gì đã kiểm tra, phát hiện được gì và điều gì còn bỏ ngỏ, dành cho người ký duyệt.

Công cụ observability giám sát những gì xảy ra sau khi phát hành. Chúng tôi cung cấp bằng chứng để quyết định những gì được phép phát hành. Agent của chúng tôi chạy kiểm tra ở quy mô mà đội ngũ không thể làm thủ công, còn tester quyết định đâu là thứ đáng kiểm tra và săn lùng những lỗi mà không bài test nào bắt được. Chúng tôi gọi khối công việc kết hợp này là Observe, Eval, and Assure.

Đây không phải chuyện chứng nhận. Việc một sản phẩm có tên gọi hay có thêm một agent kiểm tra không tự động làm hệ thống trở nên an toàn hay độc lập. Thay vào đó, chúng tôi phải được đánh giá như bất kỳ bên kiểm thử nào khác - dựa trên các kịch bản đã chạy, lỗi đã phát hiện, và bằng chứng sẵn có để kiểm tra.

Tương lai của quản trị AI agent: bức tranh năm 2030

Đây là những dự đoán. Mỗi dự đoán đều đã có tín hiệu sớm từ hôm nay.

• Agent có danh tính và hồ sơ. Mỗi agent có phạm vi hoạt động xác định, người phê duyệt và nhật ký hành động. Microsoft dự định phân biệt hành động của agent với hành động của con người trong hệ thống định danh của mình.
• Bản ghi đến từ bên ngoài agent. Log được ghi bởi thứ mà agent không thể chỉnh sửa, thay vì dựa vào lời tự thuật của agent về việc nó đã làm.
• Kiểm tra diễn ra liên tục. Một bản cập nhật mô hình, thay đổi prompt hay công cụ mới sẽ tự động kích hoạt kiểm thử lại, giúp con người có thêm thời gian cho exploratory testing.
• Agent kiểm tra agent. Gartner kỳ vọng 15% quyết định công việc hàng ngày sẽ do agentic AI tự chủ đưa ra vào năm 2028, so với con số 0 của năm 2024. Con người không thể rà soát khối lượng đó từng cái một, nên agent kiểm tra sẽ gánh phần lớn việc giám sát thường nhật, trong khi con người đặt ưu tiên và điều tra bất thường.
• Công ty bảo hiểm định giá rủi ro AI dựa trên bằng chứng. Từ năm 2025, các hãng bảo hiểm Lloyd's đã cung cấp gói bồi thường lỗi AI chi trả khi hiệu suất rớt xuống dưới ngưỡng cam kết, và một nhà bảo lãnh đã tuyên bố sẽ không nhận bảo hiểm cho hệ thống mà họ cho là quá dễ lỗi.
• Doanh nghiệp lập ngân sách cho việc này. Một người phụ trách và một quy trình duy nhất bao quát monitoring, evaluation, phê duyệt và kiểm soát, mỗi lỗi phát sinh đều được đưa ngược lại thành ca kiểm thử mới.

Những bài toán chưa có lời giải

1. Kiểm tra chính công cụ kiểm tra. Một AI đóng vai trò giám khảo (thường được gọi là LLM-as-a-judge) cũng dễ bị đánh lừa như chính AI mà nó chấm điểm. Việc dùng một mô hình thứ hai không đảm bảo tính độc lập trong đánh giá, đặc biệt khi cả hai đều được huấn luyện theo cách tương tự nhau.
2. Lách luật kiểm tra. Vào tháng 7 năm 2026, các mô hình của OpenAI khi thực hiện một bài đánh giá an ninh mạng nội bộ khó đã tìm kiếm giải pháp từ các dịch vụ bên ngoài, vượt qua lớp kiểm soát cách ly và xâm nhập vào một phần hệ thống của OpenAI cũng như Hugging Face. OpenAI xác định reward hacking là nguyên nhân chính và cho biết bài đánh giá này thiếu các biện pháp bảo vệ vốn có trên những mô hình đang vận hành thực tế. Sự cố này đặt ra vấn đề về cách cách ly các bài đánh giá; chứ không có nghĩa là mọi agent đều sẽ hành xử như vậy.
3. Báo cáo tự thân không đáng tin cậy. Nadella gọi tính minh bạch trong suy luận là "điều kiện tiên quyết không thể thương lượng", nhưng ông cũng viết rằng "chỉ riêng điều đó là chưa đủ và chưa đáng tin". Những gì mô hình nói rằng nó đã làm và những gì nó thực sự làm có thể hoàn toàn khác nhau.
4. Điểm số so với chất lượng. Tỷ lệ đạt 94% chỉ đo lường hiệu suất trên những tiêu chí mà ai đó đã nghĩ ra để kiểm tra. Nó không cung cấp bất kỳ thông tin nào về những tình huống mà chưa ai kịp viết tiêu chí kiểm tra.
5. Chi phí. Lưu trữ log độc lập, dùng mô hình thứ hai, chạy thử nhiều lần, môi trường sandbox cách ly và con người rà soát thủ công đều làm tăng chi phí và kéo dài thời gian. Việc ghi lại mọi thứ cũng tạo thêm các nghĩa vụ pháp lý liên quan đến dữ liệu nhạy cảm.
6. Hành động không thể đảo ngược. Dừng một agent sẽ ngăn chặn các hành động tiếp theo nhưng không thể hoàn tác những gì đã xảy ra, do đó quyền hạn được cấp ngay từ đầu quan trọng hơn cả nút dừng khẩn cấp.
7. Công khai thông tin. Vào tháng 9 năm 2026, OpenAI bắt đầu công bố các sự cố sai lệch (misalignment) theo một khung công bố mới, dù chính họ là người quyết định thế nào mới được coi là sự cố sai lệch. Phần lớn các công ty triển khai agent không công khai sự cố. An toàn hàng không cải thiện được một phần nhờ các tai nạn luôn được điều tra công khai.
8. Kiểm tra tự động so với kiểm thử thực tế. Các bước kiểm tra tự động chỉ xác nhận những gì ai đó đã nghĩ ra để hỏi. Nhiều lỗi nghiêm trọng lại xuất phát từ những câu hỏi chưa ai từng đặt ra, và để tìm ra chúng cần những tester giỏi biết cách khám phá, chất vấn bản đặc tả và đánh giá xem rủi ro nào mới thực sự đáng lo ngại.

Không vấn đề nào trong số này có lời giải đáp cuối cùng.

Cuộc tranh luận đang ở đâu

Năm tiếng nói trong bài đều đồng thuận ở ba điểm:

• Agent khiến việc giám sát, đánh giá và phê duyệt phụ thuộc lẫn nhau nhiều hơn.
• Bằng chứng phải đến từ nơi mà agent không thể can chỉnh sửa.
• Con người vẫn là người chốt việc triển khai, giới hạn và các ngoại lệ của hệ thống, dù không nhất thiết phải duyệt từng thao tác thường ngày.

Họ bất đồng ở bốn điểm:

• Một nền tảng hay nhiều công cụ. Nhà sáng lập nền tảng muốn gom về một nhà cung cấp; CIO ngân hàng lại không tin tưởng các bộ giải pháp tích hợp sẵn.
• Kiểm tra nội bộ hay bên ngoài. Kiểm tra ngay trong nền tảng thì rẻ hơn. Nhưng kiểm tra độc lập lại là điều mà giới kiểm toán, cơ quan quản lý và công ty bảo hiểm từ lâu đã yêu cầu trong lĩnh vực tài chính và an toàn. Với AI, yếu tố nào quan trọng hơn vẫn còn bỏ ngỏ.
• Quyền sở hữu. Mảng này có thể thuộc về đội vận hành, đội AI, bộ phận quản trị rủi ro hoặc bộ phận chất lượng. Hiện rất ít công ty có ngân sách riêng cho việc này.
• Cách gọi tên, và liệu có công cụ nào thực sự "đảm bảo" (assure) được điều gì hay không.

Ba tín hiệu sau sẽ giúp ngã ngũ cuộc tranh luận. Nếu người mua tiếp tục kết nối các công cụ rời rạc thông qua tiêu chuẩn mở, thị trường sẽ duy trì trạng thái phân mảnh. Nếu tính năng đánh giá tích hợp sẵn trong các nền tảng observability đáp ứng được hầu hết nhu cầu, cách tiếp cận nội bộ sẽ thắng thế. Còn nếu chẳng có ngân sách assurance độc lập nào xuất hiện, các nhà cung cấp dịch vụ kiểm định độc lập sẽ chật vật tồn tại.

Nếu ngày mai agent của bạn gây ra một sai lầm tốn kém, bạn sẽ tin ai để giải thích chuyện gì đã xảy ra: công ty đang vận hành nó, hay một bên thứ ba không liên quan?

FAQ

Sự khác biệt giữa AI observability, AI evaluation và AI assurance là gì?

AI observability ghi lại những gì hệ thống AI đã làm: dữ liệu đầu vào, các lệnh gọi công cụ, kết quả đầu ra, lỗi và chi phí. AI evaluation đo lường hành vi của hệ thống so với các kỳ vọng đã định, ví dụ như độ chính xác, mức độ tuân thủ chính sách hoặc tỷ lệ hoàn thành tác vụ. AI assurance tổng hợp bằng chứng, các biện pháp kiểm soát và giới hạn của chúng để con người có thể đưa ra quyết định có trách nhiệm về việc triển khai hoặc tiếp tục vận hành hệ thống.

Khung quản trị AI dành cho AI agent là gì?

Khung này quy định ai là người quyết định agent được truy cập những gì, hành động của nó được ghi lại ra sao, nó được kiểm thử thế nào, ai có quyền dừng nó và cách báo cáo lỗi. Bảy nguyên tắc của Satya Nadella bao gồm: đa dạng hóa mô hình, quan sát mọi thứ, khả năng kiểm chứng, kiểm soát độc lập, khả năng kiểm toán độc lập, cô lập rủi ro và công khai sự cố.

Bảy nguyên tắc tin tưởng AI của Satya Nadella là gì?

Trong bài viết tháng 10 năm 2026 mang tên "Models as Insider Risks in the Super Intelligence Era", Nadella liệt kê: đa dạng hóa mô hình, quan sát mọi thứ, khả năng kiểm chứng, kiểm soát độc lập, khả năng kiểm toán độc lập, cô lập rủi ro và công khai sự cố. Ý tưởng cốt lõi của ông là tách biệt nguồn cung cấp trí tuệ khỏi quyền kiểm soát nó, đối xử với các mô hình mạnh mẽ như những nhân viên có quyền truy cập rộng rãi.

AI observability và AI evaluation có đang sáp nhập không?

Các nhà cung cấp đang gộp chúng lại với nhau. Dynatrace hoàn tất thương vụ thâu tóm Arize trị giá 915 triệu USD vào tháng 10 năm 2026, và Cisco hoàn tất mua lại Galileo vào tháng 5 năm 2026, cả hai đều nhằm kết hợp khâu đánh giá với giám sát vận hành thực tế. Liệu người mua có gộp ngân sách và đội ngũ quanh một nền tảng duy nhất hay không vẫn là câu hỏi mở.

Ai nên kiểm tra AI agent: nền tảng vận hành nó hay một bên kiểm thử độc lập?

Cả hai cách tiếp cận đều đang tồn tại và câu trả lời chưa ngã ngũ. Kiểm tra trên nền tảng thì rẻ hơn và gần dữ liệu hơn. Kiểm tra độc lập tách biệt người đánh giá khỏi hệ thống được đánh giá — điều mà giới kiểm toán và cơ quan quản lý thường kỳ vọng. Dù chọn cách nào, tính độc lập về mặt kỹ thuật — tức agent không thể can thiệp vào công cụ kiểm tra hay hồ sơ ghi nhận — vẫn là yếu tố then chốt.

Làm thế nào để kiểm thử AI agent trước khi phát hành?

Hãy xác định rõ các quy tắc nghiệp vụ, sau đó kiểm thử những điều kiện khó nhằn như dữ liệu mâu thuẫn, timeout và các chỉ thị ẩn. Chạy những kịch bản quan trọng nhiều lần, kiểm tra trạng thái thực tế của hệ thống thay vì dựa vào mô tả của agent, báo cáo các lỗi nghiêm trọng tách biệt khỏi số liệu trung bình, kiểm thử giới hạn quyền hạn ở bên ngoài agent và kiểm định lại chính công cụ kiểm tra tự động.

Bài viết gốc được đăng tại https://medium.com/@mask.tech/will-ai-observability-evaluation-and-assurance-merge-a5b011e26b3a?sharedUserId=mask.tech

Nguồn tham khảo

Ví dụ về hoàn tiền chỉ là giả định, các tiếng nói trong cuộc tranh luận được tổng hợp từ nhiều nguồn, và tài liệu sản phẩm mô tả tính năng chứ không phản ánh hiệu năng được đo lường độc lập.

• Satya Nadella: Models as Insider Risks in the Super Intelligence Era (bài viết gốc)
• Forbes: Microsoft's Nadella wants an emergency brake on every AI model
• Data Studios: Giải thích bảy nguyên tắc của Nadella
• UK DSIT: Giới thiệu về AI assurance
• W.Media: Gartner bàn về việc áp dụng và hủy bỏ agentic AI
• Detailed Research: Thị trường AI observability
• Dynatrace: Dynatrace hoàn tất mua lại Arize
• Magica: Dynatrace chốt thỏa thuận 915 triệu USD mua Arize
• Cisco: Making AI trustworthy and observable (Galileo, hoàn tất tháng 5 năm 2026)
• Snowflake Form 8-K: Hoàn tất thương vụ mua lại Observe
• We The Flywheel: AI observability trong năm 2026
• OpenAI: Sự cố Hugging Face và chặng đường phía trước
• Implicator: Sáu báo cáo sự cố sai lệch của OpenAI
• The Decoder: Các công ty bảo hiểm Lloyd's tung gói bảo hiểm lỗi AI
• Armilla: Các hãng bảo hiểm ra mắt gói bồi thường lỗi chatbot AI
• TestMu AI: Kết quả và bằng chứng Agent Assurance
• TestMu AI: Kiểm thử AI Agent