Tổng quan kiến trúc tác nhân AI năm 2026: phân biệt giữa ứng dụng bọc LLM đơn giản và tác nhân tự chủ

Năm 2026, khái niệm trí tuệ nhân tạo dạng tác nhân (Agentic AI) được nhắc đến rộng rãi, nhưng không phải mọi ứng dụng gọi mô hình ngôn ngữ đều là tác nhân AI thực thụ. Một tác nhân AI đúng nghĩa sở hữu quyền tự chọn bước tiếp theo, sử dụng công cụ, quan sát kết quả và điều chỉnh linh hoạt trong một ranh giới được quản trị chặt chẽ. Quyền tự chủ giúp tăng tính thích ứng nhưng cũng làm tăng độ trễ, chi phí và khả năng sai số tích lũy; doanh nghiệp chỉ nên bổ sung tác nhân AI khi quy trình cố định hoặc một lệnh gọi mô hình kết hợp truy xuất dữ liệu không còn đáp ứng được yêu cầu của bài toán.

Rất nhiều doanh nghiệp thất vọng sau khi dùng thử ChatGPT vì bot chỉ dừng lại ở việc gợi ý câu trả lời mà không trực tiếp giải quyết được công việc trên các phần mềm nội bộ (như CRM, ERP hay Google Drive). Nguyên nhân cốt lõi là chatbot thiếu quyền truy cập vào công cụ thực thi và không sở hữu bộ nhớ ngữ cảnh dài hạn.

Bốn sai lầm khi đưa tác nhân AI vào vận hành chính thức

• ⦿Gắn nhãn tác nhân AI cho một lệnh gọi LLM đơn thuần không có vòng lặp hay công cụ hỗ trợ.
• ⦿Cấp thông tin đăng nhập và quyền truy cập quá rộng, dùng chung danh tính của người quản trị.
• ⦿Chỉ đánh giá câu trả lời cuối cùng mà không kiểm tra lệnh gọi công cụ và trạng thái trung gian.
• ⦿Không thiết lập điều kiện dừng, công tắc ngắt khẩn cấp (kill switch) và cơ chế chuyển giao cho con người xử lý.

Phân tích các mẫu thiết kế tác nhân AI phổ biến theo tài liệu kỹ thuật của Anthropic: nối chuỗi câu lệnh (prompt chaining) chia tác vụ thành chuỗi có điểm kiểm soát; phân luồng (routing) chuyển yêu cầu đến nhánh chuyên biệt; xử lý song song (parallelization) chạy các phần việc độc lập; mô hình điều phối và thực thi (orchestrator-worker) phân rã công việc; vòng lặp đánh giá và tối ưu (evaluator-optimizer) tạo cơ chế phản hồi liên tục. Đây là các mẫu thiết kế linh hoạt, không phải cấp độ trưởng thành bắt buộc. Kiến trúc hệ thống nên bắt đầu từ giải pháp đơn giản nhất và chỉ nâng cao quyền tự quyết khi quy trình đánh giá thực nghiệm chứng minh kết quả đầu ra cải thiện đủ để bù đắp cho độ trễ, chi phí và rủi ro vận hành.

Ranh giới đầu tiên là phân biệt rõ giữa ứng dụng bọc LLM (LLM wrapper), quy trình xử lý (workflow) và tác nhân AI (agent). Ứng dụng bọc LLM nhận đầu vào, có thể bổ sung dữ liệu truy xuất rồi tạo đầu ra trong một lượt gọi duy nhất hoặc theo chuỗi mã nguồn định sẵn. Quy trình tự động cho mô hình tham gia vào một số bước nhất định, nhưng lộ trình thực hiện, điểm kiểm soát và điều kiện kết thúc đều do phần mềm quyết định từ trước. Tác nhân AI nhận mục tiêu và chủ động lựa chọn bước tiếp theo hoặc công cụ dựa trên trạng thái quan sát được từ môi trường. Một ứng dụng có khả năng gọi công cụ (tool calling) chưa chắc đã là tác nhân AI nếu mã nguồn vẫn chỉ định chính xác công cụ nào được chạy và theo thứ tự cố định nào. Việc phân loại chuẩn xác giúp đội ngũ kỹ thuật xác định đúng kỳ vọng, xây dựng kế hoạch kiểm thử và thiết lập các biện pháp kiểm soát tương xứng.

Vòng lặp tác nhân AI (agent loop) tối thiểu bao gồm: trạng thái mục tiêu, bộ lập kế hoạch hoặc chính sách lựa chọn hành động, bộ thực thi công cụ, kết quả quan sát từ môi trường và điều kiện dừng. Trạng thái hệ thống bắt buộc phải tách biệt dữ liệu đã xác minh khỏi các suy luận của mô hình; kết quả quan sát trả về từ công cụ cần có cấu trúc dữ liệu chuẩn hóa và nguồn gốc rõ ràng; các lỗi phát sinh từ công cụ phải được phân loại chuẩn xác để tác nhân không coi thông báo lỗi kỹ thuật là dữ liệu nghiệp vụ. Điều kiện dừng hoàn chỉnh bao gồm: hoàn tất công việc kèm bằng chứng xác thực, chạm giới hạn số bước cho phép, cạn ngân sách, hết thời gian chờ (timeout), bị chính sách an toàn ngăn chặn hoặc có yêu cầu can thiệp từ con người. Tuyệt đối không để chính mô hình làm cơ chế duy nhất tự xác nhận nó đã hoàn thành nhiệm vụ, nhất là với các tác vụ có kết quả kiểm tra được bằng mã lệnh hay truy vấn nguồn dữ liệu.

Thiết kế công cụ đóng vai trò là giao diện tương tác giữa tác nhân AI và máy tính. Mỗi công cụ cần có tên gọi cùng phần mô tả rõ ràng, cấu trúc đầu vào giới hạn chặt chẽ kiểu dữ liệu và miền giá trị, đầu ra phân biệt rành mạch giữa dữ liệu hợp lệ và thông báo lỗi, kèm tài liệu nêu rõ tác dụng phụ và ví dụ sử dụng chuẩn xác. Một công cụ quá lớn gộp nhiều chức năng sẽ làm mờ ranh giới phân quyền; ngược lại công cụ quá nhỏ lại buộc tác nhân phải lập chuỗi gọi lệnh kéo dài rất dễ mắc sai sót. Một thao tác tạo bản nháp phải tách bạch rõ ràng với thao tác gửi đi hoặc phê duyệt. Máy chủ luôn phải xác thực lại mọi tham số, không tin tưởng mù quáng vào chuỗi JSON do mô hình tạo ra. Khóa chống xử lý trùng (idempotency key), giới hạn thời gian chờ, chính sách thử lại và siêu dữ liệu ghi vết kiểm tra là những yêu cầu bắt buộc khi vận hành chính thức, chứ không phải chi tiết bổ sung sau buổi giới thiệu thử nghiệm.

Đánh giá mức độ phù hợp của tác vụ phải luôn đi trước quyết định lựa chọn khung công nghệ. Tác nhân AI chỉ thực sự phù hợp khi lộ trình xử lý không thể lường trước toàn bộ, cần nhiều vòng thu thập bằng chứng, môi trường cung cấp phản hồi đáng tin cậy và tiêu chí hoàn tất có thể kiểm tra định lượng. Quy trình làm việc tất định sẽ phù hợp hơn khi thứ tự các bước đã ổn định, chính sách rõ ràng và phát sinh rất ít ngoại lệ. Một lệnh gọi mô hình ngôn ngữ lớn kết hợp truy xuất dữ liệu là hoàn toàn đủ dùng nếu đầu ra chỉ đơn thuần là phân loại, trích xuất thông tin hoặc soạn thảo bản nháp. Những bài toán thiếu căn cứ dữ liệu chuẩn xác thực tế (ground truth), để lại hậu quả khó đảo ngược hoặc đòi hỏi quyền hạn can thiệp quá rộng tuyệt đối không nên là điểm khởi đầu. Nhóm dự án cần lập danh mục tác vụ, đo lường khối lượng công việc, mức độ biến thiên, chất lượng dữ liệu, khả năng kiểm thử trong môi trường cô lập (sandbox), mức độ tác động và chi phí con người tham gia kiểm duyệt. Quyết định áp dụng tác nhân AI phải chỉ ra lợi ích tăng thêm rõ rệt so với mốc đo ban đầu đơn giản; nếu tác nhân AI chỉ tạo cảm giác hiện đại nhưng làm tăng độ trễ, lỗi phát sinh và chi phí cao hơn mà kết quả thực tế không cải thiện, kiến trúc chuẩn xác nhất là quay về với quy trình tự động hóa truyền thống.

Thang đo mức độ tự chủ nên được định nghĩa chặt chẽ theo quyền hạn hành động thực tế chứ không theo ngôn từ quảng bá tiếp thị. Cấp hỗ trợ chỉ dừng lại ở việc đề xuất giải pháp và người dùng tự tay thực hiện. Cấp soạn thảo tạo ra các sản phẩm đầu ra (artifact) nhưng chưa được phép tự động phát hành. Cấp thực thi có giới hạn được phép gọi một nhóm công cụ cụ thể trong phạm vi dữ liệu, hạn mức ngân sách và thời gian xác định. Cấp điều phối có khả năng tự phân rã nhiệm vụ và lựa chọn trình tự thực hiện nhưng vẫn bị chính sách kiểm tra nghiêm ngặt từng hành động. Cấp tự chủ cao có thể vận hành trong thời gian dài hơn hoặc phối hợp với các tác nhân AI khác, song chỉ phù hợp trong môi trường tin cậy với kết quả đầu ra kiểm chứng được. Mỗi cấp độ phải ghi rõ dữ liệu được phép đọc, tác động phụ trợ được chấp nhận, hạn mức chi phí, yêu cầu phê duyệt, phương án hoàn tác và người phụ trách quy trình. Việc nâng cấp quyền tự chủ phải dựa trên bằng chứng đánh giá thực nghiệm cùng lịch sử vận hành an toàn, không thể tự động cấp quyền chỉ vì mô hình mới ra mắt được quảng cáo mạnh hơn. Khi xuất hiện sự cố hoặc hiện tượng lệch lạc hành vi, hệ thống cần có cơ chế hạ cấp hàng loạt quyền hạn về chế độ đề xuất mà không phải viết lại toàn bộ ứng dụng.

