Cơ quan hành chính đã sẵn sàng với Agent OS chưa? Bộ tiêu chí tự đánh giá trước khi triển khai

37

20/06/2026 – (AIHanhChinhCong.vn) – Sau khi đã hiểu Agent OS là gì, lãnh đạo cần tư duy ra sao và có thể chọn những use case nào, câu hỏi tiếp theo mang tính quyết định là: cơ quan hành chính đã đủ sẵn sàng để triển khai Agent OS chưa? Nếu chưa sẵn sàng, nên nâng năng lực từ đâu? Nếu muốn bắt đầu, nên pilot thế nào để nhỏ, rõ, đo được, có kiểm soát và không tạo rủi ro cho dữ liệu nhạy cảm?

Đây là câu hỏi rất thực tế. Nhiều cơ quan hiện nay đã quan tâm đến AI agent, chatbot, trợ lý văn bản, tổng hợp báo cáo hoặc hỗ trợ dịch vụ công. Nhưng quan tâm không đồng nghĩa với sẵn sàng. Một cơ quan có thể có hạ tầng số, phần mềm quản lý văn bản, cổng dịch vụ công và kho tài liệu, nhưng nếu tài liệu chưa chuẩn hóa, quy trình chưa mô tả rõ, vai trò chưa phân định, dữ liệu chưa kiểm soát và chưa có cơ chế ghi nhật ký, việc đưa AI agent vào vận hành có thể tạo thêm rủi ro thay vì tạo giá trị.

Các báo cáo quốc tế gần đây về AI trong khu vực công đều nhấn mạnh một điểm chung: agentic AI có thể tạo bước chuyển lớn vì có khả năng phối hợp nhiều bước công việc, nhưng nếu thiếu đánh giá mức độ sẵn sàng, thiếu quản trị rủi ro và thiếu lựa chọn use case phù hợp, các dự án rất dễ dừng ở thử nghiệm hoặc không mở rộng được. World Economic Forum năm 2026 đã công bố khung đánh giá readiness cho agentic AI trong chính phủ, nhấn mạnh cần chọn điểm bắt đầu dựa trên giá trị công và mức độ phức tạp có thể quản lý. OECD cũng chỉ ra rằng AI trong hành chính công đang mở ra cơ hội về năng suất, chất lượng dịch vụ và trách nhiệm giải trình, nhưng đi kèm rủi ro về dữ liệu, thiên lệch, minh bạch và niềm tin.

Bài viết này đề xuất một maturity model, bộ tiêu chí tự đánh giá, checklist triển khai và kế hoạch pilot Agent OS hành chính công trong 90 ngày. Trọng tâm là giúp cơ quan không triển khai đại trà ngay, mà bắt đầu bằng một pilot đủ nhỏ để kiểm soát, đủ rõ để đo lường và đủ thực tế để tạo năng lực nền cho giai đoạn mở rộng.

Vì sao cần tự đánh giá trước khi pilot Agent OS?

Agent OS không phải là một chatbot mới. Đây là lớp vận hành để nhiều AI agent làm việc trên nền tiêu chuẩn, kho tri thức, quy trình, vai trò, nhật ký và cơ chế kiểm duyệt. Vì vậy, mức độ sẵn sàng của cơ quan không chỉ nằm ở việc có mua được công cụ AI hay không. Nó nằm ở việc tổ chức đã đủ năng lực để giao việc cho AI agent một cách an toàn hay chưa.

Một pilot Agent OS thất bại thường không thất bại vì mô hình AI yếu. Nó thường thất bại vì use case quá rộng, dữ liệu đầu vào lộn xộn, người kiểm duyệt không rõ, tiêu chí đánh giá mơ hồ, nhật ký không đầy đủ hoặc lãnh đạo kỳ vọng AI tự động tạo ra thay đổi mà không cần chuẩn hóa quy trình. Ngược lại, một pilot tốt có thể chỉ bắt đầu từ tóm tắt văn bản đến, theo dõi nhiệm vụ hoặc chuẩn hóa báo cáo tuần, nhưng nếu được thiết kế đúng, nó giúp cơ quan hình thành năng lực quan trọng hơn: biết cách chọn việc, chuẩn hóa tri thức, phân quyền, kiểm soát đầu ra và đo hiệu quả.

