從「找出風險」到「管理風險」
Day 3 用 OWASP 的清單，把我的 Chatbot 目前已知、可能存在的風險都列出來了。但列出風險只是第一步，接下來我將進行一個系統該怎麼系統性地管理這些風險，而不是東補一塊、西補一塊。

這時候我借用的是 NIST（美國國家標準與技術研究院）整理的 AI 風險管理框架。相較於 OWASP 的清單比較像這裡有哪些坑，NIST 這份框架更像是一套管理流程，告訴你怎麼有系統地面對風險而不只是列出問題。

這份框架給我一個很重要的提醒：資安不該是工程師在系統快上線前才臨時加上去的一道防線，而是應該在系統規劃的最初期，就被納入整個產品生命週期去考慮。 如果資安永遠是最後才補的功課，代表這個產品從設計階段開始就沒有把風險當一回事。

NIST AI RMF 的四個核心功能
這份框架把風險管理拆成四個階段，我用自己的話重新解釋一次:

1. Govern(治理)
   先確立一套規則跟責任分工。簡單說就是「這個系統的風險，誰該負責看？出事了誰要處理？」對我個人專案來說，這一步就是我自己要先想清楚：這個 Chatbot 的資安責任，現階段全部由我自己負責，之後如果要正式上線，治理層級要拉高。
2. Map(盤點)
   找出這個系統實際上有哪些風險。這就是我 Day 3 做的事——把 OWASP 的清單對照到自己的系統上。
3. Measure(量測)
   針對盤點出來的風險，實際去測量有多嚴重。這正是我做的 Baseline 測試——20 題手動攻擊，量出目前的 Attack Success Rate 大概是 27%。有數據才有辦法追蹤進步了沒有。
4. Manage(管理)
   根據量測結果，決定要優先處理哪些風險、怎麼分配資源去修補。這是我接下來 Blue Team 階段要做的事，先處理 System Prompt Leakage 這個目前最明確的破口，其他標記為「需留意」的項目排在後面處理。

把我的專案套進 NIST AI RMF 四個階段

為什麼要多此一舉套一個框架？
有人可能會問：反正都是同一件事，幹嘛多繞一圈套框架？

我希望在這次的實作在套上這個框架之後，能強迫自己不要只停在測試好玩的階段。如果沒有 Govern 這一步，我很容易忘記去想這個系統萬一真的上線，誰該為資安負責；如果沒有 Measure，我可能會靠感覺說這裡好像有點危險，而不是拿出實際數字說話。這份框架逼我把整個實驗，從「玩具專案」往「像樣的資安治理流程」推進一步，我希望這個系列呈現出的不是只有攻防手法，而是有沒有系統性思維。

明天預告
Day 5 會用 MITRE ATLAS 這個框架，站在「攻擊者」的角度，設計一條完整的攻擊鏈，幫接下來的 Red Team 階段畫出更清楚的路線圖。

本系列所有病患資料皆為人工生成之虛構資料，不涉及任何真實病患。GitHub Repo:medical-ai-security-lab