AI 治理是什麼？企業從風險分級到落地的完整指南

從客服查資料，到 AI Agent 執行工作，企業如何把責任、權限與證據接起來。

研究整理｜天地人學堂。資料查核基準｜2026 年 10 月 21 日。

公司裡每多一個 AI 功能，就多了一個值得說清楚的決定：它能讀什麼、能做什麼、誰確認結果，以及什麼情況必須停下來。這篇文章從企業日常工作出發，說明 AI 治理的目的、國際框架與法規，並把它們轉成清冊、風險評估、測試、人工覆核、事故處理及 90 天行動計畫。

本文適合企業經營者、部門主管、人資、資訊、資安、法務與採購人員。全文中的零組件公司是虛構教學案例；自訂分級、時程及成本算式均為操作示例。法規內容依查核日的官方資料整理，適用於特定企業的結論仍須結合實際用途、角色、法域與契約判斷。

閱讀導航：先從你正在面對的決定開始

全文目錄

• 01．AI 治理是什麼？先問 AI 被允許替公司決定什麼
• 02．從採購 AI 到管理業務決策：治理單位應該是使用情境
• 03．AI 治理、AI 倫理、資料治理與資安，有什麼不同？
• 04．NIST AI RMF 怎麼用？把四個功能連到一項真實工作
• 05．ISO、NIST 與 OECD 如何搭配？先分清楚每一套資料在回答什麼
• 06．誰應該負責 AI 治理？把權責交給能作決定的人
• 07．AI 治理從盤點開始：你真正要管理的是哪一項工作
• 08．AI 風險評估怎麼做：先找出傷害路徑，再決定管制強度
• 09．資料與供應商治理：從一句「不拿來訓練」追問到完整資料流
• 10．RAG 與知識庫治理：答案有引用，還要確認引用對不對
• 11．如何驗收 AI：把「看起來不錯」轉成可比較的證據
• 12．人工覆核如何有效：讓人有能力、有資訊，也有權拒絕
• 13．AI Agent 治理：當模型能採取行動，權限就成為核心設計
• 14．上線後的 AI 治理：版本、事故與退場都需要有人接手
• 15．歐盟 AI Act：先辨認角色、用途與市場，再確認義務
• 16．台灣企業如何接軌國際與本地治理
• 17．90 天如何做出能運作的 AI 治理
• 18．預算、衡量指標與董事會應追問的問題
• 19．AI 治理常見問題：企業最容易卡住的 12 個判斷
• 20．從第一次會議開始，讓 AI 治理真正進入工作

01．AI 治理是什麼？先問 AI 被允許替公司決定什麼

先看一個虛構教學情境。下文的零組件公司、人物分工與操作安排，均為本文設計的說明案例，不代表天地人的客戶、實際專案或已發生的成效。

一家約 120 人的零組件公司，想讓客服不必每天翻找產品手冊。資訊人員把核准的產品文件接進 AI，客服輸入問題，就能取得附有出處的回答草稿。最初的需求很單純：縮短查資料的時間，回答仍由客服確認後寄出。試用一陣子，業務主管提出下一步：既然 AI 已經讀得懂問題，能不能順便查庫存、產生報價，再把符合條件的退款直接送進系統？

這個提議沒有換掉公司的核心業務，卻改變了 AI 在業務裡的位置。查手冊時，AI 主要提供參考；形成報價時，回答可能變成對客戶的商業承諾；啟動退款時，系統開始改變公司的帳務與資金狀態。若討論仍停留在「哪一個模型回答比較好」，公司就漏掉了更重要的問題：誰可以授權它做這些事？它判斷錯誤時，由誰發現、誰暫停、誰向客戶說明？

本文對 AI 治理的工作定義是：組織為了讓 AI 的使用符合業務目的、可接受風險與應負責任，建立並持續執行的決策權、規則、控制與證據安排。這是一個便於企業操作的綜合定義，不是某一部法律的逐字定義。它管理的對象包含 AI 系統，也包含採購、資料、使用者、外部供應商，以及受到結果影響的人。

這個定義有兩個重點。第一，治理必須連回公司想達成的成果。若使用 AI 是為了縮短客戶等候時間，就不能只統計員工登入次數；若目的是提升報價品質，就必須看錯價、重工與客訴，而非只看生成速度。第二，治理必須指出誰有權作決定。沒有權責，規則會成為建議；沒有控制，建議會停在文件；沒有證據，公司無法判斷制度是否真的運作。

NIST 將 AI 風險管理框架定位為自願採用的資源，協助組織在 AI 的設計、開發、使用與評估中納入可信賴性考量。它關心的影響也包括個人與社會，並未把範圍限縮成公司的技術損失。[A01] 對企業而言，這提醒我們：AI 治理既要問「公司會損失多少」，也要問「誰會承受錯誤，而那個人是否有能力提出異議」。

從一份政策，走到能改變行為的制度

在這家虛構公司裡，第一版規定可能只有一句：「使用 AI 時，不得上傳機密資料，重要內容須人工確認。」這句話有方向，卻還不足以支持日常工作。什麼算機密？核准的企業服務與員工個人帳號是否有不同規則？客服確認的範圍是文字通順、產品適用性，還是連折扣權限也要一起判斷？找不到答案時，員工會依自己對規定的理解行動。

因此，本文建議把政策寫成可驗證的行為。以客服知識查詢為例，資料只能來自指定文件庫；輸出必須顯示所依據的手冊版本；沒有相應來源時，要把案件轉交產品人員；對外寄信仍由有權限的客服送出。這些安排不是所有企業的通用標準，也不是只要照做就能消除風險。它們的功能是把抽象要求變成明確的限制，使主管可以檢查，員工也知道遇到例外時該走哪一條路。

治理文件應回答的問題，不必一開始就很多，但必須能串起一項工作：公司為什麼要用這個 AI？哪些人與資料會進入流程？哪些結果可能影響客戶或員工？誰可以批准使用、擴大用途及接受剩餘風險？運作不如預期時，如何停止並恢復服務？這些問題有了答案，制度才開始具備操作性。

把治理做得太重，同樣可能偏離目的。若讓內部公開資料摘要與影響退款的自動化走完全相同的審查，團隊會把時間花在低影響工作上，真正值得審慎處理的案件反而無法獲得足夠注意。因此，本文採用的思路是讓控制強度隨情境與影響調整。這不是放寬所有要求，而是先分辨哪些決策需要更強的證據、授權與監督。

治理也應保留說「暫時不用 AI」的選項。若客服的主要困難其實是產品名稱不一致、文件沒有版本或價格表長期失修，先整理資料與工作流程，可能比加上一個會說話的介面更接近問題根源。不能因為公司已經買了工具，就把每一個卡點都改寫成 AI 的使用情境。工具投資的沉沒成本，不應取代對業務價值的判斷。

能夠說明，才有條件擴大使用

可以將治理的最小成果，想成一組相互連結的答案，而非一疊孤立表單。例如，客服助手有用途說明、資料範圍、負責人、已知限制、測試結果與暫停方法；每一項答案都能找到目前有效的版本。當業務主管要求加入報價功能時，公司可直接看出哪些答案仍然成立、哪些必須重寫，而不用從頭猜測原系統到底核准了什麼。

這種做法的價值，在於讓擴大使用成為有依據的決策。當經營者問「我們能不能再自動化一點」，團隊不必只回答「應該可以」或「可能有風險」，而能具體指出：現階段只能產生建議報價；正式價格仍依核准價表決定；折扣超出授權範圍的案件必須交由主管處理；若未完成特定類型的測試，相關用途就暫不開放。

AI 治理的起點，於是從抽象的「負責任使用」落到公司每天做的決定。讀懂這一點，後面那些看似複雜的國際框架、風險分級與稽核證據，才會有共同的方向：讓企業知道自己授權了什麼，能夠證明控制確實存在，也能在條件改變時修正授權。

02．從採購 AI 到管理業務決策：治理單位應該是使用情境

採購單上通常寫的是一個產品名稱，業務現場發生的卻是許多不同的行為。同一套 AI 服務，可以協助行政修改會議通知，也可以整理應徵者資料、回答客戶保固問題，甚至連接企業系統。若公司只用「這個工具已經核准」作為管理依據，就容易把對工具的信任，擴張成對任何用途的允許。

本文建議，以「誰為了什麼目的，使用什麼資料，讓 AI 產生什麼結果，接著由誰採取行動」作為基本治理單位。這個單位就是使用情境。它比軟體名稱更接近責任，也比單次提示詞更適合管理。提示詞可能每天改，使用情境卻能指出哪些改動會越過原本核准的邊界。

Microsoft 的公開影響評估模板，將預定用途與系統功能區分開來，並要求思考使用者、任務與情境，而非只羅列產品有哪些功能。[A10] 本文借用這項區分，提出一個企業實務問題：即使某個功能能做，公司是否已經有足夠條件允許它做？功能描述回答的是能力，治理決策回答的是授權。

先把成果寫清楚，才知道哪些風險值得承擔

在零組件公司的教學情境中，「導入客服 AI」不是足夠清楚的目標。較可操作的寫法是：「協助客服更快找到適用於指定產品與版本的核准資訊，降低查找與重複整理所需時間，對外答覆維持既有的品質與授權要求。」這句話同時定義預期價值與不能被犧牲的條件，也讓團隊知道需要蒐集哪些基準資料。

基準資料可以很樸素，例如現有流程每件問題大約要經過哪些步驟，何時需要產品人員協助，哪些錯誤最常導致重工。這裡沒有必要先承諾「效率提升幾成」。如果沒有量測原流程，也沒有把人工檢查時間算進去，宣稱節省工時就缺乏可比較的基礎。可以把初期承諾寫成要驗證的假設，等實際結果支持後，再決定是否擴大使用。

更重要的是，效率與品質要使用同一個工作邊界。若只計算 AI 生成答案需要的時間，卻把客服查證、修正、補寄及處理客訴的時間排除，結果可能看起來很快，實際工作卻沒有減少。治理應要求專案負責人說明「從哪裡開始算，到哪裡結束算」，讓成功條件在採購之前就能被理解，而非上線之後才重新定義。

看清楚模型、系統與業務流程的差別

模型是產生預測或內容的技術組件；企業實際交付的系統，還包含資料來源、檢索方式、權限、介面與其他程式；業務流程則決定結果被誰使用、用於什麼判斷，以及如何改變現實世界。這個區分能避免一種錯置：模型供應商提供的能力說明，無法直接證明公司的整體流程適合上線。

以客服助手為例，就算模型能正確理解產品文件，檢索系統仍可能選到過期版本；就算資料版本正確，介面也可能讓客服忽略「僅供某一機型」的限制；即使客服看懂限制，主管若要求案件迅速結束，人工確認仍可能被壓縮。以上是本文設計的可能失誤鏈，用來說明檢查範圍應沿著任務一路延伸，不能停在模型輸出的那一刻。

責任安排也應沿著這條鏈展開。供應商能提供其服務的安全、資料處理與功能文件；企業仍需判斷自己的資料是否適合使用、設定是否符合需要、員工是否理解限制，以及輸出是否進入了未經核准的決策。採用外部服務，會改變工作分工，卻不會讓使用者的業務目的自動變得合理。合約如何分配特定責任，還需要依約定與適用規範另行確認。

三種權限，帶來三種不同的管理問題

為了讓主管容易討論，本文建議先把 AI 的工作分成提供資訊、提出建議與執行行動三種層次。這是企業內部分工的教學方式，不是法定風險分類。提供資訊時，要關注來源、正確性與使用範圍；提出建議時，還要看建議如何左右人的判斷；執行行動時，則需進一步管理可操作對象、交易邊界、錯誤復原及授權是否可以撤回。

因此，客服助手進入報價流程，並非在原本功能後面多加一個按鈕就完成。公司需要重新決定：AI 能否自行選擇折扣？能否引用尚未公告的交期？報價送出前由誰確認？客戶若據此下單，公司如何判定究竟是哪個版本的條件生效？這些問題若沒有明確答案，就應先縮小功能範圍，讓它產生草稿而不直接送出。

同樣地，讓 AI 填好退款申請，與讓它把退款指令送到可執行的系統，是不同的授權。可以在專案文件中以具體動詞表示權限，例如「讀取」「草擬」「推薦」「提交」「批准」「執行」，避免只寫「處理退款」。一句含糊的用途描述，可能掩蓋多個需要分別決定的控制點。

人工覆核也需要資源與界線

「由人把關」聽起來穩妥，但公司必須知道那個人看得到什麼、懂得判斷什麼，以及真的有多少時間。若主管要求員工在極短時間內檢查大量複雜結果，卻沒有提供原始資料與明確判準，覆核可能只剩下點選同意。可以把人工處理量、案件難度與現有人力一起納入專案設計，必要時降低自動產出的速度或縮小處理範圍。

覆核者也應有權退回與停止，而不只是承擔錯誤後果。客服若發現 AI 答案與手冊不一致，應能暫停該答案的對外使用並回報；主管若不同意系統建議，應能依據規則作出另一個決定，並留下原因。這些記錄不是為了增加員工負擔，而是讓公司知道哪些情境始終無法被穩定處理，進而改善系統或調整使用邊界。

當使用情境、成功條件、行動權限與覆核能力都被說清楚，採購才能進入有意義的比較。企業可以要求供應商說明如何支持這些條件，而不只是展示流暢回答。治理因而成為採購與營運的共同語言，也使技術團隊有機會在專案一開始就指出：真正需要補足的，可能是資料、流程或決策權，而不只是另一個模型。

03．AI 治理、AI 倫理、資料治理與資安，有什麼不同？

企業在討論 AI 治理時，容易把幾個相近概念混在一起。有人認為只要資料不外洩，治理就已完成；有人把它理解為寫出公平與透明的價值宣言；也有人以為只要符合法律，就不需要再做其他管理。這些觀點各自碰到了問題的一部分，卻未必能回答系統在日常工作中應如何被授權、使用與修正。

本文採用以下分工，幫助團隊對話。這是實務上的解釋方式，不是要把各專業的邊界切得互不相干。AI 治理負責把不同要求整合為組織的決策與責任；AI 倫理協助檢視應追求什麼價值、避免什麼傷害；資料治理管理資料的來源、品質、使用與責任；資安關注系統與資訊面對威脅時的保護能力。法遵則判斷具體用途受到哪些規範約束，及企業如何履行相關義務。

資料正確，仍可能被用在不適當的決定上

假設零組件公司的手冊都已更新，文件也沒有權限問題，AI 卻把「特定環境下的測試結果」改寫成「任何使用環境都能保證」。這個情境不只關乎資料有沒有整理好，也涉及輸出是否保留了原本的限制，以及公司是否允許這種輸出成為對外承諾。若只讓資料管理者負責，問題可能找不到完整的解決路徑。

反過來說，治理也不能靠開會取代資料工作。委員會即使決定「所有答覆必須可信賴」，產品手冊若仍有互相矛盾的版本，前線就缺少可依循的答案。可以把每項治理要求連到實際工作，例如決定誰有權宣告某份文件有效、舊版本何時退出檢索、緊急更正如何通知使用者。價值原則需要人員、資料與系統一起落實。

Microsoft 的 Responsible AI Standard 公開版把資料治理、人員監督、適用目的與持續評估列為不同但相關的要求領域。[A09] 這項做法提供的是一個企業如何把原則拆解為具體工作範圍的參考，不能直接解讀成所有公司適用的法定清單。實務上仍要依自己的用途與組織能力決定控制如何設計。

沒有遭到攻擊，也可能產生不良結果

資安是必要的保護，但不涵蓋所有治理問題。假設系統沒有被入侵，資料也沒有外流，卻根據過去的退款紀錄，對某些類型客戶提出較不利的處理建議。公司仍需問：那些歷史處理方式是否合理？目前使用的分類是否與退款條件相關？受影響的客戶能否請人重新審查？這些問題不一定會出現在傳統的技術漏洞清單上。

在這個教學例子中，若業務只追求降低退款金額，而忽略客戶原本應有的處理條件，系統即使執行得完全符合設計，也可能偏離企業應遵守的承諾。治理因此要檢查目標本身，而不只是檢查模型是否達成目標。把錯誤的目標做得更穩定，無法等同於值得部署的成果。

