Tác giả: Nav Bhasin và Sri Elaprolu
Ngày phát hành: 16 MAR 2026
Chuyên mục: Generative AI, Thought Leadership

Đây là Phần II của loạt bài gồm hai phần từ AWS Generative AI Innovation Center. Nếu bạn đã bỏ lỡ Phần I, hãy tham khảo Vận hành Agentic AI Phần 1: Hướng dẫn dành cho các bên liên quan.

Rào cản lớn nhất đối với Agentic AI không phải là công nghệ—mà là mô hình vận hành. Trong Phần I, chúng tôi đã xác định rằng các tổ chức tạo ra giá trị thực từ các agent chia sẻ ba đặc điểm: họ định nghĩa công việc một cách chi tiết, họ giới hạn quyền tự chủ một cách có chủ đích, và họ coi việc cải tiến là một thói quen liên tục chứ không phải là một dự án một lần. Chúng tôi cũng giới thiệu bốn yếu tố của công việc thực sự “có hình dạng agent”: một điểm bắt đầu và kết thúc rõ ràng, khả năng đánh giá trên nhiều công cụ, thành công có thể quan sát và đo lường được, và một chế độ lỗi an toàn. Nếu không có những nền tảng này, ngay cả agent tinh vi nhất cũng sẽ bị đình trệ trong phòng thí nghiệm.

Bây giờ là câu hỏi khó hơn: ai sẽ thực hiện nó, và bằng cách nào?

Trong Phần II, chúng tôi nói chuyện trực tiếp với các nhà lãnh đạo, những người phải biến nền tảng chung đó thành hành động. Mỗi vai trò mang một bộ trách nhiệm, rủi ro và điểm đòn bẩy riêng biệt. Cho dù bạn sở hữu P&L, điều hành kiến trúc doanh nghiệp, lãnh đạo bảo mật, quản lý dữ liệu hay quản lý tuân thủ, phần này được viết bằng ngôn ngữ công việc của bạn—bởi vì đó là nơi Agentic AI thành công hoặc lặng lẽ chết đi.

Phần II – Hướng dẫn theo persona

Dành cho chủ sở hữu nghiệp vụ: đặt agent chịu trách nhiệm về các KPI của bạn.

Nếu bạn sở hữu P&L, bạn không cần một món đồ chơi công nghệ khác. Bạn cần ít phiếu yêu cầu mở hơn, ít ngày hơn trong chu kỳ chuyển đổi tiền mặt, ít giỏ hàng bị bỏ quên hơn, ít ngoại lệ tuân thủ hơn. Một agent chỉ hữu ích nếu nó có thể được gắn trực tiếp với những con số đó.

Bước đầu tiên là viết mô tả công việc cho agent giống như bạn viết cho một nhân viên mới. “Agent này nhận yêu cầu X đến, kiểm tra Y, thực hiện Z, và chuyển giao cho nhóm này khi hoàn thành.” Bao gồm ý nghĩa của việc hoàn thành theo các thuật ngữ vận hành của bạn: thời gian phản hồi, ngưỡng chất lượng, các yếu tố kích hoạt leo thang và các cam kết với khách hàng.

Bước thứ hai là neo chặt trường hợp kinh doanh vào các con số mà nhóm của bạn đã theo dõi. Có bao nhiêu đơn vị mỗi tuần đi qua quy trình làm việc này? Mỗi đơn vị tốn bao nhiêu chi phí lao động, làm lại và xóa sổ? Mất bao lâu để nó chờ đợi trong hàng đợi? Bao nhiêu lần nó bị trả lại vì thiếu hoặc sai sót? Nếu bạn không thể trả lời những câu hỏi này hôm nay, dự án đầu tiên của bạn không phải là một agent—mà là đo lường quy trình làm việc.

