AI 專案風險管理教學：把「持續關注」變成預警指標與應變門檻

10月 23, 2026

原內容日期：2026-09-27。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

風險表上最危險的四個字：持續關注

很多專案都有風險清單，但每週更新時，只看到「進度風險：高」「人力風險：中」「處理方式：持續關注」。這種寫法看似有管理，真正的問題發生時，團隊仍然不知道該由誰、在什麼條件下、採取哪一個行動。

風險管理的價值，不是證明團隊想過很多壞事，而是讓大家在訊號出現時，能比問題更早一步採取行動。

AI 很適合協助整理大量專案資訊、找出不一致、改寫風險陳述與模擬不同情境。不過，若提示詞只是「幫我分析專案風險」，AI 也可能回傳一長串通用答案，甚至產生沒有依據的機率與影響分數。

要讓 AI 的輸出能真正使用，關鍵不是要求它列更多風險，而是建立一套有證據、有門檻、有責任人的結構。

第一步：風險、問題、假設、依賴與決策要分開

風險是尚未發生、未來可能影響目標的事件；問題是目前已經存在的障礙。假設是計畫成立所依賴、但尚未驗證的前提；依賴是外部交付、核准或條件；決策則需要有權者做選擇。

例如「付款測試已失敗」是問題，必須立即排除；「若付款問題未在招生前排除，學員可能無法完成交易」才是風險。若兩者混在一起，團隊很容易只更新風險顏色，卻沒有真正解決眼前問題。

第二步：用原因、事件與影響寫出完整風險

一項可管理的風險，可以用這個句型：

由於某個已知原因或條件，可能發生某個尚未確定的事件，導致對專案目標的具體影響。

「專案可能延誤」只有結果，無法告訴團隊要觀察什麼。改寫成「由於四個課程單元目前僅一個通過審查，且每週內容產能尚未驗證，可能無法在內部門檻前完成最低上線內容，導致縮小首梯範圍或延後」，就能進一步設計指標與行動。

第三步：沒有錨點，就不要假裝有精確機率

AI 很容易產生 60%、75% 這類看似專業的數字。但如果團隊沒有歷史資料或估算模型，這些百分比通常沒有意義。

更實用的方式，是先定義機率錨點。例如：「中」代表已出現兩項以上負面訊號，或關鍵假設尚未驗證；「高」代表觸發門檻已接近，若無額外行動很可能發生。

影響也要有共同定義。影響主要里程碑、合規或重要客戶，與只需局部重排的風險，不應被放在相同層級。

除了機率和影響，還要看接近程度與發生速度。有些風險能提前數週看見，有些則在訊號出現後 24 小時內就造成影響。後者即使機率較低，也可能需要先準備備案。

第四步：為每項重大風險設計預警指標

「持續關注」要改寫成可量測的指標，例如：

通過審查的交付物數量
阻塞缺陷數與最長未解時間
外部核准是否在承諾日前取得
每日新案件與未結案件數
實際投入工時與剩餘容量

指標還要有資料來源、更新頻率與維護人。否則即使門檻寫得漂亮，也沒有人能在正確時間取得數據。

第五步：門檻要直接連到行動

好的觸發規則長這樣：

當某項指標達到某個門檻，由某個角色在指定時限內啟動某項行動，並通知需要決策的人。

例如：「若距開課 14 天時，通過內部審查的單元少於 3 個，由課程負責人在 1 個工作天內提出縮小範圍與延後兩方案，交由產品負責人決定。」

這個門檻不是預測開課一定失敗，而是讓團隊提前約定：什麼情況下不再只觀察，而要進入決策。

第六步：準備四層方案，而不是只列一個備案

重大風險至少可以分成四層：

預防：降低事件發生的機率。
減輕：降低發生後的影響。
應變：門檻觸發後立即採取的行動。
退路：應變方案也失效時的保底做法。

每個方案都要標示所需時間、成本、前置條件與核准者。涉及退款、對外公告、採購、停機、個資或權限變更時，不能由 AI 自動決定或執行。

第七步：分清楚誰掌握、誰執行、誰接受

風險擁有者負責持續掌握風險；行動負責人完成特定措施；風險接受者則有權決定是否接受剩餘風險。這三個角色可能是不同的人。

風險表若只寫「專案團隊」，通常代表真正責任仍未確認。AI 可以指出欄位空缺，但不能替未出席的人接受任務。

用 AI 管風險，最重要的不是預測，而是提早約定