這也說明為何 AI 倫理討論需要接近具體的人。與其寫「尊重所有利害關係人」，不如指出哪類客戶可能無法理解機器生成的說明、哪類員工可能因為缺少原始證據而被要求接受判斷、哪一種例外最容易被標準流程忽略。把人與情境寫清楚，公平、透明與尊重才有機會轉化成可檢查的安排。

將原則變成可討論的取捨

OECD 的 AI 原則涵蓋人權、公平與隱私、透明與可解釋性、穩健與安全，以及責任等面向；其原則於 2019 年採納，並於 2024 年更新。[A07] 對企業的啟發，是不能用單一性能指標取代所有價值判斷。實際部署時，團隊需要說明不同要求如何影響設計，以及取捨由誰決定。

例如，為了讓客服能查證答案，公司希望保留使用紀錄；但紀錄若包含大量不必要的客戶個資，又可能增加資料管理負擔。本文建議的解法是先定義需要證明什麼，再決定應保留哪些欄位、誰能存取、何時刪除，以及哪些內容可採遮罩或其他適當處理。不能因為要稽核，就不加區分地保存所有對話；也不能因為追求便利，就完全不留下可供釐清的紀錄。

再例如，公司想讓客戶理解拒絕退款的理由，但沒有必要把完整內部規則、個資或安全控制全部公開。可理解的說明應圍繞與該決定相關的條件、資料與補正方法。透明的目的，是讓人能理解並採取下一步；形式上公開大量技術資訊，未必能達到同樣效果。

法遵與治理也有不同的時間尺度。某項用途經過審查，並不表示未來所有變更都自動適用原結論。資料來源、服務地區、使用對象、決策權或輸出用途改變，都可能使原本的判斷需要重看。可以讓法遵審查與用途變更共用同一個入口，避免法律意見留在舊專案資料夾，而營運已經走向另一個流程。

因此，成熟的安排不是讓每個部門各填一份相似表單，而是讓同一套用途與證據被各專業檢視。資料負責人說明來源與品質，資安人員檢視權限與威脅，業務主管說明承諾與例外，法務判斷適用義務，最後由有權限的人作成可追溯決定。這樣的整合，才是 AI 治理對既有管理制度真正有用的地方。

04．NIST AI RMF 怎麼用？把四個功能連到一項真實工作

對不知道從哪裡開始的企業，NIST AI Risk Management Framework，也就是 AI RMF，提供了一套可共同討論風險的語言。本文以 2023 年發布的 AI RMF 1.0 公開版為基礎。截至 2026 年 10 月 21 日查核，NIST 官網明示該版本正在修訂；因此，以下是對已公開版本的實務解讀，不把尚未完成的修訂內容當作既定要求。[A01]

AI RMF 的核心包括 GOVERN、MAP、MEASURE、MANAGE 四個功能。NIST 特別說明，這些功能不是必須照順序勾完的清單，GOVERN 也應貫穿其餘功能。[A02] 對企業而言，值得掌握的是持續循環：先了解用途與影響，再取得適當證據、作出控制決策；當新的資料出現，又回頭修正判斷。

表中的操作例子是本文的情境化建議，不是 NIST 指定的控制項。NIST 另提供自願採用的 Playbook，包含建議行動與參考資料，使用者可以依需求選擇適用內容。[A03] 因此，企業不必把整份資料逐條搬成自己的制度；應先知道現在有哪些決策缺乏依據，再挑選能補上缺口的方法。

GOVERN：先決定公司如何作判斷

在客服助手專案中，本文建議管理層先確認一件事：這項系統的負責人是客服流程的業務主管，資訊團隊負責技術實作與運維，各專業依需要提供審查。這個安排不適用於所有組織，但能避免把業務承諾全部留給工程人員判斷。負責人必須能說明系統的目的、目前限制，以及遇到重大問題時誰可以決定停止。

同一個階段也要談清楚公司願意接受什麼。內部摘要中的措辭修正，與對外提供錯誤產品條件，後果並不一樣。治理者應將不可接受的結果寫成具體情境，並指明一旦觀察到它，流程應採取什麼行動。只寫「維持高品質」不足以支持上線決定，因為每個人對高品質的想像可能不同。

這裡的重點不在多設一個核章，而在讓決策可以被解釋。若某項已知問題仍被接受，公司要記錄接受原因、適用範圍、替代控制及重新檢視的條件。反之，若暫不開放某個功能，也要說明需補足什麼證據。這樣團隊才知道如何前進，而不會把治理理解成沒有期限的等待。

MAP：把真正發生的工作畫出來

可以先邀請每天處理客戶問題的人，一起描述完整流程。客戶的問題如何進來？型號是否可能寫錯？客服何時需要看圖片？手冊找不到時會詢問誰？答覆寄出後，客戶通常怎麼使用這些資訊？這些細節會決定 AI 的適用範圍，往往比系統展示時準備好的漂亮問題更值得檢查。

接著，把受影響者放進流程。公司可能只把客服視為使用者，但真正受到錯誤影響的還有客戶、產品維修人員與後續處理客訴的團隊。若輸出被轉寄到另一個部門，原先附帶的限制是否還看得到？若客戶把一般說明當成特定承諾，公司是否能清楚辨識這個差異？這些是本文案例中的評估問題，目的在於讓團隊看到資訊離開介面後的用途。

也要保留對替代方案的比較。客服找不到資料，可能是搜尋功能不足，也可能是產品分類本來就不一致。若一般搜尋加上整理過的文件，就能解決主要問題，企業可以選擇較容易維護的做法。MAP 的實務價值，在於使「為什麼要用 AI」成為一個可以檢驗的假設，而不是專案開始後不能再問的問題。

MEASURE：證據必須對應你擔心的錯誤

測試之前，可以先列出要防止的失誤。例如，找不到適用資料卻給出肯定答案、混用產品版本、把條件式說明改寫成保證、遺漏需要人工處理的例外。每一種失誤都需要能辨識它的測試與判讀方法。若只問使用者「你覺得答案好不好」，即使回饋正面，也不足以證明上述問題已受到控制。

測試資料應包含公司實際會遇到的情境，以及容易造成誤判的邊界案例。本文不設定一個所有公司通用的題數或通過率，因為案件差異、風險程度與可用證據不同。重要的是說明測試樣本從何而來、覆蓋哪些用途、誰判定對錯，以及哪些情境尚未被充分檢查。少量測試沒有發現問題，只能支持有限的結論，不能直接轉成「系統安全」。

量測也要看人的介入是否真的有效。可以在合適的測試環境裡，放入事先準備的錯誤答覆，觀察覆核者能否找到來源、辨識差異並採取正確處理。若熟悉產品的測試者都需要很長時間才看出問題，就應重新考慮正式工作中要求員工快速確認是否合理。這類測試是本文建議的方法，其設計與負擔仍需配合工作風險調整。

MANAGE：決定接下來怎麼做，並讓決定真的生效

量測結果只有進入決策，才會產生管理價值。若系統對某類舊產品總是找錯文件，可以先把那些產品移出可用範圍，而不是要求客服自行小心。若使用者無法判斷答案適用條件，可以修改介面與流程，讓必要資訊更容易被看見。若風險仍無法控制，則可以暫停該用途，維持原有處理方式。

本文建議每項處置至少寫清楚責任人、完成條件及何時重新檢視，並留下與用途版本的連結。這有助於避免「已決議改善」被誤認為「已經改善」。若需要供應商配合，也應指出公司在等待期間採取什麼安排，不能讓外部處理時程成為內部責任的空白。

四個功能就此形成循環。測試發現了新的誤用情境，MAP 要更新；新的情境牽涉不同部門，GOVERN 要重新分工；限制用途後，MEASURE 要確認限制有效；營運變更後，MANAGE 要決定是否再開放。企業真正需要留下的，是這些判斷與改動之間的關聯，而不是一份看起來每一格都已完成的表單。

05．ISO、NIST 與 OECD 如何搭配？先分清楚每一套資料在回答什麼

搜尋 AI 治理，經常會同時看到 ISO/IEC 42001、NIST AI RMF、OECD 原則，以及各地法律名稱。這些資料都重要，但性質不同。若沒有先分清楚，企業可能以為採用某一套框架，就能一併回答法遵、管理制度與技術測試的所有問題，也可能花很多時間做重複文件，卻仍無法指出哪一項用途可以上線。

本節僅依 ISO 官方公開產品頁與摘要說明各標準的範圍，未宣稱取得或完整審閱付費標準全文。下列實務搭配是本文的建議，不能當成認證稽核條文，也不構成任何法規的符合性判定。企業若要正式導入或準備第三方驗證，應依實際取得的標準版本、適用範圍與驗證要求進行。

ISO/IEC 42001：把 AI 管理變成組織能持續運作的制度

ISO 官方將 ISO/IEC 42001:2023 說明為 AI 管理系統標準，規範組織建立、實施、維持與持續改善 AI 管理系統的要求，適用對象包括提供或使用 AI 產品及服務的組織。[A04] 企業可以先從這個公開定位理解它：重點是組織如何持續管理，而不是只檢查某一次模型回答。

在零組件公司的教學情境中，本文建議用這個角度追問：客服助手不再由最初的專案成員維護時，誰接手？核准文件與實際設定不同時，如何發現？發生錯誤後，改善是否能回到制度？新主管上任時，是否仍知道已經承擔了哪些風險？這些問題關乎制度能否跨越個人與專案週期，正是中小企業容易忽略的地方。

正式取得某項管理系統證書，也不宜被說成「每一個 AI 結果都正確」或「所有市場的法律都已符合」。管理系統的適用範圍、被評估的活動與實際用途，需要分別閱讀與確認。採購者若看到供應商提出證書，本文建議進一步核對證書所涵蓋的組織、服務與範圍，並持續檢查自己的使用情境，避免把證明文件解讀成超出其內容的保證。

ISO/IEC 23894：把 AI 特有的風險放回管理工作

ISO/IEC 23894:2023 的官方摘要，將其定位為 AI 相關風險管理的指引，協助開發、部署或使用 AI 的組織，將風險管理整合進相關活動。[A05] 它與管理系統標準的角色不同；在本文的實務安排中，可把它視為深化風險辨識與處理思考的一項參考，而不把它當成另一張必須取得的通行證。

這個區分對既有管理制度很有幫助。公司可能已經有採購審查、資安事件流程與客訴管理，不必假設遇到 AI 就全部重做。可以先檢查原有流程是否涵蓋新的問題，例如用途改變、輸出不確定性、資料與模型更新，以及人員過度依賴結果。若原流程能承接，就增補欄位或檢查點；若承接不了，再設計新的安排。

本文建議避免用同一個分數掩蓋不同類型的風險。客戶個資被不適當揭露、特定群體受到不公平對待、錯誤報價造成損失，可能需要不同專業與不同處置。總分可以協助初步排序，卻不能取代對風險成因、受影響者與不可接受後果的說明。企業應讓評估者知道每一個分數在代表什麼，也能指出哪些事情不能只靠平均值處理。

ISO/IEC 42005：把受影響的人放回評估中心

ISO/IEC 42005:2025 的公開說明聚焦 AI 系統影響評估，包括 AI 系統及其可預見用途，可能如何影響個人、群體與社會。[A06] 這有助於區分兩個常被混用的問題：「這個 AI 對公司有什麼風險」與「公司使用這個 AI，會讓哪些人承擔什麼影響」。兩者相關，但答案並不相同。

例如，退款助手若把複雜案件一律轉成拒絕，公司的處理時間可能下降，客戶的補件負擔卻增加。若只看公司的效率，就可能漏掉使用者必須花更多時間才能取得人工協助的問題。可以在影響討論中，同時寫下受益者與承擔代價的人，再問那些代價是否合理、是否可以減少，以及有沒有可用的補正方式。

影響評估也不應等到系統完成才開始。若公司已經把「全部自動拒絕某類申請」寫成核心產品設計，後來才發現缺少例外與申訴處理，修改成本會比早期討論高。在本文的建議流程中，影響分析先以簡版進行，隨資料、用途與設計成熟逐步補強；對可能造成重大影響的用途，應在授權之前取得足夠審查。

ISO/IEC 38507 與 OECD：把議題帶回治理層與價值選擇

ISO/IEC 38507:2022 的官方摘要，將指引對象放在組織治理機構的成員，也涵蓋高階主管與其他相關角色，關注如何使 AI 在組織內獲得有效、適當的使用。[A08] 這提醒經營者，AI 的用途與責任安排不能完全下放成資訊部門的技術決定。當一項系統會改變客戶待遇、員工工作方式或公司的承諾，就涉及治理層的判斷。

OECD 原則則有助於提供價值方向，例如人權、可理解的資訊與責任安排。[A07] 對這家虛構公司來說，管理層需要回答的問題可以很具體：如果自動化帶來效率，但部分客戶更難取得協助，公司願意接受嗎？若某種用途無法得到充分解釋，是否仍符合對客戶的承諾？這些答案不是由模型本身決定，而應由有權限且能承擔後果的人作成。

本文建議採取一種精簡的搭配方式：以價值與適用義務確立邊界，以管理系統思維確保制度持續運作，以風險框架組織日常工作，再以影響評估及具體測試補足決策證據。不同資料可以支持同一項控制，不必因此產生多份互相矛盾的紀錄。把資料彼此的分工弄清楚，企業才有機會用有限資源做出真正可維持的 AI 治理。

06．誰應該負責 AI 治理？把權責交給能作決定的人

治理制度最容易失去作用的時刻，通常出現在需要跨部門作決定的地方。資訊人員說技術可以完成，業務認為應儘快上線，法務要求補資料，客服則擔心日後每一個錯誤都由自己承擔。若沒有事先安排決策權，專案就可能在各部門之間來回，或在時間壓力下由最積極推動的人直接決定。

本文建議先區分四種工作：為業務結果負責、執行控制、提供專業判斷，以及檢查制度是否真的被遵守。這是實務分工建議，不是要求所有中小企業設立四個新部門。人數有限時，同一個人可以承擔多個角色，但當案件影響較大或存在利益衝突，應考慮增加不同人員的審查，而非讓同一個專案負責人從提出、測試到批准都自行完成。

業務負責人不能只有名字，還要有決策能力

客服助手的業務負責人，應能回答系統服務哪一種工作、哪些條件不可以被犧牲，以及一旦停止服務，原流程如何接手。若指派的人無法調整流程、取得必要資源或要求改善，即使文件上有簽名，實際責任仍可能懸空。因此，本文建議指派負責人時，同時寫下其授權範圍與需要上報的決策。

資訊團隊則應清楚說明技術控制能做到什麼、不能做到什麼。它可以實作存取限制與操作紀錄，卻不能代替業務決定何種退款條件合理；它可以提供測試結果，也不能單憑技術通過就宣稱法律風險已解除。各專業知道自己的責任邊界，合作才不會變成互相推卸。

本文建議的重要用途決策，至少具備可識別的提案者、審查意見、批准者與生效版本。公司不必把所有人都拉進每一次討論，但應確保需要的專業有機會在決定之前表達意見。若意見不同，記錄爭點與最終理由，比把會議紀錄寫成「各單位無異議」更有管理價值。

讓 HR 管能力與工作設計，讓使用者有真正的參與

HR 在 AI 治理中的角色，不必限於安排一堂工具課。員工需要知道哪些工作已被允許、哪些資料受到限制、如何判讀與回報問題，以及何時應停止自動化。對主管而言，還要學會如何評估用途、安排覆核量與確認責任。不同角色需要的能力不同，不能用同一份課後測驗代表所有人的準備程度。

本文建議以工作情境設計訓練與驗收。例如，讓客服處理一個缺少適用手冊的問題，看他是否能辨識不足並轉交；讓主管審查一個要求自動發出報價的提案，看他是否會確認授權與錯價處理；讓資訊人員演示如何停用連接器或撤回某項權限。這些驗收方法是本文提出的設計例子，目的在確認人員能完成其角色需要的行動。

