Prompt 是「這次問什麼」，Context 是「AI 回答時可以參考的背景資訊」。AI 並不知道機關的內部作業規定或案件歷史；問題寫得再清楚，如果 Context 沒設計好，答案仍可能缺乏依據。本模組沿用同一個模擬案例：某市政府「陳情案件回覆輔助」，AI 協助承辦人起草回覆，由承辦人審查後才送出。
| 處理方式 | 適用情況 | 陳情回覆案例 |
|---|---|---|
| Include（直接放入） | 少量、每次都需要、不常變動 | 本次陳情內容（已去識別化） |
| Retrieve（需要時查取） | 大量、不是每次都用、會更新 | 現行有效的法規條文與公開處理原則 |
| Remember（跨對話記住） | 需延續多次互動、須明訂保存期限 | 案件編號與處理進度 |
| Exclude（明確不給） | 與任務無關，或不得提供給 AI | 其他民眾的個人資料、未公開的內部決策、機密公文 |
資訊
在陳情回覆案例中，「其他民眾的個人資料」最適合歸入哪一類？
一份資料能不能交給 AI，要回答兩個問題：這份資料可不可信（來源、版本、時效），以及這份資料能不能給（資料分類與機關規定）。兩個問題都通過，才進入 Include 或 Retrieve。
| 分類 | 說明 | 可否交給 AI |
|---|---|---|
| 公開資料 | 已對外公開的公告、公開統計 | 可依機關政策使用 |
| 機關內部資料 | 未對外公開的行政作業資料 | 依資料分類與授權範圍判斷 |
| 個人資料 | 可識別特定個人的資料 | 原則上避免；必要時先去識別化並依規定辦理 |
| 敏感資料 | 健康、犯罪前科等特殊類別個人資料 | 原則禁止，需有明確法源與授權 |
| 機密資料 | 依機密等級列管的公務資料 | 禁止提供給未經授權的系統或服務 |
| 禁止輸入第三方 AI 服務之資料 | 依機關政策或契約明訂不得外流的資料 | 不得輸入，無例外 |
注意
知識庫中同時有某項作業規定的新舊兩個版本，AI 取回時無法判斷哪一個現行有效。最合適的處理是什麼？
前半談的是 AI 可以「知道」什麼；後半談 AI 可以「查什麼、做什麼」。AI 一旦連上工具，就不只是產生文字，還可能讀取、改動系統資料，甚至對外發送。用途不同，控制的重點也不同。
| 技術 | 主要用途 | 陳情回覆案例 |
|---|---|---|
| RAG | 取回知識內容，協助 AI 有依據地回答 | 從法規與處理原則知識庫取回相關條文 |
| API | 系統之間既有、特定用途的介接 | 公文列管系統提供的進度查詢介面 |
| MCP | 標準化的工具發現與呼叫方式，可串接多種工具 | AI 以一致方式連接多個不同系統，不必逐一客製 |
下列哪一項最能說明 RAG 與 API／MCP 的角色差異？
| 重點 | 要回答的問題 | 陳情回覆案例 |
|---|---|---|
| 最小權限 | AI 只拿到完成任務所需的最小存取範圍嗎？ | 只查詢本案進度欄位，不開放整個列管系統 |
| 核准需求 | 哪些行動必須由具職權人員核准後才執行？ | 寫入結案狀態、正式發文一律需人工核准 |
| 執行紀錄與來源 | 每次呼叫是否留下紀錄，結果能否追溯來源與查詢時間？ | 紀錄查詢內容、時間、來源系統與結果 |
| 失敗備援 | 工具失敗、逾時或結果可疑時，怎麼處理？ | 停止自動處理，退回承辦人以人工方式辦理 |
AI 可以被授權查詢公文列管系統的進度（查詢），並協助準備回覆草稿；但不應預設授權 AI 直接修改結案狀態，或直接送出正式回覆。草稿再完整，「草稿完成」與「正式生效」之間仍需要具職權人員審查並核准的步驟。
注意
有人提議，因為 AI 的回覆草稿品質一直很高，可以讓它跳過人工核准直接發文。哪一個判斷最正確？
承接模組 1、2 的案例與流程，把這個應用會用到的資料與工具填進同一張「資料與工具權限表」。成果會填入整合 Canvas 的「資料與背景（contextAndData）」與「工具與權限（toolsAndPermissions）」欄位，不需要重新輸入案例背景。
權限表中，下列哪一列的填寫最完整？
