Chief AI Systems Architect Playbook #30

Trả lời ngắn: Chief AI Systems Architect không chỉ vẽ sơ đồ hay chọn model. Vai trò này nối problem, boundary, data, tools, evaluation, operations, people và governance thành một hệ thống có thể kiểm chứng. Playbook tốt luôn ghi assumption, trade-off, owner, evidence, stop gate, fallback và cách retire capability.

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

• Architect nhìn một AI system bằng các lớp và decision surface nào.
• Cách dùng Architect Card để chốt scope, interface, trade-off và owner.
• Cách walkthrough một system từ request đến retrieval, tool, human handoff, eval và monitor.
• Cách đặt stop gate và thực hành một card 20 phút bằng dữ liệu giả.

Lưu ý giáo dục: ARCH-30, IDs, metrics và system trong bài là synthetic. Đây là tài liệu học tập, không phải blueprint production dùng ngay. Quyết định thật cần security, privacy, legal, safety, operations và governance owners review theo context.

1. Architect nhìn hệ thống thế nào?

Architect là người nối problem, system boundary, evidence, people và decision. Họ không nhất thiết viết mọi component hoặc biết hết mọi framework. Việc quan trọng hơn là làm rõ hệ thống đang cố giải quyết điều gì, ai bị ảnh hưởng, component nào được quyền làm gì, và làm sao biết hệ thống đang hoạt động đúng.

Hãy nhìn một AI capability qua các lớp: problem/user → workflow hoặc agent → context/data → model/prompt → tools/permissions → evaluation/guardrails → observability/incident → governance/people. Đây là cách tổng hợp các bài trước trong series: knowledge map giúp thấy lớp, system design giúp nối interface, case studies cho thấy workflow, evaluation và operations tạo evidence, còn safety/readiness/governance đặt stop gate.

Hình 1 — Architect system map nối capability với boundary, evidence, người vận hành và governance; model chỉ là một phần.

Với case synthetic ARCH-30, goal là giúp support operator tìm policy được duyệt, draft câu trả lời và route ticket. Non-goal là tự quyết định ngoại lệ high-impact, tự thay policy hoặc tự gọi hành động không có approval. Chỉ hai câu này đã làm thay đổi kiến trúc: cần retrieval có nguồn, tool permission hẹp, human handoff và trace đủ để điều tra.

Boundary là ranh giới capability được làm và không được làm. Boundary tốt có ví dụ pass, ví dụ handoff và failure path; không chỉ là câu “dùng AI có trách nhiệm”. Interface là hợp đồng giữa component hoặc role về input, output và failure. Nếu retrieval trả tài liệu không có version, hoặc handoff không trả đủ context cho operator, interface đang thiếu.

2. Architect Card và decision surface

Architect Card là một trang ghi những điều cần biết trước khi quyết định build hoặc deploy. Decision surface là tập hợp câu hỏi và quyền cần trả lời: goal, boundary, assumption, interface, risk, evidence, owner, trade-off, approval và fallback. Card không thay thế design document; nó giúp team không bỏ qua quyết định quan trọng trong một bộ tài liệu dài.

Trade-off là đánh đổi có chủ ý giữa quality, cost, latency, risk và scope. Architect không cần giả vờ có lựa chọn hoàn hảo. Ví dụ, context dài có thể tăng recall nhưng làm latency và cost xấu; architect có thể chọn retrieval top-k nhỏ, citation bắt buộc và handoff khi confidence thấp. Quan trọng là lý do, threshold và điều kiện mở lại được ghi.

Evidence loop là vòng claim → test/trace → decision → monitor → review. Nếu card ghi “answer đúng” nhưng không có slice, baseline, threshold và sample, đó là claim chưa đủ. Một ADR (Architecture Decision Record) có thể lưu lựa chọn, bối cảnh, phương án đã bỏ và hệ quả; card là bản nhìn nhanh, ADR là bằng chứng quyết định có chiều sâu.

Hình 2 — Architect Card làm trade-off và decision surface nhìn thấy được trước khi team xây quá xa.

3. Walkthrough hệ thống ARCH-30

Khi một operator gửi request, ARCH-30 đi qua flow sau:

1. Frame request: nhận câu hỏi, user scope và mục tiêu; nếu thiếu context thì hỏi lại, không đoán.
2. Retrieve: tìm policy đã duyệt có version và freshness; nếu không có nguồn đủ căn cứ, trả về gap hoặc handoff.
3. Draft: model tạo draft kèm source và limitation; output chưa phải quyết định cuối.
4. Tool/permission: tool chỉ đọc ticket metadata hoặc đề xuất queue; không được tự đổi quyền, hoàn tiền hay thay policy.
5. Human handoff: high-impact, ambiguous hoặc policy conflict chuyển cho operator có quyền, kèm evidence và lý do.
6. Evaluate: chạy clear/mixed/high-impact slices, regression, refusal/handoff và citation checks.
7. Observe: lưu trace cần thiết, latency, error, feedback, drift và alert; không log secret hoặc dữ liệu thừa.

Architect phải kiểm tra cả happy path và failure path. Một demo chạy đúng không chứng minh khi provider timeout, retrieval stale, quota hết, operator không online hoặc policy conflict. Với mỗi failure, card cần ghi fallback: retry có giới hạn, trả lời an toàn, handoff, giữ HOLD hoặc rollback.

Hình 3 — End-to-end flow cho thấy output model chỉ là một điểm trong chuỗi interface, approval và evidence.

4. Architect workflow và stop gates

Một workflow có thể dùng tám bước:

1. Discover: nghe problem và affected user; ghi non-goal, constraint và feedback route.
2. Frame: chốt boundary, risk, decision right, success condition và assumption.
3. Design: chọn workflow, copilot hoặc agent theo quyền tool, context, human capacity và recovery evidence.
4. Test: dựng eval set, baseline, quality/safety/security checks, regression và slice high-impact.
5. Rehearse: thử handoff, alert, incident, rollback và data/cache impact trong môi trường bounded.
6. Gate: readiness packet có owner, freshness, exception/expiry và quyết định PASS, HOLD hoặc BLOCKED.
7. Bounded deploy: canary mở trên segment nhỏ, có monitor và stop rule. Canary là lần mở thử giới hạn để kiểm signal trước khi mở rộng.
8. Operate/review/retire: theo dõi, xử lý incident, mở lại review khi evidence stale hoặc scope đổi; decommission khi capability không còn phù hợp.

Ở bước gate, không dùng một điểm tổng để che critical gap. Quality pass nhưng rollback chưa rehearsal là HOLD; privacy control fail có thể BLOCKED tùy rule. Nếu có exception, phải có lý do, mitigation, approver, expiry, monitoring và revoke condition. Một exception không xóa requirement; nó ghi rõ ai chấp nhận rủi ro còn lại và đến khi nào.

Hình 4 — Stop gate bảo vệ đường đi từ test đến canary, rollback và review lại thay vì đẩy thẳng từ diagram sang production.

NIST AI RMF nhấn mạnh việc quản trị và quản lý risk theo vòng đời. Azure Well-Architected AI, OpenAI Agents guide và Google Cloud Architecture Framework cung cấp các câu hỏi về reliability, security, tools, observability và operational excellence. Những nguồn này giúp architect mở rộng câu hỏi; chúng không thay thế evidence của ARCH-30. NIST AI RMF Core, Azure Well-Architected AI, OpenAI Agents guide và Google Cloud Architecture Framework

5. Sai lầm, giới hạn và fallback

• Framework shopping: đổi framework liên tục nhưng chưa chốt problem/boundary. Fallback: Architect Card và một ADR nêu lý do chọn.
• Overbuilding: dựng agent nhiều tool khi workflow bounded đã đủ. Fallback: bắt đầu bằng quyền nhỏ, human gate và interface rõ.
• Blurry boundary: “AI hỗ trợ mọi việc” khiến scope và risk không kiểm được. Fallback: list non-goal, refusal và handoff examples.
• One metric: answer quality cao che latency, cost, safety hoặc feedback xấu. Fallback: dimension floors và segment monitor.
• Tool authority quá rộng: model có thể gọi action không cần thiết. Fallback: read-only first, schema, permission và approval.
• Missing owner: diagram đẹp nhưng không ai nhận alert, risk hoặc rollback. Fallback: role map, acknowledgement và escalation.
• Diagram theater: mọi box đều xanh nhưng không có test, trace hoặc rehearsal. Fallback: claim-to-evidence map.
• Stale evidence: report cũ dùng cho version/policy mới. Fallback: freshness, version pin và trigger re-eval.
• Vendor drift: provider đổi behavior hoặc quota. Fallback: change record, canary, alternative path và rollback.
• No retirement: access, data route và chi phí còn tồn khi capability hết giá trị. Fallback: decommission owner, sunset date, archive và replacement.