工作目標也應配合治理要求。若公司一方面要求員工仔細查證，一方面只依處理量獎勵績效，員工就可能面臨衝突。可以把合理的查證時間、例外回報與必要轉交視為正式工作的一部分。發現問題的人應有清楚的通報路徑，組織也應區分善意回報與違反規定，避免讓前線因擔心被責備而隱藏失誤。

影響評估需要聽見不在專案會議裡的人

Microsoft 的公開影響評估指南鼓勵跨專業討論，並提供辨識利害關係人、潛在好處與傷害的活動方法。[A11] 本文將這個方向轉化為一個簡單問題：如果只由採購者與開發者討論，還有誰的經驗會被漏掉？答案可能是夜間客服、處理特殊型號的技師、不熟悉線上服務的客戶，或必須接手被系統拒絕案件的人。

企業不一定需要為每個低影響用途舉辦大型訪談，但應依用途影響程度，安排適當的意見來源。可以邀請有相關經驗的前線人員參與測試，檢查既有客訴中的例外，或在適合的條件下蒐集使用者意見。這些資訊不能被當成代表所有人的完整證據，卻能幫助團隊發現原先沒有想到的使用方式與困難。

對客戶或員工而言，最實際的問題往往不是能否看懂模型原理，而是遇到不合理結果時能否找到人。本文建議設計可辨識的異議入口，讓當事人知道如何要求更正資料、補充情況或請求人工重新處理。若申訴仍完全交給原本造成爭議的自動流程，就很難證明公司提供了有實質作用的覆核。

申訴與事件處理應回到制度，而不是只關閉個案

在退款助手的教學情境中，若客戶指出系統遺漏一份已提交的文件，公司需要先處理該筆案件，也要檢查這是否代表流程上的共同缺陷。問題出在資料沒有同步、檢索沒有讀到、判斷規則不合適，還是客服無法看到必要資訊？不同原因需要不同改善，不能全部以「AI 偶爾會錯」結案。

可以讓異議處理紀錄與系統的用途、資料及版本相連，並依影響程度判斷是否需要擴大檢查其他案件。完成補救後，也應確認控制是否真正修正，以及是否要重新訓練相關人員或縮小使用範圍。這樣，申訴就不只是處理不滿，也成為公司理解系統在真實環境中如何表現的一種證據。

最後，治理需要一個能處理升級事項的管理節奏，但不必把所有日常問題都送到高階會議。本文建議讓一般設定與例行檢查由指定角色處理，把用途擴大、重大影響、跨部門衝突與難以控制的問題升級決策。管理層看到的資訊應足以判斷要接受、改善、限制或停止，而不是只有一張顯示使用量成長的報表。

當各角色知道自己能決定什麼、應留下什麼證據，也知道遇到不同意見時如何求助，AI 治理才有了組織基礎。接下來，企業才能把這些分工落到具體的 AI 清冊、風險分級、資料管理與上線條件，讓制度真正進入每一項使用情境。

07．AI 治理從盤點開始：你真正要管理的是哪一項工作

沿用前文的使用情境定義，這一節把每個用途轉成可維護的清冊。採購資料可以共用，但不同用途仍需自己的資料限制、負責人與核准條件。對前述虛構零組件公司而言，盤點要追到實際工作：哪些資料會被送進工具，哪些輸出會成為對外承諾，以及誰有權改變這個範圍。

例如，客服人員使用 AI 找出公開產品手冊的保固條文，與業務主管利用 AI 彙整客戶採購歷史後提出折扣建議，應建立不同情境。若再增加可以寫入訂單系統的代理功能，還要把「提出建議」與「執行交易」分開描述。這並不意味每項情境都要召開一次大型會議，而是要讓人能查到：這個功能原本獲准做甚麼，現在又多做了甚麼。

讓清冊成為可追問的工作地圖

一份有用的清冊，應該能順著資料與責任往下追。對零組件公司而言，客服檢索工具的條目可以寫成：「協助授權客服查詢已核准產品手冊；僅生成內部答覆草稿；由客服確認後回覆；不查詢客戶底價；不修改訂單。」這句話比「客服 AI 專案」更有管理價值，因為它同時界定了功能、使用者、資料與行動邊界。遇到客戶追問報價時，團隊可以立即判斷是否超出核准範圍。

清冊也要寫出一位能對結果負責的業務負責人。這個人需要有權決定流程、調整人力與接受營運上的剩餘風險；技術團隊則負責說明系統如何運作、控制如何落實。供應商窗口、開發工程師與付款的部門，都不能自動代替業務負責人。若大家認為另外一個部門應該負責，這本身就是上線前必須處理的治理缺口。

下面是本文為案例公司設計的清冊摘要，屬於教學示例，並非任何標準規定的固定欄位。

完整紀錄還應連結模型與應用版本、資料擁有者、供應商、測試報告、風險評估、核准者、監控方式及退出安排。這些文件不必重複貼進同一張表，只要有穩定的識別碼與連結，讓一次事件能從業務情境追到當時使用的版本即可。對於尚未上線的構想，也可以先記錄目的與負責人，隨成熟度逐步補足，而非逼迫提案人猜測尚未確定的技術細節。

模型卡的研究提供了一個可借用的思路。Google Research 收錄的《Model Cards for Model Reporting》主張，模型文件應交代預期用途、評估條件與表現限制。[B09] 企業可在這個概念上建立自己的「使用情境說明卡」，但需要再補上公司內部的流程與責任。供應商的模型卡說明通用模型的評估，公司自己的說明卡則回答它在這個業務環境中被允許做甚麼。兩者可以互相補充。

讓員工願意把實際使用方式說出來

盤點最容易漏掉的地方，是正式採購清單之外的工作習慣。員工可能使用個人帳號試寫信件，也可能在原有辦公軟體中啟用新增的 AI 功能。實作時，第一輪盤點採用情境訪談，問「你哪一段工作會請 AI 幫忙」「通常會貼入甚麼」「生成後由誰使用」，再與採購、登入與系統紀錄交叉核對。蒐集員工使用資訊時，仍應限定必要範圍、清楚告知用途與存取人員。

管理者也要把申報與處理原則說清楚。若員工每次提出新用途都只得到不明期限的等待，下一次很可能改採私下處理；若主管只問誰違規，團隊也可能隱藏已經存在的風險。較可行的設計，是提供容易使用的核准工具、清楚的可用資料範圍，以及有回覆期限的例外申請。發現既有高風險使用時，先控制資料與權限，再依事實處理責任。

清冊建立後，還需要一個更新動作。可以把更新責任放入原有採購、變更與離職流程：新增連接器時確認可讀取的資料，換模型時更新版本與測試，業務負責人離職時移交責任，停用功能時撤銷權限。定期複核只是補充，真正有效的更新往往發生在業務改變的當下。當清冊能支援這些決定，它才會從一份調查表，成為 AI 治理的工作入口。

08．AI 風險評估怎麼做：先找出傷害路徑，再決定管制強度

盤點完成後，最常出現的下一個要求是：「請大家替 AI 專案打分數。」評分可以協助排序，但若沒有先說明危害如何發生，很容易產生看似精確、實際無法行動的結果。客服工具與退款代理可能都拿到某個中間分數，前者需要修正知識來源，後者卻需要限制交易權限。分數相近，控制方法仍可能完全不同。

本文建議從一條完整的傷害路徑開始寫。以案例公司的報價草稿為例，可以描述為：「過期價目被檢索到；模型沒有辨識生效日期；業務人員直接採用；客戶收到錯誤價格；公司承擔爭議與重工。」這條路徑把資料品質、模型行為、人工判斷與業務後果接在一起。每一個連接點都可以問：有甚麼證據顯示這件事可能發生？在哪裡可以阻斷？若仍然發生，誰會最先知道？

評估的對象也應包含受到影響的人。公司可能把錯誤退款看成金額損失，客戶則可能因為款項未退而無法安排支出；公司可能只關注客服速度，客戶卻更在意是否被無理由拒絕。若受影響者無法發現錯誤、沒有申訴管道，或需要付出很高成本才能更正，後果就不能只用公司帳面損失衡量。

NIST 的生成式 AI 風險文件將錯誤內容、資料隱私、資訊安全及人與 AI 的互動等列入討論，提醒使用者注意模型之外的影響。[B01] 對企業而言，這些分類可用來避免遺漏，實際評估仍要回到自己的工作流程。以下分級與問法是本文建議，並非 NIST 的強制評分表，也不等同於歐盟法律中的風險分類。

將不確定性寫進評估，避免用平均分數消除警訊

每條傷害路徑至少應區分後果嚴重度、發生可能性、影響範圍、可察覺性及可逆性。退款金額打錯，若尚未送出，可以撤回草稿；若已跨境匯出，後續處理難度可能明顯提高。內部摘要錯誤與對外承諾錯誤，擴散範圍也不同。這些差異應寫在理由裡，不宜只保留一個總分。

其中最容易被低估的是證據不足。沒有發現事故，可能代表控制有效，也可能代表沒有監控；供應商沒有提供某類測試，不能直接推論系統安全。本文建議在風險紀錄中另設「證據可信度」或「未知事項」欄位。對後果嚴重、資料不足的情境，決策可以是縮小試驗範圍、增加專業評估或暫緩上線，而不是把未知填成低風險。

若情境涉嫌違反適用法律、侵害無法接受的基本權益、缺乏必要資料使用權，或沒有能力阻止重大損害，應進入獨立的停止與專業審查程序。這類警訊不能因為成本低、預期效益高或其他項目分數好而被平均掉。法律上的禁止與義務需要依所在地、產業、角色及具體用途判定；企業內部分級只是管理工具，不能自行取代這項判斷。

對已排除上述警訊的情境，本文提出三種管制層次。第一層處理公開資料的內部輔助工作，可由受訓使用者依既定規則操作。第二層涉及非公開資料、對外草稿或有實質業務影響的建議，需要資料擁有者同意、可追溯測試與明確人工覆核。第三層涉及交易、重要權益、安全或較大的自動執行能力，則需要較強的專業審查、技術限制、事故應變與定期驗證。每個組織應自行界定邊界，不能僅依名稱判斷。

風險評估的產出是一項可執行的決定

完成風險辨識後，文件至少應能回答：本次准許哪個範圍？尚有哪些風險？由誰接受？接受到甚麼時間？出現甚麼變化必須重審？若答案只有「中風險，可使用」，接手的人仍不知道如何操作。較完整的核准敘述可以是：「只限內部客服使用核准手冊；輸出先經客服確認；不得回答價格與特殊保固；出現錯誤引用或權限問題即停用該功能並交由負責人檢查。」這是教學示例，正式條件應依實際測試與業務需求調整。

剩餘風險也要與控制證據連結。說「有人會看」不足以證明人工覆核有效，應確認覆核者能看到原始依據、具備判斷能力，並且有時間與權限拒絕。說「系統會擋」也應能指出阻擋在哪個環節、測試如何完成、失效時會怎樣。這樣的紀錄讓核准者知道自己接受的是甚麼，而非在大量附件之間簽下一個概括同意。

若控制成本過高，可以重新設計用途。案例公司原本想讓 AI 自行決定退款資格，經評估後，可以先改為整理訂單事實、列出缺件與產生申請草稿，保留人員判斷。這項調整減少的不是 AI 的展示效果，而是需要同時承擔的決策與執行責任。當證據逐步累積，再決定是否增加自動化程度，會比一開始授予完整權限更容易驗證價值。

影響評估還應讓第一線人員與可能受影響的人有機會提供意見。客服可能知道哪些客戶最常遇到語言障礙，財務可能知道哪些退款流程難以撤回，業務可能知道同一個品號在不同合約中有不同條件。這些資訊未必出現在模型測試報告裡，卻可能決定風險評估是否完整。AI 治理的品質，取決於組織能否把這些分散的工作知識帶進決策。

09．資料與供應商治理：從一句「不拿來訓練」追問到完整資料流

企業評估 AI 服務時，經常先問供應商會不會把資料拿去訓練。這是一個必要問題，但資料可能在推論、紀錄保存、客服支援、外掛連接、備份與除錯過程中被處理。即使某項服務承諾不把特定資料用於訓練，也仍需確認保存多久、誰能存取、經過哪些次處理者，以及刪除如何執行。這些安排可能因產品、方案、設定與合約不同而有差異，不能用同一品牌的另一項服務代替查證。

本文建議，先為最重要的一個使用情境畫出資料流。以報價草稿為例，客戶需求從信件進入系統，與產品規格、核准價目及客戶條件合併後送往模型，生成草稿再存回文件系統。每一步都要確認傳送了甚麼、何人能讀取、保存在哪裡、保留多久、是否另外留下紀錄。若這張圖無法完成，採購問卷填得再完整，也可能漏掉真正發生資料暴露的地方。

先減少不必要資料，再討論如何保護

假設 AI 只需判斷料號、數量與出貨條件，就未必需要收到聯絡人的身分證件、完整通訊錄或與此次訂單無關的歷史對話。實作時，讓業務負責人逐項說明輸入欄位的必要性，再由技術人員驗證移除後是否影響任務。如果移除某欄位不影響產出，便有具體理由把它從流程中拿掉。這比要求員工自行記住所有不可貼上的資料更容易持續執行。

英國 ICO 的 AI 指引提醒組織，AI 涉及多個軟體元件與資料流，需要整體看待安全與資料最小化。[B07] 本文引用的是這項管理思路，並未把英國規範套用為台灣企業的直接法律義務。該頁於查核時也註明指引正在檢討，法律適用與個別處理活動仍須另行確認。

資料遮蔽也要辨識其能力邊界。把姓名改成客戶編號，若仍可經其他表格或敘述辨識個人，就不能逕稱完全匿名。即使資料沒有姓名，獨特的職稱、訂單組合或地點也可能使當事人可被識別。較務實的做法，是將遮蔽視為一層控制，搭配存取限制、用途限制與保存管理；若任務需要還原身分，把對照資料留在有獨立權限的環境，並記錄何時及由誰還原。

日誌尤其容易成為被忽略的資料副本。為了除錯而保存完整提示、文件內容與模型回應，可能把原本分散在不同系統的敏感資訊集中到同一處。NCSC 的安全開發指引把日誌列為需要保護的 AI 資產。[B06] 實作時，日常監控優先保存必要的識別碼、版本、動作與結果；只有確有需要時，才依權限開啟內容層級的調查紀錄，並設保存期限。這樣才能同時兼顧可追溯與資料暴露面。

問供應商能交出甚麼證據

供應商評估可以先從三個問題組成一段對話。第一，這項功能的處理邊界在哪裡？第二，承諾如何反映在合約與設定？第三，當承諾失效或服務改變時，企業如何發現並退出？例如「資料可以刪除」應進一步確認涵蓋原始檔、索引、對話、備份及第三方副本的哪些部分；「有權限控管」應確認權限變更是否會同步到檢索與快取；「支援稽核」應確認可提供哪些紀錄，以及可保存多久。

與其把安全認證當成一個總勾選欄位，本文建議確認認證範圍是否涵蓋實際採購的產品、環境與服務流程，證明的期間是甚麼，有哪些排除與客戶端責任。供應商的證書可以提供部分管理制度的證據，但公司仍需驗證自己的設定與使用方法。若使用者把受限資料匯入無權限區隔的知識庫，供應商具有認證也無法自動消除這項設計問題。

合約與採購紀錄可圍繞實際情境確認資料處理目的、存取與保存、次處理者、事故通知、版本變更、服務停止、輸出使用條件及資料返還方式。這是本文提出的採購檢核方向，不能直接當作完整合約範本或法律意見。對資料跨境、個資、著作權與責任分配等事項，應由具適用法域經驗的專業人員核對；不同產品的標準條款與企業議約空間也可能不同。

將無法取得的證據變成明確限制

若供應商無法說明某項關鍵處理，企業不必假裝已經查核通過。可以先限制可輸入資料、減少可連接系統、改採測試資料，或延後高影響用途。核准紀錄應把缺口寫清楚，指定補件責任與複核條件。對於事後可能影響繼續使用的承諾，例如資料保存政策或關鍵模型版本，也應建立變更通知與再評估方式。