Bước thứ ba là sắp xếp trình tự. Giai đoạn đầu của hành trình, agent hữu ích nhất thường là agent giúp loại bỏ các bước chuyển giao: nó đọc yêu cầu đến, thu thập ngữ cảnh từ nhiều hệ thống, đề xuất một kế hoạch và đặt kế hoạch đó vào tay nhóm của bạn với mọi thứ đã được chuẩn bị sẵn. Nó có thể không tự đóng vòng lặp, nhưng nó có thể loại bỏ hàng giờ hoặc hàng ngày của việc qua lại. Những chiến thắng tiết kiệm chi phí như vậy giúp xây dựng uy tín với CFO và cung cấp cho bạn vốn chính trị để theo đuổi các trường hợp sử dụng tham vọng hơn, tập trung vào doanh thu sau này.

Chủ sở hữu nghiệp vụ không cần phải hiểu các mô hình hoặc prompt. Họ cần sở hữu một danh mục nhỏ các công việc của agent được gắn trực tiếp với các chỉ số của họ, và họ cần nhấn mạnh rằng mọi sáng kiến phải bắt đầu bằng một hợp đồng công việc bằng văn bản, chứ không phải một slide với một nhãn.

Dành cho CTO hoặc kiến trúc sư trưởng: Quyết định xem bạn muốn mười agent hay một trăm agent

Nếu bạn là CTO, một trong những rủi ro lớn nhất của bạn là thành công. Một khi agent đầu tiên hoạt động tốt, các nhóm khác sẽ muốn có một agent. Nếu mỗi nhóm xây dựng stack riêng của mình—framework riêng, connector riêng, mô hình truy cập riêng—bạn sẽ kết thúc với một “vườn bách thú” các agent trông khác nhau, được kiểm thử khác nhau và không thể giám sát tổng thể.

Câu hỏi về kiến trúc rất đơn giản để đặt ra nhưng khó thực hiện: bạn muốn mười agent ấn tượng, độc lập, hay bạn muốn một hệ thống có thể hỗ trợ một trăm agent một cách an toàn?

Con đường hệ thống yêu cầu bạn thực hiện một số công việc khó khăn ngay từ đầu. Điều đó có nghĩa là tiêu chuẩn hóa cách các công cụ được hiển thị để mỗi agent gọi cùng một tích hợp khi cần đọc dữ liệu khách hàng, cập nhật một phiếu yêu cầu hoặc đặt thanh toán. Điều đó có nghĩa là tách biệt suy nghĩ khỏi hành động trong thiết kế của bạn: một thành phần lập kế hoạch, một thành phần khác gọi công cụ, một thành phần khác kiểm tra tuân thủ, một thành phần khác giải thích các quyết định cho người dùng. Điều đó có nghĩa là ghi lại dấu vết quyết định theo một định dạng nhất quán để khả năng quan sát và gỡ lỗi hoạt động trên các trường hợp sử dụng.

Nó cũng yêu cầu bạn coi các agent là các dịch vụ tồn tại lâu dài, chứ không phải các script ngắn hạn. Chúng cần danh tính, quyền hạn, xoay vòng, quản lý vòng đời và một cách để nâng cấp mà không làm hỏng người tiêu dùng của chúng. Đó là nhiều công việc hơn vào ngày đầu tiên, nhưng đó là điều cho phép bạn nói “Có” với nhóm thứ mười muốn có một agent mà không cần bắt đầu lại từ đầu.

Công việc của CTO không phải là chọn framework agent tốt nhất một cách cô lập. Đó là xây dựng một nền tảng vững chắc—danh tính, thực thi chính sách, ghi nhật ký, connector và các hook đánh giá—cho phép nhiều nhóm triển khai agent một cách an toàn, nhanh chóng và nhất quán.

Dành cho CISO: Coi agent như đồng nghiệp, không phải code

Nếu bạn chịu trách nhiệm về bảo mật, bạn đã quen với việc suy nghĩ về tài sản: hệ thống, kho dữ liệu, thông tin xác thực. Các agent bổ sung một yếu tố mới vào mô hình mối đe dọa của bạn: các thực thể được ủy quyền có thể đưa ra quyết định và thực hiện hành động với tốc độ máy.