Tự đánh giá trước khi pilot cũng giúp lãnh đạo ra quyết định thực tế hơn. Không phải cơ quan nào cũng nên bắt đầu từ cùng một use case. Cấp xã có thể phù hợp với hỗ trợ tra cứu thủ tục hoặc kiểm tra sơ bộ thành phần hồ sơ. Sở chuyên ngành có thể phù hợp với tóm tắt văn bản, tổng hợp báo cáo hoặc chuẩn hóa biểu mẫu. Cấp tỉnh và cấp Bộ có thể quan tâm đến điều hành liên thông, ma trận văn bản, dashboard mô tả hoặc phân tích xu hướng. Nhưng dù ở cấp nào, nguyên tắc vẫn là: không triển khai Agent OS khi chưa biết rõ mình muốn đo cái gì, kiểm soát cái gì và ai chịu trách nhiệm cuối cùng.

Nguyên tắc thí điểm – pilot: nhỏ, rõ, đo được, có kiểm soát

Một pilot Agent OS trong hành chính công nên được thiết kế như một thử nghiệm quản trị, không chỉ là thử nghiệm công nghệ. Công nghệ có thể tạo bản tóm tắt, dự thảo văn bản, bảng tổng hợp hoặc câu trả lời hướng dẫn. Nhưng giá trị thật nằm ở việc cơ quan kiểm chứng được rằng đầu ra đó đúng hơn, nhanh hơn, nhất quán hơn, giảm lặp lại hơn và không làm suy giảm trách nhiệm công vụ.

Có năm nguyên tắc cần giữ ngay từ đầu. Thứ nhất là nhỏ: chỉ chọn một use case, một đơn vị hoặc một nhóm tài liệu rõ ràng. Thứ hai là rõ: mô tả được nhiệm vụ của agent, dữ liệu được dùng, giới hạn không được vượt qua và tiêu chí hoàn thành. Thứ ba là đo được: có chỉ số trước – sau, ví dụ thời gian xử lý, tỷ lệ lỗi, tỷ lệ phải chỉnh sửa, mức độ hài lòng của cán bộ. Thứ tư là có kiểm soát: mọi đầu ra phải có người kiểm duyệt, có nhật ký, có phiên bản và có cơ chế dừng. Thứ năm là không ảnh hưởng dữ liệu nhạy cảm: giai đoạn pilot nên tránh dữ liệu cá nhân nhạy cảm, hồ sơ khiếu nại phức tạp, xử lý kỷ luật, dữ liệu mật hoặc quyết định tác động trực tiếp đến quyền lợi công dân.

Nói cách khác, pilot không phải để chứng minh AI “làm được mọi thứ”. Pilot là để chứng minh cơ quan có thể thiết kế, vận hành và kiểm soát một agent trong phạm vi hẹp. Khi năng lực đó hình thành, việc mở rộng sang use case phức tạp hơn mới có cơ sở.

🔴 Xem thêm Chuỗi bài về Hệ điều hành Agent – Agent OS trong hành chính công: 

1) Agent OS là gì? Vì sao hành chính công cần một “hệ điều hành agent” thay vì chỉ dùng chatbot?
2) Lãnh đạo hành chính trong kỷ nguyên AI agent: từ giao việc cho con người sang thiết kế hệ vận hành thông minh
3) 12 trường hợp sử dụng Agent OS + Claude + Hermes cho cơ quan hành chính từ cấp xã đến cấp Bộ
4) Quản trị cho AI Agent trong hoạt động hành chính công: kiểm soát rủi ro, dữ liệu, trách nhiệm và niềm tin
5) Thiết kế thí điểm Agent OS trong cơ quan hành chính: 90 ngày để thử nghiệm có kiểm soát và đo được hiệu quả

👉 Tham gia Cộng đồng AI Hành Chính Công TẠI ĐÂY

Maturity model: 5 cấp độ sẵn sàng với Agent OS

Để tự đánh giá, cơ quan có thể sử dụng mô hình trưởng thành gồm 5 cấp độ. Mô hình này không nhằm “xếp hạng” cơ quan, mà giúp xác định điểm xuất phát và việc cần làm tiếp theo. Một cơ quan có thể ở cấp độ 3 về hạ tầng nhưng chỉ ở cấp độ 1 về tri thức chuẩn hóa; hoặc có lãnh đạo rất quyết tâm nhưng dữ liệu chưa đủ sạch. Vì vậy, nên xem maturity model như bản đồ năng lực, không phải bài kiểm tra hình thức.