好的風險管理不追求每次都預測正確，而是讓團隊提早看見訊號、知道何時升級、準備可逆方案，並保留決策紀錄。

下次看到風險表上的「持續關注」，不妨多問四個問題：關注哪個指標？什麼門檻算惡化？觸發後誰做什麼？最後由誰接受剩餘風險？

只要這四題有答案，風險表就不再只是週報附件，而會成為真正的專案雷達。

行動呼籲

選一個你目前最擔心的專案風險，先不要評分。把它改寫成「原因 → 未確定事件 → 影響」，再補上一個可量測指標與一條觸發規則。你會很快看出，團隊缺的是資訊、行動，還是一個尚未做出的決定。

逐步操作

第 1 步：先定義本次分析的邊界

先寫清楚：

專案目標與成功標準
本次檢查期間，例如未來 2 週、6 週或一季
本次納入的工作範圍
不納入的範圍
可接受的損失與必須升級的條件
誰有權接受剩餘風險

若沒有邊界，AI 很容易列出大量泛用風險，清單看似完整，卻無法用來決策。

第 2 步：先分類，不要把所有不確定性都叫風險

用以下定義分類：

類型	判斷方式	例子	下一步
風險 Risk	尚未發生，但未來可能發生	若報名超過支援容量，回覆可能延遲	建立預警與應變
問題 Issue	已經發生或目前確定存在	付款測試目前失敗	進入問題追蹤與排除
假設 Assumption	計畫成立所依賴、但尚未驗證的相信	假設每週可投入 6 小時製課	指定驗證方式與期限
依賴 Dependency	交付需要外部人員或條件先完成	上線前需取得法務核准	管理承諾、期限與替代方案
決策 Decision	需要有權者選擇，不能靠分析自動決定	首梯招生上限要設 20 或 40 人	建立決策題與期限

同一件事可能同時帶出不同記錄。例如「付款測試失敗」是問題；它若未在上線前排除，可能造成「學員無法完成付款」的未來風險。

第 3 步：建立有來源編號的訊號底稿

蒐集可用資料並編號，例如：

S01：專案計畫與里程碑
S02：任務清單與實際進度
S03：會議紀錄
S04：缺陷或問題清單
S05：人員容量與排程
S06：供應商或跨部門承諾
S07：測試結果
S08：客戶、學員或使用者回饋

每一項風險都要能回指來源。若只是團隊經驗判斷，也要標示「專家判斷」，不要偽裝成已驗證事實。

第 4 步：用「原因—事件—影響」重寫風險

推薦句型：

由於【已知原因或條件】，可能發生【尚未確定的事件】，導致【對目標的具體影響】。

錯誤寫法：

進度可能延誤。

較好寫法：

由於四個單元目前只完成一個，且內容製作每週可用時間尚未驗證，可能無法在內部審查門檻前完成最低上線內容，導致首梯縮小範圍或延後開課。

原因應是目前可觀察的條件；事件必須尚未確定；影響要連回專案目標。

第 5 步：將已發生的部分移到問題清單

如果一句話使用「已經」「目前無法」「已延遲」「尚未收到且已逾期」，通常已是問題。

處理方式：

建立問題編號。
記錄影響、負責人、排除期限與驗證證據。
再問：「這個問題若未解決，接下來可能造成什麼風險？」

這能避免風險清單成為問題的停車場。

第 6 步：先定義評分錨點，再評機率

不要直接叫 AI 填 70%。如果沒有歷史基準，應使用有文字定義的區間。

示例：

等級	機率錨點
1 低	目前沒有負面訊號；前置條件均按計畫完成
2 中低	有一項弱訊號，但仍有足夠緩衝
3 中	已出現兩項以上訊號，或關鍵假設尚未驗證
4 中高	主要前置條件落後，且緩衝不足
5 高	觸發門檻已接近，若無額外行動很可能發生

若公司已有量化標準，優先採用正式標準；若沒有，就保留「依據不足」而不是編造精確百分比。

第 7 步：分面向評估影響

至少檢查：

時程
成本
範圍
品質
資安與隱私
法規或合規
客戶與使用者
營運與聲譽

影響分數應取決於已定義的門檻。例如：延誤 1 個工作天與延誤正式對外承諾日，不應只靠主觀感受判斷。

第 8 步：補上接近程度與發生速度

兩項機率與影響相同的風險，處理順序仍可能不同：

