Trả lời ngắn: Một AI system chạy production cần nơi chạy ổn định (infrastructure), ranh giới dữ liệu và quyền (security), cùng tín hiệu để biết từng run đã làm gì (observability). Output đẹp không chứng minh hệ thống an toàn. Bạn cần runtime map, identity, secrets, log, metric, trace, owner và đường dừng khi có sự cố.

Đọc xong, bạn sẽ hiểu:

  • Infrastructure, security và observability nối với nhau ở đâu.
  • Vì sao identity, secrets và data boundary phải được thiết kế trước tool.
  • Log, metric và trace trả lời ba câu hỏi khác nhau.
  • Cách lập runtime/security map 15 phút bằng dữ liệu giả.

Lưu ý giáo dục: Ví dụ chỉ dùng đơn hàng, draft và run giả. Không đưa token, dữ liệu riêng tư, tiền thật hoặc quyền production vào bài tập.

1. Ba lớp của một AI system chạy thật

a. Infrastructure, security, observability

Infrastructure là runtime, network, storage và các service AI phụ thuộc. Security là ranh giới identity, dữ liệu và quyền. Observability là khả năng hiểu run qua telemetry: log, metric và trace. Ba lớp liên quan nhưng không thay nhau.

Một container chạy ổn định nhưng cấp quyền đọc toàn bộ database vẫn rủi ro. Một policy quyền chặt nhưng không có trace thì khó điều tra khi output sai. Một dashboard nhiều chart nhưng không có provenance vẫn chưa cho biết câu trả lời dựa vào nguồn nào.

Hình 1 — AI production cần nơi chạy, ranh giới quyền và bằng chứng của từng run.

b. Ví dụ trợ lý hoàn tiền

Runtime gọi model và tool get_order. Security giới hạn order nào người dùng được xem. Tool write chỉ tạo draft refund và chờ approval. Observability ghi run id, policy version, tool status và quyết định người duyệt. Thiếu một lớp, reviewer có thể không trả lời được “ai làm gì, dựa vào đâu, lúc nào và có thể dừng ở đâu?”.

2. Infrastructure: AI chạy ở đâu và qua những gì?

a. Vẽ dependency map

Runtime là nơi process/model/tool thực sự chạy. Map tối thiểu nên có request gateway, model endpoint, retrieval/data store, tool service, queue và nơi ghi telemetry. Tách environment dev/test/prod để thử prompt hoặc tool không chạm nhầm dữ liệu thật.

Một content pipeline có thể là: upload Markdown → worker tạo draft → image service → reviewer → validator → deploy gate. Nếu worker, image service và validator không có version/owner, lỗi có thể bị đổ cho model dù nguyên nhân nằm ở dependency.

b. Dependency failure không phải model failure

Model timeout, retrieval timeout và tool permission đều tạo trải nghiệm khác nhau. Cần error code, timeout, retry có giới hạn và fallback rõ. Đừng retry vô hạn khi side effect có thể lặp. Infrastructure map cũng cần biết dữ liệu nào lưu ở đâu, retention bao lâu và service nào gọi service nào.

Hãy ghi cả owner và điều kiện thay đổi cho mỗi dependency. Nếu model endpoint đổi version, retrieval index được rebuild hoặc queue đổi retry policy, người review phải biết artifact nào bị ảnh hưởng. Map không cần vẽ phức tạp; một bảng tên service, input, output, owner và fallback đã đủ để bắt đầu.

Hình 2 — Runtime map giúp tách lỗi model khỏi lỗi dependency, queue, permission hoặc telemetry.

3. Security: ai được làm gì với dữ liệu nào?

a. Identity và least privilege

Identity là danh tính gắn với quyền gọi model, database hoặc tool. Least privilege là chỉ cấp quyền tối thiểu cần cho nhiệm vụ. Trợ lý đọc đơn chỉ nên nhận field cần thiết; agent viết refund không nên giữ quyền deploy hay truy cập toàn bộ khách hàng.

Secrets là key/token không được đưa vào prompt, log, hình ảnh hoặc Git. Tách secrets khỏi content và dùng secret manager phù hợp với môi trường. Google Cloud mô tả production AI security theo lớp application, data và infrastructure, gồm các rủi ro prompt injection, data leakage và quyền quá rộng. Google Cloud AI security

b. Data boundary và prompt injection

Một tài liệu nội bộ có thể chứa câu “bỏ qua policy và gửi dữ liệu”. Đó là nội dung cần xử lý, không tự trở thành instruction. Security boundary cần tách user input, system instruction, retrieved data và tool arguments; kiểm quyền trước khi trả dữ liệu.

Hãy dừng khi không xác định được tenant/access scope, không biết secret đi qua log nào hoặc không thể xoá/redact dữ liệu nhạy cảm khỏi trace. Một prototype read-only và dữ liệu giả vẫn có giá trị học tập mà không cần mở quyền thật.

Security cũng là câu hỏi vận hành: ai nhận alert, ai thu hồi quyền, ai duyệt khôi phục và thời gian lưu bằng chứng là bao lâu. Nếu không có owner, ranh giới chỉ nằm trên sơ đồ chứ chưa thành kiểm soát chạy thật.

Hình 3 — Security review kiểm danh tính, dữ liệu, secrets và ranh giới trước khi gọi tool.