採購評估最後應能支持退出。案例公司若把全部手冊、測試問題與流程設定只存放在單一供應商介面，一旦停止服務，可能連原本如何運作都難以還原。本文建議保留自己可控的核准知識來源、測試集、情境清冊與操作文件，並在導入初期驗證必要資料能否匯出。這些安排會使供應商關係更具可管理性，也讓企業有條件比較替代方案。

10．RAG 與知識庫治理：答案有引用，還要確認引用對不對

案例公司把產品手冊接入 RAG，也就是檢索增強生成之後，客服很快發現回答附上了文件來源。這是一個有用的進展，但治理問題隨即變得更具體：檢索到的是新版還是舊版？這份文件適用哪一個產品與客戶？提問者是否有權讀取？模型引用的段落，是否真的支持它所下的結論？

Microsoft 對 RAG 的官方說明將它描述為結合搜尋與大型語言模型的應用方式，並提醒檢索不完整或內容品質不足時，回答仍可能不正確。[B13] 因此，企業應把 RAG 看成一條可檢查的資料處理流程。它讓企業有機會提供較適切的背景資料，也增加了文件準備、索引、授權與引用驗證的管理工作。

先決定哪些文件有資格代表公司

本文建議，每個知識來源至少要有擁有者、版本、生效日期、適用範圍與狀態。公開產品手冊、內部工程備忘錄與尚未核准的草稿，可以同時存在於公司資料夾，卻不能因此取得相同的回答權重。若草稿與正式手冊衝突，系統需要有明確的來源優先序，或直接停止回答並交由人員判斷。

對報價與退款等內容，還要確認文件是一般規則，還是特定合約的例外條款。模型找到一份真實文件，並不表示這份文件適用於眼前的客戶。案例公司可以讓每份可檢索文件帶有產品版本、銷售區域、合約類型與有效期間等欄位，再由程式依情境過濾。欄位設計應由熟悉業務規則的人參與，而不是只讓工程師根據檔案格式自行猜測。

這也會改變公司處理過期文件的方式。舊手冊可能仍需保留供歷史案件查證，不能簡單全部刪除；但它應該退出一般現行問答的檢索範圍。本文建議分開設計「現行查詢」與「歷史查證」的入口，明示文件生效期間，避免同一個索引在缺乏條件時混用。這是對資料使用目的的管理，而不只是整理檔案名稱。

權限要在檢索時成立

OWASP 在向量與嵌入弱點的說明中，指出共用向量資料環境可能出現跨群組的資訊洩漏。[B05] 一個常見的設計誤區，是先把所有文件送進模型，再要求模型不要告訴使用者某些內容。這會讓沒有必要進入上下文的資料先進入處理流程。可以在檢索與工具層核對身分與權限，讓使用者只能取回自己可讀取的內容，並測試一般使用者、離職帳號、跨部門帳號與服務帳號等不同情境。

Microsoft 的文件層級存取控制說明特別指出，來源系統的權限變更，必須透過對應機制同步到索引，才會反映在搜尋結果。[B08] 這個細節值得管理者追問：員工調職後，原本的敏感文件何時不再可見？若索引同步失敗，系統如何反應？供應商宣稱支援權限繼承，仍應以實際資料來源、版本與設定驗證，尤其要留意文件中標示為預覽的功能。

檔案切成多個片段後，權限與來源資料也要隨片段保存。否則系統可能找到一段內容，卻無法還原它屬於哪份文件、哪個版本或哪位擁有者。本文建議為原始文件、片段與索引版本建立關聯，並把可追溯性納入測試。當客戶指出錯誤，公司需要能查回當時取出的段落，而不只是看到模型後來生成的一段流暢文字。

引用驗證要分成幾個問題

「有引用」至少要拆開檢查來源是否存在、使用者是否有權查看、來源是否仍有效，以及它是否支持回答中的具體主張。假設模型回答某零件可用於高溫環境，附上的手冊卻只說明一般儲存溫度，形式上雖然有來源，實質上仍然缺乏依據。對於影響安全、規格或契約承諾的回答，應把關鍵主張與支持段落並列給覆核者。

如果找不到足夠資料，系統應有可用的下一步，例如請使用者補充品號、顯示相關文件但不下結論，或轉交負責人。可以把「知道何時停止回答」列為功能設計的一部分，並測試沒有答案、文件互相衝突、資料超過有效期等情境。這樣的設計能讓使用者繼續完成工作，也避免把沉默或拒絕回覆直接等同於失敗。

知識庫還需要防範來源內容中的惡意指令。外部文件可能寫著要求系統忽略規則、改查其他資料或執行工具，這些文字應被視為待分析資料，不能自動取得指揮系統的權限。OWASP 對間接提示注入的說明，即涵蓋模型從網站與檔案接受輸入的情境。[B02] 可以把此類情境放入測試，並以工具授權與資料隔離限制可能後果，不能只在提示詞加上一句「不要被騙」。

最後是刪除與更正。移除來源檔案後，還要確認片段、向量索引、快取與其他副本的處理狀態。若文件內容更正，相關測試與回覆模板也可能需要更新。對於曾經被用於其他訓練或調整流程的資料，應另向負責人與供應商確認處理方式，不能把檔案刪除視為所有影響已經消失。知識庫治理的完成條件，是資料的生命週期真正能被追蹤。

11．如何驗收 AI：把「看起來不錯」轉成可比較的證據

到了驗收會議，供應商通常能展示幾個令人滿意的回答。這些展示有助於理解功能，但企業還需要知道：換一種問法會怎樣？資料缺漏會怎樣？使用者沒有權限時會怎樣？若模型說已完成退款，財務系統是否真的留下正確紀錄？能否上線，應根據這些問題的證據決定。

本文建議在開發前，先由業務與技術團隊共同寫出「成功的工作結果」。客服檢索的結果可能是找出正確手冊、引用適用段落、回答原始問題，並在資料不足時轉交人員。報價草稿還需要確認數量、幣別、稅別、有效期限及核准價目。退款代理則要確認對象、訂單、資格、金額與交易狀態；只要其中一個關鍵條件錯誤，就可能無法視為成功。

Anthropic 在代理評估文章中區分執行紀錄與最終環境結果，指出代理自稱完成工作，與系統中確實完成工作是不同的觀察對象。[B10] 企業可以據此要求測試同時檢查回答、工具動作與實際資料狀態。這也使驗收焦點從文字流暢度，延伸到整個工作是否按照授權完成。

建立會揭露問題的測試集

本文建議測試集包含日常任務、容易混淆的邊界情境、已知失敗，以及刻意檢查控制是否有效的案例。日常任務用來觀察能否創造價值；邊界情境用來檢查缺件、矛盾與例外；控制測試則驗證資料隔離、權限、停止及人工核准。這些類別應分開報告，避免大量容易的題目稀釋少數嚴重失敗。

假設測試資料中有兩份不同版本的保固條款，應預先寫明哪份適用，以及資訊不足時可以接受的處理。若兩位熟悉業務的人對答案都無法達成共識，應先釐清規則，不能急著要求模型達成某個準確率。AI 專案因此也會暴露原有流程中不明確的例外條件；先把規則說清楚，通常比繼續調整提示詞更有幫助。

測試資料與開發資料也應分開管理。團隊可以用一組案例反覆調整系統，但還應保留未參與調整的驗證案例，觀察改善能否延伸到其他問題。若每次失敗都把答案直接加入提示詞，再拿相同題目宣稱進步，測到的可能只是對既有題目的適應。測試集更新時，應保留版本、修改理由與新舊結果，讓成效比較有共同基礎。

對生成式系統，單次成功也不代表每次都相同。本文建議對關鍵情境重複執行，並記錄模型版本、設定與工具環境。重複次數應依成本、風險與行為變異決定，不存在所有企業通用的神奇次數。若某項退款檢查有時會被略過，這種不穩定性本身就是上線條件的一部分，不能只挑選成功紀錄呈現。

每個指標都要交代分子、分母與適用範圍

「正確率達到 98％」資訊仍然不足。它可能是句子、問題、任務或交易的比例，也可能由模型自行評分。本文建議每個數字都附上定義、樣本來源、測試日期、評分方式與重要排除項目。若是客服問答，應說明如何處理部分正確、錯誤引用、合理拒答與應該回答卻拒答的情況；若是交易代理，則應另外記錄未授權動作與重複交易。

以下是本文設計的指標示例，企業應依自己的用途選擇與修訂。

假設一組教學測試共有 300 件任務，其中 295 件成功，整體通過率約為 98.3％。若失敗的 5 件都涉及跨客戶資料洩漏，這個漂亮的平均值仍無法支持上線。風險相關的失敗需要獨立判定，並且回到可能造成的後果。可以把不可接受的事件設成獨立阻擋條件，其他品質指標再用來衡量改善與服務水準。

另一個常見誤解，是 100 次測試沒有失敗，就代表實際失敗率為零。即使先假設測試互相獨立、來自相同分布，且每次失敗機率固定，零失敗的 100 次試驗，其單側 95％二項分布信賴上界仍約為 2.95％，由「1 減去 0.05 的 100 次方根」計算而得。這是統計假設下的示例，並非對任何產品風險的估計。實務上，刻意挑選的題目、相似問法與變動環境還可能不符合這些假設，更不能把有限測試當成無風險證明。

把評分者也納入品質管理

模型協助評分可以節省時間，但評分規則仍需由人確認。可以先讓業務專家標註一組案例，與自動評分結果比較，檢查評分模型是否偏好冗長答案、忽略細小金額錯誤，或把有引用但未受支持的說法判為正確。對於資料洩漏、契約承諾及交易執行，應盡量使用可直接檢查的系統狀態與規則，並保留必要人工複核。

放行決定最後需要把證據與限制一起呈現。本文建議至少保留用途、版本、測試範圍、失敗類型、尚未覆蓋的情境、人工支援安排及停止條件。核准可以是限定部門、限定資料或限定操作，而不必只有全面開放與全面停止兩種選擇。當下一次模型、知識庫或流程改變，同一套測試就能提供比較基礎，協助團隊判斷改動究竟改善了哪一件事。

12．人工覆核如何有效：讓人有能力、有資訊，也有權拒絕

許多 AI 計畫把「最後由人確認」寫成主要控制。這句話真正要落實，至少需要三個條件：人知道要檢查甚麼，介面提供足夠證據，組織允許他在不確定時停下來。少了其中一項，覆核者可能只是替系統按下確認，卻承擔了表面上的責任。

在案例公司，客服每天若要處理大量問題，看到一段語氣完整、附有來源的回答，可能逐漸只檢查措辭。NIST 的生成式 AI 風險文件將對自動化過度依賴列為人與 AI 互動的議題。[B01] 因此，企業應檢查實際的工作條件，而不只確認流程圖上是否畫了一個人。當覆核時間不足、來源無法開啟或主管要求一律快速通過，人工關卡的效果就需要重新評估。

先決定人要做哪一種判斷

本文建議把覆核任務寫成具體問題。客服應確認來源是否適用、回答是否超出文件、是否需要轉交專業人員；業務應確認數量、幣別、折扣與交期是否符合核准條件；財務應確認退款對象、資格、金額及是否已有交易。這些判斷需要不同的業務知識，不能只因為某位員工熟悉 AI 工具，就讓他負責所有情境。

覆核權限也要與責任配合。若員工可以看見異常，卻無法拒絕、修改或交由另一位負責人處理，就沒有完整的介入能力。本文建議在重要流程中提供明確的「退回補件」「轉人工處理」與「停止此項動作」，並讓覆核者留下簡短理由。主管應定期看這些理由，辨識資料不足、規則不明與系統問題，而不是把所有退回都當作效率低落。

Microsoft 的人與 AI 互動研究提出，設計應協助使用者理解系統能力與限制，並支援錯誤發生時的處理。[B11] 對企業流程的啟示，是把重要資訊放在決定旁邊。若要批准退款，畫面應清楚顯示訂單、收款對象、金額、依據與將發生的動作；若要批准對外報價，就應讓人直接看到採用價目與特殊條件，而不必另外開啟多個系統尋找。

讓覆核看見證據與差異

對重要金額或資格判定，本文建議優先呈現原始紀錄、核准規則與計算結果，再呈現 AI 的整理。這樣能降低覆核者只沿著模型敘述走的機會。若輸出包含推論，應把確定事實、缺少資訊與待判斷事項分開，避免用一段完整文字掩蓋資料缺口。這裡要求的是可核對的依據與處理紀錄，不需要把模型生成的長篇理由視為真實決策機制的完整揭露。

覆核也要能察覺重複與累積效果。單筆退款看起來合理，若同一客戶在短時間內重複提出，整體結果可能不同。單次報價折扣沒有超過門檻，若代理拆成多筆交易，也可能造成超出授權的結果。因此，可以在交易類流程中加入必要的歷史與累計資訊，並由後端規則檢查，讓人能理解當下決定與既有行為的關係。

人工核准還有一個容易忽略的時點問題：人核准的是哪一份內容？若系統在核准後又換了收款對象、金額或附件，先前的同意就不再對應實際執行。可以把核准綁定到明確版本與動作，關鍵內容變更後重新確認。這項設計在電子郵件寄送、付款、刪除及對外發布等情境同樣適用。

用實際工作測試人工關卡

本文建議在試辦階段安排受控演練，觀察覆核者能否發現事先設計的錯誤，例如引用錯版手冊、幣別不符、缺少退款條件，或對外訊息包含不必要個資。演練應使用適當的測試資料，清楚界定目的，避免把測試變成責備員工的工具。若多數人沒有發現某類錯誤，應先檢查介面、訓練、時間與規則，而不是只提醒大家更仔細。

抽查比例也應依影響與已知問題調整。低影響的內部草稿，可以在驗證後採風險導向抽查；涉及資金、重大權益或難以撤回的動作，則需要更強的事前確認與系統限制。本文沒有提供通用的抽查百分比，因為相同百分比在不同交易量、錯誤後果與偵測能力下，代表的保障程度不同。

對外服務還需要讓客戶知道如何請人介入。申訴入口應容易找到，能讓當事人補充資料、說明爭議並取得後續處理資訊。若客戶必須先說服同一個 AI 自己有資格申訴，程序可能在最需要協助時失去作用。可以把申訴案件獨立記錄，確認承辦人能回看當時依據與版本，並把合理更正回饋到規則與測試。

人工覆核的價值，最終應反映在工作結果。企業可以觀察被攔下的錯誤類型、覆核工時、退回原因、申訴更正與員工反映，再決定是否調整自動化範圍。如果一項工具產生草稿很快，卻讓每個人花更多時間查證，業務負責人就應重新評估它是否真的改善流程。這也是 AI 治理需要同時看品質與效益的原因。

13．AI Agent 治理：當模型能採取行動，權限就成為核心設計

客服工具開始接上訂單、報價與退款系統之後，治理重點會發生變化。原本的錯誤可能停留在一段文字，現在則可能寫進資料庫、寄給客戶，或觸發金流。管理者需要把「能理解指令」與「有權執行」分開設計，並且確認每一次動作的授權依據。

OWASP 在其 2025 版「Excessive Agency」說明中，把過多功能、過多權限與過多自主性列為重要成因。[B04] 本文採用這個已標示版本的分類來說明設計問題，並不把它稱為所有年份的固定編號。對案例公司而言，實際問題可以很簡單：一個只負責準備退款申請的代理，是否真的需要取得直接退款、修改銀行資料與刪除訂單的能力？

將業務授權做成系統能執行的限制

本文建議先列出代理的動作清單，再逐項決定可讀、可建議、可建立草稿、可在條件內執行，以及必須人工核准的範圍。這些權限應在實際工具與後端系統中落實。若公司只在提示詞寫「不得退款超過上限」，但呼叫介面允許任意金額，真正的控制仍然不足。後端應依帳號、角色、交易條件與核准紀錄檢查請求，拒絕不符合條件的動作。

工具也應盡量貼近必要任務。代理若只需查詢某筆訂單，就提供受限制的訂單查詢能力；若只需建立待審退款，就提供只能建立待審狀態的功能。開放一個可以任意執行指令、讀寫所有資料或連線任何網址的通用工具，會擴大需要證明安全的範圍。細分工具的目的，是讓權限與責任有清楚的邊界，而非增加操作步驟本身。