Lập kế hoạch (planning) không nhất thiết là một chuỗi suy nghĩ dài dòng được lưu trữ và hiển thị cho người dùng. Trong môi trường vận hành chính thức, kế hoạch hành động nên là một cấu trúc tác vụ ngắn gọn bao gồm: mục tiêu, các bước dự kiến, mối quan hệ phụ thuộc, công cụ cần dùng, tiêu chí hoàn tất và điểm bắt buộc phải hỏi ý kiến con người. Với nhiệm vụ quen thuộc, việc áp dụng mẫu kế hoạch định sẵn giúp giảm thiểu sự biến thiên. Với nhiệm vụ mở, bộ lập kế hoạch sẽ tạo đồ thị các bước, sau đó bộ kiểm tra hợp lệ tất định sẽ rà soát sự tồn tại của công cụ, quyền hạn truy cập, vòng lặp vô tận, ngân sách và các bước tiềm ẩn rủi ro. Bản kế hoạch luôn được quản lý phiên bản vì kết quả quan sát mới từ môi trường có thể làm thay đổi lộ trình di chuyển. Việc lập lại kế hoạch cần lý do rõ ràng như công cụ báo lỗi, giả định ban đầu bị bác bỏ hoặc có nguồn dữ liệu mới; nếu mô hình liên tục viết lại kế hoạch mà không thúc đẩy tiến độ thực tế, cơ chế giám sát tự động (watchdog) phải dừng ngay tác vụ. Tuyệt đối không lưu chuỗi suy luận từng bước (chain-of-thought) nhạy cảm làm bằng chứng; thay vào đó, hãy lưu bản tóm tắt quyết định, lệnh gọi công cụ kèm tham số và các nguồn quan sát có thể kiểm chứng độc lập. Cách tiếp cận này giúp gỡ lỗi hệ thống mà không bị nhầm lẫn giữa lời giải thích suông của mô hình với nguyên nhân vật lý thực tế của hành động.

Máy trạng thái (state machine) là lớp phần mềm điều phối đáng tin cậy bao bọc xung quanh mô hình AI. Các trạng thái nghiệp vụ có thể bao gồm: đã tiếp nhận (requested), đã làm rõ (clarified), đã lập kế hoạch (planned), chờ phê duyệt (awaiting approval), đang thực thi (executing), đang kiểm chứng (verifying), hoàn thành (completed), thất bại (failed), đã hủy (cancelled) và chuyển cấp xử lý (escalated). Việc chuyển đổi trạng thái do các sự kiện có cấu trúc dữ liệu chuẩn kích hoạt, đi kèm định danh tác nhân kích hoạt, thời điểm chính xác và mã liên kết tương quan (correlation ID). Mô hình có thể đề xuất bước chuyển trạng thái, nhưng dịch vụ hệ thống mới là nơi kiểm tra đầy đủ các điều kiện. Toàn bộ trạng thái được lưu trữ bền vững bên ngoài cửa sổ ngữ cảnh để khôi phục nguyên vẹn sau khi khởi động lại, tránh phụ thuộc vào trí nhớ hội thoại tạm thời. Với các tác vụ kéo dài, điểm kiểm tra lưu vết (checkpoint) sẽ ghi nhận sản phẩm đầu ra, kết quả thực thi công cụ và các bước đã cam kết; khi tiếp tục thực hiện, hệ thống không chạy lại các hành động có tác động phụ ngoài ý muốn. Phiên bản cấu trúc trạng thái phải đảm bảo tương thích với quy trình đang vận hành. Một tác nhân AI thực chất thường là sự kết hợp chặt chẽ giữa khả năng suy luận xác suất của mô hình và máy trạng thái tất định của phần mềm: mô hình xử lý phần ngôn ngữ mơ hồ, còn hệ thống bảo đảm quyền hạn, tính nhất quán và khả năng phục hồi khi gặp sự cố. Nếu mọi trạng thái chỉ nằm trong câu lệnh prompt, đội ngũ vận hành không thể biết công việc đang dừng ở đâu hay làm thế nào để dừng an toàn tại một bước cụ thể.

Bộ nhớ của tác nhân AI cần được phân chia rành mạch theo mục đích sử dụng và vòng đời lưu trữ. Bộ nhớ làm việc (working memory) lưu giữ dữ liệu của nhiệm vụ đang xử lý; bộ nhớ tình tiết (episodic memory) ghi lại các sự kiện đã diễn ra; bộ nhớ ngữ nghĩa (semantic memory) chứa tri thức đã được xác minh; bộ nhớ tùy chọn (preference memory) lưu trữ các thiết lập được người dùng cho phép; bộ nhớ quy trình (procedural memory) mô tả cách thức thực hiện và chính sách tuân thủ. Không phải mọi đoạn hội thoại trao đổi đều xứng đáng được đưa vào bộ nhớ dài hạn. Hành vi ghi vào bộ nhớ là một thao tác chịu sự chi phối nghiêm ngặt của chính sách: phải xác định rõ nguồn gốc, người sở hữu, mức độ tin cậy, cấp độ phân loại dữ liệu, thời hạn lưu giữ, quyền yêu cầu xóa và phạm vi tái sử dụng. Dữ liệu cá nhân hoặc bí mật kinh doanh tuyệt đối không được tự tiện ghi lại chỉ vì mô hình phỏng đoán rằng nó sẽ hữu ích. Quá trình truy xuất dữ liệu từ bộ nhớ phải áp dụng đúng quyền hạn của người đang ủy quyền cho tác nhân, tránh tình trạng tác nhân ghi nhớ và vô tình tiết lộ thông tin nhạy cảm từ các phiên làm việc của người dùng khác. Mỗi mục dữ liệu trong bộ nhớ cần có nguồn gốc xuất xứ và ngày rà soát định kỳ; nội dung suy diễn chủ quan phải được tách biệt hoàn toàn khỏi dữ kiện thực tế. Quá trình cô đọng tri thức (consolidation) có thể tóm tắt các chuỗi sự kiện, song bản tóm tắt đó bắt buộc phải được kiểm tra tính xác thực trước khi sử dụng cho các quyết định nghiệp vụ quan trọng.

Kỹ thuật tối ưu ngữ cảnh (context engineering) quyết định chính xác những gì mô hình AI nhìn thấy ở từng bước thực thi. Ngữ cảnh chỉ nên chứa: mục tiêu hiện tại, chính sách liên quan, các công cụ cần thiết, kết quả quan sát mới nhất và lượng bằng chứng tối thiểu; việc nhồi nhét toàn bộ lịch sử vào mọi lượt xử lý vừa gây lãng phí chi phí token, vừa làm tăng độ nhiễu và nguy cơ bị tấn công chèn lệnh (prompt injection). Bộ dựng ngữ cảnh (context builder) cần chủ động lọc dữ liệu theo quyền hạn truy cập, tính cập nhật thời gian, mức độ liên quan và phân tầng tin cậy. Mọi nội dung do người dùng nhập vào, trang web trích xuất hay công cụ bên ngoài trả về đều phải được gắn nhãn là dữ liệu không đáng tin cậy, tuyệt đối không được ghép lẫn vào phần chỉ dẫn hệ thống (system instruction). Khi dung lượng ngữ cảnh chạm ngưỡng giới hạn, hệ thống cần ưu tiên giữ lại các sản phẩm đầu ra có cấu trúc và tham chiếu nguồn xác thực thay vì sử dụng kỹ thuật tóm tắt mù quáng. Quá trình nén ngữ cảnh bắt buộc phải bảo toàn các quyết định đã đưa ra, các ràng buộc kỹ thuật và những lỗi chưa được giải quyết. Bản chụp ngữ cảnh (context snapshot) cần được gắn chặt với nhật ký truy vết để phục vụ việc tái hiện đánh giá, song các bản ghi nhật ký phải được che chắn thông tin nhạy cảm. Chất lượng của tác nhân không chỉ phụ thuộc vào mô hình; ngay cả một mô hình tiên tiến nhất nếu phải làm việc với ngữ cảnh sai lệch, lỗi thời hoặc bị lẫn chỉ dẫn độc hại thì vẫn sẽ đưa ra những kế hoạch hành động tồi tệ.