Điểm quan trọng của mô hình này là không khuyến khích nhảy cóc. Nếu cơ quan đang ở cấp độ 0 hoặc 1, không nên triển khai agent có quyền truy cập nhiều hệ thống hoặc tham gia quy trình nhạy cảm. Nếu đang ở cấp độ 2, pilot 90 ngày là bước phù hợp để kiểm chứng năng lực. Nếu đạt cấp độ 3 sau pilot, cơ quan có thể quyết định mở rộng có chọn lọc. Nếu muốn lên cấp độ 4, cần chuyển từ “dự án thử nghiệm” sang “cơ chế quản trị thường xuyên”.

Mô hình trưởng thành giúp cơ quan biết mình đang ở đâu trước khi pilot Agent OS, tránh triển khai đại trà khi nền tảng quản trị chưa đủ chín

Bộ tiêu chí tự đánh giá trước khi triển khai

Trước khi chọn pilot, cơ quan nên tự đánh giá trên 7 nhóm năng lực. Mỗi nhóm có thể chấm theo thang 0–2 điểm: 0 là chưa có hoặc rất yếu; 1 là có nhưng chưa chuẩn hóa; 2 là đã rõ, có tài liệu và có người chịu trách nhiệm. Tổng điểm tối đa là 28. Nếu dưới 12 điểm, nên chuẩn hóa tài liệu và quy trình trước. Nếu từ 12 đến 20 điểm, có thể pilot use case rủi ro thấp. Nếu trên 20 điểm, có thể pilot use case có mức phức tạp trung bình nhưng vẫn cần kiểm soát chặt.

Bảng này nên được sử dụng trong một buổi làm việc ngắn giữa lãnh đạo phụ trách, chuyên viên nghiệp vụ, văn phòng, pháp chế, CNTT và an toàn thông tin. Điều cần tránh là để một nhóm kỹ thuật tự chấm toàn bộ. Agent OS là vấn đề liên ngành, nên đánh giá readiness cũng phải liên ngành.

Sau khi chấm điểm, cơ quan không nên chỉ nhìn tổng điểm. Hãy nhìn nhóm tiêu chí nào thấp nhất. Nếu kho tri thức thấp, ưu tiên chuẩn hóa tài liệu. Nếu vai trò thấp, cần phân quyền trước. Nếu kiểm soát thấp, chưa nên chạy thử với dữ liệu thật. Nếu đo hiệu quả thấp, pilot dễ biến thành hoạt động trình diễn vì không biết thành công được xác định như thế nào.

Chọn use case pilot: ưu tiên an toàn và dễ đo

Trong giai đoạn đầu, cơ quan nên chọn use case có rủi ro thấp đến trung bình, dữ liệu không nhạy cảm và đầu ra có thể kiểm duyệt dễ dàng. Bốn nhóm use case phù hợp nhất là: văn bản điều hành, tổng hợp báo cáo, hỗ trợ tra cứu thủ tục và chuẩn hóa biểu mẫu.

Với văn bản điều hành, agent có thể tóm tắt văn bản đến, trích xuất nhiệm vụ, nhận diện thời hạn, đề xuất tuyến xử lý sơ bộ và tạo bảng theo dõi. Đây là nhóm phù hợp vì cơ quan nào cũng có văn bản, khối lượng lặp lại cao và kết quả dễ kiểm tra. Tuy nhiên, agent không được tự giao việc chính thức hoặc tự thay đổi trạng thái nhiệm vụ nếu chưa có người duyệt.

Với tổng hợp báo cáo, agent có thể chuẩn hóa cấu trúc báo cáo tuần, tổng hợp nội dung từ các đơn vị, phát hiện thiếu trường thông tin và tạo bản tóm tắt điều hành. Use case này giúp giảm thời gian làm việc thủ công của bộ phận tổng hợp, đồng thời tạo nền cho báo cáo có dữ liệu chuẩn hơn.

Với hỗ trợ tra cứu thủ tục, agent có thể trả lời câu hỏi về thành phần hồ sơ, thời hạn, biểu mẫu và kênh nộp dựa trên kho tri thức đã duyệt. Đây là use case có giá trị với cấp xã, phường và trung tâm phục vụ hành chính công. Tuy nhiên, phải ghi rõ agent chỉ hướng dẫn thông tin chung, không kết luận trường hợp pháp lý cụ thể thay cán bộ.