Sai lầm là coi các agent chỉ là một ứng dụng khác. Chúng gần giống đồng nghiệp hơn. Chúng có tài khoản. Chúng có vai trò. Chúng có các công cụ mà chúng có thể sử dụng. Chúng có thể mắc lỗi. Chúng có thể bị cấu hình sai.

Động thái thực tế là thiết lập danh tính phi con người cho các agent với sự nghiêm túc tương tự như bạn áp dụng cho danh tính con người. Mỗi agent nên có thông tin xác thực, quyền hạn và nhật ký kiểm toán riêng. Nó không nên kế thừa tất cả các quyền của tài khoản dịch vụ mà nó đang chạy. Khi một agent đọc dữ liệu nhạy cảm hoặc gọi một công cụ có rủi ro cao, điều đó phải hiển thị trong nhật ký của bạn theo cách mà nhóm của bạn nhận ra.

Bạn cũng sẽ muốn có cách để dừng các agent một cách sạch sẽ. Điều đó có nghĩa là các công tắc ngắt khẩn cấp thực sự hoạt động, chứ không chỉ là một dòng trong tài liệu thiết kế. Điều đó có nghĩa là các chính sách nói rằng, “Loại hành động này luôn yêu cầu sự chấp thuận của con người,” và thực thi điều đó ở cấp độ công cụ, chứ không chỉ trong prompt của agent. Điều đó có nghĩa là theo dõi hành vi có sự thay đổi: một agent đột nhiên gọi một công cụ thường xuyên hơn nhiều so với bình thường, hoặc bắt đầu đọc dữ liệu mà nó chưa từng cần trước đây.

Các CISO thích nghi tốt với Agentic AI không cố gắng chặn hoàn toàn quyền tự chủ. Họ xác định nơi quyền tự chủ được chấp nhận, bằng chứng nào cần thiết để tin tưởng nó, và điều gì xảy ra khi niềm tin đó bị phá vỡ. Họ tham gia vào cuộc trò chuyện thiết kế sớm và biến chính sách thành một phần của hình dạng agent, chứ không phải là một cổng ở cuối.

Dành cho giám đốc dữ liệu (CDO): Làm cho dữ liệu trở nên “nhàm chán”

Các agent khuếch đại bất kỳ nền tảng dữ liệu nào bạn đã có. Nếu dữ liệu của bạn bị phân mảnh, lỗi thời và không được ghi lại, các agent có thể nhanh chóng làm cho những vấn đề đó hiển thị rõ ràng với mọi người. Nếu dữ liệu của bạn nhất quán, được quản lý tốt và dễ hiểu, các agent có thể nhân lên giá trị của nó.

Công việc của CDO trong kỷ nguyên Agentic là làm cho dữ liệu trở nên “nhàm chán”, theo cách tốt nhất có thể. Điều đó có nghĩa là khi một agent hỏi, “Hiển thị tất cả các yêu cầu mở vượt quá ngưỡng này,” nó sẽ nhận được một câu trả lời nhất quán bất kể nó hoạt động ở Region hay nghiệp vụ nào. Điều đó có nghĩa là một định nghĩa về “điểm sức khỏe khách hàng” tồn tại và được ghi lại đủ tốt để cả người và agent đều có thể sử dụng nó. Điều đó có nghĩa là nguồn gốc rõ ràng: khi có điều gì đó sai, bạn có thể truy ngược quyết định thông qua các chỉ số, thông qua các tính năng, cho đến hệ thống nguồn.

Điều đó cũng có nghĩa là phải thực tế về sự sẵn sàng. Một số quy trình làm việc đơn giản là chưa sẵn sàng cho các quyết định tự động vì dữ liệu mà chúng dựa vào quá không đầy đủ hoặc quá mâu thuẫn. Các CDO giỏi nhất sẽ tận dụng điều này. Họ không nói, “Chúng tôi không thể hỗ trợ các agent.” Họ nói, “Chúng tôi có thể hỗ trợ loại công việc này hôm nay. Nếu bạn muốn tự động hóa loại khác, đây là những cải tiến dữ liệu chúng tôi cần trước tiên.”

