Sushil Kumar, CEO của Cyara – Loạt Phỏng Vấn

Sushil Kumar, CEO của Cyara là một nhà điều hành phần mềm doanh nghiệp và doanh nhân có hơn 25 năm kinh nghiệm lãnh đạo trong lĩnh vực trí tuệ nhân tạo, DevOps, hạ tầng đám mây, chiến lược sản phẩm và kiểm thử phần mềm. Ông gia nhập Cyara với vai trò CEO vào tháng 12 năm 2025, sau khi từng là đồng sáng lập và CEO của RelicX.ai, nơi ông xây dựng nền tảng tự động hoá kiểm thử dựa trên ý định, được hỗ trợ bởi AI sinh ra, và sau đó được công ty Harness mua lại. Ông sau đó đã dẫn dắt việc tích hợp công nghệ của RelicX vào Harness và giúp định hình chiến lược AI Test Automation của họ. Trước đó trong sự nghiệp, Kumar từng giữ chức Giám đốc Tổng quát DevOps tại Broadcom, Phó Chủ tịch Cấp cao về Sản phẩm tại CA Technologies, và đã làm việc hơn 16 năm tại Oracle, nơi ông đảm nhiệm các vị trí lãnh đạo sản phẩm cấp cao và giúp mở rộng các doanh nghiệp phần mềm doanh nghiệp lớn. Trong các vai trò này, ông tập trung vào việc xây dựng và mở rộng các nền tảng AI, đám mây, DevOps và tự động hoá cho các doanh nghiệp quy mô lớn. Nhiệm vụ của ông tại Cyara tập trung vào việc mở rộng khả năng bảo đảm trải nghiệm khách hàng được hỗ trợ bởi AI của công ty và mở rộng phạm vi toàn cầu.

Cyara là một công ty bảo đảm trải nghiệm khách hàng giúp các doanh nghiệp kiểm thử, giám sát và xác thực các tương tác của khách hàng trên các kênh thoại, kỹ thuật số, tin nhắn và AI hội thoại. Nền tảng Cyara Agentic Platform của họ được thiết kế để giải quyết các thách thức ngày càng tăng do trải nghiệm khách hàng dựa trên AI tạo ra, bao gồm kiểm thử các tác nhân AI không định đoạt, phát hiện ảo giác và sự trôi dạt hành vi, xác thực tuân thủ, giám sát hệ thống sản xuất và đánh giá hành trình khách hàng từ đầu đến cuối. Nền tảng này kết hợp kiểm thử tác nhân AI, giám sát sản xuất, bảo đảm thoại và viễn thông, kiểm thử kênh kỹ thuật số và khả năng quan sát CX, hỗ trợ hơn 350 triệu hành trình khách hàng hàng năm trên một mạng lưới toàn cầu trải rộng hơn 140 quốc gia. Khi các doanh nghiệp triển khai ngày càng nhiều tác nhân AI tự chủ vào quy trình làm việc tiếp xúc với khách hàng, Cyara đang định vị công nghệ của mình như một lớp bảo đảm để đánh giá liệu các hệ thống đó có hoạt động một cách đáng tin cậy, an toàn và nhất quán trước và sau khi triển khai.

Bạn đã dành phần lớn sự nghiệp của mình để xây dựng và mở rộng phần mềm doanh nghiệp, từ Oracle và CA/Broadcom đến việc sáng lập Relicx và hiện đang dẫn dắt Cyara. Kinh nghiệm đó đã hình thành quan điểm của bạn như thế nào về việc các tác nhân AI nên được quản lý ít giống phần mềm truyền thống và nhiều hơn như các thành viên của lực lượng lao động?

Tôi đã dành phần lớn sự nghiệp của mình để xây dựng và mở rộng phần mềm doanh nghiệp, và kỷ luật mà chúng tôi xây dựng ở đó là một kỷ luật xoay quanh các hệ thống định đoạt. Bạn biết phần mềm nên làm gì. Bạn xác thực nó dựa trên kỳ vọng đó. Khi nó gặp sự cố, nó sẽ thông báo cho bạn: một lỗi, một giao dịch thất bại, một cảnh báo.

