📝 本系列為 iThome 鐵人賽學習筆記，屬個人教學與非商業用途；文中法規與標準內容均以自身理解後的話轉述並註明出處，非逐字引用。

階段三｜台灣有哪些機構與資源

制度讀懂了，文件卻對不起來

第三階段走到這裡，台灣的 AI 治理版圖已經完整攤開：制度地圖（Day 15）、AI 產品與系統評測中心（Artificial Intelligence Evaluation Center，以下簡稱 AIEC，見 Day 16）、測試與驗證機構（Day 17）、十大評測項目（Day 18）、驗證與認證體系（Day 19）。你已經知道「誰在管、用什麼管、去哪裡測、證書怎麼來」。

但這裡有一道現實的落差。當你真的要把一個 AI 產品賣進政府或醫院時，眼前攤開的不是這些法規標準，而是另一套長相完全不同的文件——資安自評表、切結書、招標文件裡的資安要求。它們用的是「請勾選」「茲聲明」「投標廠商應具備」這種公文語言，跟前面十九天讀的「原則」「條款」「控制措施」對不太起來。

今天這一天，就是要在這兩套語言之間，架一座橋——把辛苦讀懂的制度知識，翻譯成標案文件上真正會用到的說法。 這是第三階段的收尾，也是整套治理知識轉化為競標能力的關鍵一步。

標案上會遇到的三種資安文件

先認識這三種文件。當一個 AI 專案要進入政府或醫院的採購流程，跟資安、AI 治理有關的文件，大致是如下圖所示的三種：

• 資安自評表：一張「請廠商自我檢查」的清單。採購方列出一條條資安要求，廠商逐條勾選「符合／不符合／不適用」，並簡述做法或附證據。它是自我聲明式的檢查表。
• 切結書：一份「白紙黑字的承諾」。廠商簽名聲明「我保證做到某些事、若違反願負相應責任」。它把口頭承諾變成有法律份量的擔保，常見的如個資保護切結、資安責任切結。
• 需求建議書（Request for Proposal，以下簡稱 RFP）的資安要求：招標文件裡，採購方明訂「投標廠商必須符合哪些資安條件」的那一段規格。它是採購方開給廠商的門檻——不符合，可能連投標資格都沒有。

這三種文件在台灣的政府採購裡有成熟的框架依據：例如《資通安全管理法》相關規範與採購資安檢核要求、行政院公共工程委員會函頒的《資訊服務採購契約範本》所含的資安檢核事項，以及國家資通安全研究院公開的資安服務需求建議書範本。醫院（尤其公立醫院與涉及大量個資的醫療院所）的採購，資安要求往往更嚴。注意官方用語是「資通安全」，簡稱「資安」。

過去這些文件多半聚焦傳統資訊安全；但隨著 AI 大量進入採購標的，AI 治理的要求（模型可信任度、AI 生成標示、演算法公平性等）正逐步被寫進這些文件。這正是本系列前十九天的知識能派上用場的地方。

翻譯的核心：一張對照表

把制度語言翻成標案語言，靠的是一組穩定的對應關係。下圖呈現制度概念如何轉成標案文件中的具體要求：

把這個轉譯關係攤開成表格，即為本文的核心對照表。以 AIEC 十大評測項目（Day 18）為列，每一列回答四個問題：背後的制度來源是什麼、標案文件會怎麼問、要交出什麼證據、證據在本系列哪一天做出來。 表中「基本法」指《人工智慧基本法》（見 Day 8），「42001」指 ISO/IEC 42001:2023（見 Day 9–13）。

這張表要傳達的邏輯只有一句：每一條抽象的原則或標準，最終都會落成一句「可勾選、可查證、可簽名」的具體要求。 而最右邊那一欄之所以重要，是因為採購方真正在乎的不是你答「符合」，而是你答完之後拿得出什麼。

值得補充的是，這張表的形狀正是 Day 29 那份《AI 專案資安合規檢核表》的雛形——到了 Day 29，同樣這十列會被寫成程式讀得懂的資料結構，可以自動查核佐證檔案在不在、自動列出缺口。

實戰示範：RAG 客服投一個醫院標案