Một trong những đóng góp có giá trị nhất mà CDO có thể mang lại cho cuộc trò chuyện về agent là một bản đồ: những miền nào có dữ liệu cấp độ sản xuất, những miền nào đang trong quá trình, và những nơi có “bãi mìn”. Bản đồ đó giúp mọi người khác chọn công việc đầu tiên của họ một cách khôn ngoan, thay vì phát hiện ra nợ dữ liệu giữa chừng quá trình triển khai.

Dành cho giám đốc khoa học dữ liệu hoặc AI (CDSO/CAIO): Đánh giá là sản phẩm thực sự của bạn

Nếu bạn lãnh đạo khoa học dữ liệu hoặc AI, thật hấp dẫn khi tập trung vào các mô hình: Foundation Model nào, kỹ thuật tinh chỉnh nào, điểm chuẩn nào. Những quyết định đó quan trọng, nhưng trong sản xuất, sản phẩm thực sự của bạn là hệ thống đánh giá được bao quanh mô hình.

Các agent có thể thất bại theo những cách mà các điểm chuẩn không đo lường được. Chúng bị mắc kẹt trong các vòng lặp. Chúng gọi công cụ không chính xác. Chúng hoàn thành một nửa nhiệm vụ theo những cách trông có vẻ hợp lý nhưng lại sai. Chúng hoạt động tốt trên dữ liệu kiểm thử sạch và sụp đổ ở các trường hợp biên mà không ai nghĩ đến. Một hệ thống đánh giá hiệu quả thực hiện ba điều.

Đầu tiên, nó biến công việc thực tế thành các bài kiểm thử. Khi một agent mắc lỗi trong sản xuất, kịch bản đó trở thành một phần của bộ đánh giá đang phát triển. Theo thời gian, những trường hợp khó nhất bạn gặp phải sẽ trở thành rào chắn giúp bảo vệ bạn khỏi sự suy giảm.

Thứ hai, nó chạy tự động. Các thay đổi đối với prompt, mô hình, công cụ hoặc chỉ mục truy xuất sẽ kích hoạt đánh giá trước khi thay đổi đó được triển khai. Điều đó mang lại cho bạn sự tự tin để lặp lại nhanh chóng, bởi vì bạn không dựa vào một vài kiểm tra ngẫu nhiên và hy vọng.

Thứ ba, nó đo lường những gì doanh nghiệp quan tâm. Điều đó bao gồm các chỉ số kỹ thuật như độ trễ và tỷ lệ thành công của công cụ, nhưng cũng bao gồm tỷ lệ hoàn thành nhiệm vụ, tỷ lệ leo thang, chi phí cho mỗi quyết định và tỷ lệ công việc mà con người chấp nhận khuyến nghị của agent nguyên trạng. Khi những con số đó hiển thị rõ ràng và cải thiện, niềm tin sẽ theo sau.

Các nhóm đầu tư vào đây sớm sẽ nhận thấy rằng việc lựa chọn mô hình trở nên đơn giản hơn, không khó hơn. Một khi bạn có thể thấy cách một mô hình hoạt động trên các nhiệm vụ thực tế của mình, cuộc tranh luận “mô hình nào tốt nhất?” sẽ trở thành một so sánh có cơ sở thay vì một cuộc thảo luận triết học.

Dành cho cán bộ tuân thủ hoặc pháp lý: Thiết kế cho các cuộc kiểm toán trước khi bạn đối mặt với chúng

Nếu bạn chịu trách nhiệm về rủi ro tuân thủ hoặc pháp lý, Agentic AI có lẽ trông giống như một mục tiêu di động. Các quy định đang phát triển, và hoạt động tiếp thị của nhà cung cấp đi trước sự rõ ràng về quy định. Bạn không thể đóng băng tổ chức cho đến khi mọi tiêu chuẩn được thiết lập, nhưng bạn cũng không thể chấp nhận “Chúng ta sẽ tìm ra cách quản trị sau.”