Các tác nhân AI không hoạt động theo cách đó. Chúng không định đoạt, vì vậy cùng một đầu vào có thể đi theo các đường khác nhau. Quan trọng hơn, chúng có thể hành động thay mặt công ty. Chúng đưa ra các cam kết: hoàn tiền, chính sách, lời hứa. Và khi một trong số đó sai, không có gì bị phá vỡ. Một câu trả lời sai nghe giống hệt một câu trả lời đúng. Giao dịch thành công, bảng điều khiển vẫn xanh, và khách hàng rời đi với một điều mà công ty chưa bao giờ đồng ý.

Khi phần mềm có thể đưa ra quyết định và cam kết, và có thể sai mà không thông báo cho bạn, nó cần một mô hình vận hành khác.

Đó là nơi so sánh với lực lượng lao động trở nên có giá trị. Bạn không quản lý một nhân viên bằng cách lập trình mọi quyết định họ sẽ thực hiện. Bạn giao cho họ một vai trò, thiết lập quyền hạn đi kèm, và mở rộng quyền hạn đó khi họ chứng tỏ được. Một tác nhân hoạt động theo cùng cách dưới cùng cấu trúc.

Theo tôi, tính tự chủ không phải là quyết định triển khai. Đó là một chuỗi các lần thăng chức. Một tác nhân đạt được mỗi cấp độ bằng cách chứng minh nó có thể thực hiện công việc, ở trong giới hạn quyền hạn, và nhận ra khi cần trợ giúp.

Mô hình vận hành \”HR-like\” cho các tác nhân AI thực tế trông như thế nào trong một doanh nghiệp, và những yếu tố nào các công ty nên triển khai đầu tiên?

Bắt đầu với công việc. Mỗi tác nhân nên có một mô tả công việc gần như hoàn chỉnh trước khi đưa vào môi trường sản xuất. Nó cần đạt được gì, thông tin nào là có thẩm quyền cho nó, dữ liệu khách hàng nào nó có thể sử dụng, quyết định nào nó có thể tự thực hiện, và trách nhiệm của nó kết thúc ở đâu. Nếu một công ty không thể viết những điều này thành một đoạn văn, tác nhân chưa sẵn sàng cho một vai trò. Nó chỉ sẵn sàng cho một bản demo.

Bốn yếu tố xuất phát từ vai trò đó, và thứ tự quan trọng. Bằng chứng trước khi ra mắt, có nghĩa là chứng minh tác nhân có thể thực hiện công việc trong các điều kiện giống thực tế hơn là một bài kiểm tra có kiểm soát. Giám sát trong quá trình hoạt động, để bạn biết tác nhân thực sự đã làm gì và không chỉ hệ thống có phản hồi hay không. Cổng thăng chức, để quyền hạn cao hơn được cấp khi có bằng chứng hỗ trợ và không trước đó. Và một người sở hữu trong bộ phận kinh doanh, không phải trong kỹ thuật, chịu trách nhiệm về những gì mà tác nhân được phép thực hiện.

Nếu sắp xếp sai thứ tự, những điều còn lại sẽ không còn hiệu lực. Nếu trách nhiệm mơ hồ, việc chứng minh hiệu suất tốt trở nên không thể, và thất bại cũng vậy. Vai trò phải đến trước, và bằng chứng theo sau.

Nếu một tác nhân AI được giao một vai trò cụ thể, các tổ chức nên xác định trách nhiệm, quyền hạn và ranh giới của nó như thế nào trước khi cho phép nó tương tác với khách hàng hoặc các hệ thống quan trọng?

Vai trò cho biết mục đích của agent. Quyền hạn cho biết nó có thể tiếp cận gì. Đó là hai cuộc trò chuyện khác nhau, và các công ty thường chỉ có phần đầu tiên.