Với chuẩn hóa biểu mẫu, agent có thể giúp rà soát biểu mẫu, phát hiện thiếu trường thông tin, chuẩn hóa cách đặt tên, gợi ý cấu trúc văn bản và tạo bản nháp theo mẫu. Đây là use case rủi ro thấp nếu không dùng dữ liệu cá nhân nhạy cảm và có cán bộ kiểm duyệt trước khi sử dụng.

Thiết kế Agent OS tối thiểu: không cần lớn, nhưng phải đủ

Một pilot 90 ngày không cần xây Agent OS hoàn chỉnh như một nền tảng lớn. Nhưng phải có Agent OS tối thiểu. Nếu thiếu lớp tối thiểu này, pilot rất dễ biến thành thử nghiệm prompt rời rạc, phụ thuộc vào một vài cá nhân và không thể nhân rộng.

Agent OS tối thiểu gồm 6 thành phần. Thứ nhất là kho tri thức: tập hợp văn bản, biểu mẫu, quy trình, câu hỏi thường gặp, mẫu báo cáo hoặc tài liệu hướng dẫn đã được kiểm duyệt. Thứ hai là tiêu chuẩn: cách đặt tên tài liệu, phiên bản, nguồn, trạng thái hiệu lực, mẫu đầu ra và tiêu chí chất lượng. Thứ ba là quy trình: mô tả agent tham gia bước nào, cán bộ kiểm duyệt ở đâu, khi nào dừng, khi nào chuyển tiếp.

Thứ tư là vai trò: lãnh đạo bảo trợ, chủ quy trình nghiệp vụ, người kiểm duyệt, CNTT, pháp chế, an toàn thông tin và người dùng thử. Thứ năm là nhật ký: lưu đầu vào, đầu ra, phiên bản prompt, người duyệt, lỗi phát hiện và phản hồi. Thứ sáu là kiểm duyệt: mọi đầu ra trong pilot phải được con người xem xét trước khi sử dụng chính thức.

Có thể tóm tắt Agent OS tối thiểu bằng một nguyên tắc: agent chỉ được làm việc trong “hàng rào” đã thiết kế trước. Hàng rào đó gồm dữ liệu được phép dùng, nhiệm vụ được phép làm, đầu ra được phép tạo, người được phép duyệt và nhật ký bắt buộc phải lưu.

Kế hoạch thực thi 90 ngày: từ khảo sát đến quyết định mở rộng

Kế hoạch 90 ngày nên được chia thành 4 giai đoạn. Mỗi giai đoạn có sản phẩm đầu ra rõ, KPI tương ứng và người chịu trách nhiệm. Điểm quan trọng là không chờ đến cuối pilot mới đánh giá. Cần đánh giá hằng tuần, ghi nhận lỗi, điều chỉnh tri thức và cập nhật prompt chuẩn.

Kế hoạch này không nhằm tạo áp lực phải “thành công bằng mọi giá”. Một pilot tốt có thể kết luận rằng use case chưa nên mở rộng vì dữ liệu chưa sạch hoặc quy trình chưa ổn. Đó vẫn là kết quả có giá trị, vì cơ quan tránh được triển khai đại trà sai thời điểm. Thành công của pilot không chỉ là agent chạy được, mà là cơ quan học được điều kiện để AI agent vận hành an toàn trong môi trường công vụ.

Tuần 1–2: khảo sát và chuẩn hóa tài liệu đầu vào

Hai tuần đầu quyết định chất lượng toàn bộ pilot. Nếu giai đoạn này làm qua loa, các tuần sau sẽ phải sửa liên tục. Cơ quan cần bắt đầu bằng việc chọn một use case hẹp và mô tả quy trình hiện tại bằng ngôn ngữ nghiệp vụ, không phải ngôn ngữ kỹ thuật. Ví dụ, thay vì nói “xây chatbot văn bản”, hãy nói rõ: “hỗ trợ tóm tắt văn bản đến và trích xuất nhiệm vụ, thời hạn, đơn vị liên quan để chuyên viên văn phòng kiểm tra trước khi trình lãnh đạo”.