光看對照表還是抽象。用本系列的檢索增強生成（Retrieval-Augmented Generation，以下簡稱 RAG）客服範例，實際走一次「投標一個醫院 AI 客服採購案」的情境，就具體了。假設醫院要導入一套 AI 客服，招標文件裡有資安與 AI 治理要求，需要準備的三份文件如下圖所示。

一、資安自評表：把十大評測項目變成勾選項

醫院自評表裡的資安要求，可以直接用 Day 18 的十大評測項目當骨架，逐項回答。以下是示範性質的自評條目：

• ✔ 系統是否防範個資外洩（隱私）？ 知識庫已去識別化（Day 22、24）。
• ✔ 是否防範提示注入等攻擊（資安）？ 系統提示隔離加上輸入淨化（Day 23）。
• ✔ 使用者是否僅能存取被授權資料（存取控制）？ 檢索層依權限過濾（Day 25）。
• ✔ AI 回答是否標示生成並附來源（透明性）？ 每則回覆標註 AI 生成並附引用（Day 24）。
• ✔ 是否留存可追溯的操作紀錄（當責性）？ 全程保留防竄改稽核日誌（Day 27）。

實際的自評表通常不只是打勾，而是一張有固定欄位的表格。以「隱私」那一列為例，填完之後長這樣：

四個欄位裡，最後一欄的份量最重。 「符合」是聲明，「實作做法」是說明，只有「佐證文件」是可以被查證的東西。逐項填寫時會發現：每一項證據，正好就是第四階段（Day 21–30）要動手做的技術控制。也就是說，本系列後半寫的每一段程式，最後都是在為這張自評表補上一格證據。

二、切結書：把原則翻成承諾句

切結書要的是明確、可負責的承諾。把基本法原則（Day 8）翻成切結語言，例如：

本公司承諾：所提供之 AI 客服系統，對使用者個人資料採資料最小化與去識別化處理；AI 生成之回覆均明確標示，不使人誤認為真人；並留存完整操作紀錄以供查核。如有違反，願負相應之法律與契約責任。

這段話的每一句，都能追溯回前面的制度來源——資料最小化（基本法隱私原則）、AI 生成標示（透明原則）、操作紀錄（問責原則）。切結書不是空話，它是把你技術上做得到的事，正式承諾出來。

三、RFP 資格門檻：讀懂採購方要什麼

如果你是投標方，還要反過來讀懂 RFP 裡的資安要求，確認自己夠格。未來的 AI 採購 RFP，可能出現這類條款（示範）：

投標廠商所提供之 AI 系統，宜具備 ISO/IEC 42001 驗證或等效之 AI 管理制度；並宜檢附第三方（如 AIEC）之評測或評價報告，證明其在準確性、隱私、資安等面向之可信任度。

這裡值得留意條款的用字。公文與契約用語中，「應」是強制要求——不符合就可能失去投標資格，才是嚴格意義的門檻；「宜」則屬鼓勵性、建議性要求，未達成通常不會直接淘汰，但會影響評選印象與分數。AI 治理要求剛開始進入採購文件，目前多以「宜」的過渡形式出現（如上例與前面的對照表）；待驗證體系與市場量能成熟，才可能逐步升格為「應」。判讀 RFP 時先分清這兩個字，就知道哪些是不可退讓的硬門檻、哪些是能拉開差距的加分項。

讀到這種條款，前十九天的知識就直接派上用場——你會知道 ISO/IEC 42001 是什麼（Day 9–13）、AIEC 評測報告怎麼來（Day 17）、十大評測項目指什麼（Day 18）。制度知識，在這一刻直接轉化成「看得懂門檻、備得齊文件」的競標能力。

門檻的高度不是隨機的：資安責任等級

拿到不同機關的自評表，第一個困惑通常是：為什麼有的只有五題、有的卻有五十題？ 這不是承辦人的心情問題，背後有制度依據。

《資通安全管理法》第 7 條第 3 項授權主管機關（依同法第 2 條為數位發展部）訂定分級辦法，據此訂有《資通安全責任等級分級辦法》。這部辦法把公務機關與特定非公務機關——依《資通安全管理法》第 3 條，指關鍵基礎設施提供者、公營事業，以及政府捐助之財團法人——的資安責任，由高至低分成 A、B、C、D、E 五級：