Architect cũng có giới hạn. Không thể biết mọi failure trước khi có traffic thật; sample có thể lệch; human operator có thể mệt; cost/latency sẽ đổi khi context và volume đổi. Vì thế “đã thiết kế” không đồng nghĩa “đã ready”. Khi uncertainty quan trọng chưa được đo, ghi nó vào decision record và chọn bounded experiment hoặc HOLD, không che bằng ngôn ngữ chắc chắn.

6. Practice Bridge 20 phút

Mở Notes hoặc Google Sheets miễn phí. Tạo các cột goal, non_goal, boundary, interface, risk, control, evidence, owner, trade_off, decision, monitor, fallback, review_trigger. Dùng system synthetic ARCH-30, không dùng secret hoặc customer data.

Mẫu đối chiếu đã điền

Trong 20 phút, trả lời ba stop questions: (1) capability này không được làm gì, (2) evidence nào khiến bạn đổi decision, (3) ai có quyền dừng và họ nhận alert trong bao lâu? Nếu chưa trả lời được một câu, card chưa sẵn sàng để gọi PASS. Hãy ghi một next action có owner và thời hạn; đó là output tốt hơn một sơ đồ đầy màu.

7. Tổng kết: architect giữ đường nối

a. Năm ý chính

• Architect nối problem, boundary, interface, evidence, people và decision; không chỉ chọn model hay vẽ diagram.
• Architect Card làm goal, non-goal, risk, owner, trade-off, evidence và fallback nhìn thấy trước khi build quá xa.
• Một AI system cần kiểm end-to-end: request, context, tool permission, human handoff, evaluation, observability và governance.
• Stop gate, canary, rehearsal, rollback và review trigger biến design thành deployment có điều kiện.
• Không framework hay điểm tổng nào thay thế được judgment, freshness, owner, bounded scope và decommission plan.

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

• Vì sao workflow bounded có thể phù hợp hơn agent tự hành trong ARCH-30?
• Architect Card khác một sơ đồ kiến trúc đẹp ở điểm nào?
• Khi nào quality pass vẫn phải HOLD?
• Một capability hết giá trị cần làm gì trước khi gọi là retired?

c. Gợi ý đáp án

Xem gợi ý câu 1

Bounded workflow giới hạn tool authority và dễ kiểm evidence/recovery hơn khi human capacity hoặc rollback chưa trưởng thành. Xem lại mục 1 và mục 3.

Xem gợi ý câu 2

Card ghi decision surface: goal, boundary, owner, risk, evidence, trade-off, approval và fallback; diagram chỉ cho thấy cấu trúc. Xem lại mục 2.

Xem gợi ý câu 3

Quality pass không bù được rollback, privacy, safety, owner hoặc evidence freshness gap; decision phụ thuộc critical floor. Xem lại mục 4 và mục 5.

Xem gợi ý câu 4

Retire cần owner, sunset, thu hồi access/data route, archive evidence, thông báo và replacement path nếu còn người dùng. Xem lại mục 4 và mục 5.

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

e. Nguồn tham khảo

• NIST AI RMF Core — governance và risk theo vòng đời.
• Azure Well-Architected AI — các câu hỏi architecture, reliability và operations.
• OpenAI Agents guide — tools, guardrails, state và tracing.
• Google Cloud Architecture Framework — system design, security, reliability, cost và operations.

Bài trước là AI Governance và Responsible Deployment #29. Đây là bài capstone cuối của AI PROFESSIONAL SERIES; next step an toàn là dùng Architect Card với một case synthetic, không đưa credential hay dữ liệu thật vào Practice Bridge.

Để ôn lại các điểm neo của series, quay về AI Knowledge Map: Prompt đến Production #1, Integrated AI System Design Framework #12, Case Study: AI System Failure Analysis #18 và Production AI Operating System #24. Đây là các hub để đối chiếu trước khi đưa Architect Card vào một bài tập mới.

Lưu ý giáo dục: Một playbook tốt làm rõ điều chưa biết và điểm dừng. Trước production thật, hãy để các owner phù hợp xác nhận security, privacy, safety, operations, governance, rollback và decommission.