Định danh (identity) của tác nhân AI phải trả lời dứt khoát ba câu hỏi cốt lõi: tác nhân nào đang hành động, hành động thay mặt ai và trong phạm vi ủy quyền cụ thể nào. Mỗi tác nhân phải sở hữu một định danh khối lượng công việc (workload identity) riêng biệt; mỗi phiên làm việc phải được liên kết chặt chẽ với người dùng hoặc dịch vụ yêu cầu; mã xác thực ủy quyền (delegation token) phải chỉ định rõ đối tượng thụ hưởng, phạm vi quyền hạn, mục đích sử dụng, hạn mức chi tiêu và thời hạn hiệu lực. Tuyệt đối không dùng chung một khóa API quản trị cho toàn bộ hệ thống tác nhân AI. Khi tác nhân gọi công cụ, cổng kiểm soát (gateway) phải xác thực đồng thời cả định danh của tác nhân lẫn quyền hạn thực tế của chủ thể được đại diện. Những thao tác nghiệp vụ quan trọng không được phép ủy quyền bắt buộc phải yêu cầu người có thẩm quyền tương tác trực tiếp. Chuỗi ủy quyền phải được ghi nhận đầy đủ nhằm đảm bảo tính chống chối bỏ (non-repudiation): hệ thống luôn có thể truy vết chính xác ai là người khởi tạo yêu cầu, tác nhân nào lập kế hoạch, công cụ nào thực thi và ai là người phê duyệt. Khi nhân sự thay đổi vai trò hoặc nghỉ việc, toàn bộ mã ủy quyền và các tác vụ dài hạn liên quan phải lập tức bị thu hồi. Đây là nền tảng tối quan trọng để tác nhân AI vận hành như một thực thể máy có trách nhiệm giải trình rõ ràng, chứ không phải là một đoạn mã tự động ẩn danh.

Phân quyền (authorization) cần được kiểm tra nghiêm ngặt ngay tại thời điểm phát sinh hành động, chứ không chỉ xác thực một lần lúc bắt đầu phiên làm việc. Chính sách bảo mật có thể kết hợp giữa kiểm soát truy cập dựa trên vai trò (RBAC) cho các vị trí công việc ổn định, dựa trên thuộc tính (ABAC) cho đặc tính dữ liệu, và dựa trên mối quan hệ (ReBAC) cho các quan hệ thực tế như chủ sở hữu hồ sơ hoặc thành viên dự án. Cổng công cụ (tool gateway) tiếp nhận thông tin về hành động dự kiến, tài nguyên mục tiêu, chủ thể yêu cầu, mục đích sử dụng, môi trường thực thi cùng tín hiệu rủi ro, sau đó trả về quyết định cho phép, từ chối hoặc yêu cầu phê duyệt từ con người. Mô hình AI tuyệt đối không được tự ý diễn giải hay bỏ qua chính sách. Đối với các truy vấn dữ liệu, bộ lọc phân quyền phải được áp dụng trực tiếp tại nguồn dữ liệu hoặc tầng ngữ nghĩa; việc chỉ ẩn nút bấm trên giao diện người dùng hoàn toàn không phải là biện pháp kiểm soát an ninh. Đối với các hành động gây tác động phụ trợ, chính sách phải kiểm tra kỹ giá trị giao dịch, đối tượng tiếp nhận, khung giờ thực thi và tần suất gọi lệnh. Mọi quyết định chính sách đều phải được ghi nhật ký kèm theo phiên bản chính sách để phục vụ giải trình sau này. Nguyên tắc mặc định từ chối (default deny) là bắt buộc đối với mọi công cụ mới tích hợp; các quyền cấp tạm thời phải tự động hết hiệu lực sau thời gian quy định. Hoạt động rà soát quyền hạn cần xem xét toàn diện cả quyền trực tiếp, quyền kế thừa và các thông tin đăng nhập do tác nhân lưu giữ. Một tác nhân AI dù chỉ sở hữu số lượng công cụ rất ít nhưng mỗi công cụ lại chạy bằng tài khoản quản trị toàn quyền thì hoàn toàn vi phạm nguyên tắc quyền tối thiểu (least privilege).

Môi trường cô lập (sandbox) giúp khoanh vùng phạm vi ảnh hưởng thiệt hại trong giai đoạn phát triển và đối với cả các tác vụ tiềm ẩn rủi ro cao. Môi trường kiểm thử nên sử dụng dữ liệu tổng hợp hoặc dữ liệu đã được khử định danh, các tài khoản giả lập, danh sách trắng các tên miền mạng được phép kết nối và hạn mức sử dụng thấp. Hệ thống tập tin tạm thời phải được tách biệt hoàn toàn, các tiến trình xử lý cần có giới hạn cụ thể về CPU, dung lượng bộ nhớ, thời gian chạy và các lệnh gọi hệ thống khi cần thiết. Công cụ duyệt web hoặc thực thi mã lệnh tuyệt đối không được phép có đường kết nối tự do tới dịch vụ siêu dữ liệu hạ tầng, kho lưu trữ khóa bí mật hay mạng nội bộ của doanh nghiệp. Các sản phẩm đầu ra khi chuyển từ môi trường cô lập sang môi trường vận hành chính thức bắt buộc phải trải qua quy trình kiểm tra hợp lệ và phê duyệt chặt chẽ, không bao giờ được tự động phát hành. Việc triển khai thử nghiệm cho một nhóm nhỏ (canary) giúp theo dõi sát sao hành vi thực tế trước khi phát hành diện rộng. Môi trường cô lập không thể thay thế cho cơ chế phân quyền: một môi trường cách ly nghiêm ngặt vẫn có thể làm rò rỉ dữ liệu nếu đầu vào bị lẫn thông tin bí mật. Đội ngũ kiểm thử an ninh chuyên sâu (red-team) phải chủ động thử nghiệm các kịch bản vượt rào cách ly, trích xuất dữ liệu trái phép, làm cạn kiệt tài nguyên hệ thống và kết hợp nhiều công cụ để lách qua chính sách kiểm soát. Mục tiêu cốt lõi là khi tác nhân AI mắc sai sót, hậu quả luôn được giới hạn ở mức tối thiểu và hệ thống có đầy đủ bằng chứng để phân tích nguyên nhân gốc rễ.

Tấn công chèn câu lệnh gián tiếp (indirect prompt injection) xảy ra khi tác nhân AI đọc phải các nội dung chứa chỉ dẫn độc hại nhằm làm thay đổi hành vi dự kiến, chẳng hạn như nội dung email, trang web, tài liệu đính kèm hoặc kết quả trả về từ công cụ. Tuyến phòng vệ đầu tiên bắt đầu bằng việc tách biệt rạch ròi giữa câu lệnh điều khiển và dữ liệu đầu vào, gắn nhãn mức độ tin cậy và kiên quyết không cho phép nội dung bên ngoài ghi đè lên chính sách an toàn của hệ thống. Kết quả đầu ra của công cụ phải được phân tích cú pháp theo cấu trúc dữ liệu chuẩn; các đoạn văn bản tự do chỉ được xem là dữ liệu thô phục vụ phân tích chứ không bao giờ được coi là mệnh lệnh thực thi. Động cơ chính sách an toàn phải ngăn chặn kịp thời mọi hành động nguy hiểm, bất kể mô hình AI có đưa ra lời giải thích hợp lý đến mức nào. Quá trình truy xuất dữ liệu phải lọc nguồn thông tin theo quyền hạn truy cập và nguồn gốc xuất xứ rõ ràng. Với các tác vụ duyệt web, tác nhân AI không được đồng thời nắm giữ khóa bí mật hoặc các công cụ có phạm vi tác động phụ rộng lớn nếu không thật sự cần thiết. Các giải pháp phát hiện có thể đưa ra cảnh báo về mẫu hành vi bất thường, nhưng không được coi là lớp phòng vệ duy nhất. Bộ dữ liệu kiểm thử cần bao gồm các kịch bản chèn lệnh đa ngôn ngữ, ẩn giấu tinh vi trong mã định dạng, tài liệu đính kèm và các chuỗi tấn công nhiều bước. Khi phát hiện dấu hiệu bất thường, hệ thống cần lập tức lưu giữ sản phẩm đầu ra làm bằng chứng, tạm dừng nhánh xử lý bị ảnh hưởng và chuyển giao ngay cho con người xử lý, thay vì để mô hình tự tranh luận đối kháng với nội dung độc hại.

Tầng điều khiển (control plane) chịu trách nhiệm quản lý danh mục tác nhân, các phiên bản câu lệnh chỉ dẫn, mô hình, công cụ, chính sách an toàn, dữ liệu đánh giá, tham chiếu khóa bí mật và quy trình phát hành. Tầng dữ liệu (data plane) chịu trách nhiệm thực thi tác vụ, truy xuất dữ liệu và gọi công cụ trong phạm vi quyền hạn được cấp phát. Việc tách rời hai tầng kiến trúc này giúp tổ chức dễ dàng điều chỉnh chính sách kiểm soát mà không cần can thiệp vào logic nghiệp vụ, đồng thời ngăn chặn môi trường thực thi tự ý thay đổi cấu hình bảo mật. Mọi phiên bản tác nhân AI đều phải có bản kê khai (manifest) đầy đủ: người phụ trách, mục đích nghiệp vụ, phân tầng rủi ro, loại mô hình, bộ công cụ tích hợp, phân loại dữ liệu, hạn mức ngân sách, người phê duyệt, bộ kiểm thử nghiệm thu và ngày rà soát định kỳ. Quá trình triển khai phải ký số các sản phẩm đầu ra và chỉ cho phép những phiên bản đã qua phê duyệt được vận hành chính thức. Cơ chế cờ tính năng (feature flag) hỗ trợ triển khai thử nghiệm diện hẹp và quay về phiên bản trước nhanh chóng khi cần. Khóa bí mật không bao giờ được đặt trong câu lệnh prompt hay bản kê khai, mà phải được cấp phát động cho cổng công cụ. Tầng điều khiển cũng cung cấp danh mục kiểm kê toàn diện để trả lời tức thì các câu hỏi: hiện có những tác nhân nào đang hoạt động, ai chịu trách nhiệm giải trình và tác nhân nào đang khai thác nguồn dữ liệu cụ thể. Việc thiếu vắng danh mục kiểm kê sẽ khiến doanh nghiệp không thể thu hồi quyền hạn kịp thời khi đầu nối tích hợp, mô hình AI hoặc nhà cung cấp gặp sự cố an ninh.