• A 級：業務涉及國家機密者；涉及外交、國防或國土安全事項者；涉及全國性民眾服務或跨公務機關共用性資通系統之維運者；持有全國性民眾或公務員個人資料檔案者；或屬公務機關且業務涉及全國性關鍵基礎設施事項者。公立醫學中心亦列於此級。
• B 級：業務涉及公務機關捐助、資助或研發之國家核心科技資訊者；涉及區域性、地區性民眾服務或跨公務機關共用性資通系統者；持有區域性或地區性民眾個人資料檔案者；涉及中央二級機關及所屬各級機關共用性資通系統之維運者；或涉及區域性、地區性關鍵基礎設施事項者。公立區域醫院與地區醫院列於此級。
• C、D、E 級：判準換成另一個軸——有沒有在維運資通系統。維運自行或委外設置、開發之資通系統者為 C 級；自行辦理資通業務但未維運這類系統者為 D 級；既無資通系統、也未提供資通服務，或資通業務全部由上級機關兼辦、代管者為 E 級。

判斷 A 級與 B 級的主軸，是「全國性」與「區域、地區性」的差別。這也直接解答了醫療場域的一個常見疑問：同樣是醫院，醫學中心與區域醫院的資安責任等級本來就不同級，落到採購文件上的要求密度自然不一樣。五個等級與採購要求強度的關係，如下圖所示。

等級不是機關自己說了算——依該辦法，行政院應每三年核定自身的資通安全責任等級並送主管機關備查；行政院直屬機關則應每三年提交自身、所屬與所監督的公務機關、以及所管特定非公務機關的等級，報主管機關核定。每一級對應一組不同強度的應辦事項（辦法以附表逐級列出），例如資安專責人力的配置、教育訓練時數、資通安全防護措施的種類，以及是否需要導入資訊安全管理系統並通過第三方驗證。

對投標方來說，這條制度線索很實用：採購方的責任等級愈高，它會把愈嚴的要求往下寫進 RFP，也會把愈多義務透過契約轉嫁給你。 同一套 AI 客服賣給不同等級的機關，需要應付的資安要求密度可能差一個量級。看到自評表題目暴增時，先確認對方是幾級，就能理解題數差異的來由。

另外有一項具體的資格門檻值得知道：數位發展部數位產業署（即推動 AIEC 的同一個機關，見 Day 15、Day 16）辦有資訊安全服務機構能量登錄——由政府先審查廠商在某類資安服務上實際具備的人力與技術能力，通過者列冊公告，供政府機關採購時參考。不少資安相關標案會把「具備某項能量登錄」直接寫成投標資格。這提醒我們一件事：標案上的門檻，不只有國際標準與驗證，也包含這類本土的登錄制度。

醫院為什麼問得特別細：廠商在個資法上的「受託者」身分

責任等級解釋了「要求有多嚴」，但還沒解釋醫院為何連細節都要問。這不是刁難，而是它自己身上另有一層法律義務，必須往下轉嫁。

《個人資料保護法》（以下簡稱個資法）容許機關委託他人蒐集、處理或利用個人資料，但同時課予委託機關監督受託者的義務。《個人資料保護法施行細則》第 8 條把這項監督義務具體化，明定委託機關至少應監督下列事項：

• 預定蒐集、處理或利用個資的範圍、類別、特定目的與期間；
• 受託者採取的安全維護措施；
• 有複委託（受託者再把工作轉包給第三方）時，所約定的再受託者；
• 受託者或其受僱人違反相關法規時，應通知委託機關的事項與採行的補救措施；
• 委託機關保留指示的事項；
• 委託關係終止或解除時，個資載體的返還，以及受託者所持有個資的刪除。

同條並要求委託機關定期確認受託者的執行狀況，並將確認結果作成紀錄。

把這條規定套回 AI 專案，三件事會立刻變得很具體：