接近程度 Proximity：最快何時可能發生？
發生速度 Velocity：從訊號出現到造成影響，有多少反應時間？
可偵測性 Detectability：發生前是否容易被看見？

例如內容延誤通常能逐週觀察；支付中斷可能在短時間內直接阻斷交易。後者即使機率較低，也可能需要先準備退路。

第 9 步：區分三種責任

每項重大風險至少要有：

風險擁有者：持續掌握整體風險並提出建議。
行動負責人：完成某一項預防或應變任務。
風險接受者：有權決定是否接受剩餘風險。

「專案團隊」不是合格的負責人。請填角色或具名人員，並確認對方已知情；AI 不能替未出席的人接受任務。

第 10 步：設計早期預警指標

早期預警指標必須回答：

量什麼？
從哪裡取得？
多久更新一次？
誰維護？
哪個方向代表惡化？

例子：

已完成並通過審查的單元數／計畫單元數
關鍵測試通過率與阻塞缺陷數
待回覆問題的數量與最長等待時間
實際工時與剩餘容量
測試報名頁的訪客至意向登記轉換率

第 11 步：把「持續關注」改成觸發門檻

一個可用的觸發規則包含：

當【指標】達到【門檻】，由【角色】在【時限】內啟動【行動】，並通知【對象】。

例如：

若距預定開課 14 天時，通過內部審查的單元少於 3 個，由課程負責人在 1 個工作天內提出「縮小首梯範圍」與「延後」兩個方案，交由產品負責人決定。

門檻不是預言，而是事先約定的行動界線。

第 12 步：建立四層應對方案

層次	目的	例子
預防 Prevent	降低事件發生機率	提前完成高風險單元腳本
減輕 Mitigate	降低事件發生後的影響	首梯只開必要模組
應變 Contingency	觸發後立即採取的方案	暫停招生並通知已登記者
退路 Fallback	應變方案也失效時的保底	改為人工付款確認或退款流程，但須經授權與合規審查

每個方案都要記錄所需時間、成本、前置條件與核准者。沒有預留資源的備案，通常只是願望。

第 13 步：評估剩餘風險

採取措施後，風險不一定歸零。請重新評估：

仍可能發生的事件
仍可能造成的影響
新增的次生風險
是否落在可接受範圍
誰有權接受
接受有效到何時

例如縮小首梯人數可降低支援壓力，卻可能增加「樣本不足以判斷市場需求」的風險。

第 14 步：建立固定檢視頻率與升級格式

建議依風險節奏安排：

高接近、高速度：每日或每兩日檢視
中等風險：每週檢視
低風險、遠期風險：雙週或里程碑檢視

每次更新至少保留：

上次狀態與本次狀態
變化原因
新證據
已完成行動
下一個門檻
是否需要決策

第 15 步：設定關閉、轉問題與重新開啟條件

風險不能因為「最近沒人提」就消失。請明確設定：

關閉條件：風險期間已過、原因消失或控制措施已驗證。
轉問題條件：未確定事件已經發生。
重新開啟條件：新的證據讓風險再次成立。
經驗回收：實際是否發生、預警是否有效、門檻是否太早或太晚。

可直接複製的完整提示詞

以下內容可貼入一般生成式 AI 工具。請先依公司規範去識別化，再替換中括號欄位。

【角色】
你是一位審慎、重視證據的專案風險分析助手。你擅長把零散的專案資料整理成可行動的風險雷達，但無權替專案負責人接受風險、承諾資源、指派未確認的人員，或對外發布通知。

【任務】
請根據我提供的資料：
1. 區分風險、已發生問題、假設、依賴與待決策事項。
2. 將風險改寫為「原因 → 未確定事件 → 對專案目標的影響」。
3. 找出支持與反駁每項風險的證據，標示來源編號。
4. 依我提供的錨點評估機率、影響、接近程度、發生速度與可偵測性。
5. 設計可量測的早期預警指標、資料來源、更新頻率與觸發門檻。
6. 提出預防、減輕、應變與退路方案，標示前置條件、成本或資源需求。
7. 區分風險擁有者、行動負責人與風險接受者；若未提供，標示「待指定」。
8. 評估措施後的剩餘風險與可能新增的次生風險。
9. 產出可帶進專案週會的一頁摘要與升級訊息草稿。