Kỹ thuật nối chuỗi câu lệnh (prompt chaining) đặc biệt phù hợp khi một tác vụ lớn có thể phân rã thành các bước xử lý ổn định và từng bước đều có thể kiểm tra độc lập. Ví dụ như quy trình tiếp nhận hồ sơ, trích xuất các trường thông tin, kiểm tra cấu trúc dữ liệu, đối chiếu danh mục và tạo bản thảo sơ bộ. Điểm kiểm soát giữa các bước có thể là đoạn mã tất định hoặc bộ đánh giá bằng mô hình AI tùy thuộc vào tính chất tiêu chí; các tiêu chí định lượng nên được ưu tiên kiểm tra bằng mã lệnh. Mỗi bước chỉ nên nạp lượng ngữ cảnh tối thiểu và yêu cầu cấu trúc đầu ra rõ ràng, giúp đội ngũ nhanh chóng khoanh vùng vị trí phát sinh lỗi. Nếu bước xử lý phía trước không đạt yêu cầu, quy trình tuyệt đối không cố chấp tiếp tục nhằm che giấu sai sót. Việc nối chuỗi câu lệnh làm tăng độ trễ tổng thể, do đó chỉ nên tách bước khi hành động này thực sự nâng cao chất lượng hoặc khả năng kiểm soát. Các phần việc độc lập có thể chạy song song rồi mới tổng hợp kết quả. Khi lộ trình xử lý đã được định hình rõ ràng từ trước, việc gọi đây là một quy trình tự động (workflow) thay vì tác nhân AI sẽ giúp đội ngũ tránh cấp phát quyền tự quyết không cần thiết. Quy trình tự động vẫn hoàn toàn có thể tận dụng sức mạnh của các mô hình ngôn ngữ lớn và công cụ chuyên dụng, song mang lại hành vi vận hành có độ dự đoán chính xác cao hơn nhiều.

Cơ chế phân luồng (routing) sử dụng bộ phân loại để lựa chọn mô hình, câu lệnh chỉ dẫn, quy trình xử lý hoặc đội ngũ nhân sự tiếp nhận phù hợp. Bộ phân luồng cần có hệ thống phân loại rõ ràng, không bị chồng chéo quá mức, kèm ngưỡng tin cậy xác định và phương án dự phòng khi độ chắc chắn thấp. Bộ dữ liệu kiểm thử phải phản ánh đúng thực tế vận hành, bao gồm các yêu cầu đa ý định, ngôn ngữ đời thường, dữ liệu thiếu sót và cả những đầu vào đối kháng. Nếu kết quả phân luồng quyết định đến quyền hạn tiếp cận dữ liệu, bộ phân loại tuyệt đối không được coi là lớp phân quyền chính thức; chính sách an toàn vẫn bắt buộc phải kiểm tra lại quyền hạn sau khi phân luồng hoàn tất. Bộ phân luồng có thể ưu tiên sử dụng mô hình nhỏ gọn cho các tác vụ đơn giản và chuyển sang mô hình tiên tiến cho các ca xử lý phức tạp, song mọi sự thay đổi đều phải được đánh giá thực nghiệm riêng biệt cho từng luồng. Hiện tượng lệch lạc hành vi có thể xuất hiện khi sản phẩm kinh doanh hoặc thói quen người dùng thay đổi, do đó ma trận nhầm lẫn và tỷ lệ kích hoạt phương án dự phòng cần được theo dõi liên tục. Một bộ phân luồng gặp sự cố có thể âm thầm chuyển dữ liệu nhạy cảm đến các quy trình xử lý không đủ điều kiện an toàn; nhật ký truy vết bắt buộc phải lưu trữ quyết định phân luồng, điểm tin cậy, phiên bản mô hình và lý do lựa chọn có cấu trúc rõ ràng.

Xử lý song song (parallelization) rút ngắn thời gian cho các tác vụ con độc lập hoặc thu thập nhiều góc đánh giá, nhưng làm tăng chi phí và độ phức tạp khi tổng hợp. Phân nhánh (fan-out) cần giới hạn số nhánh, ngân sách và thời gian chờ; gom nhánh (fan-in) phải xử lý các nhánh bị thiếu, mâu thuẫn hay trùng lặp. Không nên coi ý kiến đa số của mô hình là sự thật nếu tất cả đều dùng chung dữ liệu sai. Trong rà soát, mỗi tác nhân thực thi có tiêu chí và vai trò khác nhau; bộ tổng hợp trích xuất bằng chứng thay vì chỉ chọn câu trả lời tự tin nhất. Thao tác có tác động phụ không chạy song song nếu thứ tự hoặc khóa dữ liệu quan trọng. Mã liên kết (correlation ID) kết nối mọi nhánh, và tín hiệu hủy lệnh truyền xuống ngay khi tác vụ chính dừng. Kết quả từng nhánh cần ghi rõ nguồn gốc và độ tươi mới của dữ liệu. Đội ngũ nên đối chuẩn lợi ích giảm độ trễ so với chi phí thực tế; đôi khi một truy vấn theo lô hoặc đoạn mã xử lý vector hóa lại tốt hơn nhiều tác nhân chạy đồng thời.

Mô hình điều phối và thực thi (orchestrator-worker) đặc biệt hữu ích khi một nhiệm vụ lớn bao gồm nhiều phần việc có thể phân công linh hoạt. Bộ điều phối sẽ thiết lập hợp đồng tác vụ rõ ràng cho từng tác nhân thực thi: mục tiêu cụ thể, dữ liệu đầu vào, cấu trúc dữ liệu đầu ra, phạm vi công cụ được phép dùng, hạn mức ngân sách, thời hạn hoàn thành và các bài kiểm tra nghiệm thu. Tác nhân thực thi tuyệt đối không được tự ý mở rộng mục tiêu nhiệm vụ hoặc chuyển giao thông tin đăng nhập cho tác nhân khác. Kết quả hoàn thành phải được gửi về dưới dạng sản phẩm đầu ra có cấu trúc kèm đầy đủ bằng chứng xác thực; bộ điều phối sẽ kiểm tra tính hợp lệ trước khi tích hợp vào kết quả chung. Nếu tác nhân thực thi thất bại, việc thử lại chỉ được thực hiện khi xác định đó là lỗi tạm thời và thao tác không gây tác động phụ nguy hiểm; nếu không, hệ thống phải lập lại kế hoạch hoặc chuyển cấp xử lý cho con người. Bộ điều phối không nên biến thành một siêu tác nhân nắm giữ toàn bộ quyền hạn. Cổng công cụ vẫn phải cấp quyền tối thiểu theo từng tác vụ riêng biệt, và các hành động có mức độ ảnh hưởng lớn bắt buộc phải thông qua phê duyệt độc lập. Khi số lượng tác nhân thực thi gia tăng, nguy cơ phát sinh vòng lặp vô tận, tắc nghẽn khóa chết và bùng nổ chi phí sẽ tăng lên tương ứng, do đó bộ lập lịch cần thiết lập giới hạn xử lý đồng thời cùng đồ thị phụ thuộc rõ ràng. Kiến trúc đa tác nhân chỉ thực sự mang lại giá trị khi tính chuyên môn hóa hoặc khả năng xử lý song song có thể đo lường định lượng được; việc chỉ đơn thuần biến đổi một câu lệnh prompt thành nhiều nhân vật giả lập khác nhau không thể tự tạo ra độ tin cậy cho hệ thống.

Mô hình đánh giá và tối ưu (evaluator-optimizer) thiết lập một vòng lặp liên tục, trong đó một thành phần đảm nhận việc sinh kết quả và thành phần còn lại chấm điểm theo bảng tiêu chí chuẩn rồi yêu cầu chỉnh sửa nếu chưa đạt. Bảng tiêu chí cần dựa trên các chỉ số có thể quan sát định lượng được như: trích dẫn đầy đủ nguồn gốc, đúng cấu trúc dữ liệu quy định, bao quát trọn vẹn yêu cầu nghiệp vụ, không chứa dữ liệu cấm và vượt qua các bài kiểm thử đơn vị. Nếu bộ đánh giá chỉ dùng một mô hình AI đơn lẻ với câu lệnh chung chung, nó rất dễ rơi vào bẫy đồng thuận với chính sai sót của bộ sinh kết quả. Việc kết hợp chặt chẽ giữa kiểm tra bằng mã lệnh, xác minh truy xuất dữ liệu nguồn, mô hình giám khảo đã qua hiệu chuẩn và lấy mẫu kiểm duyệt bởi con người sẽ mang lại độ chuẩn xác cao hơn nhiều. Vòng lặp phải được giới hạn số lần thử tối đa và tự động dừng lại khi mức độ cải thiện không còn đáng kể. Mọi phiên bản chỉnh sửa đều phải lưu giữ sự khác biệt (diff) và phản hồi chi tiết để phục vụ phân tích. Tuyệt đối không dùng bộ đánh giá để hợp thức hóa cho những hành động sai phạm đã diễn ra; các thao tác có tác động phụ ngoài hệ thống chỉ được phép thực thi sau khi sản phẩm đầu ra vượt qua điểm kiểm soát an toàn. Điểm số của mô hình giám khảo cần được kiểm tra đối chiếu định kỳ với đánh giá của chuyên gia con người, đặc biệt là mỗi khi nâng cấp mô hình. Quá trình tối ưu hóa phải luôn hướng đến kết quả thực tế của bài toán nghiệp vụ, chứ không đơn thuần chỉ nhằm nâng cao một điểm số lý thuyết dễ bị thao túng.

