我做 AI 治理與模型風險工作，常需要在技術語言和一般人的問題之間來回翻譯。工程師問的是指標有沒有改善，主管問的是能不能上線，受影響的人問的卻可能是：「如果它判錯我，接下來怎麼辦？」我不認為第三個問題比較不專業。相反地，若一份報告回答不了它，圖表再完整也少了最重要的一頁。
我們先定義問題。把模型風險說成人話，不是把複雜內容刪到只剩一句「請放心」。它是保留必要的前提、限制與不確定性，讓沒有參與開發的人仍能理解系統會做什麼、在哪裡可能出錯，以及自己有什麼選擇。這件事比找一個更容易懂的比喻難，因為你必須先知道哪些複雜度不能省略。
一張準確率圖，回答不了所有問題
假設一個模型協助篩選大量申請資料，報告寫著整體準確率很高。這個數字可能有用，但它沒有直接告訴申請者：被錯誤排除的機率是多少？不同條件的人是否面對相同的錯誤？結果是建議還是最終決定？能否要求真人複查？這是假設案例，並非我任職單位的產品或實際事件。
技術報告往往很擅長描述模型在測試資料上的表現，卻不一定說清楚使用現場的後果。若一次誤判只讓畫面多顯示一個不相關項目，與誤判會讓人失去機會，風險的重量完全不同。評估不能只問「錯幾次」，還要問「錯在誰身上、造成什麼事、能不能補救」。
把名詞換成白話，還不夠
有些說明把「假陽性」改寫成「系統誤以為有問題」，讀起來確實容易一些。但若沒有交代被標記後會發生什麼，使用者仍無法判斷影響。我會試著寫成：「系統可能把不符合條件的人標成需進一步檢查；這個標記不應直接決定結果，當事人可要求複核。」後半句才讓人看見制度如何處理錯誤。
同樣地，「資料可能存在偏差」如果只停在這裡，也很像一張萬用免責貼紙。更有用的說法應指出：哪些人較少出現在訓練或測試資料中、對這些人的判斷因此有多大不確定，以及上線後準備怎麼監測。若證據不足，就直接寫不足；不要用抽象名詞把未知包成已經處理完畢。
主管需要的是決策條件，不是顏色漂亮的燈號
把風險濃縮成綠、黃、紅三格很方便，但顏色會遮住判斷依據。兩個同樣被標成黃色的問題，一個可能是可以透過人工複核控制的誤差，另一個可能是根本沒有足夠資料確認影響。若它們被放進同一格，會議很容易變成討論「黃燈能不能先過」，而不是討論各自還缺什麼證據。
我更希望看到可以採取行動的句子：「在完成某組使用者測試之前，不把模型結果用於最後決定」；或「若申訴量超過預先設定的範圍，暫停自動化流程」。這些條件也需要持續檢驗，並非寫了就保證安全，但至少讓決策者知道自己接受了什麼風險、承諾了什麼補救。知道風險後仍做決策的人，必須能對受影響者說明並承擔。
說明書應讓人找得到出口
若一個人收到系統產生的不利結果，最需要的未必是模型架構圖。他可能先想知道：這個結果依據哪些資料？資料錯了可以更正嗎？是否有人能重新看一次？多久會得到回覆？這些不是產品說明末尾的附錄，而是系統對人的基本交代。
因此，我會把公開說明分成幾個層次：先用短文說清用途、影響與申訴方式；再提供較完整的評估方法和限制；專業審查者則能追到測試設計與版本變更。不同讀者不必看同樣長的文件，但關鍵資訊不能只藏在最深的一層。透明不是把資料一股腦丟出去，而是讓需要的人找得到、看得懂、用得上。
最難寫的句子，往往是「我們還不知道」
開發團隊可能擔心承認未知會讓產品失去信任。我理解這份壓力；但如果不確定性會影響人的機會、資源或名譽，隱藏它只會把代價轉給使用者。說明「目前沒有足夠證據支持在這種情境使用」，比先做出篤定承諾、事後才補救更負責。
當然，白話說明也可能過度簡化。我會用一個問題檢查自己的文字：讀者看完之後，會不會以為系統比實際更準、更公平，或更容易退出？如果會，就要補回被刪掉的前提。清楚不等於順耳，誠實也不保證讓每個人滿意。
我想寫的是能被使用的規則
我一直希望有一天能寫出一般人看得懂的 AI 權利指南。這個目標對我而言，不是把艱深術語全部換成可愛插圖，而是讓一個人在面對系統時，知道自己能問什麼、要求什麼、拒絕什麼。若一份文件只讓專家彼此點頭，卻無法幫助當事人釐清選擇，它仍有缺口。
所以，下次看到「模型已通過評估」這句話，我會繼續追問：評估了哪些情境？誰沒有被充分測到？錯誤發生時誰負責？誰可以要求改變？把這些問題寫進報告，可能讓版面不那麼漂亮，卻能讓一個技術決策真正接受檢驗。對我來說，這才是把模型風險說成人話的目的。