Hãy nêu rõ ba điều. Hệ thống và dữ liệu nào mà agent có thể chạm tới, và theo hướng nào, vì việc đọc một hồ sơ khách hàng và việc thay đổi hồ sơ đó không phải là cùng một quyền. Những gì agent có thể tự mình cam kết, nơi chứa tiền và trách nhiệm: hoàn tiền, tín dụng, hoặc ngoại lệ chính sách. Và những yếu tố buộc phải chuyển giao, cả những trường hợp bạn có thể nêu trước và tín hiệu cho thấy agent đã vượt ra ngoài khả năng của mình.

Đây không phải là những quyết định để giao cho đội công nghệ. Họ quyết định mức độ rủi ro mà công ty đang chịu. Những người chịu trách nhiệm về trải nghiệm khách hàng và rủi ro tuân thủ cần có tiếng nói trong việc xác định ranh giới, và họ thường là những người cuối cùng được hỏi.

Sau đó bạn phải chứng minh agent luôn nằm trong giới hạn đó. Mục tiêu không phải là loại bỏ mọi sai sót có thể xảy ra. Sẽ có sai lầm. Câu hỏi là liệu agent có hiểu ranh giới của mình, biết khi nào dừng lại, và có thể thực hiện công việc được giao mà không gây ra hậu quả ở nơi khác trong hành trình khách hàng hay không.

Bạn cho rằng tự chủ lớn hơn nên được kiếm được chứ không phải được cấp ngay từ đầu. Một agent AI cần chứng minh gì trước khi doanh nghiệp mở rộng phạm vi hành động mà nó có thể thực hiện một cách độc lập?

Giờ đây việc xây dựng một agent AI đã trở nên dễ dàng. Phần khó là chứng minh nó xứng đáng với mức tự chủ.

Trước khi mở rộng những gì một agent có thể tự thực hiện, doanh nghiệp cần bằng chứng rằng nó thực hiện công việc được giao một cách nhất quán và luôn nằm trong giới hạn của mình. Điều đó có nghĩa là cách nó xử lý các tình huống bạn mong đợi, cũng như những tình huống bạn không dự đoán trước. Một agent có thể tỏ ra mạnh mẽ trong môi trường kiểm soát nhưng lại hành xử khác khi bối cảnh hoặc các hệ thống xung quanh thay đổi.

Khách hàng có thể bắt đầu với một câu hỏi thanh toán đơn giản và trở nên bực bội sau một giao dịch không thành công. Agent phải nhận ra sự thay đổi này ngay khi nó xảy ra và thay đổi hướng đi, thay vì tiếp tục theo lộ trình đã được xác nhận.

Ba yếu tố cần được đáp ứng trước khi mở rộng quyền hạn. Agent thực hiện công việc trong điều kiện thực tế, không chỉ trong môi trường sạch sẽ. Nó biết ranh giới năng lực của mình và dừng lại ở đó. Và ai đó có thể cung cấp bằng chứng cho cả hai khi được yêu cầu.

Mức độ chứng minh phải phù hợp với mức độ tự chủ. Các quyết định nhỏ, bằng chứng nhẹ. Việc truy cập vào hệ thống thanh toán, hoặc khả năng cam kết công ty vào một ngoại lệ chính sách, yêu cầu tiêu chuẩn phải cao hơn đáng kể.

Các công ty nên đánh giá liên tục hiệu suất của các agent AI như thế nào sau khi triển khai, đặc biệt khi chất lượng quyết định của chúng không thể chỉ đo lường bằng các chỉ số kiểm thử phần mềm truyền thống?

Đây là nơi tư duy phần mềm truyền thống gặp khó khăn. Với phần mềm quyết định, bạn kiểm tra xem một thứ có vượt qua hay không. Với một agent AI, bạn có thể nhận được phản hồi thành công từ hệ thống nhưng vẫn có một tương tác khách hàng thất bại.

Vì vậy bạn đánh giá kết quả, không phải phản hồi. Agent có hiểu mục tiêu mà khách hàng đang cố gắng đạt được không? Nó có sử dụng thông tin đúng không? Nó có hoàn thành hành trình không? Nó có giữ trong giới hạn của mình và chuyển giao khi cần không?