Giao tiếp đa tác nhân (multi-agent communication) đòi hỏi giao thức chuẩn hóa và ranh giới trách nhiệm rõ ràng. Mỗi phong bì thông điệp cần chứa đầy đủ các trường: bên gửi, bên nhận, mã tác vụ, ý định hành động, phiên bản cấu trúc dữ liệu, tham chiếu bằng chứng, thời hạn xử lý và cấp độ phân loại dữ liệu. Tác nhân tiếp nhận không được mặc định tin tưởng nội dung chỉ vì bên gửi là một tác nhân nội bộ khác; chính sách kiểm soát và quy trình kiểm tra tính hợp lệ vẫn bắt buộc phải áp dụng đầy đủ. Bộ nhớ dùng chung rất dễ dẫn đến rò rỉ dữ liệu chéo giữa các luồng xử lý, do đó nên ưu tiên sử dụng kho lưu trữ sản phẩm đầu ra có danh sách kiểm soát quyền truy cập (ACL) và cơ chế dẫn chiếu, thay vì quảng bá toàn bộ ngữ cảnh một cách tùy tiện. Trách nhiệm sở hữu tác vụ tuyệt đối không được mơ hồ: phải có một tác nhân chịu trách nhiệm tổng hợp cuối cùng, và một nhân sự hoặc dịch vụ có thẩm quyền phê duyệt dứt khoát. Hệ thống cần trang bị cơ chế tự động phát hiện vòng lặp chuyển giao việc, công việc bị trùng lặp và xung đột dữ liệu. Giao thức tương tác giữa các tác nhân (A2A) hoặc các giao thức mở tương tự có thể chuẩn hóa việc khám phá dịch vụ và truyền tải thông điệp, song không thể thay thế cho hệ thống định danh, cơ chế phân quyền hay các cam kết nghiệp vụ. Tại nhiều doanh nghiệp SME, mô hình một bộ điều phối kết hợp với các công cụ chuyên dụng thường đơn giản, tiết kiệm chi phí và dễ vận hành hơn nhiều so với một mạng lưới tác nhân ngang hàng (peer-to-peer). Chỉ nên cân nhắc lựa chọn kiến trúc phân tán khi quyền sở hữu nghiệp vụ theo mảng và lợi ích về khả năng phục hồi hệ thống thực sự đòi hỏi.

Đánh giá năng lực tác nhân AI bắt đầu từ bản đặc tả tác vụ chi tiết. Mỗi tình huống kiểm thử cần xác định rõ: dữ liệu đầu vào, trạng thái môi trường ban đầu, phạm vi quyền hạn, kết quả mong đợi, các hành động tuyệt đối bị cấm, bằng chứng bắt buộc phải dùng và tiêu chí nghiệm thu cụ thể. Bộ dữ liệu kiểm thử phải bao quát các kịch bản chuẩn tắc, các trường hợp biên dị biệt, các yêu cầu mơ hồ, tình trạng thiếu hụt dữ liệu, sự cố công cụ báo lỗi, sự kiện bị chính sách từ chối và cả những đầu vào đối kháng độc hại. Dữ liệu kiểm thử phải được quản lý phiên bản nghiêm ngặt, không để rò rỉ vào câu lệnh prompt hay dữ liệu huấn luyện làm mất đi tính khách quan. Cần phân chia rạch ròi giữa tập dữ liệu phát triển và tập dữ liệu kiểm chứng độc lập (holdout); chủ động bổ sung thêm các trường hợp phát sinh từ sự cố vận hành thực tế sau khi đã khử sạch thông tin nhạy cảm. Điểm số tổng hợp phải luôn đi kèm phân tích chi tiết theo từng tầng rủi ro, bởi một lỗi nghiêm trọng như gửi nhầm email tài chính không thể bị cào bằng bằng cách tính trung bình cộng với hàng loạt câu trả lời đúng vô thưởng vô phạt. Khi có bất kỳ sự thay đổi nào về mô hình, câu lệnh, công cụ hay chính sách an toàn, quy trình kiểm thử hồi quy bắt buộc phải chạy lại trên cùng một bản chụp trạng thái môi trường. Toàn bộ hồ sơ đánh giá phải lưu giữ mã lệnh, cấu hình và mốc thời gian để có thể tái tạo kết quả bất cứ lúc nào. Nếu không sở hữu một bộ kiểm thử theo từng tác vụ chuẩn hóa, mọi tuyên bố về việc tác nhân AI đạt độ chính xác cao đều hoàn toàn vô nghĩa.

Đánh giá lộ trình thực thi (trajectory evaluation) xem xét toàn diện con đường mà tác nhân AI đã đi qua, thay vì chỉ đánh giá duy nhất kết quả đầu ra cuối cùng. Một kết quả bề ngoài có vẻ đúng vẫn có thể được tạo ra bằng các công cụ không được cấp phép, việc truy vấn dữ liệu quá mức cần thiết hoặc trải qua nhiều lần thử lại lãng phí tài nguyên; ngược lại, một tác vụ chủ động dừng lại an toàn vẫn là hành vi hoàn toàn đúng đắn dù công việc chưa hoàn tất. Bản ghi vết truy vết sẽ được chấm điểm dựa trên: sự lựa chọn công cụ, trình tự các bước, tính chuẩn xác của tham số, bằng chứng thu thập, mức độ tuân thủ chính sách, số bước thực hiện, khả năng phục hồi sau lỗi và điều kiện dừng. Lộ trình chuẩn tham chiếu không nhất thiết phải là con đường duy nhất, do đó bảng tiêu chí nên tập trung đánh giá các yếu tố bất biến và tính hiệu quả tổng thể thay vì ép buộc mô hình phải sao chép máy móc một đường đi cố định. Bộ giả lập công cụ giúp chạy thử nghiệm ngoại tuyến trong môi trường được kiểm soát hoàn toàn; tính năng chạy lại (replay) tận dụng các kết quả quan sát đã ghi nhận để so sánh năng lực của mô hình mới. Đối với các hành động gây tác động phụ, chế độ chạy thử nghiệm (dry-run) sẽ trả về bản xem trước thay vì thực thi trực tiếp trên hệ thống. Bản so sánh khác biệt lộ trình sẽ làm sáng tỏ những thay đổi giữa các phiên bản phần mềm. Chuyên gia kiểm duyệt con người chỉ cần xem xét các mẫu theo phân tầng rủi ro và các bản ghi vết bất thường, không nhất thiết phải đọc toàn bộ nhật ký. Đây là phương pháp hiệu quả nhất để phát hiện sớm các tác nhân AI có xu hướng đi vòng vo hoặc lạm quyền trước khi hậu quả tiêu cực kịp xảy ra.

Đánh giá kết quả nghiệp vụ (outcome evaluation) đo lường giá trị thực tế ở điểm cuối của quy trình: phiếu hỗ trợ được xử lý chính xác, hồ sơ được hoàn tất trọn vẹn, mã nguồn vượt qua kiểm thử, báo giá được phê duyệt thành công hay thời gian chu kỳ công việc được rút ngắn. Việc hoàn thành tác vụ bắt buộc phải có cơ chế xác minh độc lập bất cứ khi nào có thể, tuyệt đối không dựa dẫm vào lời tự tuyên bố của mô hình. Trong chăm sóc khách hàng, kết quả thực tế còn bao gồm tỷ lệ mở lại phiếu, tỷ lệ chuyển cấp xử lý và sự hài lòng của khách hàng; trong lập trình gồm kết quả kiểm thử, rà soát mã nguồn và kiểm tra hồi quy; trong vận hành nội bộ gồm đối soát số liệu và tỷ lệ phải chỉnh sửa thủ công. Cần đo lường đồng thời chất lượng cùng độ trễ, chi phí token, công sức con người can thiệp và tần suất sự cố để tránh việc tối ưu hóa cục bộ một chiều. Mốc chuẩn so sánh ban đầu có thể là quy trình do con người tự làm, quy trình tự động cố định hoặc mô hình ngôn ngữ không dùng tác nhân. Các thử nghiệm cần có nhóm đối tượng thử nghiệm và khoảng thời gian đủ tính đại diện, có tính đến yếu tố mùa vụ khi cần thiết. Các kết quả tiêu cực cần được mổ xẻ thấu đáo về mặt chất lượng dữ liệu, công cụ, kế hoạch, chính sách, mô hình AI hay sự thay đổi trong cấu trúc tổ chức. Chỉ khi tác nhân AI chứng minh được khả năng cải thiện rõ rệt kết quả nghiệp vụ đi kèm mức rủi ro trong ngưỡng chấp nhận được, doanh nghiệp mới có đủ cơ sở để nâng cao quyền tự chủ hoặc mở rộng quy mô áp dụng.