服務帳號也要有可追溯的身分。當代理代表某位員工操作，系統應知道原始使用者是誰、他擁有甚麼權限，以及代理取得了哪些委派權限。若所有操作共用一個高權限帳號，出現事故時會難以區分誰要求、誰核准與誰執行。可以把委派範圍與有效時間納入設計，並讓憑證撤銷與人員離職流程相互連動。

外部內容能提供資訊，不能自行取得授權

代理會讀取客戶信件、網站、文件與工具回傳內容，這些輸入都可能包含不可靠或具有操控意圖的文字。即使來源是公司內部文件，也不代表其中的每一句話都具有改變系統規則的權限。本文建議清楚區分使用者授權、系統政策與外部資料，並讓資料內容無法直接改寫工具權限或核准條件。

OWASP 的提示注入指引指出，RAG 與微調無法完全排除這類風險；敏感資訊揭露指引也提醒，僅在系統提示中限制資料輸出，仍可能遭到繞過。[B02][B03] 這些觀察支持一個務實設計：即使模型誤讀了文件，後端仍應阻止它取得不必要資料、改變授權或執行超出範圍的動作。提示詞是控制的一部分，資料與工具的邊界還需要由程式及權限機制維持。

對會瀏覽外部網站的代理，本文建議依用途限制可連接位置、可傳送資料與可下載內容。對會讀取郵件的代理，則限制它將內容帶到其他系統的能力。若代理需要把客戶資料傳給另一項服務，應先確認這條資料流已獲核准，而不能只因模型認為有助於完成任務就允許。這項要求與前面的供應商及資料治理相接，避免新工具悄悄打開另一個出口。

同時管理金額、次數、時間與重複執行

代理可能在多輪嘗試中消耗成本，也可能在網路逾時後重試動作。本文建議為每項任務設定可理解的執行預算，例如最大嘗試次數、最長執行時間、可使用工具範圍與費用上限；具體數值依業務與測試結果設定。超過預算時，系統應停止、保留狀態並通知負責人，避免無限重試或默默轉用未核准服務。

交易類工具還要能辨識同一件事是否已經完成。假設退款請求送出後沒有即時收到回覆，代理若再送一次，可能造成重複退款。本文建議使用交易識別碼與後端檢查，讓相同請求重送時能辨識既有結果。這是傳統交易系統也需要處理的問題；AI Agent 的多輪與重試行為，使它更值得在測試時明確驗證。

停止機制也應能在模型之外生效。資訊人員應可以撤銷工具憑證、暫停寫入、取消排程或切換為唯讀模式，不必期待代理收到一句「請停止」後自行遵守。若已經送出付款或公開資訊，停止後續動作不代表先前結果被撤銷，仍要透過財務、客服或事件程序處理。這一點需要在管理者看過的架構與演練中說清楚。

多代理協作不應使責任消失

當企業使用多個代理分工，仍應保留一個能對完整工作負責的業務流程。研究代理找到資料，報價代理產生草稿，執行代理送出交易，每個交接點都要知道輸入來源、權限與可接受的輸出。另一個代理回覆「主管已同意」，不能自動取代可驗證的核准紀錄。可以把跨代理訊息視為需要驗證的工作資料，重要授權仍由可信任的系統狀態確認。

對案例公司而言，可以先讓代理完成資料整理與草稿，再逐步增加經過驗證的動作。每次擴大自主性，都要更新情境清冊、風險評估、測試與監控。這樣的進程讓治理與能力成長同步，也讓經營者能清楚看見：公司究竟把哪一部分判斷與執行交給了系統，又保留了哪些必要的人員責任。

14．上線後的 AI 治理：版本、事故與退場都需要有人接手

一個 AI 系統通過測試，只表示某個版本在已知條件下取得了足以支持當次決定的證據。上線後，資料會更新、使用者會改變問法，供應商可能調整模型，業務也可能擴大用途。治理因此需要持續觀察系統是否仍在原本的核准範圍內工作，以及原先的風險判斷是否仍然成立。

NCSC 的安全維運指引將行為監控、輸入監控與更新管理納入 AI 生命週期，並指出資料、模型及提示的變更可能改變系統行為。[B14] 企業可以依這個方向把 AI 納入既有維運制度，再補上模型與資料特有的觀察項目。若公司原本已有變更、資安事件與服務中斷流程，優先讓新制度接得上原有責任，通常更容易落實。

監控要能引發行動

本文建議先定義幾個與業務後果直接相連的訊號。客服問答可以看錯誤引用、人工修正、轉人工與客訴更正；報價流程可以看幣別、價目與條件錯誤；退款代理則要看未授權動作、重複交易、核准失敗與人工中止。使用次數與節省時間可以衡量採用情況，但需要與品質及風險指標一起閱讀。

監控紀錄要能對應同一個版本。本文建議記錄應用版本、模型識別、主要設定、知識庫版本、工具與核准流程版本，以及事件時間與情境識別碼。實際可取得的模型版本資訊取決於服務能力；若供應商無法固定或提供精確版本，就應記錄這項限制，並增加變更偵測與回歸測試。不能把一個會自動更新的模型名稱，當成永遠相同的測試對象。

對每項重要訊號，還要先決定由誰處理、何時升級，以及可以採取哪些措施。例如出現跨客戶資料時，應立即限制相關資料存取並啟動調查；一般措辭問題則可進入例行改善。具體通知期限與外部通報義務，應依適用規範及事故情境確認，本文不設定一個適用所有組織的時限。警報的價值來自有人接手，不能只停留在儀表板上。

把變更視為一個可比較的實驗

更新知識庫、提示詞、檢索設定或工具，都可能影響結果。本文建議依變更影響決定驗證範圍：修正錯字與增加退款權限，需要的審查強度顯然不同。對重要變更，保留舊版、執行既有測試、補上新情境，再用限定範圍觀察。若正式環境不適合直接比較，可以先用經適當處理的測試資料重播，或在不執行實際動作的環境中觀察。

變更紀錄需要說明為何改、改了甚麼、預期影響與如何撤回。若只記錄「更新模型，效果更好」，下一位維運人員將無法判斷哪一類品質改善、哪些限制仍存在。本文建議把核准決定與測試報告連結，保留變更前後的結果差異；對於尚未解決的問題，標示仍維持的使用限制，而不是在新版上線後自動視為關閉。

事故處理先控制影響，再釐清原因

假設案例公司的退款代理對同一筆訂單重複送出請求。第一步應是控制後續影響，例如暫停退款寫入、撤銷相關憑證或切換人工流程，同時保留必要的事件證據。接著確認影響範圍：哪些訂單、哪些客戶、哪些時間、哪些版本，以及哪些動作已經生效。調查不應只問模型說了甚麼，也要看工具請求、核准紀錄與後端交易結果。

NIST SP 800-61 第 3 版將事件應變納入整體資安風險管理，涵蓋準備、偵測、回應及復原等工作。[B12] 本文據此建議，AI 事故也應有跨部門的處理安排。資訊人員負責系統與證據，業務負責確認客戶與服務影響，法務或合規人員判斷適用義務，管理者決定資源與復原條件。對外說明則應由明確窗口負責，避免多個部門發布互相矛盾的訊息。

回復舊版有時可以阻止同類錯誤繼續發生，但不能撤回已寄出的訊息、已被看見的資料或已完成的金流。可以把技術復原與業務補救分開追蹤。前者檢查系統是否恢復可接受狀態，後者確認客戶通知、資料更正、退款調整與申訴處理是否完成。只有系統重新啟動，並不代表事件已經結案。

事後檢討應沿著傷害路徑查找控制缺口。重複退款可能涉及代理重試、後端未辨識重複請求、監控過慢與人工覆核資訊不足。若報告只寫「AI 判斷錯誤，已加強提示詞」，就會漏掉其他可改善的地方。可以把改善轉成可驗證事項，指定負責人、完成條件與重新測試方式，再將事件加入測試集。

退場是導入計畫的一部分

有些 AI 功能經過試辦後，可能因覆核成本太高、資料品質不足或需求改變而停止。企業應能有秩序地退場，包括停止排程、撤銷憑證、移除不再需要的連接器、處理資料與索引、保留必要證據，並確認原有工作由誰接手。若功能沒有負責人、長期無人使用卻持續保留權限，也應列入清理範圍。

可以在首次上線時就回答一個問題：「如果明天必須停用，這項業務如何繼續？」答案可以是人工處理、既有系統或另一個已驗證流程。替代方式需要與目前服務規模相符，不能只寫「必要時人工接手」卻沒有承辦人與容量評估。定期演練停止與恢復，能讓經營者知道公司的可控性是真實能力。

當盤點、評估、測試、覆核、監控與退場接成一個循環，企業才有條件讓 AI 使用範圍逐步擴大。每一輪更新留下的證據，也會成為下一次決策的起點。接下來討論國際規範與導入安排時，重點就能更清楚：外部要求應落在哪些既有工作上，還有哪些缺口需要補足。

15．歐盟 AI Act：先辨認角色、用途與市場，再確認義務

當前面的客服系統準備提供給歐洲經銷商使用，老闆很可能問：「我們需要通過歐盟 AI 認證嗎？」這個問題看似直接，卻把數個尚未確認的前提擠在一起。公司究竟是使用別人的服務，還是以自己的品牌提供 AI 系統？系統只回答產品規格，還是會影響自然人的就業、信用或醫療權益？輸出會在哪裡使用？這些問題沒有回答之前，任何一口報出的認證方案，都可能與真正的義務錯開。

歐盟《人工智慧法案》，通常稱為 EU AI Act，是法規。企業內部的風險分級是管理方法，ISO／IEC 42001 則是管理系統標準。三者可以協作，但名稱相近不代表法律效果相同。企業應先確認自己是否落入法規範圍，再整理需要哪些證據；不能反過來，先買一份證書，再假定法律問題已經解決。

台灣公司，也可能需要做適用性判斷

EU AI Act 的適用範圍並不只看公司登記地址。Article 2 涵蓋向歐盟市場提供 AI 系統或一般用途 AI 模型的供應者，也涵蓋在歐盟設立或位於歐盟的部署者；第三國的供應者與部署者，其 AI 輸出在歐盟使用時，也可能落入範圍。是否適用仍須連同具體角色、活動與例外判斷，不能只用「客戶是外國公司」或「伺服器在台灣」下結論。[C01]

這對零組件公司的實務意義是，採購表應多問兩件事：這個系統服務哪些市場，以及誰真正使用它的輸出。如果客服只協助台灣同仁搜尋公開手冊，與把 AI 評估結果交給歐洲企業作為聘僱決定依據，所需分析不同。兩者使用相同模型、甚至相同軟體，也不能共用一份沒有用途說明的法遵結論。

本文建議企業建立一張「適用性判斷紀錄」，包含法律實體、產品名稱、預定用途、使用者、受影響的人、使用市場、公司的角色、判斷依據及下次重查日期。這份紀錄不必一開始就寫成數十頁法律報告；但有疑義的欄位必須寫明誰負責確認，不能用「應該沒有問題」充當結論。如果用途從回答問題改成執行退款，或使用市場從台灣擴展到歐盟，紀錄就要重新打開。

供應者、部署者與模型供應者，承擔的工作不同

一般企業購買商用聊天工具，與自行訓練並向市場提供一般用途 AI 模型，並不是同一種角色。歐盟針對一般用途 AI 模型供應者設有技術文件、下游資訊、著作權政策、訓練內容摘要等要求；具系統性風險的模型還有額外要求。這不表示每一家使用 API 的公司都要負擔完整模型供應者義務。另一方面，把外部模型整合為自有品牌的系統，也不能因為「模型不是我做的」而直接排除自己的系統供應者責任。[C01][C05]

在採購會議裡，值得追問的不是「廠商有沒有宣稱符合 AI Act」，而是「廠商用什麼身分，對哪一個產品版本、哪一項義務，提供了什麼證據」。一份模型文件可能說明底層能力與限制，卻不會替企業確認自家客戶資料是否有適當處理依據，也不會替退款流程決定授權上限。供應鏈上的文件必須彼此接得起來，才可能形成可檢視的責任鏈。

例如，模型供應者說明模型可能產生不準確內容，系統整合商提供來源引用與工具權限設計，使用企業則定義哪些退款需要人工核准。三層工作各有負責人。若企業只收集第一層的安全白皮書，後兩層仍然空白，文件再完整也不足以支持實際放行。這是本文對責任分工的管理建議，並非逐項替特定系統作出法律認定。

風險不是依照「有沒有生成式 AI」分類

歐盟的高風險判斷包含不同路徑。Article 6（1）涉及受附件一所列產品法規涵蓋的產品或安全元件，並有相應的第三方符合性評估條件；Article 6（2）則連結附件三所列特定用途，例如部分就業、教育、關鍵基礎設施或重要服務情境。這不是把所有工廠 AI、所有人資軟體或所有大型模型一律列為高風險。附件三相關例外也有條件，不能自行用「只是輔助」四個字跳過分析。[C01]

對讀者更實用的判斷順序是：先查是否涉及禁止實務，再查是否涉及特定高風險用途及其條件，接著確認透明義務、模型相關義務及其他法律。一般企業內部使用的「低、中、高」管理分級，只是協助分配審查資源的工具，不能取代這個法律判斷順序。

回到虛構案例，讓客服查詢螺絲尺寸，與讓系統推斷員工情緒以評價工作表現，所涉及的問題完全不同。後者必須先檢查禁止實務與例外，不能因為主管同意、員工簽過一般同意書，或公司自行評成中度風險，就認為能合法上線。企業內部的核准程序能分配責任，不能創造法律原本沒有給的許可。

2026 年的時間表，必須使用修法後版本

截至本文 2026 年 10 月 21 日查核，AI Omnibus 已不是單純的立法提案。歐盟官方確認修正法於 2026 年 7 月 27 日生效；EUR-Lex 的 2026 年 7 月 27 日合併版本亦列出 Regulation（EU）2026／1744。修法調整部分高風險義務時程，因此，把 AI Act 寫成「2026 年全面適用」，會漏掉現行法的重要差異。[C02][C03]

上表是主要時程的閱讀導航，不是完整過渡條款清單。修法新增部分禁止實務另自 2026 年 12 月 2 日適用；Article 111 也有既有系統及模型的安排。對特定產品做決策時，應回到現行條文，而不是只截取時間表的一列。[C01][C02][C05]

透明與 AI 素養，容易被誤讀成兩張表單

Article 50 的重點之一，是讓相關人員知道自己正在與 AI 互動，並對特定合成內容、深偽或公共利益文字建立不同的標示安排。這些義務有各自的主體、適用條件與例外，不能簡化為「所有 AI 文字都要加同一句警語」。歐盟執委會於 2026 年 7 月發布相關指引，供應者與部署者應分別核對。對於 2026 年 8 月 2 日前已上市、生成合成內容的特定系統，Article 50（2）的機器可讀標記另有至 2026 年 12 月 2 日的過渡安排。[C04][C01]

企業可以先做一件具體的事：讓客服、行銷與產品團隊各自列出使用者第一次接觸 AI 的位置。是聊天視窗、電子郵件、服務條款，還是影片開頭？接著檢查告知是否看得見、是否說明重要限制，以及需要人工協助時是否找得到人。把小字藏在沒有人會打開的頁面，與讓使用者在決策當下理解服務性質，治理效果相差很大。

AI 素養也不能只用簽到表代表。修正後 Article 4 仍要求供應者及部署者採取措施，支持相關人員發展 AI 素養，並考量其知識、經驗、訓練與使用脈絡；同時明示不要求保證每一個人的特定素養水準。它沒有指定必須購買某一張課程證書。[C02] 因此，本文建議把培訓證據放在工作情境：客服能否辨認無來源的答案，採購能否問出資料保留條件，主管能否在例外案件出現時決定停用，而不只統計多少人上完課。

法規章節的價值，在於讓企業提出正確問題。它不是一份可以直接套用到所有行業的法律意見。只要確認涉及跨境市場、高影響決策、敏感個資或特定監理領域，就應把系統清冊、資料流與用途說明交給適格的法務或外部專業人員。資料準備得越具體，法律判斷越容易落到可執行的條件，而不會停在籠統的「有風險」。