Trong giai đoạn này, nhóm pilot cần tập hợp tài liệu đầu vào. Tài liệu có thể gồm quy chế làm việc, mẫu văn bản, văn bản đến đã ẩn thông tin nhạy cảm, báo cáo cũ, danh mục thủ tục, câu hỏi thường gặp hoặc biểu mẫu. Mỗi tài liệu cần có tên, nguồn, ngày cập nhật, trạng thái sử dụng và người chịu trách nhiệm xác nhận. Những tài liệu không chắc hiệu lực hoặc chứa dữ liệu nhạy cảm phải loại khỏi kho pilot.

Sản phẩm đầu ra quan trọng nhất của tuần 1–2 là phiếu use case pilot. Phiếu này nêu rõ mục tiêu, phạm vi, dữ liệu được phép dùng, dữ liệu không được dùng, đầu ra mong muốn, người kiểm duyệt, KPI, rủi ro và cơ chế dừng. Nếu chưa viết được phiếu này, chưa nên chuyển sang xây agent.

Tuần 3–6: xây agent, kịch bản, prompt chuẩn và tiêu chí kiểm soát

Từ tuần 3 đến tuần 6, trọng tâm chuyển sang thiết kế agent trong “hàng rào” đã xác định. Đây là giai đoạn dễ bị cuốn vào thử nghiệm công nghệ. Vì vậy, nhóm pilot cần giữ nguyên tắc: không mở rộng phạm vi khi chưa kiểm soát tốt phạm vi ban đầu. Nếu use case là tóm tắt văn bản đến, agent chỉ tập trung vào tóm tắt, trích xuất nhiệm vụ, thời hạn, đơn vị liên quan và cảnh báo thiếu thông tin; không tự ý chuyển sang soạn văn bản trả lời hoặc phân tích pháp lý sâu.

Prompt chuẩn cần được viết như một quy trình nghiệp vụ thu nhỏ. Nó phải chỉ rõ vai trò của agent, nguồn dữ liệu được dùng, định dạng đầu ra, cách xử lý khi không đủ thông tin và câu cảnh báo bắt buộc. Ví dụ, agent phải được yêu cầu ghi rõ “không đủ căn cứ” khi tài liệu đầu vào không có thời hạn hoặc không nêu đơn vị chủ trì, thay vì tự suy đoán.

Tiêu chí kiểm soát cần được thiết kế song song với prompt. Nhóm kiểm duyệt nên có checklist đánh giá đầu ra: tóm tắt có đúng ý chính không, có bỏ sót thời hạn không, có gán sai đơn vị không, có tạo thông tin không có trong tài liệu không, có dùng văn phong phù hợp hành chính không. Mỗi lỗi phải được ghi vào nhật ký để điều chỉnh prompt hoặc bổ sung tri thức.

Tuần 7–10: chạy thử, đo thời gian, đo lỗi và thu phản hồi

Giai đoạn chạy thử nên dùng dữ liệu thật nhưng đã loại bỏ hoặc ẩn thông tin nhạy cảm nếu cần. Mọi đầu ra của agent vẫn phải được con người duyệt trước khi sử dụng. Đây là lúc cơ quan đo giá trị thực tế, không chỉ đánh giá cảm tính. Nếu trước đây cán bộ mất 15 phút để tóm tắt một văn bản, pilot cần đo xem agent giúp giảm còn bao nhiêu phút sau khi tính cả thời gian kiểm duyệt. Nếu agent tạo báo cáo tuần, cần đo tỷ lệ nội dung phải chỉnh sửa và loại lỗi thường gặp.

Phản hồi người dùng rất quan trọng. Có những đầu ra đúng về nội dung nhưng không phù hợp thói quen hành chính; có những bản tóm tắt ngắn nhưng thiếu sắc thái điều hành; có những prompt cho kết quả tốt với văn bản đơn giản nhưng sai với văn bản nhiều phụ lục. Những phản hồi đó không nên coi là thất bại. Chúng là dữ liệu học tổ chức.

Trong tuần 7–10, nhóm pilot nên họp ngắn hằng tuần để xem báo cáo lỗi, điều chỉnh kho tri thức, sửa prompt, cập nhật checklist và ghi nhận bài học. Nếu phát hiện lỗi nghiêm trọng như tạo thông tin không có căn cứ, dùng sai dữ liệu, lộ thông tin nhạy cảm hoặc đề xuất vượt thẩm quyền, pilot phải dừng phần liên quan để rà soát.

Tuần 11–12: tổng kết, quyết định mở rộng hoặc điều chỉnh