Đánh giá an toàn thông tin (security evaluation) mô phỏng các hành vi lạm dụng danh tính, công cụ và ngữ cảnh. Quy trình kiểm thử bao gồm: tấn công chèn câu lệnh trực tiếp và gián tiếp, trích xuất dữ liệu trái phép, leo thang đặc quyền, lạm dụng thẩm quyền ủy nhiệm (confused deputy), phát lại thông tin đăng nhập, chèn tham số công cụ độc hại, giả mạo yêu cầu từ máy chủ (SSRF), tấn công duyệt thư mục (path traversal), tải tệp tin độc hại, tấn công làm cạn kiệt ngân sách (denial of wallet) và tạo vòng lặp tiêu hao tài nguyên. Đội ngũ kiểm thử an ninh (red-team) phải thử nghiệm các chuỗi tấn công nhiều bước, bởi từng hành động đơn lẻ có thể hoàn toàn hợp lệ nhưng khi kết hợp lại sẽ gây ra hậu quả bị nghiêm cấm. Việc cài cắm khóa bí mật mồi nhử (canary secret) và tài nguyên giả lập giúp phát hiện kịp thời các truy cập trái phép ngay trong môi trường cô lập (sandbox). Các quyết định của chính sách an toàn cần được kiểm tra toàn diện cả ở trường hợp cho phép lẫn từ chối, nhằm tránh việc thiết lập kiểm soát quá khắt khe làm tê liệt quy trình vận hành. Quy trình kiểm thử an toàn phải được kích hoạt lại mỗi khi tích hợp thêm công cụ, thay đổi đầu nối kết nối hoặc chuyển đổi mô hình AI. Mọi kết quả kiểm thử đều phải ghi nhận rõ mức độ nghiêm trọng, khả năng tái hiện lỗi, người chịu trách nhiệm và thời hạn xử lý; các bản vá bắt buộc phải trải qua kiểm thử hồi quy. Tuyệt đối không bao giờ tuyên bố một tác nhân AI an toàn tuyệt đối. Bằng chứng an toàn hợp lý nhất chính là mô hình mối đe dọa hiện hành, độ bao phủ của bộ kiểm thử, mức rủi ro còn lại nằm trong ngưỡng chấp nhận và cơ chế ứng phó sự cố đã được diễn tập thuần thục.

Khả năng quan sát (observability) của tác nhân AI cần vết truy vết xuyên suốt từ yêu cầu, kế hoạch, truy xuất dữ liệu, lệnh gọi mô hình, lệnh gọi công cụ, chính sách, phê duyệt đến bộ xác minh. Mỗi đoạn vết (span) ghi nhận phiên bản, độ trễ, số token, chi phí, trạng thái và tham chiếu đến sản phẩm đầu ra; nội dung nhạy cảm được che chắn hoặc lưu trong vùng kiểm soát riêng. Bảng điều khiển vận hành theo dõi tỷ lệ hoàn thành, số bước, tỷ lệ vòng lặp, lỗi công cụ, số lần bị từ chối, thời gian chờ duyệt, chuyển cấp và ngân sách. Bảng điều khiển chất lượng theo dõi kết quả thực tế, căn cứ dữ liệu và tỷ lệ chỉnh sửa. Bảng điều khiển an toàn theo dõi truy cập bất thường, việc dùng khóa bí mật và công tắc ngắt khẩn cấp. Nhật ký không nên lưu chuỗi suy luận nội tâm; bản tóm tắt quyết định và kết quả quan sát là đủ cho kiểm tra. Cảnh báo cần gắn kèm quy trình ứng phó và người phụ trách. Lấy mẫu có thể giảm chi phí nhưng vết truy vết rủi ro cao cần ghi đầy đủ. Khi người dùng báo lỗi, mã liên kết (correlation ID) cho phép tái hiện đúng phiên làm việc thay vì đoán từ ảnh chụp màn hình.

Quản trị tài chính tác nhân AI (Agent FinOps) quản lý chi phí theo từng tác vụ và kết quả thực tế. Hạn mức ngân sách bao gồm token, phí công cụ, điện toán, số bước, thời gian và mức xử lý đồng thời. Bộ điều phối kiểm tra ngân sách trước khi phân nhánh; mỗi tác nhân thực thi nhận phần riêng; phần ngân sách chưa dùng không mặc định cho phép thực hiện hành động rủi ro hơn. Định tuyến mô hình dùng mô hình nhỏ cho phân luồng, trích xuất hay kiểm tra hợp lệ đơn giản, và dùng mô hình mạnh khi đánh giá chứng minh sự cần thiết. Bộ nhớ đệm câu lệnh (prompt cache), bộ nhớ đệm truy xuất và tái sử dụng sản phẩm đầu ra giúp giảm chi phí nhưng phải tôn trọng quyền truy cập và độ mới dữ liệu. Tấn công làm cạn ngân sách (denial-of-wallet) được phát hiện qua tỷ lệ vòng lặp, bùng nổ yêu cầu và chi phí bất thường; bộ ngắt mạch (circuit breaker) sẽ dừng phiên hoặc không gian khách hàng (tenant). Báo cáo chi phí cần gắn với tình huống sử dụng, phiên bản tác nhân và kết quả nghiệp vụ, không chỉ tổng hóa đơn. Tối ưu chi phí không được âm thầm cắt giảm rào chắn bảo vệ hay bộ xác minh. Một tác nhân giá rẻ nhưng cần nhiều chỉnh sửa thủ công có thể đắt đỏ hơn quy trình tự động đơn giản.

Kỹ thuật độ tin cậy (reliability engineering) luôn giả định mô hình và công cụ sẽ gặp lỗi. Thời gian chờ tối đa, thử lại và phương án dự phòng được cấu hình theo từng loại lỗi. Thử lại dùng thuật toán lùi theo hàm mũ kèm biến thiên ngẫu nhiên (exponential backoff và jitter), chỉ áp dụng cho lỗi tạm thời; thao tác có tác động phụ cần khóa chống xử lý trùng (idempotency key) hoặc truy vấn trạng thái giao dịch trước khi thử lại. Bộ ngắt mạch (circuit breaker) cô lập đầu nối lỗi. Hàng đợi thư chết (dead-letter queue) giữ lại tác vụ cần điều tra. Vách ngăn cách ly (bulkhead) giới hạn để một khách hàng hoặc công cụ không chiếm dụng toàn bộ hệ thống. Điểm kiểm tra (checkpoint) giúp tiếp tục tác vụ kéo dài. Nếu nhà cung cấp mô hình gián đoạn, mô hình dự phòng chỉ được dùng khi đã qua đánh giá và chính sách cho phép; nếu không, hệ thống chuyển sang quy trình cố định hoặc con người. Kiểm thử hỗn loạn (chaos test) mô phỏng thời gian chờ, phản hồi sai định dạng, thành công một phần và mất mạng. Cam kết dịch vụ (SLO) tách độ sẵn sàng kỹ thuật khỏi tỷ lệ thành công của tác vụ. Quy trình vận hành (runbook) mô tả cách dừng, khôi phục, đối soát tác động phụ và thông báo người bị ảnh hưởng.

Cơ chế có con người kiểm duyệt (human-in-the-loop) cần thiết kế rõ vai trò và giao diện, không chỉ gắn thêm nút duyệt. Thẻ phê duyệt hiển thị mục tiêu, hành động, đối tượng, dữ liệu thay đổi, bằng chứng, chính sách kích hoạt, mức chắc chắn và phương án hoàn tác. Người duyệt có thể chỉnh sửa, từ chối có lý do, yêu cầu thêm dữ liệu hoặc chuyển cấp xử lý. Yêu cầu phê duyệt tự hết hạn nếu trạng thái môi trường thay đổi; trước khi thực thi, công cụ kiểm tra lại giá, quyền hạn hay trạng thái giao dịch. Hệ thống đo thời gian chờ và tỷ lệ sửa để phát hiện khâu tự động hóa chưa hoàn thiện. Với các trường hợp lặp lại ổn định, quyền hạn có thể mở rộng qua rà soát quản trị; khi có sự cố, lập tức hạ cấp quyền. Người duyệt không phải chịu trách nhiệm cho lỗi mà giao diện che giấu. Đào tạo nhân sự phải nêu rõ giới hạn và cách kiểm chứng bằng chứng. Lấy mẫu ngẫu nhiên sau tự động hóa giúp duy trì kiểm soát ngay cả khi không duyệt từng ca riêng lẻ.

Vòng đời phát hành gồm kiểm thử ngoại tuyến, môi trường cô lập (sandbox), chạy ngầm song song (shadow), chạy thử nghiệm (pilot), phát hành thử cho nhóm nhỏ (canary) và vận hành chính thức (production). Giai đoạn chạy ngầm hoạt động trên dữ liệu thật nhưng không gây tác động phụ, so sánh đề xuất với hành động thực tế. Chạy thử nghiệm giới hạn người dùng, công cụ, dữ liệu và phân tầng rủi ro. Phát hành thử tăng dần lưu lượng với ngưỡng quay về bản trước rõ ràng về chất lượng, chi phí và sự cố. Mỗi giai đoạn đều có tiêu chí đầu vào và đầu ra cùng người ký duyệt. Mô hình, câu lệnh, cấu trúc công cụ, chính sách và chuyển dịch bộ nhớ được quản lý phiên bản độc lập, nhưng bản kê khai phát hành khóa chặt tổ hợp đã kiểm thử. Đổi mô hình không phải là thay thế vô hình; cần kiểm thử hồi quy lộ trình và kết quả. Môi trường vận hành giám sát hiện tượng lệch lạc của đầu vào, phản hồi công cụ và hiệu năng. Rà soát định kỳ quyết định tiếp tục, tinh chỉnh, giảm quyền hay ngừng hoạt động. Tác nhân hết người phụ trách hoặc không còn tình huống sử dụng phải bị tắt và thu hồi thông tin đăng nhập, không để chạy như hệ thống ngầm (shadow IT).