16．台灣企業如何接軌國際與本地治理

讀完國際框架，台灣企業常出現兩種反應。第一種是覺得公司規模太小，這些制度只屬於跨國集團；第二種是認為只要全部照搬，未來就不會出錯。兩種思路都有同一個盲點：沒有先問企業的業務風險、客戶要求與法定責任，究竟落在哪裡。

治理需要比例原則。只有少數員工使用核准工具整理公開資訊，與公司把大量客戶資料交給外部服務、讓代理人修改交易紀錄，理應承擔不同的設計成本。但比例原則不是規模小就免責，而是把有限資源優先放在最可能產生重大傷害、最難恢復的環節。

台灣基本法已經施行，不能再沿用草案說法

全國法規資料庫記載，《人工智慧基本法》於 2026 年 1 月 14 日公布，並依第 20 條自公布日施行。法律設計包括政府推動 AI 的基本原則、主管機關分工，以及由數位發展部推動風險分類框架、各目的事業主管機關發展風險管理規範等安排。[C06]

閱讀時必須看清楚條文主詞。法律中的政府政策要求，不宜直接改寫成每一家民營公司都負有完全相同、可用同一方式處罰的義務。反過來，也不能因為基本法具有政策與制度建構性質，就認為企業目前使用 AI 完全不受規範。個資、契約、智慧財產、勞動、消費者保護及各產業既有規定，仍須依具體情境檢視。

對企業經營者而言，這代表應建立「規範追蹤責任」，而不是讓每個同仁自行追新聞。誰負責確認產業主管機關的新指引？誰把更新轉成採購或作業條件？誰判斷已上線用途需要重審？若法規動態只留在轉寄信件裡，沒有對應到清冊中的系統，資訊再及時也不會變成治理。

數發部風險分類框架，是接軌的共同語言

數位發展部於 2026 年 7 月 7 日正式訂定「人工智慧風險分類框架」。官方文件說明，其主要對象是各目的事業主管機關，也提供產業及社會大眾參考，工作流程包括盤點情境、識別風險、評估風險與應對風險。領域管理規範的形成與執行，仍涉及各主管機關的權責。[C07][C08][C09]

這項定位很重要。企業可以用框架來整理自己的使用情境與傷害路徑，讓未來與客戶、主管機關或稽核人員的對話更一致；但不能把它宣傳成一張所有公司都必須取得的認證。也不能把歐盟分類的名稱直接貼到台灣每一個用途上，省略當地法規與產業條件。

本文建議的接軌方式，是保留一份共同的證據底稿，再附加不同要求的對照。例如，系統目的、資料來源、負責人、權限、測試、事故與版本紀錄，都是企業本來就應能說明的事。歐洲客戶要求的文件、台灣產業指引與公司內控要求，可以在同一份底稿上標註對應，避免各部門分別做三份內容逐漸分歧的清單。

這種做法還有一個現實優點：當某一項法規改變，只需要找到受到影響的控制與證據，而不是重寫所有政策。假設新的客戶條款要求更短的事故通報時間，企業可以確認通報流程、窗口與供應商合約是否能支援；不用把原本的資料分類、教育訓練與權限制度全部推倒重來。

先分清法律、契約、標準與企業自己的承諾

一個常見誤解是，客戶要求公司填寫 AI 治理問卷，就等於法律規定公司必須完成問卷裡的每一項。實際上，問卷可能混合法定要求、客戶的採購偏好、國際標準及超出法定底線的商業條件。企業應逐項標明來源，才能知道哪些不能省略，哪些可協商替代證據，哪些需要另外報價或調整服務範圍。

如果公司主動承諾「所有客戶資料都不離開台灣」，就必須確認備份、錯誤紀錄、客服支援與次處理者的路徑，而不只是主要資料庫的位置。如果承諾「任何 AI 決策都有人審查」，就要確認實際系統不會在人工核准之前寄出通知或執行交易。這些例子說明，對外承諾會增加企業自己必須維持的控制責任。寫得越漂亮，不代表成本越低。

因此，AI 治理也應參與業務提案。業務需要知道哪些承諾已有證據、哪些需要加購設定、哪些目前做不到。讓法務在合約簽完後才第一次看到「資料絕不外流」的保證，常會迫使團隊在成交後補救。把技術限制提前說清楚，反而能避免交付時的信任損耗。

國際案例可以學方法，不能直接搬用門檻

新加坡 IMDA 在 2026 年更新代理式 AI 治理框架，強調人類仍須承擔責任，並納入企業實務案例。這類材料的價值，是讓企業看到如何把權限、人工介入與責任安排轉成工作設計，而不是替所有產業提供同一組安全數字。[C10]

讀到某家公司允許代理人自動執行特定動作，不代表零組件公司也應照做。密碼重設、退款、庫存修改與安全設備控制的傷害、可恢復性和使用者權利並不相同。借用案例時應拆出決策邏輯：行動的影響範圍多大，錯了能否撤銷，誰有能力確認，以及停止後怎麼維持服務。這些問題比複製一張漂亮的架構圖更有轉移價值。

台灣中小企業不一定需要立即成立大型 AI 治理辦公室。但至少要有能做決策的負責人、有業務代表、有資料與系統管理能力，並能在需要時取得法務及領域專業協助。一人可以兼任多個角色，但「自己提案、自己測試、自己核准重大風險」的情形，應設計適當的第二層檢視。這是本文提出的治理安排，不是人數愈多就愈合規的公式。

17．90 天如何做出能運作的 AI 治理

治理最容易在「文件都完成了」的那一天失去方向。政策、表單與培訓各自結案，真正要上線的團隊卻仍不知道應交給誰審查。與其先把制度寫到完美，本文建議用 90 天完成一個範圍明確、可以被檢驗的治理循環。90 天是本文的推動示例，不是任何法規、NIST 或 ISO 規定的完成期限；高度受監理或影響生命安全的用途，也不應為了趕這個時程而省略必要程序。

第一輪的首要目的，是證明公司能回答四個問題：現在有哪些 AI 用途，其中哪些值得先處理，一個用途上線之前需要哪些證據，以及發現問題之後誰能讓它停止。能把這四個問題接成流程，就比一次完成大量無人維護的文件更接近可持續治理。

第 1 至 15 天：讓看不見的使用浮上檯面

專案負責人先與業務、客服、財務、人資及資訊同仁訪談，問他們已經用 AI 處理哪些工作。提問最好從工作開始，例如「哪些資料會被複製到外部服務」，而不只問「你有沒有用 AI」。員工可能不知道某個瀏覽器外掛或軟體內建功能也會傳送資料。如果盤點方式像追究違規，團隊更可能只交出已獲准的那一部分。

這段時間的產出是初版清冊、資料流的粗略圖，以及需要立即限制的用途。先處理沒有負責人、用途不清楚、可能接觸不適當資料或具不可逆操作權限的項目。對低影響的常見工作，則提供明確的可用工具與資料範圍，讓盤點同時帶來可行的替代方案。

在虛構案例中，盤點不只記錄「客服使用某聊天工具」，還要問清楚：誰把產品手冊上傳進去，手冊是否含未公開報價，是否有經銷商專屬資訊，客服是否會把答案直接寄給客戶，以及寄出後由誰處理爭議。這些答案會決定試辦範圍，不應等到系統開發完成才補問。

第 16 至 30 天：選一個用途，把核准條件寫清楚

本文建議先選有明確痛點、資料可整理、結果容易檢查、人工替代仍可運作的用途。客服查詢已核准的產品手冊，通常比自動決定賠償金額更適合作為治理流程的第一個教學示例；這是相對的管理判斷，實際仍要看產品與服務是否涉及安全等重大影響。

業務主管負責說明想改善的結果，系統負責人說明資料與權限，審查者協助辨認風險。三者共同寫出「允許做什麼」與「遇到什麼必須交回人工」。例如，允許提供有版本依據的規格資訊，不允許自行承諾尚未確認的交期；允許草擬回覆，不允許在未授權下修改客戶資料。

這段時間應有一個真正的決策會議。會議結論可能是同意有限試辦，也可能是要求縮小範圍，或暫不導入。成功的標準不是每個提案都通過，而是每個結論都有理由、負責人與後續條件。只有退件卻不說明怎樣才能重新申請，治理就會變成難以穿越的關卡。

第 31 至 60 天：把測試、人工覆核與事故演練接起來

這個階段的重點，不是增加功能數量，而是讓前面的核准條件能在系統裡實際被檢驗。測試資料應含正常問題、資訊不足、版本衝突與超出權限的請求。每一個重要失敗都要能連回一項控制，才知道問題應由資料、介面、流程或權限設計解決。

人工覆核也要接受測試。找幾位實際使用者，觀察他們能否看出來源、能否辨識錯誤、是否有足夠時間拒絕輸出。若所有答案都包裝得非常流暢，而原始資料藏在多層點擊後面，名義上的覆核人可能只能按下同意。改善這種情況，往往比再加一條「請務必檢查」的提示有效。

事故演練可以很小。假設一份已失效手冊被重新加入知識庫，團隊要回答誰能發現、誰先停用、哪些回覆需要追查、如何通知受到影響的客戶，以及恢復服務需要什麼條件。演練不需要真的寄出錯誤訊息，更不應為了演習動用正式退款。其產出應包括已發現的流程缺口與修正責任，而不是一張「演練完成」照片。

第 61 至 90 天：用有限上線證明治理能持續

當放行條件達成後，先限定使用者、資料範圍與操作能力，觀察真實工作中的表現。對試辦成果的報告，應同時呈現完成了多少任務、需要多少人工修正、哪些類型仍然不適用，以及維運要花多少時間。只挑幾段成功對話展示，無法支持擴大投資。

到了第 90 天，管理團隊應作出有選項的決策：維持現有範圍、擴展到相近用途、先修正控制，或停止這項應用。每個選項都應連到證據。若使用量太少、樣本過於單一或重大問題尚未解決，延長觀察期可以是負責任的結論，不需要為了專案結案而宣稱完成全面部署。

這份計畫可以由小團隊完成，但不能沒有固定的追蹤節奏。本文建議每週用短會檢查阻礙決策的事項，每個階段結束時檢查一次證據。日常討論聚焦在「哪個決定缺了什麼」，避免把會議變成各部門朗讀工作清單。

第二輪才開始擴充，避免讓治理跟不上授權

當客服檢索用途運作穩定，零組件公司可能想加入報價與退款。這應視為新的治理決策，而不是同一個系統的普通更新。因為權限與傷害路徑已經改變，原來證明「答案有依據」的測試，不能證明「交易執行正確而且有授權」。

第二輪可以重用清冊、風險評估與事故格式，但需要重新確認動作邊界、核准者、金額限制、重複執行與復原方式。這正是治理資產的價值：每次擴充不用從零開始，卻也不會因為工具名稱沒變，就把上一輪核准無限延伸。

如果公司只有能力維護一個用途，就先把一個用途維護好。讓十個部門各自成立沒有負責人的試驗，可能比把同一套有證據的流程複製到第二個相近情境更快，卻不一定更接近可持續的成效。治理的推進速度，應以組織能承擔的維運與判斷能力為條件。

18．預算、衡量指標與董事會應追問的問題

AI 治理要花多少錢，不能只看顧問報價或認證費。真正的成本包括整理資料、限制權限、測試、人工覆核、事故處理與維持版本紀錄的時間；這些工作即使沒有列在「AI 治理」的會計科目裡，也不會自動消失。當企業只計算模型訂閱費，就容易把後面的工作誤認為額外負擔，而不是把它視為交付可靠服務的一部分。

另一方面，也不應把所有資訊安全與法務費用都算到一個小型 AI 試辦，藉此得出「治理太昂貴」的結論。既有身分管理、資料分類、工單與事故通報流程，如果本來就能使用，應區分共同基礎成本與此次新增成本。合理預算需要看增量，而不是把每一項制度重新購買一次。

用工作量估算，不用沒有邊界的市場行情

本文建議把預算拆成四類：首次建立控制的投入、每月運作成本、隨使用量增加的成本，以及變更或事故時的額外投入。每類都寫出計算假設。這樣才看得見，某個方案便宜是因為做得更有效率，還是把人工覆核與維運留給客戶自行吸收。

以下只是一個自行設定假設的算式示例，不是天地人的報價，也不是市場行情。假設公司第一輪投入 80 小時進行盤點與制度設計，40 小時整理資料及權限，60 小時測試與修正，20 小時培訓與演練，共 200 小時；再假設用每小時 NT$800 的內部完整成本估算，人力投入即為 NT$160,000。若另假設工具與測試環境費用為 NT$20,000，初期估算合計 NT$180,000。

這個算式的用途，是讓主管看見構成，而不是用 NT$180,000 為所有公司定價。若現有資料混亂，資料整理可能遠高於 40 小時；若涉及高影響決策，專業評估與測試可能遠高於 60 小時；若已有成熟內控制度，也可能減少首次設計的工作。外部法律服務、正式驗證與特殊測試若不在假設內，必須另列，不能藏在合計數之外。

同樣地，時數要避免重複計算。一位主管在例行會議中花 30 分鐘審查 AI 試辦，未必等於公司增加了 30 分鐘現金支出，但仍代表資源被占用。報告可以區分現金支出與內部機會成本，讓經營者自行判斷資源配置；不能把所有時間都換算成營收，也不能因為薪資本來就會支付而認為時間完全沒有成本。

效率改善，先扣掉覆核與重工

假設客服原本處理一項問題需要 10 分鐘，使用 AI 後生成草稿需要 2 分鐘，人工檢查與修正還要 5 分鐘。可討論的初步改善是每件 3 分鐘，而不是只比較 10 分鐘與 2 分鐘。若少數錯誤需要主管額外處理，這些成本也要分攤到觀察期間。以上數字均為本文示例，目的是說明計算方法。

此外，節省時間是否真的變成可利用產能，要看需求與工作安排。如果員工每天節省零碎的幾分鐘，卻無法因此承接更多案件或改善其他服務，效益不應直接乘以薪資後宣稱已實現現金獲利。可以先報告可釋放的工作時間，再追蹤它被用到哪裡，避免把潛在價值寫成已入帳成果。

對治理的投資回報，也不要只靠「避免一次巨大事故」說服董事會。事故損失往往難以精確估算，若任意填入龐大金額，模型就會輕易支持任何支出。更可驗證的起點，是觀察治理是否縮短了低風險用途的核准時間，是否減少重複審查，是否更早發現不能上線的設計，以及是否讓客戶盡職調查更容易完成。

指標要有分母，也要保留不確定性

本文建議管理報表至少同時看覆蓋、品質、風險與價值四個面向。覆蓋面向關心哪些正式用途已有負責人與有效核准；品質面向關心任務是否正確完成；風險面向關心重大事件、例外與控制失效；價值面向則關心扣除覆核後的工作改善及整體成本。任何一個面向單獨變好，都不足以代表治理成熟。

例如，「100％ 完成盤點」必須說明分母是哪些部門、哪些已知系統、涵蓋什麼日期。公司可能只是完成已申報清單，仍未發現員工自行使用的外部工具。「零事故」也可能代表沒有通報管道、紀錄保存不足，或使用量太低。健康的報告應同時寫出觀測範圍，讓讀者理解數字能證明什麼、不能證明什麼。

管理團隊還應防止指標彼此扭曲。如果只獎勵自動處理比例，團隊可能把本該交給人工的案件也交給系統；如果只追求沒有任何例外，員工可能乾脆不申報新用途。指標應鼓勵對問題的真實揭露，並讓「主動縮小不適合的應用範圍」也能被認定為有價值的決策。

董事會與經營者，應追問可被驗證的責任

董事會不必閱讀每一份測試明細，但應要求管理階層能清楚回答幾個問題：公司最重要的 AI 用途是什麼，最大的剩餘風險由誰接受，有哪些承諾尚未有證據支持，重大事故發生時誰能停用，以及停止後業務怎麼繼續。這些問題把技術報告拉回公司必須承擔的責任。

更進一步，可以要求團隊展示一個完整案件。從原始需求、核准範圍、資料來源、測試紀錄，到最近一次版本變更與例外處理，能否用同一個系統識別碼串起來？如果不能，企業看到的可能是一組分散的文件，而不是正在運作的治理流程。