【專案基本資料】
- 專案名稱：[專案名稱]
- 專案目標：[可驗證成果]
- 主要里程碑：[日期／事件]
- 本次分析期間：[起訖或未來幾週]
- 納入範圍：[範圍]
- 不納入範圍：[範圍]
- 主要利害關係人：[角色]
- 可接受損失或容忍門檻：[若未知請填未知]
- 風險接受權限：[角色；若未知請填未知]

【分類定義】
- 風險：尚未發生、未來可能發生並影響目標的事件。
- 問題：目前已發生或確定存在，需要排除或控制。
- 假設：計畫成立所依賴、但尚未驗證的前提。
- 依賴：需要外部人員、交付物、核准或條件先完成。
- 決策：需要有權者選擇的事項。

【輸入資料格式】
請盡量依下列格式提供，每一筆保留來源編號：

來源編號｜日期｜來源類型｜內容｜狀態｜負責角色｜證據連結或備註
[S01]｜[日期]｜[計畫／會議／測試／任務／回饋]｜[內容]｜[已確認／口頭回報／待驗證]｜[角色]｜[備註]

目前已知事項：
[貼上專案資料]

目前風險清單（如有）：
[貼上既有風險表]

【評分錨點】
機率：
1 低＝目前沒有負面訊號，前置條件按計畫完成
2 中低＝有一項弱訊號，但仍有足夠緩衝
3 中＝有兩項以上訊號，或關鍵假設尚未驗證
4 中高＝主要前置條件落後，且緩衝不足
5 高＝觸發門檻已接近，若無額外行動很可能發生

影響：
1 輕微＝不影響主要里程碑，可由既有資源吸收
2 有限＝需局部重排，但不改變主要承諾
3 中等＝影響一項主要交付、成本或使用者體驗
4 重大＝影響主要里程碑、合規、關鍵客戶或跨部門承諾
5 嚴重＝可能造成安全、重大法規、重大財務或不可逆聲譽影響

接近程度：[請填組織定義，或使用 7天內／8至30天／31天以上]
發生速度：[快速＝訊號後24小時內造成影響；中等＝2至7天；緩慢＝超過7天]

【限制與判斷規則】
1. 不得捏造日期、數字、機率、成本、政策、承諾或負責人。
2. 沒有歷史資料時，不得產生看似精確的百分比；改用文字錨點並說明依據不足。
3. 已發生事項必須列為問題，不得只留在風險清單。
4. 使用者提出的希望日期不等於正式期限；口頭想法不等於核准。
5. 沉默、被副本或參加會議不代表同意或接受風險。
6. 每項結論都要回指來源編號；沒有來源時標示「專家判斷／待驗證」。
7. 早期預警指標必須可量測，觸發門檻必須能連到具體行動。
8. 若行動涉及對外通知、採購、加班、退款、停機、個資或權限變更，標示「需人工核准」。
9. 若資料不足，先完成可完成的分析，再列出最多 7 個高價值確認問題。
10. 不要因為需要填滿表格而新增泛用風險。

【輸出格式】
A. 主管一分鐘摘要
- 目前風險態勢
- 前三項需要注意的風險
- 已觸發門檻
- 本週需要的決策

B. 分類表
編號｜原始敘述｜分類（風險／問題／假設／依賴／決策）｜判斷理由｜來源

C. 風險登錄表
風險編號｜原因｜未確定事件｜影響｜支持證據｜反向證據｜機率｜影響｜接近程度｜發生速度｜可偵測性｜優先級｜信心｜風險擁有者｜下次檢視日

D. 早期預警與觸發矩陣
風險編號｜指標｜目前值｜資料來源｜更新頻率｜黃色門檻｜紅色門檻｜觸發後行動｜行動負責人｜完成時限｜需核准者

E. 應對方案
風險編號｜預防｜減輕｜應變｜退路｜前置條件｜所需資源｜完成證據｜剩餘風險｜次生風險

F. 三種情境
- 基準情境
- 受阻情境
- 極端但合理情境
每種情境列出訊號、影響、可逆決策與不可逆決策。

G. 兩週行動清單
優先序｜行動｜負責角色｜期限｜依賴｜完成證據｜對應風險

H. 升級訊息草稿
用 120 至 180 字寫出：事實、風險、已採取行動、選項、需要誰在何時前決定什麼。不得替決策者做決定。

I. 待確認問題
最多 7 題，依「回答後最能改變風險判斷」排序。