Đánh giá cơ bản, chấm điểm câu trả lời dựa trên bộ chuẩn vàng, là mức tối thiểu. Mọi công ty đều sẽ có chúng. Các yếu tố quyết định liệu khách hàng có tiếp tục tin tưởng bạn hay không nằm ở phía dưới: tuân thủ, thiên vị, lạm dụng, và cách agent hoạt động với những người gọi thực tế, giọng địa phương của họ, tiếng ồn nền, điện thoại rẻ tiền, hoặc việc bị gián đoạn giữa câu. Trong lĩnh vực thoại, điều này quan trọng hơn so với mong đợi, vì mỗi điểm số dựa trên bản ghi âm. Nếu lớp nhận dạng giọng nói hiểu sai câu hỏi, agent sẽ trả lời một câu hỏi mà không ai đặt ra.

Công thức tính toán đáng để suy ngẫm. Điểm 99% trong đánh giá nghe có vẻ xuất sắc. Với một triệu cuộc trò chuyện mỗi năm, điều đó tương đương với mười nghìn trường hợp thất bại.

Hai nguyên tắc vẫn đứng vững. Việc xác thực phải độc lập với agent và nền tảng mô hình. Chúng tôi không tự xây dựng các agent, điều này là một phần lý do tôi có thể nói thẳng rằng không nhà cung cấp nào nên là người đánh giá AI của chính mình. Tiêu chuẩn là các chính sách nội bộ của doanh nghiệp, cam kết với khách hàng và các nghĩa vụ pháp lý, chứ không phải bảng điểm của nhà cung cấp.

Và mỗi lỗi trong môi trường sản xuất nên trở thành một cổng kiểm soát. Không phải một phiếu, không phải một mục trong backlog. Một bài kiểm tra mà agent phải vượt qua trước khi phiên bản tiếp theo được phát hành. Nếu một vấn đề xảy ra trong sản xuất và không trở thành một tiêu chí mà agent phải vượt qua, bạn đang trả tiền để phát hiện cùng một vấn đề hai lần.

Niềm tin và quản trị ngày càng được nhắc đến như những rào cản lớn đối với việc mở rộng AI có tính năng agent. Bạn có tin rằng công nghệ đang tiến nhanh hơn khả năng giám sát của doanh nghiệp không, và những rủi ro nào điều đó tạo ra?

Tôi nghĩ đó chính là điều đang xảy ra, và khoảng cách là cấu trúc hơn là do thiếu nỗ lực. Một ý tưởng có thể trở thành một agent giao tiếp với khách hàng trong vòng vài tuần. Tuy nhiên, kỷ luật vận hành quanh agent đó, quyền sở hữu, bằng chứng, giám sát lại mất thời gian lâu hơn nhiều, vì nó liên quan đến con người và trách nhiệm, không chỉ phần mềm.

Rủi ro là khoảng cách sẽ vẫn vô hình trong khi nó ngày càng rộng ra. Một agent có thể đưa ra cho khách hàng một câu trả lời sai một cách tự tin mà không có lỗi, không có giao dịch thất bại và không có cảnh báo nào. Mọi bảng điều khiển đều hiện màu xanh. Hoạt động truyền thống phụ thuộc vào hệ thống thông báo cho bạn khi chúng gặp sự cố, và các agent không luôn đáng tin cậy trong việc này.

Tôi không cho rằng câu trả lời là phải chậm lại. Những công ty thắng cuộc ở đây sẽ di chuyển nhanh. Câu trả lời là xây dựng bằng chứng và giám sát cho phép bạn di chuyển nhanh với sự tự tin. Càng nhiều quyền tự chủ mà một agent nhận được, bạn càng cần nhiều bằng chứng để chứng minh nó có thể chịu trách nhiệm.

Khi một agent tự động đưa ra quyết định kém, ai cuối cùng phải chịu trách nhiệm: nhà phát triển, đơn vị kinh doanh triển khai, nhà cung cấp mô hình, hay giám đốc đã phê duyệt việc sử dụng nó?

Cuối cùng, công ty triển khai agent là người chịu trách nhiệm về kết quả. Nhiều bên tham gia vào việc xây dựng và vận hành hệ thống, nhưng khách hàng không có mối quan hệ với nhà cung cấp mô hình. Khách hàng có mối quan hệ với công ty mà tên của nó xuất hiện trong tương tác.