對前述零組件公司而言，最有說服力的成果不會是「我們已發布 AI 政策」，而是客服主管可以指出哪一版產品手冊支援哪一類回答，資訊人員可以證明未授權的客戶資料無法被讀取，財務主管知道退款權限尚未開放，經營者則能說明下次擴充前需要補齊哪些條件。這些證據讓成長有了可管理的邊界。

AI 治理最終要支持的，是企業在知道限制、看得見責任、保留介入能力的前提下，持續做出更好的業務決策。當制度能讓適合的用途較快獲得明確核准，也能讓不適合的用途及早停止，治理才真正進入日常營運。下一次模型更新、供應商更換或主管提出新功能時，公司便有能力重新判斷，而不是再次從一場無法結案的爭論開始。

19．AI 治理常見問題：企業最容易卡住的 12 個判斷

AI 治理是什麼？一句話如何向主管說明？

AI 治理是企業持續決定「AI 可以用在哪裡、由誰負責、需要哪些控制，以及拿什麼證據確認」的管理機制。本文用這個工作定義，把原則、系統與業務現場連起來。主管若只能看到工具採購清單，還看不到決策責任與受影響的人，治理的範圍就仍然不足。第一步可以先拿一項真實工作，寫出用途、資料、動作與核准人，再決定需要哪些制度。

AI 治理與 AI 倫理有什麼不同？

AI 倫理協助企業討論應尊重什麼價值，例如人的自主、公平及隱私；AI 治理把這些價值放進權責、採購、設計、測試、監督與補救流程。兩者會相互影響。若公司主張公平，卻沒有檢查誰容易受到不利影響，也沒有申訴管道，價值仍停留在宣言。本文第 3 章提供跨部門的對照方式，第 6 章說明如何讓受影響的人參與。

只有使用 ChatGPT 或其他現成工具，也需要 AI 治理嗎？

需要有與使用情境相稱的管理安排。購買現成工具，並沒有替公司決定哪些資料可以輸入、哪些輸出可以對外採用，以及誰負責處理錯誤。使用公開資訊草擬內部文案，可以採較簡單的規則；處理客戶個資、契約條件或重要人事決定，則需要更具體的審查。企業應以實際方案及設定查證資料條件，避免把某個產品的一項宣傳套用到所有帳號與功能。

中小企業一定要成立 AI 治理委員會嗎？

本文不主張所有公司都先設一個委員會。起點是確定有人能決定業務範圍、有人能維護資料與系統、有人能提出專業審查，而且重大風險有清楚的升級路徑。小公司可以兼任角色；涉及較大影響時，則應安排足夠獨立的第二層檢視。組織名稱不能代替決策能力，會議次數也不能證明控制有效。

NIST AI RMF、ISO/IEC 42001 與 EU AI Act 應該先選哪一個？

先確認適用的法律及契約要求，再決定需要哪些管理方法。NIST AI RMF 協助整理風險管理工作，ISO/IEC 42001 提供 AI 管理系統要求，EU AI Act 則是需要依範圍、角色及用途分析的法規。企業可以把同一份清冊、測試和事件證據對應到不同要求，避免重複製作內容不一致的文件。第 5 章解釋框架分工，第 15 章處理法律適用問題。[A01][A04][C01]

取得 ISO/IEC 42001 證書，就代表 AI 一定合規嗎？

不能直接作這個推論。管理系統證書有其驗證範圍、期間與條件，也不能保證每一次 AI 輸出正確，或企業在每個法域的所有用途均已符合要求。採購方應看證書涵蓋什麼組織、系統及活動，並另外確認實際用途的資料、權利與法規問題。本文沒有宣稱讀者完成範本即可通過驗證。[A04][C01]

AI 系統測試達到很高正確率，為何仍可能不能上線？

因為錯誤的後果不同。寫錯一個內部草稿標點，與把不屬於使用者的資料揭露出去，不能在平均分數裡視為相同的一題。測試還要說明樣本如何選取、誰評分、有哪些群體及邊界條件、哪些重大失敗尚未處理。即使樣本中沒有看到事故，也不能宣稱實際風險是零。第 11 章提供分母、重大失敗與放行條件的設計方法。

RAG 已經附上來源，還需要人工檢查嗎？

是否需要逐筆人工檢查，取決於用途及控制設計；但「附來源」本身並不足以證明回答可採用。還要確認來源有效、使用者有權讀取、引用支持答案，而且問題沒有超出文件適用條件。來源引用是一項核對工具。企業可依風險安排抽查、逐筆覆核或限制動作，並在資訊不足、文件衝突或影響較大的情況轉交人工。

AI Agent 治理與一般聊天工具治理，差在哪裡？

Agent 可能把判斷接到外部動作，因此治理必須涵蓋工具、帳號、參數、核准、重試、成本及停止方式。能讀取價格表，不代表能核准折扣；能建立報價草稿，不代表能直接寄出。最重要的實作是讓執行系統檢查權限，並讓每一次重大動作都有可追溯的核准依據。外部文件或電子郵件中的指令，也不能自行取得公司授權。第 13 章以退款流程拆解這些差異。

買企業版、選地端部署，就能解決資料風險嗎？

這些選擇可能改變資料與控制條件，但仍須查證實際方案、設定、權限及操作。企業版並不自動修正公司原本過度開放的文件；地端部署也仍需管理系統維護、更新、存取、備份及日誌。應先畫出資料會到哪裡、哪些人與服務能接觸、如何刪除與退出，再比較方案。本文第 9 至 10 章的問題單，可用於不同部署模式。

AI 治理要花多少錢，多久才能完成？

沒有能直接套用到所有企業的單一價格或完成期限。預算會受到用途數量、資料品質、權限整合、風險、監理要求、外部服務與維運工作影響。本文的 90 天計畫，是驗證一個受限用途能否完成治理循環的示例；第 18 章的成本也是可替換假設的教學算式。企業應先定義交付範圍與驗收，再向相關服務提供者取得具體報價。

AI 治理培訓上完之後，怎麼知道團隊真的會用？

可請每一種角色完成自己的工作證據。使用者要能判斷資料是否適合輸入、辨認無依據答案並回報問題；主管要能核准範圍與說明剩餘風險；IT 要能展示權限及停止機制；採購要能指出供應商證據缺口。這些是本文建議的能力驗收，不是法定證照條件。將演練結果連回清冊、測試與改善紀錄，才看得出培訓是否改變了實際工作。

20．從第一次會議開始，讓 AI 治理真正進入工作

回到那家虛構的零組件公司。到了文章最後，真正值得改變的，並不是把「客服 AI」改成更響亮的專案名稱，而是讓公司能明白決定：哪一段查詢可以放心交給系統，哪一段商業承諾必須由人確認，哪一種失敗必須立刻停止，以及下一次擴大使用之前要補上什麼證據。

你可以把第一次工作會議安排為 60 分鐘。這是本文建議的起步方式，並非完成治理的標準工時。前 15 分鐘選一項已經有人在用、而且值得改善的工作；接著 15 分鐘畫出資料、輸出與外部動作；再用 15 分鐘討論最可能受影響的人、最難恢復的錯誤及現有控制；最後 15 分鐘決定負責人、允許範圍、下一份證據與回看日期。

離開會議時，至少留下四件東西：一筆能被看懂的清冊紀錄、一個有權作決定的業務負責人、一項明確的使用邊界，以及一個可以檢驗的下一步。若當天發現資料或權限條件不清楚，下一步就可以是釐清條件。停止擴大某項用途，也是有價值的管理決定。

當每一次擴大 AI 權限，都伴隨相應的證據與責任，企業才有條件把成功的試點變成可持續的營運能力。這也是 AI 治理最實際的價值：讓人知道哪些工作可以放心前進、哪些問題需要改變設計，以及誰會把決定落實。

把文章帶回團隊使用

先完成一份 AI 使用清冊，再挑一項工作練習風險判斷、來源核對與人工接手。若需要安排企業內部的 AI 應用、使用規範或跨部門實作培訓，可查看天地人的企業 AI 培訓與導入服務，或透過 service@tiandiren.tw 說明希望改善的工作、參與角色與預計時程。實際課綱、業師、交付及報價依需求確認。

延伸閱讀

• AI Agent 是什麼？從運作原理到企業導入。接續理解 AI 如何使用工具與完成任務。
• 企業 AI 導入怎麼做？90 天試點與執行步驟。將治理安排接到部門導入專案。
• AI 專案為何做完 PoC 卻無法上線？。深入檢查生產系統的交付與驗收。
• RAG 有引用仍答錯？檢索與生成測試。練習把錯誤定位到正確環節。
• 企業導入 AI 要花多少錢？預算與 ROI 試算。延伸整理投資與效益假設。

研究方法、案例與審核範圍

本文以英文官方來源為優先，並以台灣正式法規及主管機關資料補充本地制度。正文引用 35 筆第一手資料，涵蓋 NIST、ISO、OECD、歐盟、台灣政府、OWASP、NCSC、ICO、研究論文及技術提供者的原始文件。來源表保留版本、查核日期、支持主張、短原文與使用界線，讀者可直接回到原始頁面核對。

本稿由 AI 協助研究、撰寫、圖表設計及多輪交叉檢核。檢核包括 35 筆來源短引、48 項關鍵主張、法規日期、數值算式、案例標示及圖文一致性。這是編輯與證據檢核，未取得外部律師、認證機構或具名真人專家的簽證。ISO 引用範圍限於官方公開摘要，沒有宣稱閱讀付費標準全文。

案例公司、流程中的假設數據、內部分級、90 天安排及成本估算，均為說明管理方法而設計。它們不代表真實客戶成果、市場平均值或政府規定。本文將事實來源、編輯推論與操作建議分開標示；法律與產品內容以 2026 年 10 月 21 日可查資料為準，後續修訂仍須更新。

發布前於 2026 年 10 月 21 日重查 NIST 版本、歐盟現行合併法及修正法、台灣基本法與數發部框架，未發現影響本文結論的變動。C01 與 C02 已重新直接讀取官方正文，並核對 Article 4、50、111、113；C10 的直接回應仍未提供完整正文，採官方搜尋索引及官方總覽交叉核對，不宣稱完整讀取框架。兩支影片僅核對官方頁面、標題、上傳資訊與嵌入網址，未逐段審聽，本文不引述影片對話或未驗證時間碼。

原始來源與引用原文

以下短原文只保留支持本文判斷所需的片段；中文翻譯為本文整理。來源的公開摘要、指引、法律、研究或產品說明各有適用範圍，請連同「使用界線」閱讀。來源更新可能改變頁面內容，查核日期均保留。

A01．AI Risk Management Framework

來源機構：National Institute of Standards and Technology（NIST）。採用版本／日期：框架發布：2023-01-26；查核時網頁明示 AI RMF 1.0 正在修訂。查核日：2026-10-21。

原始出處：https://www.nist.gov/itl/ai-risk-management-framework

支持的主張：AI RMF 為自願採用的框架；風險範圍涵蓋個人、組織與社會；納入設計、開發、使用與評估；2026-10-21 查核時 1.0 正在修訂，本文仍以已公開 1.0 作實務解讀。

is intended for voluntary use

中譯／說明：供自願採用。

使用界線：不代表所有法域均無相關強制義務；不得把框架採用等同法律符合性或產品認證。本文不推測修訂版內容。

A02．AI RMF Core

來源機構：NIST AI Resource Center。採用版本／日期：摘自 AI RMF 1.0（2023）；頁面另標示修訂中。查核日：2026-10-21。

原始出處：https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

支持的主張：四項功能為 GOVERN、MAP、MEASURE、MANAGE；功能不構成必須依序完成的檢查表；GOVERN 橫跨其他功能；本文的客服助手操作是情境化建議而非 NIST 指定流程。

Governance is designed to be a cross-cutting function

中譯／說明：治理被設計為貫穿各項工作的功能。

使用界線：本文只概述核心關係，未重製分類與子分類全文；示例控制不是 NIST 原文要求。

A03．NIST AI RMF Playbook

來源機構：NIST。採用版本／日期：首個完整版本：2023-03-30；網頁更新：2026-06-10。查核日：2026-10-21。

原始出處：https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook

支持的主張：Playbook 為自願採用的配套資源；提供建議行動、參考資料與相關指引；使用者可以按情境選用，並非全部逐條強制套用。

includes suggested actions, references, and related guidance

中譯／說明：包含建議行動、參考資料及相關指引。

使用界線：不將 Playbook 當作認證清單；頁面指出將在 AI RMF 1.0 修訂後更新。

A04．ISO/IEC 42001:2023：AI management systems

來源機構：International Organization for Standardization（ISO）。採用版本／日期：2023-12，Edition 1。查核日：2026-10-21。

原始出處：https://www.iso.org/standard/42001

支持的主張：為 AI 管理系統標準；要求範圍涉及建立、實施、維持與持續改善 AI 管理系統；適用於提供或使用 AI 產品服務的組織。

establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System

中譯／說明：建立、實施、維持並持續改善人工智慧管理系統。

使用界線：只查核官方公開摘要與介紹，未宣稱閱讀付費全文；不列未核對條款，亦不以管理系統驗證推論所有個別 AI 結果正確或一切法律均已符合。

A05．ISO/IEC 23894:2023：AI — Guidance on risk management

來源機構：ISO。採用版本／日期：2023-02，Edition 1。查核日：2026-10-21。

原始出處：https://www.iso.org/standard/77304.html

支持的主張：為 AI 相關風險管理指引；協助將風險管理整合至 AI 活動與功能；可依組織及其情境調整應用。

The application of this guidance can be customized to any organization and its context.

中譯／說明：這份指引的應用可依組織及其情境調整。

使用界線：僅依官方公開摘要，未引用或重製付費條文；不把指引誤稱為獨立產品認證。

A06．ISO/IEC 42005:2025：AI system impact assessment

來源機構：ISO。採用版本／日期：2025-05，Edition 1。查核日：2026-10-21。

原始出處：https://www.iso.org/standard/42005

支持的主張：提供 AI 系統影響評估指引；關注 AI 系統及可預見用途對個人、群體與社會的影響。

may affect individuals, groups, or society at large

中譯／說明：可能影響個人、群體或整體社會。

使用界線：只採官方公開介紹；本文提出的操作例子不是該標準逐字要求，不宣稱已完成正式標準符合性評估。

A07．AI principles

來源機構：Organisation for Economic Co-operation and Development（OECD）。採用版本／日期：2019 年採納；2024 年更新。查核日：2026-10-21。

原始出處：https://www.oecd.org/en/topics/ai-principles.html

支持的主張：AI 原則於 2019 年採納、2024 年更新；價值面向包括人權、公平與隱私、透明與可解釋性、穩健與安全及責任；本文以其為價值方向，不視為企業通用的直接法律義務。

Adopted in 2019 and updated in 2024

中譯／說明：於 2019 年採納，並於 2024 年更新。

使用界線：本段沒有列出各國採納或執法狀態；價值原則不等於個別法域的強制法規清單。

A08．ISO/IEC 38507:2022：Governance implications of the use of artificial intelligence by organizations

來源機構：ISO。採用版本／日期：2022-04，Edition 1。查核日：2026-10-21。

原始出處：https://www.iso.org/standard/56641.html

支持的主張：指引對象包括組織治理機構成員；關注 AI 在組織內有效、有效率且適當的使用；亦涵蓋高階主管及其他專業角色。

guidance for members of the governing body of an organization

中譯／說明：提供組織治理機構成員所需的指引。

使用界線：僅查核公開摘要；本文未逐條聲稱董事會或特定職稱依法必須採取某一行動。

A09．Microsoft Responsible AI Standard, v2：General Requirements

來源機構：Microsoft。採用版本／日期：2022-06，公開版 v2。查核日：2026-10-21。

原始出處：https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf

支持的主張：Microsoft 將責任原則轉化為不同的目標與要求範圍；公開文件涵蓋資料治理、適用目的、人員監督與持續評估；僅作企業實踐參考，不是所有公司的法定清單。

Microsoft AI systems are subject to appropriate data governance and management practices.

