靖本

延續系列文章的風險與風險管理，目前討論到的都是需要管理的目標和管理時的要點，但說到底誰來管理這些風險？又是誰來為識別與提出這些風險呢？ 因此，在討論完風險後，最重要的是了解在這些管理活動中，到底有哪些角色需要參與，才能讓整個風險管理活動更加周全。從直觀的角度來看，通常會想到組織內人工智慧相關技術的資深工程師，如資料科學家、模型工程師等，又或者是品質系統或治理單位的成員等，但實際當我們在思考人工智慧技術應用到組織內時，這些角色（Actor）應該考量所有會影響 AI 系統如何被設計、建置、部署、使用、評估，或會受到系統影響的人。 NIST AI RMF 認為人工智慧之於組織與人，並不是技術單方面產生影響，而是人與技術之間持續互動，也就是社會技術（Socio-Technical）的視角。因此,想要正確地理解所有利害關係人得先回到該規範第二章中所描繪的 AI 系統的生命週期與關聯面向，如下圖： 此圖1來源自 OECD，並且針對 Test, Evaluation, Verification, and Validation（TEVV）和 AI system 的 operational context 進行了強調與調整。從圖來看，第二圈指出思考模型的四個面向，而最外環則指出 AI 系統生命週期的各階段。不過整張圖的重點在於一件事，也就是 AI 系統的生命週期並不只是在於模型開發。AI 系統的生命週期涵蓋從資料蒐集與處理、模型建立、部署與使用，到營運與監控等活動，並且形成持續迭代的循環。

風險管理就是管理風險，聽起來好像很直觀，但具體來說要做哪些事情呢？是對風險進行評估？是來一場審查？是進行一次稽核？或者進行某種測試？感覺聽起來沒問題，但感覺好像又漏了些什麼！ NIST AI RMF 再一次沿用了 ISO 31000:2018 對於風險管理的定義： 組織為了針對風險進行方向引導與控制，而有系統地協調各項管理活動 簡單說，風險管理並不是進行某一種單一行動，而是協調多種管理活動，讓組織在面對風險時能夠建立一致的方向、做出適當的判斷，並採取相應的控制措施。 因此，風險評估、審查、稽核或測試都可能是風險管理的一部分，但單獨進行其中任何一項，都不能代表完整的風險管理。在後續的文章中，我們會逐步地去瞭解 NIST AI RMF 在風險管理上所主張的相關活動與舉措，但在進一步了解這些方法前，最重要的是有正確的 mindset，因為這樣才能讓自己在規劃與執行風險管理時仍持續地保持謹慎並且尋求更好的做法，而建構 mindset 的最好方法，不外乎就是了解風險管理的棘手挑戰。NIST AI RMF 在這裡進一步提出了四個 AI 風險管理需要面對的重要課題： 1. 風險衡量 組織的資源永遠都是有限的。為了能夠正確地將資源投到關鍵的風險，對風險進行衡量是相當重要的舉措。在面對尚無有效衡量方式或尚未進行衡量的風險時，很難憑藉直觀方式來判定是否需要投入資源，畢竟未能被衡量的風險，既不能假定是高風險也無法認為不能衡量就是低風險，而這也是規範裡開宗明義所指出的一個要點。 常見的風險衡量方式多半會設計一些評估條件並且透過風險矩陣來進行。不過聽起來貌似簡單，但面對 AI 應用，NIST 針對衡量又提出了七類的挑戰：

這些年，AI 的蓬勃發展和誘人的可能性，早已讓組織一股腦地投入 AI 相關應用與探索，以便提升自身的競爭力。不過隨著技術漸漸落地，應該也不難發現 AI 所帶來的不確定性。比方說，即便發送相同問題的請求，AI 也無法保證次次給出相同或預期的結果，而且這還不討論近幾年大語言模型的幻覺現象。因此，想要從 AI 獲得好處，我們需要思考的是如何管控這些不確定性，並且做出合理的權衡決策。 NIST AI RMF 便是用來協助組織管理 AI 所帶來的風險與影響，讓組織能在控制潛在危害的同時，真正取得 AI 所帶來的效益。 想要了解這個工具，首先得先來聊聊 Risk 在風險管理情境下的概念。在日常情境下，聽到 Risk 這個字多半會先想到負面的事件。不過在風險管理的角度上來看，Risk 卻有更為寬廣的定義。 ISO 31000 定義 Risk2 為不確定性對既定目標所產生的影響(effect of uncertainty on objectives)

生產！生產！生產！ 每當有新的技術出現時，肯定會以生產力倍增等讓人目亂神迷的字彙登場，不管是 20 年前的教你事半功倍的敏捷，還是十年前小步迭代快速前進的 DevOps，誰不想當菁英團隊呢？不只是老闆想，工程師也能從創造過程中得到滿滿的成就感。這次的 AI 風則吹得更強，不僅有快和生產力，連同取代誰取代誰的新聞也不停地被宣傳。 AI 已經成了不可逆的趨勢 軟體工程師或多或少都會使用 AI 工具來協助自己的開發，更何況現在大型組織甚至會以公司政策的方式推廣。用的人是變多，但相信的人呢? 從 2025 年的 stackoverflow 報告來看，卻只有 33% 的工程師相信 AI 的產出1。當然用或不用看個人需求，但新聞卻一直訴說著，AI 正在取代軟體工程師！組織內會有多少比例用 AI 取代之類云云。不過，隨著時間過去，這些訊息看起來顯得開始漸漸冷靜。開始有科技龍頭表示，他們有著新的軟體人才需求。說到底，到底怎了？，這訊息，這日子還要不要過了呢？ AI 變動了軟體開發過程的成本配比 一個軟體開發的團隊，不管怎樣配比，肯定寫程式的人比較多。畢竟這是一個現實的議題，需求沒實現出來，一切也就都白搭了。只是當軟體開發出來，就會發現還有很多工作等著要處理，所以全端、全循環、一條龍等工程師頭銜總是能夠喚起工程師們嘴角的苦笑。不過現在這個程式生產活，貌似有了一個沒心沒肝又不喊累的 AI 可以頂上了。 哇~瓶頸有解了！