Ứng phó sự cố (incident response) cho tác nhân AI bổ sung các tình huống: vượt quyền hạn, tác động phụ sai lệch, rò rỉ dữ liệu, ảo giác gây hậu quả, vòng lặp chi phí và công cụ bị xâm nhập. Mức độ nghiêm trọng dựa trên tính chất dữ liệu, phạm vi, khả năng đảo ngược và người bị ảnh hưởng. Công tắc ngắt khẩn cấp (kill switch) có thể dừng một phiên, một phiên bản tác nhân, công cụ, không gian khách hàng hoặc toàn bộ tầng điều khiển. Bảo toàn chứng cứ lưu trữ vết truy vết, chính sách, sự kiện thông tin đăng nhập, sản phẩm đầu ra và phiên bản mô hình mà không làm lộ thêm dữ liệu. Khoanh vùng sự cố gồm thu hồi mã ủy quyền, cô lập công cụ, hạ tác nhân về chế độ chỉ đọc hoặc chuyển xử lý thủ công. Khôi phục cần đối soát mọi tác động phụ trước khi chạy lại. Thông báo sự cố tuân theo hợp đồng và pháp luật hiện hành. Báo cáo sau sự cố tìm biện pháp kiểm soát còn thiếu hoặc giả định sai, không chỉ đổ lỗi cho câu lệnh. Mỗi hành động khắc phục có người phụ trách và bài kiểm thử chứng minh. Tình huống sự cố sau khi khử thông tin nhạy cảm được đưa vào bộ kiểm thử hồi quy.

Quản trị hệ thống (governance) ánh xạ tác nhân AI vào danh mục kiểm kê, người phụ trách và phân tầng rủi ro. Đánh giá rủi ro xem xét mục đích, người dùng, dữ liệu, công cụ, mức tự chủ, quy mô, khả năng đảo ngược và tác động bên ngoài. Biện pháp kiểm soát chọn theo rủi ro: tài liệu và đánh giá cơ bản cho cấp thấp; định danh, phê duyệt, kiểm thử an ninh chuyên sâu (red-team), giám sát và thẩm định độc lập cho cấp cao. Hồ sơ thay đổi ghi rõ lý do, bằng chứng và người duyệt. Tác nhân hoặc công cụ bên thứ ba cũng vào quy trình quản trị rủi ro nhà cung cấp với điều khoản lưu giữ, bên xử lý dữ liệu phụ, xử lý sự cố, kiểm tra, xuất dữ liệu và chấm dứt. Chính sách sử dụng nêu rõ dữ liệu cấm, công cụ được duyệt và cách báo lỗi. Hội đồng quản trị không cần duyệt từng câu lệnh prompt nhưng cần đặt ngưỡng và theo dõi chỉ số rủi ro. Quản trị hiệu quả là kiểm soát vận hành thực tế và có bằng chứng, không phải danh sách nguyên tắc chung chung.

Khả năng chuyển đổi (portability) đòi hỏi lưu đặc tả tác vụ, bộ dữ liệu đánh giá, hợp đồng công cụ, chính sách và sản phẩm đầu ra ở định dạng do doanh nghiệp kiểm soát. Lớp chuyển đổi khung không tự đảm bảo đổi mô hình trơn tru vì hành vi lập kế hoạch, chọn công cụ, ngữ cảnh và ranh giới an toàn khác nhau. Đội ngũ cần đối chuẩn ít nhất một phương án thay thế trên tập kiểm chứng độc lập và ước tính chi phí chuyển đổi. Bộ nhớ và chỉ mục vector phải có đường xuất dữ liệu hoặc tái tạo từ nguồn gốc. Công cụ nên dùng chuẩn JSON Schema hoặc giao thức mở kèm tài liệu mô tả rõ phần mở rộng. Khả năng quan sát không bị khóa trong bảng điều khiển của một nhà cung cấp duy nhất; vết truy vết có thể xuất ra ngoài. Kế hoạch rút lui bao gồm thu hồi thông tin đăng nhập, xóa dữ liệu, chuyển giao tác vụ đang chạy và xác minh tác động phụ. Doanh nghiệp vẫn có thể dùng tính năng độc quyền nếu giá trị vượt trội, miễn là hiểu rõ đánh đổi và đường thoát hiểm. Trừu tượng hóa quá sớm cũng tốn kém, nên khả năng chuyển đổi cần tập trung vào các tài sản có giá trị nhất.

Trải nghiệm người dùng (UX) của tác nhân AI phải làm rõ trạng thái và quyền hạn. Người dùng cần biết tác nhân đang lập kế hoạch, chờ công cụ, chờ duyệt, bị chặn hay đã hoàn tất; biểu tượng xoay vòng vô tận chỉ che giấu lỗi hỏng. Cung cấp bản xem trước (preview) cho thao tác có tác động phụ; có tính năng hoàn tác hoặc bù đắp khi khả thi; lệnh hủy truyền ngay đến tác nhân thực thi và công cụ. Câu trả lời tách bạch dữ kiện, suy luận và đề xuất, kèm nguồn dẫn. Khi không chắc chắn, tác nhân hỏi một câu thật sự cần thiết thay vì đẩy mọi mơ hồ cho người dùng. Lịch sử tương tác hiển thị sản phẩm đầu ra và hành động, không phơi bày chuỗi suy luận nội tâm. Thông báo lỗi nêu rõ bước nào gặp sự cố, dữ liệu nào an toàn và các lựa chọn tiếp theo. Phản hồi được gắn vào vết truy vết. Khả năng tiếp cận, chuẩn hóa tiếng Việt và tính năng duyệt trên di động đều cần kiểm thử. Độ tin cậy đến từ khả năng quan sát và quyền kiểm soát thực chất, không từ hình đại diện giống người hay lời lẽ tự tin thái quá.

Quản lý thay đổi (change management) xác định tác nhân AI làm biến đổi phân công công việc nào. Người phụ trách quy trình quyết định bước nào lược bỏ, bước nào AI hỗ trợ và bước nào giữ lại con người. Nhân viên tham gia thiết kế ngoại lệ và tiêu chí chất lượng; nếu không, kinh nghiệm thực tế truyền miệng sẽ bị bỏ sót. Đào tạo dựa trên tình huống thật gồm cả lỗi và chuyển cấp xử lý, không chỉ các buổi trình diễn thành công. Chỉ số KPI không khuyến khích người dùng duyệt vội để làm đẹp tỷ lệ tự động hóa. Kênh phản hồi phân loại rõ vấn đề về sản phẩm, dữ liệu, chính sách hay mô hình. Các vai trò mới như người phụ trách tác nhân, chuyên viên đánh giá và nhân sự trực vận hành được phân bổ thời gian rõ ràng. Mức độ đón nhận được đo cùng tỷ lệ chỉnh sửa thủ công, kết quả thực tế và thái độ nhân viên. Khi năng lực tăng, quy trình chuẩn (SOP) và ma trận trách nhiệm (RACI) cần cập nhật. Truyền thông tránh hứa hẹn thay thế hoàn toàn con người; mục tiêu là phân bổ lại công việc mà không làm mất trách nhiệm giải trình.

Hiệu quả đầu tư (ROI) phải tính từ mốc đo ban đầu của quy trình. Cần đo khối lượng, thời gian chu kỳ, thời gian thao tác thực tế, tỷ lệ lỗi, công làm lại, chuyển cấp, chi phí và kết quả trước khi chạy thử. Lợi ích của tác nhân gồm tiết kiệm trực tiếp, tăng năng lực, nâng chất lượng, giảm rủi ro và tác động đến doanh thu; phương pháp quy đổi tài chính cần được bộ phận tài chính phê duyệt. Chi phí gồm khảo sát, dữ liệu, tích hợp công cụ, mô hình, hạ tầng, đánh giá, bảo mật, con người rà soát, sự cố và bảo trì. Cần so sánh với quy trình tự động đơn giản, không chỉ quy trình thủ công. Báo cáo theo nhiều kịch bản và phân tích độ nhạy với tỷ lệ tiếp nhận, chi phí mô hình và tỷ lệ ngoại lệ. Thời gian thu hồi vốn không đưa ra lời hứa chung chung. Rà soát danh mục định kỳ giữ lại trường hợp có kết quả thực và dừng tác nhân không tạo giá trị. Bài toán kinh tế đơn vị trên một tác vụ hoàn tất đúng giúp phát hiện tự động hóa bề ngoài cao nhưng chi phí ẩn lớn.

Định nghĩa hoàn thành (Definition of Done) cho vận hành chính thức gồm: đặc tả tác vụ kèm người phụ trách; mô hình mối đe dọa; cơ chế định danh và ủy quyền; cấu trúc công cụ, quyền tối thiểu, chống xử lý trùng (idempotency); chính sách bộ nhớ; bộ dữ liệu đánh giá và tập kiểm chứng độc lập; kiểm thử lộ trình, kết quả, bảo mật và tải hệ thống; ngân sách, thời gian chờ, điều kiện dừng, công tắc ngắt khẩn cấp; giao diện phê duyệt; vết truy vết và cảnh báo; tài liệu ứng phó sự cố; sao lưu trạng thái; phát hành thử cho nhóm nhỏ và quay về bản trước; đào tạo người dùng; mốc đo ban đầu và kế hoạch đo lường. Mọi kiểm soát đều phải có bằng chứng vận hành thực tế, không chỉ trên giấy tờ. Tác nhân phải hoàn tất tập tác vụ đại diện, dừng đúng khi thiếu dữ liệu và bị từ chối đúng khi vượt quyền. Các tác động phụ được đối soát kỹ lưỡng. Chỉ sau khi tiêu chí hoàn tất giai đoạn được ký duyệt, hệ thống mới được tăng lưu lượng hoặc nâng quyền tự chủ. Một buổi trình diễn gọi công cụ thành công chưa đủ đạt chuẩn để đưa vào vận hành chính thức.