Điều đó không có nghĩa là trách nhiệm chỉ nằm ở một người. Nó lan truyền qua chuỗi quyết định. Nhà phát triển chịu trách nhiệm về cách hệ thống được xây dựng. Doanh nghiệp quyết định agent được phép làm gì. Nhà cung cấp chịu trách nhiệm về công nghệ mà họ cung cấp. Lãnh đạo chịu trách nhiệm đảm bảo công ty có các kiểm soát và giám sát để quản lý rủi ro.

Sai lầm là cho rằng vì mô hình đã đưa ra quyết định, nên mô hình sở hữu quyết định đó. Thực tế không phải như vậy. Nếu một agent thực hiện cam kết với khách hàng thay mặt bạn, cam kết đó thuộc về thương hiệu. Khách hàng hiểu điều này một cách tự nhiên, và các cơ quan quản lý cũng vậy.

Các agent AI có thể hành xử không lường trước được khi gặp các tình huống không được dự đoán trong quá trình thử nghiệm. Doanh nghiệp nên kiểm tra các trường hợp biên này như thế nào trước khi cho phép các agent truy cập khách hàng, hệ thống tài chính hoặc dữ liệu nhạy cảm?

Bạn phải giả định rằng agent cuối cùng sẽ gặp phải điều gì đó mà nó không được thiết kế để xử lý. Câu hỏi là sẽ xảy ra gì khi điều đó xảy ra.

Vì vậy, hãy xác thực vượt ra ngoài lộ trình dự kiến. Đưa cho agent các yêu cầu mơ hồ. Cung cấp cho nó thông tin mâu thuẫn. Đưa cho nó ngữ cảnh không đầy đủ. Đặt nó vào các tình huống mà câu trả lời đúng là dừng lại và chuyển tiếp thay vì tiếp tục. Thêm các điều kiện thực tế, trong giao tiếp bằng giọng nói có nghĩa là giọng địa phương, tiếng ồn, kết nối kém và người gọi thay đổi chủ đề giữa chừng. Mục tiêu không phải là xác nhận agent hoạt động, mà là tìm hiểu cách nó phản ứng khi các điều kiện không sạch sẽ.

Điểm quan trọng hơn là bạn phải xác thực toàn bộ hành trình, không chỉ riêng agent. Mô hình thường không phải là vấn đề. Khi có sự cố, câu hỏi đầu tiên của tôi là mô hình đã nhận được ngữ cảnh gì. Có thể đó là một bài viết kiến thức đã lỗi thời, hoặc hai hệ thống mang chính sách mâu thuẫn, hoặc một quá trình chuyển giao đã bỏ lỡ những gì khách hàng đã giải thích. Mỗi thành phần có thể vượt qua bài kiểm tra riêng của mình, nhưng hành trình khách hàng vẫn có thể thất bại ở các khoảng hở giữa chúng.

Lớp giữa các hệ thống là thứ chúng tôi đã dành nhiều năm để thiết lập, trên 450 doanh nghiệp và hơn 350 triệu hành trình khách hàng mỗi năm. Dù có tính năng agent hay không, nó vẫn bị hỏng theo cùng một cách. Chúng tôi cũng thấy các agent được xây dựng trên công nghệ của hơn 55 nhà cung cấp khác nhau, cộng với mọi nền tảng trung tâm liên lạc lớn, và đó là cách chúng tôi biết mô hình này vẫn áp dụng bất kể mô hình nào nằm phía dưới.

Trước khi một agent được cấp quyền truy cập vào những thứ quan trọng, doanh nghiệp nên có bằng chứng về cách nó hoạt động khi mọi việc diễn ra suôn sẻ và khi chúng không như mong đợi.

Bạn thấy việc kiểm thử AI sẽ phát triển như thế nào khi các công ty chuyển từ phần mềm quyết định định hướng sang các hệ thống suy luận, lập kế hoạch, giao tiếp và thực hiện hành động trên nhiều ứng dụng?