【最後自我檢查】
輸出前請逐項檢查：
- 是否把已發生問題誤寫成風險？
- 是否把原因、事件與影響混在一起？
- 是否出現沒有來源的精確數字？
- 是否每個高優先風險都有指標、門檻與行動？
- 是否清楚區分風險擁有者、行動負責人及接受者？
- 是否將建議誤寫成已核准決定？
- 是否標示資料缺口、剩餘風險及次生風險？

可替換欄位速查

[專案名稱]：例如「AI 辦公實戰迷你課首梯試行」
[可驗證成果]：例如「完成首梯交付並蒐集結構化回饋」
[主要里程碑]：內部審查、付款測試、開放報名、正式開課
[分析期間]：建議配合專案節奏，例如未來 6 週
[容忍門檻]：例如最大招生人數、可接受延誤或不可碰觸的隱私界線
[來源資料]：任務表、會議紀錄、測試結果、容量表、外部承諾

實際教學範例

專案背景

某團隊預計在 6 週內推出「AI 辦公實戰」小型付費課程，以首梯驗證內容價值與交付流程。

目前資料：

S01：規劃四個單元，目前僅第一單元通過內部審查。
S02：內容負責人估計每週可投入 6 小時，但尚未連續兩週驗證。
S03：報名頁已有草稿，尚未完成手機版檢查。
S04：付款測試已執行一次，測試交易未成功。
S05：電子報名單共 320 筆，但目前資料沒有標示每筆的行銷同意狀態。
S06：首梯支援由一人負責，尚未定義每日可處理量。
S07：團隊沒有過往付費課程轉換率基準。

第一步：先分類

編號	原始事項	正確分類	理由
C01	付款測試未成功	問題	已經發生，應立即排除
C02	每週可投入 6 小時	假設	尚未以實際工時驗證
C03	名單可用於招生通知	假設／合規待確認	缺少同意狀態，不能直接使用
C04	首梯招生上限	決策	需由有權者依支援容量決定
C05	其餘單元可能趕不上審查門檻	風險	未來可能發生
C06	課程是否能吸引足夠付費者	風險	尚未發生，且缺少歷史基準

第二步：建立風險陳述

R01 內容就緒風險

由於四個單元目前僅一個通過審查，且每週 6 小時產能仍是假設，可能無法在開課前 14 天完成最低上線內容，導致縮小首梯範圍或延後開課。

R02 付款中斷風險

由於測試交易目前失敗且排除時間未知，可能在開放報名時仍無法完成付款，導致學員流失、人工處理增加或延後招生。

注意：測試失敗本身記錄在問題清單；「開放報名時仍無法付款」才是未來風險。

R03 名單誤用風險

由於現有名單未標示行銷同意狀態，若未完成合法性與內部政策確認就寄送招生訊息，可能造成隱私、合規或信任損害。

R04 支援超載風險

由於首梯僅一人支援，且每日可處理量尚未量測，若報名人數或問題量超過容量，可能造成回覆延遲與學習體驗下降。

R05 需求不足風險

由於團隊沒有付費轉換率基準，且尚未進行小規模意向驗證，可能在正式投入完整製作後發現付費需求不足，導致投入無法回收或需要重新定位。

第三步：預警與觸發矩陣

以下數字僅為案例中的管理門檻，不代表通用標準。

風險	早期指標	黃色門檻	紅色門檻	觸發後行動
R01 內容就緒	通過審查的單元數	距開課 21 天少於 3 個	距開課 14 天少於 3 個	提出縮小範圍與延後兩方案，交由產品負責人決定
R02 付款中斷	端到端測試結果	連續一次失敗且原因未知	開放報名前 3 個工作天仍未通過	暫緩公開付款入口，啟動核准過的替代流程或延後
R03 名單誤用	已確認同意狀態比例	尚未完成盤點	寄送前仍無法確認	停止使用未確認名單，交由法務／隱私負責角色判斷
R04 支援超載	每日新案件與未結案件	連續 2 日超過設定容量	最長等待超過服務門檻	限制招生、增加支援或調整服務承諾，需由負責人核准
R05 需求不足	意向頁訪客、登記與願付回覆	樣本不足以判斷	到決策日仍未達事先設定的最低驗證量	縮小製作範圍、延長驗證或停止投入，由產品負責人決定

第四步：行動方案示例