• 你就是那個「受託者」。 醫院要你填自評表、簽切結書、附證據，本質上是它在履行法定的監督義務——它必須留下「已經監督過你」的紀錄。理解這一層，就不會把這些文件當成無意義的形式主義。
• 呼叫外部模型，很可能構成「複委託」。 如果你的 RAG 客服把病人的問題送到第三方的大型語言模型（Large Language Model，以下簡稱 LLM）應用程式介面（Application Programming Interface，以下簡稱 API），那個服務商實質上也碰到了資料。複委託是施行細則第 8 條明列的監督事項，代表它必須事先講清楚、寫進契約，而不是預設可以自己決定。
• 契約結束時，要刪的不只是資料庫。 RAG 系統會把文件切塊後轉成向量存進向量資料庫（Day 21），對話紀錄可能留在日誌裡（Day 27），快取裡也可能有殘留。「返還與刪除」的義務涵蓋的是所有承載個資的載體，設計階段就要想好怎麼刪得乾淨、又怎麼證明刪過了。

醫療場域還有兩層額外的敏感度：病歷資料的去識別化程度（Day 22 會實作），以及研究用途與服務用途的界線——同一批資料拿去做客服跟拿去做研究，適用的規範與審查程序並不相同。這些都會反映在醫院自評表那些「看起來很囉唆」的題目裡。

AI 進到採購裡，多了幾條新的紅線

前面談的都是既有資安框架往 AI 延伸。但已經有一類要求，是純粹因為 AI 才出現的，而且可能直接決定投標資格。

最具代表性的案例是 DeepSeek 禁令。2025 年 2 月 3 日，行政院要求公務機關全面禁用 DeepSeek 的 AI 服務；資通安全署其後說明，禁用範圍包含雲端服務、行動應用程式與地端下載等各種使用方式。官方說明的理由包括：訓練資料有著作權疑慮、模型存在思想審查與資料偏異、資料可能跨境傳送至中國，以及個資風險。政策保留了學術例外，但那是一道正式程序：公立大學及研究機構如有使用需求，須依規定程序報准核可後始得使用；主管政委並建議以不含個資與資料的電腦單機下載、斷網使用較為安全。這項禁令針對公務機關，並未限制一般民間使用。

這件事對開發者的意義，遠比「少一個模型可以用」來得大：

• 模型選擇從技術問題變成資格問題。 過去挑模型考慮的是效果、成本、延遲；現在還要考慮「我的採購方能不能用它」。一個技術上表現最好的模型，可能因為來源國別而讓整個投標案出局。
• 地端部署不等於安全過關。 值得注意的是，這道禁令連「地端下載」都涵蓋在內。也就是說，「我把模型下載下來自己跑，資料沒有出去」這個常見的辯護，在這類禁令面前不成立——受質疑的是模型本身，不只是資料傳輸路徑。
• 資料落地成為必答題。 如果 RAG 客服呼叫的是境外 LLM API，病人的問題就離開了機關的控制範圍。這在醫院標案裡幾乎一定會被問到，可能的答案有：改用地端模型、選擇有境內機房的服務、或在送出前先做去識別化（Day 22）。無論選哪一條，都必須寫得出來、證明得了。

這三件事，可以視為 AI 採購上的三道新閘門，如下圖所示。

再往前看一步：這類「AI 供應來源可不可信」的問題，正是 Day 28 供應鏈治理要處理的技術面。今天在採購文件上被問的問題，Day 28 會給出可執行的答案——用 **AI 物料清單（AI Bill of Materials，以下簡稱 AI-BOM）**盤點你用了誰的模型與套件，並用完整性驗證證明它沒有被掉包。

得標之後才是開始：履約與驗收

很多人以為資安要求在決標那天就結束了。實際上，決標只是把要求從「投標文件」搬到「契約」而已，真正的執行期才剛開始。一個 AI 標案完整的資安檢核，貫穿以下幾個階段：

• 投標階段：資格審查、資安自評表、切結書、評選簡報。前面幾節談的都是這一段。
• 履約階段：這是時間最長、也最容易出事的一段（見下）。
• 驗收階段：採購方常會要求提出弱點掃描報告或滲透測試報告（前者由自動化工具掃出已知漏洞，後者由人扮演攻擊者實際嘗試入侵），作為系統上線前的安全佐證；AI 系統則可能額外要求提出評測或紅隊測試結果。本系列 Day 26 產出的紅隊測試報告，正是這一項的填答材料。
• 維運階段：定期複測、資安事件通報、人員權限的定期複核。