中譯／說明：Microsoft 的 AI 系統應採取適當的資料治理與管理實務。

使用界線：這是 Microsoft 2022 年公開的企業標準，不宣稱為其最新內部政策；不重製標準全文，亦不將個別公司的內規擴張為普遍法律義務。

A10．Microsoft Responsible AI Impact Assessment Template

來源機構：Microsoft。採用版本／日期：2022-06，公開版。查核日：2026-10-21。

原始出處：https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-RAI-Impact-Assessment-Template.pdf

支持的主張：預定用途不等於系統功能；用途說明涉及誰使用、為何使用及使用情境；正文的工具核准與用途授權區分，是本文的實務延伸。

They are not the same as system features

中譯／說明：它們與系統功能並不相同。

使用界線：這是一份企業內部方法的公開模板；本文未重製其全表，也不聲稱填表即可證明法規符合性。

A11．Microsoft Responsible AI Impact Assessment Guide

來源機構：Microsoft。採用版本／日期：2022-06，公開版。查核日：2026-10-21。

原始出處：https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-RAI-Impact-Assessment-Guide.pdf

支持的主張：影響評估需要團隊與跨專業合作；指南提供利害關係人、潛在益處與傷害的討論方法；正文的客服與退款例子由本文原創，不是 Microsoft 個案。

Some parts of the Impact Assessment require teamwork.

中譯／說明：影響評估的部分工作需要團隊合作。

使用界線：本來源僅支持方法方向；本文的角色、訓練與申訴設計為管理建議，並非所有企業的法定義務或 Microsoft 要求。

B01．Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（NIST AI 600-1）

來源機構：National Institute of Standards and Technology（NIST）。採用版本／日期：2024-07。查核日：2026-10-21。

原始出處：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

支持的主張：生成式 AI 的錯誤內容、隱私、資訊安全與人機互動風險；過度依賴與 automation bias；測試、監控及事故等建議行動。

The production of confidently stated but erroneous or false content

中譯／說明：以肯定語氣產出錯誤或不實內容。

使用界線：自願性風險管理參考文件。正文的企業分級、核准條件與操作示例由本文設計，非 NIST 強制要求。文件中的歷史行政命令背景不代表該命令在查核日仍有效。

B02．LLM01:2025 Prompt Injection

來源機構：OWASP Gen AI Security Project。採用版本／日期：2025 版風險分類；頁面持續更新。查核日：2026-10-21。

原始出處：https://genai.owasp.org/llmrisk/llm01-prompt-injection/

支持的主張：外部網站與檔案可能引發間接提示注入；RAG 與微調不能完全消除提示注入；區分不可信內容、最小權限及高影響行動的人員確認。

Separate and clearly denote untrusted content to limit its influence on user prompts.

中譯／說明：區隔並清楚標示不可信內容，以限制其對使用者提示的影響。

使用界線：採用明示的 2025 版分類，不宣稱為查核日最新版本或法定要求。任何單一措施都不構成完全防護保證。

B03．LLM02:2025 Sensitive Information Disclosure

來源機構：OWASP Gen AI Security Project。採用版本／日期：2025 版風險分類；頁面持續更新。查核日：2026-10-21。

原始出處：https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/

支持的主張：敏感資訊可能由 LLM 應用輸出暴露；系統提示限制可能被繞過；資料最小權限及來源限制。

Only grant access to data that is necessary for the specific user or process.

中譯／說明：僅授予特定使用者或流程所必需的資料存取權限。

使用界線：採用 2025 版說明作為安全設計參考，不推論任何特定服務必然會訓練、保存或洩漏使用者資料。

B04．LLM06:2025 Excessive Agency

來源機構：OWASP Gen AI Security Project。採用版本／日期：2025 版風險分類；頁面持續更新。查核日：2026-10-21。

原始出處：https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

支持的主張：過多功能、權限與自主性造成 Excessive Agency；下游系統應獨立落實授權；最小工具範圍及對高影響行動的確認。

Implement authorization in downstream systems rather than relying on an LLM

中譯／說明：在下游系統實作授權，避免依賴大型語言模型判斷。

使用界線：原文短引為完整句子的一部分。正文具體工具、交易與預算設計為本文建議；採用 2025 版而非聲稱現行固定編號。

B05．LLM08:2025 Vector and Embedding Weaknesses

來源機構：OWASP Gen AI Security Project。採用版本／日期：2025 版風險分類；頁面持續更新。查核日：2026-10-21。

原始出處：https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/

支持的主張：共用向量資料環境可能出現不同群組間的資訊洩漏；RAG 存取需要權限控管。

A permission-aware vector database should be implemented to restrict access

中譯／說明：應採用能辨識權限的向量資料庫來限制存取。

使用界線：原文短引為句子片段。本文未主張向量資料庫本身即可完成整個應用的授權保護。

B06．Guidelines for secure AI system development：Secure development

來源機構：UK National Cyber Security Centre（NCSC）。採用版本／日期：2023-11-27；Version 1.0。查核日：2026-10-21。

原始出處：https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines/secure-development

支持的主張：供應鏈、AI 資產、資料、模型與提示文件的安全管理；日誌應作為敏感資料保護。

You treat logs as sensitive data and implement controls

中譯／說明：將日誌視為敏感資料，並實施控制措施。

使用界線：安全開發指引，非通用法定義務。正文資料流、採購及退出流程是本文操作建議。

B07．How should we assess security and data minimisation in AI?

來源機構：UK Information Commissioner's Office（ICO）。採用版本／日期：持續更新指引；查核時標示正在檢討。查核日：2026-10-21。

原始出處：https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/how-should-we-assess-security-and-data-minimisation-in-ai/

支持的主張：AI 安全需考量軟體元件、資料流與工作流程的整體關係；資料最小化與個資移轉紀錄；指引因 Data (Use and Access) Act 正在檢討。

There is no ‘one-size-fits-all’ approach to security.

中譯／說明：資訊安全沒有適用所有情境的單一做法。

使用界線：英國主管機關指引，查核時正在檢討。本文僅引用管理與技術原則，不作為台灣法定義務或英國現行法律適用的完整說明。

B08．Document-level access control in Azure AI Search

來源機構：Microsoft Learn。採用版本／日期：持續更新產品文件；以查核日內容為準。查核日：2026-10-21。

原始出處：https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview

支持的主張：文件層級存取控制與查詢時權限檢查；來源權限變更須依同步機制寫入索引才反映於結果；部分身分與權限整合功能為預覽狀態。

as long as the document ACL metadata is synchronized to the index.

中譯／說明：前提是文件存取控制清單的中繼資料已同步到索引。

使用界線：特定產品文件，不能直接外推其他 RAG 系統。部分功能標示 preview，導入前須確認實際版本、資料來源、同步模型及適用條件。

B09．Model Cards for Model Reporting

來源機構：Mitchell et al.；Google Research 官方論文頁。採用版本／日期：2019。查核日：2026-10-21。

原始出處：https://research.google/pubs/model-cards-for-model-reporting/

支持的主張：模型卡說明預期使用情境、評估程序及表現限制。

Model cards also disclose the context under which models are intended to be used

中譯／說明：模型卡也揭露模型預定使用的情境。

使用界線：引用官方論文頁摘要。企業使用情境說明卡與清冊欄位是本文延伸設計，非原論文固定格式。

B10．Demystifying evals for AI agents

來源機構：Anthropic。採用版本／日期：2026-01-09。查核日：2026-10-21。

原始出處：https://www.anthropic.com/research/demystifying-evals-for-ai-agents

支持的主張：評估需區分代理執行紀錄與最終環境結果；多輪代理與多次試驗的評估觀念。

The outcome is the final state in the environment at the end of the trial.

中譯／說明：結果是一次試驗結束時環境中的最終狀態。

使用界線：供應商工程經驗文章，並非獨立普遍成效證明。正文的測試分類、放行方法與統計示例為本文設計；沒有借用原文客戶案例或成效數字。

B11．Guidelines for Human-AI Interaction

來源機構：Amershi et al.；Microsoft Research。採用版本／日期：2019-05；CHI 2019。查核日：2026-10-21。

原始出處：https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/

支持的主張：人與 AI 互動設計應說明能力與限制；錯誤處理、控制與回饋的設計觀念。

We propose 18 generally applicable design guidelines for human-AI interaction.

中譯／說明：我們提出 18 項可廣泛應用的人與 AI 互動設計指引。

使用界線：學術研究與其作者說明，非安全或法遵認證。正文的覆核畫面、權責與演練方法為本文設計。

B12．Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile（NIST SP 800-61 Rev. 3）

來源機構：National Institute of Standards and Technology（NIST）。採用版本／日期：2025-04-03；Final。查核日：2026-10-21。

原始出處：https://csrc.nist.gov/pubs/sp/800/61/r3/final

支持的主張：將事件應變納入資安風險管理；事件準備、偵測、回應與復原。

improve the efficiency and effectiveness of their incident detection, response, and recovery activities.

中譯／說明：改善事件偵測、回應與復原活動的效率及有效性。

使用界線：一般資安事件應變指引。AI 事故部門分工、業務補救與教學事件是本文提出的實務安排，不是通用法律通報時限。

B13．Retrieval augmented generation（RAG）and indexes

來源機構：Microsoft Learn。採用版本／日期：2026-08-21；持續更新產品文件。查核日：2026-10-21。

原始出處：https://learn.microsoft.com/en-us/azure/foundry/concepts/retrieval-augmented-generation

支持的主張：RAG 結合搜尋與大型語言模型；檢索不完整或資料準備不佳仍可能造成錯誤；檢索時的存取控制與不可信內容處理。

RAG systems can expose sensitive content if you don't design access and prompting carefully.

中譯／說明：若未妥善設計存取與提示，RAG 系統可能暴露敏感內容。

使用界線：特定產品的概念說明。本文未宣稱 RAG 能消除幻覺或提示注入，也未假設所有系統採相同架構。

B14．Guidelines for secure AI system development：Secure operation and maintenance

來源機構：UK National Cyber Security Centre（NCSC）。採用版本／日期：2023-11-27；Version 1.0。查核日：2026-10-21。

原始出處：https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines/secure-operation-maintenance

支持的主張：AI 系統行為與輸入監控；資料、模型及提示變更可能改變系統行為；更新管理與資訊分享。

changes to data, models or prompts can lead to changes in system behaviour

中譯／說明：資料、模型或提示的變更，可能導致系統行為改變。

使用界線：安全維運指引。正文的監控指標、變更分級、事件處理與退場安排為本文建議。

C01．Regulation (EU) 2024/1689, consolidated version 27 July 2026

來源機構：European Union / EUR-Lex。採用版本／日期：2026-07-27。查核日：2026-10-21。

原始出處：https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng

支持的主張：Article 2 的範圍與域外關聯；Article 6（1）、6（2）不同高風險判斷；Articles 50、111、113 的義務與過渡條款。

where the output produced by the AI system is used in the Union

中譯／說明：AI 系統產生的輸出在歐盟使用時。

使用界線：合併版本屬文件整理工具，個案法律判斷仍以正式公報與適用法為準；本文不是全條文逐項意見。

C02．Regulation (EU) 2026/1744: Digital Omnibus on AI

來源機構：European Union / Official Journal。採用版本／日期：2026-07-24。查核日：2026-10-21。

原始出處：https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=oj%3AL_202601744

支持的主張：AI Omnibus 已為正式修正法；Article 4 AI literacy 修正；高風險適用日期修正。

This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.

中譯／說明：此義務不要求供應者或部署者保證任何個人的特定 AI 素養水準。

使用界線：原封包以官方索引、合併法與執委會公告交叉核對；發布前已直接取得公報正文，重查 AI 素養與施行日期，未宣稱逐頁審閱整份公報。

C03．AI Omnibus enters into force

來源機構：European Commission。採用版本／日期：2026-07-27。查核日：2026-10-21。

原始出處：https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force

支持的主張：2026-07-27 生效；Annex III 2027-12-02；產品型高風險 2028-08-02。

On 27 July 2026, the AI Omnibus enters into force across the EU

中譯／說明：AI Omnibus 於 2026 年 7 月 27 日在歐盟生效。

使用界線：官方公告為摘要；法律細節須對照修正法與現行合併條文。

C04．Guidelines on transparency obligations for providers and deployers of AI systems

來源機構：European Commission。採用版本／日期：2026-07-20；頁面更新 2026-07-31。查核日：2026-10-21。

原始出處：https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems

支持的主張：Article 50 指引存在與發布日期；一般透明義務適用起日。

These transparency obligations apply from 2 August 2026.

中譯／說明：這些透明義務自 2026 年 8 月 2 日開始適用。

使用界線：本來源為指引發布及下載頁；正文細節另核現行 Article 50 與 111，不把發布頁當完整法律意見。

C05．Guidelines for providers of general-purpose AI models

來源機構：European Commission。採用版本／日期：頁面更新 2026-04-28。查核日：2026-10-21。

原始出處：https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers

支持的主張：GPAI 供應者與一般使用者角色區分；義務、執法及既有模型過渡日期。

By 2 August 2027, providers of GPAI models placed on the market before 2 August 2025 must comply.

中譯／說明：於 2025 年 8 月 2 日前上市的 GPAI 模型，其供應者須於 2027 年 8 月 2 日前符合義務。

使用界線：官方指引為執委會解釋，頁面明示不具法律拘束力；實際角色仍需依行為判斷。

C06．人工智慧基本法

來源機構：法務部全國法規資料庫。採用版本／日期：2026-01-14。查核日：2026-10-21。

原始出處：https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=H0160093

支持的主張：公布與施行日期；政府原則與主管機關分工；Article 16 風險分類框架。

本法自公布之日起施行。

中譯／說明：原文為繁體中文，無另行翻譯。

使用界線：須看清條文主詞；不能把政府政策義務直接等同所有民營企業的普遍處罰義務。

C07．訂定「人工智慧風險分類框架」，並自即日生效。

來源機構：數位發展部。採用版本／日期：2026-07-07；頁面更新 2026-09-17。查核日：2026-10-21。

原始出處：https://moda.gov.tw/press/bulletin/20086

支持的主張：框架正式公告日期；數位策略字第 1150015933 號。

並自即日生效。

中譯／說明：原文為繁體中文，無另行翻譯。

使用界線：公告框架本身不等於各產業已完成全部管理規範。

C08．AI 風險分類框架

來源機構：數位發展部。採用版本／日期：建立 2026-03-23；更新 2026-07-08。查核日：2026-10-21。

原始出處：https://moda.gov.tw/major-policies/ai/governance/19244

支持的主張：框架定位為跨部會共同語言；主管機關權責與四項流程。

提供一套共通的評估標準。

中譯／說明：原文為繁體中文，無另行翻譯。

使用界線：不是普遍企業認證制度；各目的事業主管機關負責領域管理規範。

C09．Artificial Intelligence Risk Taxonomy and Assessment Framework, Version 1.0

來源機構：Ministry of Digital Affairs, Taiwan。採用版本／日期：2026-07-07。查核日：2026-10-21。

原始出處：https://www-api.moda.gov.tw/File/Get/moda/zh-tw/3TAWUGBklnkogPX

支持的主張：主要對象為產業主管機關；產業與一般大眾參考用途；情境盤點、識別、評估與應對流程。

Primary Subjects of this Document.

中譯／說明：本文件的主要適用對象。

使用界線：引用 Executive Summary 的角色定位；未將政府風險分類工具改寫為企業強制認證。

C10．Updated Model AI Governance Framework for Agentic AI

來源機構：Infocomm Media Development Authority, Singapore。採用版本／日期：2026-05-20。查核日：2026-10-21。

原始出處：https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/factsheets/2026/updated-model-ai-governance-framework-for-agentic-ai

支持的主張：2026 年框架更新及企業案例；人類最終問責與操作方法的參考價值。

while emphasising that humans are ultimately accountable.

中譯／說明：同時強調人類最終仍須承擔責任。

使用界線：發布重查時，直接頁面僅回傳標題及日期；正文與問責短引由官方搜尋索引及官方 AI 總覽交叉核對。只引用更新與問責重點，不複製個別公司的權限門檻。