Hai tuần cuối không nên chỉ viết báo cáo tổng kết hình thức. Đây là giai đoạn ra quyết định quản trị. Cơ quan cần trả lời bốn câu hỏi: pilot có đạt KPI không; rủi ro có nằm trong mức kiểm soát được không; người dùng có chấp nhận không; và điều kiện nào phải hoàn thiện trước khi mở rộng.

Có ba khả năng sau pilot. Khả năng thứ nhất là mở rộng có điều kiện: use case đạt KPI, lỗi nghiêm trọng bằng 0, người dùng chấp nhận và governance đủ rõ. Khi đó, có thể mở rộng sang đơn vị khác hoặc use case gần kề. Khả năng thứ hai là điều chỉnh và pilot lại: có giá trị nhưng dữ liệu chưa sạch, prompt chưa ổn hoặc quy trình kiểm duyệt còn chậm. Khả năng thứ ba là dừng use case: rủi ro cao hơn giá trị, dữ liệu không phù hợp hoặc không đo được hiệu quả.

Điều quan trọng là quyết định phải dựa trên bằng chứng. Báo cáo kết thúc pilot cần có số liệu trước – sau, danh sách lỗi, phản hồi người dùng, đánh giá rủi ro, bài học và đề xuất cụ thể. Nếu chỉ kết luận “AI hữu ích” hoặc “AI chưa tốt” thì pilot chưa hoàn thành nhiệm vụ quản trị.

Bộ KPI đề xuất cho pilot Agent OS hành chính công

KPI của pilot không nên quá nhiều. Nếu đặt quá nhiều chỉ số, nhóm pilot sẽ mất thời gian báo cáo thay vì học từ vận hành. Nên chọn một số KPI gắn với mục tiêu nghiệp vụ, chất lượng đầu ra, kiểm soát rủi ro và mức độ chấp nhận của người dùng.

Các ngưỡng trong bảng chỉ nên xem là tham khảo. Với cơ quan mới bắt đầu, giảm 15% thời gian nhưng loại bỏ được lỗi hướng dẫn và chuẩn hóa được kho tri thức cũng có thể là kết quả tốt. Với cơ quan đã có nền tảng dữ liệu tốt, ngưỡng có thể cao hơn. Điều quan trọng là KPI phải được thống nhất trước khi chạy thử.

Mẫu báo cáo kết thúc pilot

Báo cáo kết thúc pilot nên ngắn, rõ và có khả năng phục vụ quyết định. Không nên viết thành báo cáo dài nhưng thiếu số liệu. Một mẫu báo cáo tốt cần trả lời được câu hỏi: có nên mở rộng không, nếu có thì mở rộng với điều kiện gì?

Cấu trúc báo cáo có thể gồm 8 phần. Phần thứ nhất là thông tin chung: tên use case, đơn vị thực hiện, thời gian, phạm vi. Phần thứ hai là mục tiêu và KPI đã đặt. Phần thứ ba là mô tả Agent OS tối thiểu đã xây dựng: kho tri thức, prompt, quy trình, vai trò, nhật ký, kiểm duyệt. Phần thứ tư là kết quả định lượng: thời gian, lỗi, tỷ lệ duyệt, số tài liệu chuẩn hóa, phản hồi người dùng.

Phần thứ năm là kết quả định tính: điểm mạnh, điểm yếu, tình huống agent xử lý tốt, tình huống agent xử lý kém. Phần thứ sáu là đánh giá rủi ro: dữ liệu, pháp lý, nghiệp vụ, an toàn thông tin, trách nhiệm giải trình. Phần thứ bảy là bài học và điều kiện mở rộng. Phần cuối cùng là kiến nghị: mở rộng, điều chỉnh hoặc dừng.

Báo cáo này nên được trình bày trước lãnh đạo và các bên liên quan. Nếu quyết định mở rộng, báo cáo phải kèm danh sách việc cần hoàn thiện, người chịu trách nhiệm và thời hạn. Nếu quyết định dừng, báo cáo cũng có giá trị vì giúp cơ quan hiểu giới hạn hiện tại và tránh đầu tư sai hướng.

Vai trò triển khai: không giao hết cho CNTT

