Trả lời ngắn: Failure-mode register là sổ sống ghi system có thể fail thế nào, trigger/impact ra sao, control nào ngăn hoặc phát hiện, ai sở hữu và evidence ở đâu. Nó biến “system safe” thành các risk statement có test, escalation, review date và residual risk; thiếu control hoặc evidence thì không đánh dấu safe.

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

  • Cách tìm failure mode theo từng chặng của AI workflow.
  • Cách viết risk statement, preventive/detective/corrective control và evidence.
  • Cách chấm severity, escalation và risk còn lại sau control.
  • Vì sao register phải có owner, review date và trạng thái mở.

Lưu ý giáo dục: Case và ID trong bài là synthetic. Không đưa credential, private data, exploit payload hoặc hướng dẫn gây hại vào register thử nghiệm. Register thật phải được safety/security/legal owner review theo risk và quy định tổ chức.

1. Failure-mode register là gì?

Failure mode là cách system có thể fail hoặc tạo outcome không mong muốn. Trigger là điều kiện làm failure xuất hiện; impact là hậu quả lên user, data, safety, cost hoặc operations. Control là biện pháp prevent, detect hoặc correct failure. Register tốt nối các field này với owner, evidence, status và review date.

Case support copilot SAFE-27 có flow intake → retrieval → model → tool → human handoff → response → trace. Một row không viết “AI có thể không an toàn”. Nó viết cụ thể: “Nếu retrieval trả policy stale, copilot có thể suggest queue sai; control là freshness check + source date + human review; evidence là test case và alert; owner là TEAM-SAFE-27.”

Field Câu hỏi Ví dụ giả
Failure mode Hỏng theo cách nào? stale policy suggestion
Trigger Điều kiện nào kích hoạt? source date vượt freshness
Impact Ai/cái gì bị ảnh hưởng? wrong queue, high-impact risk
Control Prevent/detect/correct gì? freshness + handoff
Evidence Làm sao biết control chạy? test, trace, review
Owner Ai xử lý/approve? TEAM-SAFE-27

Hình 1 — Register tốt bám theo flow và nối failure mode với control, evidence, owner và review.

Register không phải danh sách tĩnh viết một lần. Change prompt/model/tool, incident, feedback hoặc policy đều có thể mở risk mới. Trạng thái có thể là OPEN, MITIGATED, MONITORING, ACCEPTED, CLOSED; CLOSED cần evidence và người có quyền quyết định, không chỉ là checkbox.

2. Tìm failure mode theo flow

Đi qua mỗi chặng và hỏi bốn câu: “Có thể fail thế nào?”, “Ai chịu impact?”, “Có thể bị misuse/abuse ra sao ở mức khái quát?”, “Làm sao detect trước khi harm lan rộng?” Không cần viết payload hay cách vượt control. Mục tiêu là hiểu boundary và control.

Chặng Failure mode synthetic Câu hỏi control
Intake sensitive field không được redact Redaction test và access log ở đâu?
Retrieval source stale/unauthorized Freshness, permission và citation check?
Model overconfident khi evidence thiếu Uncertainty/handoff rule?
Tool action side effect không approve Permission, human gate và audit?
Human reviewer bỏ qua high-impact SLA, escalation và sampling?
Operations alert/trace không đủ SLO, trace completeness và runbook?

Fail-safe là trạng thái giảm harm khi system lỗi hoặc không chắc. Ví dụ tool boundary không có permission rõ thì không gọi action; model không tìm thấy evidence thì nêu uncertainty/handoff; trace thiếu bundle ID thì giữ incident NOT_VERIFIED. Fail-safe không phải lúc nào cũng “tắt system”; nó là chọn hành vi ít rủi ro hơn trong boundary.

3. Viết risk statement và control

Risk statement tốt có cấu trúc: Nếu [trigger], thì [failure mode] có thể gây [impact], vì [cause]; control/evidence là [control + proof]. Ví dụ:

Nếu source policy stale ở retrieval, copilot có thể đưa queue suggestion không còn đúng, vì freshness không được kiểm. Preventive control là lọc theo policy date; detective control là freshness alert; corrective control là handoff và refresh index. Evidence là fixture, trace field và review record.

Có ba nhóm control:

  • Preventive: chặn từ trước: schema validation, least privilege, input redaction, allowed tool list, human approval.
  • Detective: phát hiện: alert, trace, policy flag, eval slice, anomaly, sampling review.
  • Corrective: giảm tác động/sửa: rollback, disable action, handoff, re-index, label fix, incident runbook.

Hình 2 — Một risk cần control có loại, owner, evidence và hành động khi control fail; chữ “guardrail” một mình chưa đủ.

Control cũng có failure mode. Redaction có thể bỏ sót; alert có thể noisy; human review có thể quá tải; rollback artifact có thể stale. Đưa “control failure” vào register row khác hoặc control dependency, nếu không system sẽ coi control là phép màu không bao giờ hỏng.

NIST AI 600-1 thảo luận các risk và consideration của generative AI; NIST AI RMF Core cung cấp cách nghĩ theo Govern, Map, Measure, Manage. Nguồn chính thức giúp mở rộng risk vocabulary, nhưng register phải gắn với flow, capability và evidence cụ thể của team. NIST AI 600-1 và NIST AI RMF Core

4. Severity, escalation và residual risk

Residual risk là risk còn lại sau khi control hoạt động. Đừng gọi mọi risk LOW để release dễ hơn. Severity nên xét impact, exposure, detectability, reversibility và affected population. Một lỗi queue có thể medium ở request thường nhưng high nếu liên quan high-impact process.

Severity Ví dụ Escalation/decision
Low formatting sai, dễ sửa, không side effect owner xử lý, review định kỳ
Medium stale source làm routing sai hold slice, product/ops review
High side effect không approve hoặc privacy leak contain, human/security escalation
Critical harm rộng, control bypass, evidence mất stop capability, incident commander

Hình 3 — Severity không tự quyết định release; escalation, residual risk, evidence và risk acceptance phải có owner.

Escalation là chuyển risk tới owner có quyền xử lý. Risk acceptance là quyết định có owner về việc chấp nhận residual risk; người viết row không mặc nhiên có quyền accept. High-impact path cần human approval và fail-safe. Nếu owner vắng, escalation path không rõ hoặc evidence chưa đủ, trạng thái nên là OPEN/HOLD.

Acceptance cũng cần phạm vi và thời hạn: chấp nhận risk cho fixture nội bộ không đồng nghĩa chấp nhận cho traffic rộng. Ghi điều kiện hết hạn, metric phải theo dõi, người có quyền revoke và event bắt buộc review lại. Nếu control phụ thuộc vendor, data source hoặc reviewer capacity, ghi dependency đó ngay trong row. Khi dependency thay đổi, register mở lại risk và chạy lại control test.

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

  • Checklist theater: tick guardrail nhưng không có test/evidence. Fallback: link test, trace, reviewer và review date.
  • Generic control: ghi “add monitoring”. Fallback: field, threshold, alert owner và runbook cụ thể.
  • Severity inflation: gọi mọi lỗi critical để né quyết định. Fallback: impact/exposure/reversibility rubric.
  • Duplicate rows: cùng failure xuất hiện nhiều nơi, owner mơ hồ. Fallback: canonical ID và linked dependency.
  • Unknown owner: risk mở nhưng không ai nhận. Fallback: escalation và giữ release hold.
  • Stale register: code/policy đổi nhưng row cũ. Fallback: trigger review theo change, incident và cadence.
  • Automation overclaim: control tự động được coi là an toàn tuyệt đối. Fallback: sample human review, adversarial test ở mức an toàn và residual risk.
  • Risk acceptance không quyền: người gần system tự accept risk high-impact. Fallback: decision matrix và separation of duties.