Một cách tiếp cận thực dụng là làm việc ngược lại từ một cuộc kiểm toán. Hãy tưởng tượng một cơ quan quản lý hoặc ủy ban kiểm toán nội bộ hỏi, “Vào ngày này, tại sao agent này lại thực hiện hành động này?” Hãy quyết định ngay bây giờ bạn cần bằng chứng gì để trả lời câu hỏi đó một cách rõ ràng và nhanh chóng.

Điều đó ngụ ý một vài lựa chọn thiết kế. Mỗi agent nên để lại một dấu vết: những đầu vào nó đã thấy, những công cụ nó đã gọi, những lựa chọn nó đã xem xét, những gì nó đã chọn và những quy tắc nó đã áp dụng. Đối với các lĩnh vực có rủi ro cao như quyết định tín dụng, bảo hiểm, và các hành động liên quan đến việc làm, con người phải luôn tham gia vào vòng lặp, và vai trò của agent nên là tư vấn hoặc chuẩn bị: thu thập dữ liệu, tổ chức bằng chứng, đề xuất hành động. Sự chấp thuận của con người trở thành một phần của hồ sơ.

Điều đó cũng ngụ ý rằng không phải tất cả các ý tưởng về agent đều được phép. Một số trường hợp sử dụng nằm hoàn toàn trong các vùng đỏ quy định cho đến khi các framework và kiểm soát trưởng thành. Công việc của bạn là làm cho những ranh giới đó hiển thị rõ ràng từ sớm. Khi bạn có thể nói “Có” với một số agent với các điều kiện rõ ràng, “Có sau” với những agent khác với các điều kiện tiên quyết cụ thể, và “Không” với một vài agent với lý do rõ ràng, bạn có thể trở thành người hỗ trợ thay vì người cản trở.

Một trong những điều hữu ích nhất bạn có thể làm cho phần còn lại của đội ngũ lãnh đạo là biến những mối quan tâm trừu tượng như “chúng ta cần AI có trách nhiệm” thành một danh sách kiểm tra cụ thể có thể áp dụng cho từng agent được đề xuất trước khi công việc bắt đầu.

Kêu gọi hành động

Nếu các mô hình trong bài viết này nghe có vẻ quen thuộc, bạn không bị tụt hậu. Bạn đang ở vị trí mà hầu hết các doanh nghiệp đang ở. Điều khác biệt giữa những người tiến lên là quyết định coi Agentic AI là một thách thức về mô hình vận hành, chứ không phải là một thử nghiệm công nghệ. Năm bước bạn có thể thực hiện để bắt đầu:

Tập hợp đúng người. Tập hợp chủ sở hữu LOB, CTO, CISO, CDO, lãnh đạo AI/DS và trưởng bộ phận tuân thủ của bạn lại với nhau—không phải để trình diễn, mà để có một buổi làm việc. Mỗi người trả lời một câu hỏi: “Điều gì là trở ngại lớn nhất ngăn cản chúng ta đưa một agent vào sản xuất trên một quy trình làm việc thực tế?”

Chọn một công việc, không phải một trường hợp sử dụng. Xác định một công việc cụ thể với điểm bắt đầu rõ ràng, điểm kết thúc rõ ràng, các công cụ được xác định và một thước đo thành công mà người ngoài nhóm có thể xác minh. Cùng nhau viết mô tả công việc của agent. Nếu mọi người không thể đồng ý về việc hoàn thành trông như thế nào, bạn đã tìm thấy vấn đề đầu tiên cần giải quyết.

Vẽ bản đồ sẵn sàng của bạn. Yêu cầu CDO và CISO của bạn cùng nhau phác thảo những miền dữ liệu và hệ thống nào đã sẵn sàng cho các quyết định tự động hôm nay, những miền nào cần cải thiện trước, và đâu là những ranh giới cứng. Bản đồ một trang đó có thể giúp bạn tiết kiệm hàng tháng công sức lãng phí.