Quản trị sự tiến hóa cấu trúc dữ liệu (schema evolution) là yêu cầu thiết yếu vì tác nhân phụ thuộc lớn vào mô tả và cấu trúc công cụ. Thêm trường tùy chọn thường an toàn hơn đổi nghĩa trường cũ; xóa giá trị liệt kê hoặc đổi đơn vị có thể làm kế hoạch cũ chạy sai lệch. Hợp đồng công cụ cần có phiên bản theo ngữ nghĩa, kiểm thử tương thích và thời hạn ngừng hỗ trợ. Bản kê khai tác nhân khóa phiên bản hoặc dải năng lực đã qua đánh giá. Cổng công cụ có thể chuyển đổi phiên bản trong thời gian chuyển tiếp nhưng phải ghi nhật ký. Khi cấu trúc đổi, việc chạy lại lộ trình đại diện và kiểm thử hợp đồng phải hoàn tất trước khi triển khai. Khả năng tự động khám phá công cụ không đồng nghĩa tự động tin phiên bản mới. Nếu phản hồi xuất hiện trường lạ, bộ phân tích cú pháp cần bỏ an toàn hoặc báo lỗi dứt khoát thay vì đưa toàn bộ vào ngữ cảnh. Người phụ trách cần thông báo thay đổi phá vỡ tính tương thích và kế hoạch quay về bản trước. Quản trị cấu trúc dữ liệu chặt chẽ giúp giảm dạng sự cố khó nhận biết: hệ thống vẫn chạy nhưng tác động phụ khác với ý định ban đầu.

Kỹ thuật bảo vệ quyền riêng tư (privacy engineering) áp dụng nguyên tắc giảm thiểu dữ liệu ở từng bước. Hợp đồng tác vụ chỉ yêu cầu trường cần thiết; dữ liệu truy xuất và phản hồi công cụ được lọc trước khi vào mô hình. Kỹ thuật ẩn danh tạm thời (pseudonymization) áp dụng khi danh tính không cần thiết cho suy luận. Dữ liệu nhạy cảm cần mục đích, sự đồng ý hoặc căn cứ xử lý hợp pháp, thời hạn lưu giữ và quyền chủ thể theo pháp luật. Tác nhân không tự suy ra thuộc tính nhạy cảm hay lưu tùy chọn lâu dài nếu chưa được phép. Nhật ký, bộ dữ liệu đánh giá và cơ chế chạy lại cũng nằm trong phạm vi quyền riêng tư; sao chép vết truy vết vận hành sang môi trường phát triển có thể tạo vi phạm. Chống thất thoát dữ liệu (DLP) phát hiện mẫu vi phạm, nhưng con người rà soát và chính sách vẫn là bắt buộc. Nhà cung cấp mô hình được đánh giá về vị trí đặt máy chủ, thời hạn lưu giữ, việc dùng dữ liệu để huấn luyện và danh sách bên xử lý dữ liệu phụ (subprocessor). Xóa dữ liệu phải thực hiện đồng bộ trên bộ nhớ, sản phẩm đầu ra, bộ nhớ đệm và nhật ký theo lịch đã duyệt.

Quy trình xác minh (verification) nên tận dụng các hệ thống tất định. Tính toán số học do mã lệnh hoặc công cụ chuyên dụng thực hiện; mô hình chỉ chọn tham số và diễn giải chứ không được coi là máy tính chính xác. Tác nhân viết mã cần chạy kiểm thử đơn vị, tích hợp, phân tích tĩnh và kiểm thử trong môi trường cô lập. Tác nhân tài liệu đối chiếu trích dẫn với đoạn văn bản nguồn. Tác nhân giao dịch truy vấn lại trạng thái sau khi hành động phát sinh. Tác nhân SQL chạy bộ phân tích cú pháp, danh sách được phép và ước tính chi phí trước khi gửi lệnh vào cơ sở dữ liệu. Bộ xác minh độc lập không dùng chung câu lệnh và ngữ cảnh lỗi nếu có lựa chọn khác. Khi không thể xác minh đầy đủ, đầu ra cần gắn nhãn không chắc chắn và yêu cầu con người rà soát. Gói bằng chứng gồm mã băm đầu vào, nguồn trích dẫn, kết quả công cụ, bài kiểm thử và phê duyệt. Cách này biến thành công từ cảm giác hợp lý thành trạng thái có bằng chứng. Bản thân bộ xác minh vẫn có thể lỗi, nên cần kiểm thử chính nó và giám sát tỷ lệ chấp nhận sai (false accept) cùng từ chối nhầm (false reject).

Mua sắm và lựa chọn tác nhân hay nền tảng AI cần đánh giá khả năng quan sát và kiểm soát, không chỉ nhìn vào điểm chuẩn của mô hình. Các câu hỏi gồm: có cho phép xuất vết truy vết không, chính sách an toàn nằm ở đâu, định danh tích hợp thế nào, dữ liệu lưu giữ bao lâu, cập nhật mô hình có báo trước không, quay về bản trước ra sao, chợ công cụ được kiểm duyệt thế nào và cam kết xử lý sự cố (SLA) là gì. Nhà cung cấp cần cung cấp tài liệu an ninh, bên xử lý dữ liệu phụ (subprocessor), báo cáo kiểm tra và điều khoản xóa dữ liệu. Chạy thử nghiệm (PoC) dùng tác vụ thật nhưng dữ liệu an toàn, so sánh với mốc ban đầu và giải pháp khác. Hợp đồng quy định quyền sở hữu câu lệnh, dữ liệu đánh giá, bộ nhớ và sản phẩm đầu ra; quyền kiểm tra; thông báo sự cố; khả năng chuyển đổi; hỗ trợ khi chấm dứt hợp đồng. Rủi ro tập trung cần được xem xét nếu nhiều tác nhân cùng phụ thuộc một nhà cung cấp. Điểm đánh giá nhà cung cấp không thay thế kiểm thử trong kiến trúc cụ thể của doanh nghiệp.

Mô hình vận hành (operating model) cần người phụ trách tác nhân chịu trách nhiệm kết quả, người phụ trách nền tảng chịu môi trường chạy, người phụ trách dữ liệu chịu nguồn và người phụ trách rủi ro thiết lập kiểm soát. Đội ngũ sản phẩm không thể giao toàn bộ trách nhiệm cho nhà cung cấp mô hình; bộ phận bảo mật cũng không thể vận hành tác nhân thay phòng ban nghiệp vụ. Ma trận trách nhiệm (RACI) chỉ rõ ai phê duyệt công cụ, quyền tự chủ, đổi mô hình, đóng sự cố và ngừng hoạt động. Nhân sự trực vận hành nhận cảnh báo cần có quy trình chuẩn, quyền ngắt khẩn cấp và kênh chuyển cấp. Nhịp độ rà soát định kỳ xem xét chất lượng, chi phí, rủi ro, phản hồi người dùng và danh mục thay đổi. Trung tâm chuyên môn có thể cung cấp tiêu chuẩn và nền tảng, còn đội ngũ chuyên môn sở hữu tác vụ cụ thể. Với doanh nghiệp SME, một người có thể giữ nhiều vai trò nhưng quyết định và bằng chứng vẫn phải tách bạch. Mô hình vận hành là điều kiện để tác nhân tồn tại sau thử nghiệm; thiếu người phụ trách, lỗi sẽ tích tụ và thông tin đăng nhập không ai thu hồi.

Một kiến trúc tham chiếu (reference architecture) thực dụng bao gồm các thành phần cốt lõi: kênh tiếp nhận, tầng nạp tác vụ, liên kết định danh, cổng chính sách, bộ điều phối, cổng mô hình, bộ dựng ngữ cảnh, dịch vụ bộ nhớ, cổng công cụ, kho lưu trữ sản phẩm đầu ra, bộ đánh giá, dịch vụ phê duyệt và hệ thống quan sát toàn diện. Mỗi thành phần kỹ thuật cần có giao diện kết nối và các kịch bản xử lý khi gặp lỗi rõ ràng. Cổng mô hình giúp chuẩn hóa giao tiếp với các nhà cung cấp khác nhau nhưng không được che giấu những khác biệt quan trọng trong quá trình đánh giá thực nghiệm. Cổng công cụ là điểm chốt chặn thực thi phân quyền và cơ chế chống xử lý trùng (idempotency). Kho lưu trữ sản phẩm đầu ra lưu giữ các tệp dữ liệu lớn bên ngoài cửa sổ ngữ cảnh để tối ưu chi phí. Dịch vụ phê duyệt tạo ra các giao dịch có thời hạn hiệu lực cụ thể. Hệ thống quan sát tiếp nhận nhật ký truy vết từ mọi tầng kiến trúc. Sơ đồ kiến trúc có thể được tinh gọn cho các tình huống ứng dụng quy mô nhỏ, song các chức năng bảo vệ cốt lõi tuyệt đối không được nhồi nhét tạm bợ toàn bộ vào một câu lệnh prompt duy nhất. Sơ đồ triển khai hạ tầng phải thể hiện rành mạch ranh giới tin cậy, luồng di chuyển của dữ liệu và các cổng kết nối ra ngoài hệ thống. Mô hình mối đe dọa an ninh và mô hình dự toán chi phí nên sử dụng chung một sơ đồ kiến trúc nhằm tránh tình trạng tài liệu kỹ thuật bị mâu thuẫn lẫn nhau.