Register có giới hạn: không dự đoán mọi failure; severity có subjective judgment; test fixture có thể thiếu edge case; risk giảm ở lab nhưng tăng ở traffic thật; provider behavior drift. Vì vậy hãy ghi UNKNOWN, NOT_VERIFIED, evidence gap và next review. Một register trung thực có thể nhiều row mở; đó là tín hiệu cần quản trị, không phải lý do xóa row.

6. Practice Bridge 15 phút

Mở Google Sheets hoặc Notes miễn phí. Tạo cột risk_id, flow_step, failure, trigger, impact, severity, control, evidence, owner, status, review_date, escalation. Dùng case synthetic.

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

Risk Failure/impact Control và decision
R-27-01 Stale policy → wrong routing freshness check + human review, OPEN
R-27-02 Tool side effect không approve permission + human gate, BLOCKED
R-27-03 Trace redaction miss redaction test + access review, HOLD
R-27-04 Overconfident answer thiếu source citation/uncertainty rule, MONITORING

Trong 15 phút, thêm một evidence link giả, một owner, một review date và điều kiện escalation. Stop condition: nếu control chỉ là câu “có guardrail” hoặc không biết khi nào control fail, giữ row OPEN, chưa risk-accept. Ghi thêm lần review kế tiếp để register tiếp tục sống.

7. Tổng kết: safety là evidence sống

a. Năm ý chính

  • Failure-mode register viết cụ thể failure, trigger, impact, control, evidence, owner và status.
  • Tìm failure theo intake, retrieval, model, tool, human, data và operations; hỏi cả misuse/boundary ở mức an toàn.
  • Preventive, detective và corrective control đều cần test; control cũng có failure mode.
  • Severity, escalation và residual risk cần người có quyền quyết định, nhất là high-impact path.
  • Risk không có owner, evidence, review date hoặc fail-safe phải giữ OPEN/HOLD, không đánh dấu safe.

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

  • Một risk statement tốt có những phần nào?
  • Control preventive khác detective/corrective ra sao?
  • Vì sao residual risk cần owner có quyền accept?
  • Khi nào register row phải giữ OPEN?

c. Gợi ý đáp án

Xem gợi ý câu 1

Nó có trigger, failure mode, impact, cause, control và evidence; owner/status giúp vận hành tiếp. Xem lại mục 1 và mục 3.

Xem gợi ý câu 2

Preventive chặn trước, detective phát hiện, corrective giảm tác động hoặc sửa sau failure. Xem lại mục 3.

Xem gợi ý câu 3

Risk acceptance là quyết định accountability; người không có quyền không nên tự chấp nhận high-impact residual risk. Xem lại mục 4 và mục 5.

Xem gợi ý câu 4

Giữ OPEN khi owner, control, evidence, review date hoặc escalation chưa rõ, hay control chưa chứng minh. Xem lại mục 5 và mục 6.

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

Thuật ngữ Giải thích ngắn
Failure mode Cách system có thể fail hoặc gây outcome không mong muốn.
Trigger Điều kiện làm failure mode xuất hiện.
Impact Hậu quả lên user, data, safety, cost hoặc operations.
Control Biện pháp prevent, detect hoặc correct failure.
Detectability Khả năng phát hiện failure trước/sau impact.
Residual risk Risk còn lại sau khi control hoạt động.
Escalation Chuyển risk/incident tới owner có quyền xử lý.
Risk acceptance Quyết định có owner về việc chấp nhận risk còn lại.
Fail-safe Trạng thái giảm harm khi system không chắc hoặc lỗi.

e. Nguồn tham khảo

Bài trước là Xây Evaluation Harness #26. Bài tiếp theo là Production Readiness Review #28.

Lưu ý giáo dục: “Safe” không phải nhãn trang trí. Chỉ đóng risk khi control, evidence, owner, escalation và residual-risk decision thật sự tồn tại; nếu chưa, giữ OPEN hoặc HOLD.