Kiểm thử phải chuyển từ việc hỏi liệu hệ thống có tạo ra câu trả lời mong đợi hay không sang việc hỏi liệu nó có đạt được kết quả đúng không.

Đó là một sự chuyển đổi đáng kể. Một agent có thể đi qua nhiều lộ trình khác nhau để giải quyết cùng một vấn đề của khách hàng, và các lộ trình đó có thể thay đổi theo thời gian khi mô hình và kiến thức phía sau chúng thay đổi. Bạn không thể viết kịch bản cho mọi tương tác có thể xảy ra. Bạn phải đánh giá liệu agent có hiểu ý định, đưa ra các quyết định hợp lý trong quá trình và giữ trong giới hạn đã được giao hay không.

Tôi muốn cẩn thận với một điều, vì ngành đang bắt đầu sai lầm một cách tốn kém. Kiểm thử trước khi ra mắt hiện quan trọng hơn, không phải ít hơn. Nó quyết định liệu một agent có sẵn sàng hay không. Lập luận rằng bạn có thể bỏ qua bước này và chỉ quan sát trong môi trường sản xuất là một cách để phát hiện vấn đề trước khách hàng.

Điều thay đổi là kiểm thử trước khi ra mắt không còn là bước cuối cùng của quy trình. Sản xuất tiết lộ các điều kiện mà môi trường kiểm soát không thể tái tạo hoàn toàn, và những gì sản xuất phát hiện sẽ trở thành một bài kiểm tra mà agent phải vượt qua trước bản phát hành tiếp theo. Bằng chứng trước khi ra mắt, giám sát trong sản xuất, và mỗi phần hỗ trợ lẫn nhau. Agent đang hoạt động ở tháng thứ sáu nên đáng kể hơn so với agent đã ra mắt.

Nhìn về phía trước, yếu tố nào sẽ phân biệt các tổ chức xây dựng thành công lực lượng AI đáng tin cậy so với những tổ chức vẫn mắc kẹt trong việc chạy các dự án thí điểm AI nhỏ?

Các tổ chức thu được lợi nhuận thực sự từ các agent là những tổ chức đã xây dựng mô hình vận hành dựa trên bằng chứng. Những tổ chức chậm lại thường không bị công nghệ chặn lại. Họ bị chặn vì không ai có thể tạo ra những gì cấp độ phê duyệt tiếp theo yêu cầu. Bộ phận pháp lý đặt câu hỏi hợp lý, hoặc ủy ban rủi ro cũng vậy, và không có câu trả lời, vì vậy dự án thí điểm vẫn chỉ là thí điểm. Công nghệ có thể đã sẵn sàng nhưng tổ chức vẫn không thể biện minh cho việc trao thêm quyền hạn cho nó.

Đó là sự khác biệt giữa một dự án thí điểm và một lực lượng lao động vận hành. Trong một thí điểm, luôn có người giám sát. Trong một mô hình vận hành, mỗi agent có một công việc mà bạn có thể diễn đạt trong một câu. Quyền hạn của nó được giới hạn và ghi lại. Hiệu suất của nó được đánh giá bởi một yếu tố khác với đội ngũ đã tạo ra nó. Các lỗi sản xuất trở thành cổng phát hành. Nhiều tự chủ hơn sẽ theo sau bằng bằng chứng.

Sự khác biệt thứ hai là quyền sở hữu. Ở các công ty mở rộng quy mô, agent thuộc về chức năng kinh doanh mà nó phục vụ, với một chủ sở hữu được chỉ định chịu trách nhiệm về những gì nó làm. Khi nó vẫn là dự án AI do một đội AI sở hữu, nó sẽ vẫn nhỏ, vì không có lãnh đạo kinh doanh nào muốn chịu rủi ro của một thứ họ không kiểm soát.

Tất cả những điều này không phải là gì xa lạ. Nó gần giống như cách một công ty đã quản lý những người mà họ tin tưởng với trách nhiệm thực sự.

Một dự án thí điểm có thể dựa trên niềm tin của tổ chức. Mở rộng quy mô đòi hỏi bằng chứng.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, các độc giả muốn tìm hiểu thêm nên truy cập Cyara.