Một pilot Agent OS hành chính công cần tối thiểu 6 vai trò. Lãnh đạo cơ quan hoặc lãnh đạo đơn vị là người bảo trợ và chịu trách nhiệm cuối cùng. Chủ quy trình nghiệp vụ mô tả công việc, xác định tiêu chí đầu ra và kiểm tra giá trị thực tế. Pháp chế rà soát thẩm quyền, căn cứ và giới hạn sử dụng. CNTT thiết lập môi trường kỹ thuật, kết nối dữ liệu và bảo đảm vận hành. Văn phòng hoặc văn thư hỗ trợ chuẩn hóa tài liệu, quy trình văn bản, biểu mẫu và theo dõi nhiệm vụ. An toàn thông tin kiểm soát quyền truy cập, dữ liệu nhạy cảm, nhật ký và rủi ro bảo mật.

Nếu thiếu một trong các vai trò này, pilot vẫn có thể chạy về mặt kỹ thuật nhưng khó bền vững về mặt tổ chức. Đặc biệt, không nên giao toàn bộ cho CNTT. AI agent trong hành chính công không chỉ là bài toán kỹ thuật. Đó là bài toán nghiệp vụ, pháp lý, dữ liệu, kiểm soát và niềm tin.

Một cách làm hiệu quả là lập nhóm pilot nhỏ, họp định kỳ, ghi nhận quyết định ngắn gọn và lưu toàn bộ thay đổi vào nhật ký. Nhóm pilot không cần đông, nhưng phải có đủ quyền tiếp cận tài liệu, quyền xin ý kiến lãnh đạo và quyền dừng thử nghiệm khi phát hiện rủi ro.

Bắt đầu bằng thí điểm 90 ngày, không triển khai đại trà ngay

Nếu cơ quan đang cân nhắc Agent OS, khuyến nghị thực tế nhất là: đừng triển khai đại trà ngay. Hãy bắt đầu bằng một pilot 90 ngày với một use case ít rủi ro, ví dụ tóm tắt văn bản đến, theo dõi nhiệm vụ, tổng hợp báo cáo tuần, hỗ trợ tra cứu thủ tục hoặc chuẩn hóa biểu mẫu. Một pilot nhỏ nhưng được thiết kế đúng sẽ giúp cơ quan học nhanh hơn, kiểm soát tốt hơn và tạo bằng chứng rõ hơn cho quyết định mở rộng.

AIHanhChinhCong.vn có thể đồng hành cùng các cơ quan, địa phương và đơn vị chuyên môn trong việc tự đánh giá maturity, lựa chọn use case pilot, xây phiếu nhiệm vụ AI agent, chuẩn hóa kho tri thức, thiết kế KPI, lập báo cáo kết thúc pilot và xây lộ trình nâng năng lực Agent OS. Cách tiếp cận phù hợp với khu vực công không phải là “làm thật lớn ngay”, mà là làm nhỏ, làm chắc, đo được và có kiểm soát.

Câu hỏi “cơ quan hành chính đã sẵn sàng với Agent OS chưa?” không thể trả lời bằng cảm tính. Nó cần được trả lời bằng maturity model, checklist, KPI, vai trò và một kế hoạch pilot cụ thể. Agent OS chỉ tạo giá trị khi cơ quan có đủ nền tảng: kho tri thức được chuẩn hóa, quy trình được mô tả, dữ liệu được phân loại, vai trò được phân định, nhật ký được lưu và đầu ra được kiểm duyệt.

Pilot 90 ngày là cách phù hợp để chuyển từ nhận thức sang hành động. Nó đủ ngắn để không tạo gánh nặng lớn, nhưng đủ dài để kiểm chứng giá trị, phát hiện rủi ro và hình thành năng lực vận hành. Quan trọng hơn, pilot giúp cơ quan thay đổi tư duy: AI agent không phải công cụ mua về để dùng ngay, mà là một thành phần của hệ vận hành thông minh cần được thiết kế, quản trị và cải tiến liên tục.

Bài học cốt lõi là: đừng bắt đầu bằng triển khai đại trà. Hãy bắt đầu bằng một thí điểm Agent OS hành chính công trong 90 ngày, với một use case nhỏ, rõ, đo được và có kiểm soát. Nếu làm đúng, pilot không chỉ tạo ra một agent thử nghiệm, mà còn tạo ra năng lực tổ chức để bước vào giai đoạn AI agent an toàn, có trách nhiệm và đáng tin cậy hơn.

TS. Nguyễn Trung Hòa