履約階段有四件事，是 AI 專案特別容易踩到的：

• 變更管理：換模型要不要報備？ 傳統軟體專案的變更是改版本號；AI 專案卻可能因為上游服務更新，讓模型行為在未改動任何一行程式的情況下改變。契約若寫了「系統組態變更應經機關同意」，那麼把原本使用的商用模型換成另一家供應商的模型、或把地端模型升版，很可能就落在報備範圍內。這也是為什麼 Day 28 要把模型與套件版本釘選、並留下可比對的指紋（雜湊值）——你需要一份說得清楚「現在跑的到底是什麼」的紀錄。
• 資安事件通報有時限。 依《資通安全事件通報應變及演練辦法》（原名《資通安全事件通報及應變辦法》，2026 年 1 月 5 日修正發布名稱及全文為現名），公務機關於知悉資通安全事件後應於一小時內至主管機關指定的系統平臺通報（第 6 條）；特定非公務機關同樣是一小時，依中央目的事業主管機關指定的方式通報（第 11 條）。醫院若屬關鍵基礎設施提供者，適用的正是後者。委外契約通常會把這項義務往下轉嫁給廠商，也就是說，廠商可能被要求在極短時間內回報異常。一小時的時限，短到不容許「先查清楚再說」。要在一小時內講得出「發生了什麼、影響哪些資料」，前提是平時就有可查的稽核日誌——這正是 Day 27 要建的東西。
• 人員異動與權限回收。 專案成員離職、輪調時，其對系統與資料的存取權必須即時撤銷，而且要留下撤銷紀錄。對 RAG 系統來說，這不只是後台帳號，也包含模型 API 金鑰、向量資料庫的連線憑證（存取控制的設計見 Day 25）。
• 契約終止時的資料返還與刪除。 前面談受託者義務時已經說明，這是個資法施行細則第 8 條明列的監督事項。要在專案結束時交得出「已刪除」的證明，最好的做法是從第一天就設計好資料的生命週期，而不是到最後一天才盤點資料散在哪些地方。

把這四件事合起來看，會得到一個對開發者很重要的結論：投標階段交的是「文件」，履約階段交的是「持續產生的紀錄」。 前者可以臨時整理，後者不行——沒有在系統裡預先設計好日誌、版本紀錄與權限機制，履約期間根本產不出來。這也是本系列把稽核與供應鏈放在第四階段後半、當作壓軸的原因。

從醫院採購自評提煉的幾個心法

筆者過去參與醫院資訊採購的資安自評時，體會到幾個把「法規詞彙」翻成「標案語言」的實務心法，分享給同樣要面對這類文件的讀者：

• 先對照、再作答：拿到自評表，先把每一條要求對回它背後的制度來源（是隱私原則？還是資安控制？），便能知道該拿什麼證據回答，而不是逐條硬想。
• 證據勝於形容詞：自評表最忌諱「本公司高度重視資安」這種形容詞。採購方要的是「做了什麼、留下什麼證據」。
• 切結書只承諾做得到的事：切結書有法律效力，別為了得標承諾做不到的事。技術控制做到哪，就承諾到哪——這也是為什麼技術落地（第四階段）必須扎實。
• 用同一套底稿應對多個標案：不同標案的自評表格式各異，但背後的資安要求高度重疊。備好一份以十大評測項目為骨架的「主底稿」，每次投標只需微調，效率大增。

其中第二點與第三點值得再展開；在此之前，先補充一個自評表上最常被誤用的選項。

證據勝於形容詞：兩種答法的差距

同一道題目「請說明貴公司如何防止 AI 系統洩漏個人資料」，兩種答法的差距如下。

不合格的答法：

本公司高度重視個資保護，採用業界標準之加密機制與嚴謹的內部管理流程，確保使用者資料安全無虞。

這段話的問題不在於它是假的，而在於它沒有任何一句可以被查證。「高度重視」無法查核、「業界標準」沒有指名、「安全無虞」是結論不是做法。承辦人讀完之後，手上依然沒有可以歸檔的東西。