Cam kết một nhịp độ. Thiết lập một cuộc họp định kỳ hàng tuần hoặc hai tuần một lần, nơi nhóm đa chức năng kiểm tra cách agent hoạt động, điều gì hiệu quả, điều gì bị hỏng và điều gì cần điều chỉnh. Nếu bạn chỉ đánh giá khi ra mắt, bạn đang xây dựng một bản demo. Nếu bạn đánh giá liên tục, bạn đang xây dựng một năng lực.

Biến quản trị thành đầu vào thiết kế, không phải cổng ra mắt. Hãy quyết định ngay bây giờ bạn sẽ cần bằng chứng gì nếu một kiểm toán viên hỏi “Tại sao agent này lại làm điều này?” sáu tháng kể từ hôm nay. Tích hợp điều đó vào kiến trúc trước khi dòng code đầu tiên được viết.

Các doanh nghiệp tạo ra giá trị thực từ Agentic AI đã đạt được điều đó bằng cách thực hiện những công việc không hào nhoáng: định nghĩa công việc một cách chính xác, giới hạn quyền tự chủ một cách có chủ đích, đầu tư vào đánh giá không ngừng nghỉ và điều chỉnh các bên liên quan xung quanh một mô hình vận hành chung.

Hợp tác với Generative AI Innovation Center

Bạn không cần phải tự mình điều hướng hành trình này. Cho dù bạn đang lên kế hoạch cho dự án thí điểm Agentic đầu tiên hay mở rộng quy mô thành một năng lực toàn doanh nghiệp, hãy liên hệ với nhóm Generative AI Innovation Center để bắt đầu một cuộc trò chuyện dựa trên các quy trình làm việc, dữ liệu và kết quả kinh doanh của bạn.

---

Về tác giả

Nav Bhasin

Nav Bhasin là Giám đốc Khoa học Dữ liệu cấp cao tại AWS Generative AI Innovation Center, nơi ông thúc đẩy hành trình của khách hàng doanh nghiệp từ ý tưởng Agentic AI đến triển khai sản xuất. Với hơn một thập kỷ kinh nghiệm xây dựng các sản phẩm AI trên các lĩnh vực công nghiệp, năng lượng và chăm sóc sức khỏe, Nav đã dành sáu năm tại AWS để lãnh đạo các nhóm kiến trúc sư và nhà khoa học GenAI trên toàn thế giới, đóng vai trò trung tâm trong việc đưa các sản phẩm như Amazon Bedrock, Amazon SageMaker và AgentCore vào ứng dụng sản xuất. Trước khi gia nhập Innovation Center, ông đã lãnh đạo các nhóm kiến trúc go-to-market và khoa học dữ liệu cho danh mục sản phẩm GenAI cốt lõi của AWS. Trước AWS, Nav từng là Trưởng bộ phận Khoa học Dữ liệu và Kỹ thuật tại Utopus Insights và lãnh đạo Kỹ thuật và Kiến trúc tại Honeywell. Nav có bằng MBA và bằng sau đại học về Kỹ thuật Điện tử.

Sri Elaprolu

Sri Elaprolu là Giám đốc của AWS Generative AI Innovation Center, nơi ông lãnh đạo một nhóm toàn cầu triển khai các giải pháp AI tiên tiến cho các tổ chức doanh nghiệp và chính phủ. Trong suốt 13 năm làm việc tại AWS, ông đã lãnh đạo các nhóm khoa học ML hợp tác với các doanh nghiệp toàn cầu và các tổ chức khu vực công. Trước khi gia nhập AWS, ông đã dành 14 năm tại Northrop Grumman trong các vai trò lãnh đạo phát triển sản phẩm và kỹ thuật phần mềm. Sri có bằng Thạc sĩ Khoa học Kỹ thuật và bằng MBA.