風險	預防	減輕	應變	退路
R01	先完成核心單元腳本，固定每週審查	將延伸內容改為課後素材	首梯只交付已驗證核心內容	延後開課並通知已登記者，需核准
R02	提前完成多裝置端到端測試	準備人工核對流程與工作量估算	暫停付款入口並公告處理方式	取消交易或退款，須按正式政策執行
R03	先盤點同意欄位與來源	只使用可證明同意的對象	停止寄送未確認名單	改用公開內容與自然流量驗證
R04	先用試辦量測每案處理時間	設計 FAQ 與固定答覆時段	限制名額、調整回覆時效	暫停新增名額並安排退款或轉梯，需核准
R05	先測試問題、受眾與願付意向	先做最低可行版本	延長小規模驗證	停止本輪投入並保存可重用內容

第五步：三種情境

基準情境

三個核心單元在內部門檻前完成。
付款流程通過測試。
使用已確認同意的受眾進行小規模招募。
首梯人數受控，支援量可量測。

受阻情境

內容僅兩個單元就緒。
付款問題已修正，但行動版仍未驗證。
團隊可選擇縮小首梯範圍或延後，而不是假裝照原計畫進行。

極端但合理情境

付款在招生日前仍無法使用。
名單同意狀態無法釐清。
不應臨時繞過合規要求；可改為延後、公開候補登記或停止本輪招生。

一分鐘主管摘要示例

首梯試行目前有兩項需立即處理的缺口：付款測試已失敗，屬於問題；現有名單的行銷同意狀態不明，寄送前必須完成確認。內容進度屬中高風險，距開課 21 天若仍少於三個單元通過審查，將進入黃色門檻。建議本週完成付款根因排除、名單合法性判斷與內容產能實測，並由產品負責人在門檻觸發時選擇縮小範圍或延後。團隊不應在未確認前公開承諾日期、使用名單或啟用替代付款方式。

升級訊息示例

目前四個單元僅一個通過審查，且每週 6 小時製作產能尚未驗證。若距開課 14 天仍少於三個單元就緒，首梯完整範圍將無法按計畫交付。團隊已先完成核心單元排序並安排每週審查。請產品負責人在門檻觸發後 1 個工作天內，決定採「縮小首梯範圍」或「延後開課」；兩方案的學員影響與所需通知將另附。此訊息不代表已決定延後。

常見錯誤、隱私與使用注意事項

常見錯誤

1. 風險只寫成名詞

「供應商風險」「進度風險」無法行動。至少補上原因、事件與影響。

2. 把已發生問題留在風險表

問題需要排除期限與完成證據；只標成紅色風險，反而容易延誤處理。

3. AI 自動填入 75% 機率

若沒有歷史資料、樣本或正式估算方法，精確百分比只是裝飾。改用有定義的文字錨點。

4. 只用「機率 × 影響」排序

同分風險可能有完全不同的接近程度、發生速度與可偵測性。不要迷信單一總分。

5. 每項都列為高風險

這通常代表錨點沒有定義，或團隊沒有說清楚風險容忍度。

6. 負責人填「大家」或「專案組」

責任必須落到明確角色；仍需由真人確認接受任務。

7. 只有預防措施，沒有觸發後行動

預防不一定成功。重大風險要有應變與退路。

8. 觸發門檻無法量測

「情況惡化時」「需求太低時」仍然模糊。要說明指標、資料來源與判定時間。

9. 把建議寫成核准

AI 產生的「建議延後」不是正式決議。輸出中要標明決策者與狀態。

10. 風險永不關閉

每項風險都要有關閉、轉問題與重新開啟條件，避免清單無限膨脹。

資料隱私注意事項

送入 AI 前，先移除或代碼化：

客戶、學員、員工姓名與聯絡方式
Email 名單與同意紀錄
未公開價格、營收、成本與預算
合約條款、供應商報價與談判內容
帳號、API 金鑰、付款資訊與系統憑證
尚未公開的產品策略與上市日期
個人績效、健康、申訴或勞資資料

若組織未核准外部 AI 處理資料，請只使用去識別化摘要、虛構範例或公司核准的環境。

使用注意事項

AI 輸出是風險工作底稿，不是正式核准文件。
高風險判斷要由了解業務、法規與技術的人複核。
觸發門檻要先取得團隊共識，不能事後為符合結果而更改。
涉及安全、資安、個資、法規、重大財務或人事議題時，依正式治理流程升級。
不要把「沒有證據」解讀成「沒有風險」。
也不要把「可以想像」直接寫成高風險；需要來源、訊號或合理機制。
風險接受必須記錄範圍、期限、接受者與剩餘影響。