合格的答法：

本系統於三個環節防止個資外洩：（一）知識庫建置階段完成去識別化，姓名、病歷號、聯絡方式於入庫前移除；（二）檢索層依使用者身分過濾，未經授權的資料不會進入模型的提示；（三）回覆送出前經出口遮蔽規則檢查，命中個資樣態即攔截。上述三項均有單元測試與測試紀錄，並將每次查詢寫入稽核日誌，保存期間依契約約定。佐證：附件三、附件五、附件七。

差別在於，第二種答法讓對方知道要去哪裡查。判斷自己的答案夠不夠格，有個簡單的檢驗：把句子裡的形容詞全部刪掉，如果剩下的還是完整的說明，就合格；如果刪完只剩空殼，就要重寫。

「不適用」不是逃生門

自評表通常有「不適用」這個選項，它常被當成「做不到但又不想勾不符合」時的退路。這是危險的用法。

「不適用」的正確意思是「這條要求在本案的範圍內不存在」——例如系統完全不處理生物特徵資料，那麼與生物特徵有關的條目自然不適用。勾選時必須一併寫明為什麼不適用，而且這個理由要能對得上其他欄位的描述。反過來說，如果某條要求確實做不到，誠實勾「不符合」並說明替代措施與改善時程，比勉強勾選「不適用」安全得多——因為前者是一個可以討論的專案風險，後者一旦被發現與事實不符，性質就變成了不實陳述。

這正好接到第三個心法的嚴重性。承諾寫過頭，其後果不只是失去這個案子。若切結或自評的內容與事實不符，而被認定為以不實文件投標或履約，即可能落入《政府採購法》第 101 條所列的情形之一。依該條，機關應將其事實、理由與依同法第 103 條第 1 項所定的期間通知廠商，並附記如未提出異議即刊登政府採購公報；而依第 103 條第 1 項，經刊登者自刊登之次日起一定期間內，不得參加投標、作為決標對象或分包廠商。期間依情形分為三級：最重者三年，其次一年，較輕者則自三個月起算、依再次被刊登的次數遞增至一年。換句話說，一份寫得太漂亮的切結書，最壞的結果不是這個案子做不好，而是接下來最長三年都不能投標。 這也是為什麼「只承諾做得到的事」不是道德勸說，而是風險控管。

從採購方的角度：怎麼把 AI 要求寫進 RFP

本系列的讀者不只有投標的開發者，也有機關與醫院裡負責寫規格的人。把視角翻過來看，同一套知識可以用來把 AI 要求寫進 RFP。這裡有四個建議：

• 要求必須可驗證。 「系統應具備良好的資安防護」這種寫法，等於沒寫——它無法判定符合與否，最後只會收到一堆形容詞。改成「投標廠商應說明其對提示注入攻擊之防護設計，並檢附測試紀錄」，才是可以審的條件。
• 直接指定證據形式。 與其問「是否留存操作紀錄」，不如寫「應留存可追溯之操作紀錄，並於驗收時提供樣本及防竄改機制說明」。指定形式能大幅減少廠商各說各話的空間。
• 分清「應」與「宜」，並且想清楚後果。 每寫下一個「應」，就等於篩掉一批廠商。AI 治理相關要求目前市場量能仍在成長，若一次全部設為「應」，可能導致流標；設為「宜」並納入評選配分，通常是這個階段比較務實的作法。
• 給技術演進留空間。 AI 領域的模型與工具汰換極快，把規格寫死到特定模型名稱或特定版本，往往在履約期間就過時了。比較好的寫法是要求「能力」與「證據」，而不是要求「品牌」；同時明訂變更報備的程序，讓後續替換有路可走。

寫 RFP 的人與讀 RFP 的人，用的其實是同一張對照表——只是一個從左讀到右，一個從右讀到左。而最後一點心法（可重用的主底稿），正好接上本系列的最終產出。

對映到本系列：白皮書就是那份「主底稿」

今天的內容，讓本系列最終要交付的《AI 專案資安合規檢核表》有了明確的實用定位：它不只是一份學習總結，而是一份可以直接拿去應對標案的「主底稿」。