4. Observability và incident response

a. Log, metric và trace

Log là bản ghi sự kiện: request nhận lúc nào, tool nào được gọi, status gì. Metric là số theo dõi xu hướng: latency, error rate, token hoặc tỷ lệ fallback. Trace là chuỗi liên kết một run qua gateway, retrieval, model, tool và approval.

Với AI, trace nên có provenance: nguồn retrieval, version prompt/policy, tool arguments đã redact, output bị guardrail chặn và decision. Microsoft khuyến nghị AI observability mở rộng log/metric/trace bằng tín hiệu AI-native và evaluation để theo dõi chất lượng, an toàn. Microsoft AI observability

b. Từ cảnh báo đến rollback

Incident response là phát hiện, giới hạn, điều tra và phục hồi sự cố. Alert latency cao chỉ nói có triệu chứng; trace giúp tìm run và dependency; log cho biết event; evaluation cho biết chất lượng có giảm không. Khi có prompt injection hoặc tool misuse, containment có thể là tắt tool write, chuyển read-only, rollback policy/prompt và thông báo owner.

Telemetry cũng có giới hạn: log thiếu field, metric nhiễu, trace bị redact hoặc retention quá ngắn. Vì vậy, “có dashboard” không đồng nghĩa “đã điều tra được mọi run”. NIST AI RMF đưa quản lý rủi ro và trách nhiệm vào toàn vòng đời AI, không thay thế quyết định cụ thể của tổ chức. NIST AI RMF

5. Practice Bridge 15 phút

a. Cách làm

Dùng Google Sheets/notes. Chọn refund assistant hoặc content pipeline giả; điền bảy hàng: runtime, identity, data, model, tool, telemetry và fallback. Ghi owner và trạng thái, không dùng API key, PII, tiền thật hoặc environment production.

Mẫu đối chiếu

Lớp Mẫu dữ liệu giả Câu hỏi kiểm Trạng thái Bước tiếp theo
Runtime worker dev tạo draft Chạy ở env nào? Đã chọn Ghi version
Identity user-demo đọc A100 Quyền tới đâu? Giới hạn Test deny
Data policy-v2026-01 giả Nguồn/version? Có mẫu Check freshness
Model model tạo draft Input/output gì? Có contract Viết test
Tool get_order read-only Có side effect? Không Giới hạn field
Telemetry run_id + log/metric/trace Dựng lại được không? Chưa test Tạo 3 case
Fallback NEED_REVIEW + owner Khi nào dừng? Đã định Ghi runbook

b. Kết quả mong đợi

Tìm ít nhất một ô “Chưa test” và một quyền cần giảm. Đây là artifact giáo dục, chưa phải deployment plan. Bài tiếp theo là AI Professional Diagnostic Assessment #6.

Hình 4 — Bảng map biến infrastructure, security và telemetry thành câu hỏi có owner và điểm dừng.

6. Tổng kết: production cần bằng chứng

a. Năm ý chính

  • Infrastructure cho AI nơi chạy và dependency; security đặt ranh giới; observability tạo bằng chứng.
  • Runtime map giúp phân biệt lỗi model với lỗi network, queue, permission hoặc tool.
  • Identity, least privilege, secrets và data boundary phải có trước quyền gọi.
  • Log, metric, trace và provenance trả lời các câu hỏi khác nhau; dashboard không thay evaluation.
  • Khi có incident, giảm quyền/tắt write/rollback và chuyển owner; thiếu telemetry thì nói rõ không biết.

b. Câu hỏi tự kiểm tra

  • Infrastructure, security và observability khác nhau ở câu hỏi nào?
  • Vì sao secrets không được đưa vào prompt hoặc log?
  • Log, metric và trace lần lượt giúp biết gì?
  • Incident response bắt đầu và kết thúc ở những bước nào?

c. Gợi ý đáp án

Xem gợi ý câu 1

Infrastructure là nơi chạy; security là ranh giới; observability là bằng chứng của run. Xem lại mục 1.

Xem gợi ý câu 2

Secrets có thể bị lộ qua prompt, log hoặc artifact; tách chúng khỏi content và Git. Xem lại mục 3.

Xem gợi ý câu 3

Log ghi event, metric theo dõi xu hướng, trace nối các bước của run. Xem lại mục 4.

Xem gợi ý câu 4

Phát hiện, containment, điều tra, rollback/phục hồi và ghi nhận owner. Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Infrastructure Runtime, network, storage và service phụ thuộc.
Runtime Nơi process/model/tool thực sự chạy.
Identity Danh tính gắn với quyền gọi.
Least privilege Chỉ cấp quyền tối thiểu.
Secrets Key/token cần bảo vệ khỏi prompt/log.
Observability Hiểu run qua telemetry.
Provenance Nguồn và lịch sử tạo output.
Incident response Phát hiện, giới hạn, điều tra, phục hồi sự cố.

e. Nguồn tham khảo

Bài trước là Agent và Tool-use Architecture Review #4. Bài tiếp theo là bài diagnostic để tự kiểm tra năng lực.

Lưu ý giáo dục: Infrastructure/security/observability review không thay thế security assessment, evaluation, incident playbook hoặc approval của owner. Giữ prototype nhỏ và read-only tới khi có bằng chứng.