• 它以 AIEC 十大評測項目為欄位骨架（Day 18），每一項都對應一段技術控制與一份證據（第四階段）；
• 填一次，就同時回應了自評表的勾選、切結書的承諾、RFP 的門檻；
• 面對新標案時，它是可重用、可微調的資產——這也是本系列從第一天就承諾的「可再利用於醫院案與政府標案」的價值。

換句話說，第四階段每完成一天的技術實作，都是在為這份「主底稿」補上一格可查證的證據。到了 Day 29，它就會收斂成一份完整、可勾選、能直接應對標案的檢核表。

小結：第三階段完結

如上圖所示，今天把制度知識翻譯成了實戰語言，也為第三階段（Day 15–20）畫下句點：

• 標案上的三種資安文件：資安自評表、切結書、RFP 資安要求；門檻的高低則由採購方的資安責任等級（A 至 E 級）決定；
• 翻譯的核心是一張以十大評測項目為列的對照表：制度來源、標案怎麼問、要交什麼證據，一列一列對得上；
• 醫院問得細，是因為廠商在個資法上是「受託者」，複委託、資料返還與刪除都必須事先講清楚；
• AI 帶來了新的紅線：模型的來源國別可能直接決定投標資格，資料落地成為必答題；
• 決標不是終點：履約與驗收階段的變更報備、一小時事件通報、權限回收與資料刪除，靠的是系統裡預先設計好的紀錄；
• 實務心法：先對照再作答、證據勝於形容詞、「不適用」不是逃生門、只承諾做得到的事；
• 視角可以反過來：機關端寫 RFP 時，要求必須可驗證、直接指定證據形式、分清「應」與「宜」、給技術演進留空間；
• 本系列白皮書，就是那份以十大評測項目為骨架、可重用於各標案的主底稿。

回顧第三階段：我們從制度地圖出發（Day 15），認識了 AIEC 與測試、驗證機構（Day 16–17）、十大評測項目（Day 18）、驗證認證體系與本土案例（Day 19），最後把這一切翻譯成標案語言（Day 20）。「台灣有哪些機構與資源、又怎麼用」這個問題，到這裡回答完整了。

明天（Day 21）進入第四階段「技術落地」——從零打造一個最小的 RAG 範例。 今天列出的每一格證據，接下來九天都要真的做出來。整個系列最硬、也最能證明「從法條到程式碼」的部分，正式開始。

• 程式碼：本篇為實務方法與文件示範，無對應程式碼；文中自評表、切結、RFP 條目均為示範性質，技術證據落點見第四階段（Day 21–30）。
• 參考條文／出處：政府採購資安框架參考《資通安全管理法》相關規範、行政院公共工程委員會《資訊服務採購契約範本》所含資安檢核事項、國家資通安全研究院之資安服務需求建議書範本，以及資通安全署之採購資安檢核要求等公開資料（moda.gov.tw、nics.nat.gov.tw、pcc.gov.tw）。資安責任等級分級依《資通安全管理法》第 7 條第 3 項授權訂定之《資通安全責任等級分級辦法》第 3 至 8 條（全國法規資料庫）；資訊安全服務機構能量登錄見數位發展部數位產業署公開資訊。委外監督義務見《個人資料保護法》及《個人資料保護法施行細則》第 8 條（全國法規資料庫）；資安事件通報時限見《資通安全事件通報應變及演練辦法》第 6 條、第 11 條（2026 年 1 月 5 日修正發布現行名稱及全文，全國法規資料庫）；不良廠商刊登公報與停權期間見《政府採購法》第 101 條、第 103 條（全國法規資料庫）。DeepSeek 禁用政策見行政院 2025 年 2 月 3 日新聞稿及數位發展部相關新聞稿。法律、命令與公文（依《著作權法》第 9 條，公文包括公務員於職務上草擬之文告、講稿、新聞稿及其他文書）均非著作權標的，可自由引用；ISO/IEC 42001 之章節對映以目的轉述、未引原文。文中自評表、切結書、RFP 之具體條目為筆者為教學所設計之示範，非特定機關文件原文。制度對映之原則、標準、評測項目見 Day 8、9–13、18。