作者: Tempest Ciel

事件背景：Apple 預告收緊「全磁碟存取」

Apple 宣布，未來將為 macOS 的「全磁碟存取」（Full Disk Access）增加控制，確保使用者只能透過「非常明確的操作」授予這項權限。官方理由是，部分開發者正以可能危及使用者的方式運用它；一旦開放，App 可能接觸檔案、郵件、訊息與瀏覽紀錄，通訊對象的隱私也可能連帶受影響。Apple 更直接點名：隨著 AI 代理愈來愈自主，相關風險將顯著增加。這是已確認的官方政策方向，但 Apple 尚未公布實施版本、時程與介面細節。官方公告：https://developer.apple.com/news/?id=p6zjojqw

事件最初由 Daring Fireball 作者 John Gruber 延伸評論。他判斷這波調整與 Meta Muse 等桌面代理引發的爭議有關，也擔心備份、開發及系統工具可能被迫頻繁重新授權。必須區分的是：Apple 沒有在公告中點名任何產品，因此「針對 Muse」是 Gruber 的合理解讀，不是 Apple 證實的因果關係。原始評論：https://daringfireball.net/2026/10/apple_full_disk_access

真正的問題不是磁碟，而是權限尺度

依 Apple 現行使用手冊，全磁碟存取可讓 App 讀取電腦上的所有檔案，包括 Mail、Messages、Safari、Home 等其他 App 的資料、Time Machine 備份，以及部分系統管理設定。這不是「允許開啟某個資料夾」，而是跨越多個原本分立的隱私邊界。官方說明：https://support.apple.com/guide/mac-help/change-privacy-security-settings-on-mac-mchl211c911f/mac

這項設計有合理歷史背景。備份與磁碟管理軟體若不能持續掃描大量資料，就無法完成核心工作。Apple 在 WWDC23 也曾說明，已獲全磁碟存取的備份或磁碟工具，存取其他 App 容器時不會再次跳出提示：https://developer.apple.com/videos/play/wwdc2023/10053/。換句話說，它原本服務的是功能明確、行為相對可預期的工具。

AI 代理改變了這個前提。傳統備份程式通常只是按照固定規則複製資料；代理則會解析內容、決定下一步，甚至把本機資訊帶入雲端工作流程。權限授予的對象雖然仍是一個 App，但實際使用者已從固定程式邏輯，擴大成可能自主規劃任務的模型。因此，作業系統知道「這個程式獲准讀取」，卻未必知道使用者是否同意「這次任務讀取這批資料、用於這個目的」。

為何現在值得注意

Inc. 專欄作者 Jason Aten 曾記錄個人使用 Muse 的經驗：他表示自己拒絕連接 Messages，事後卻發現相關設定開啟，系統並同步了超過 18.7 萬筆 Messages 資料列；Muse 還以不正確的通知預覽說法解釋資料來源。報導引述 Meta 主管承認代理的說明有誤並致歉。這是當事人的個案紀錄，不能推論所有使用者都會遇到相同行為，卻清楚展示「系統權限存在」與「使用者理解代理會做什麼」之間的落差。報導：https://www.inc.com/jason-aten/meta-keeps-apologizing-for-muse-its-explanations-miss-the-point-entirely/91409363

商業上，代理產品希望安裝後立刻展現價值：整理郵件、搜尋文件、理解對話並代辦工作。要求愈少、可見資料愈多，體驗愈順；但同一套設計也擴大誤解指令、提示注入、帳號遭接管或產品本身判斷錯誤時的損害範圍。這是為何 Apple 不能只把責任推回「使用者按過同意」：一次性的廣泛授權，未必等於對未來每項自主行動的知情同意。

可能造成的實際影響

對代理開發者而言，權限需求可能必須從安裝流程中的一次性門檻，改寫成更清楚的用途說明與權限降級方案。若沒有全磁碟存取，產品仍應能以使用者挑選檔案、指定資料夾或個別服務授權完成部分工作，而不是完全失效。合理推論是，權限取得愈困難，產品就愈需要證明「為何非要讀取全部資料不可」。

對備份、端點防護、搜尋索引、開發工具與輔助使用工具而言，風險則是合法工作流程被一併增加摩擦。Apple 目前只承諾增加控制，並未表示會改成每次存取都詢問，也沒有證實將採用任務級、資料類型級或限時權限。任何具體介面設計，目前都只能視為可能方案，不能當成已公布功能。

企業管理同樣需要觀察。現有受管理的 Mac 可透過「隱私權偏好設定政策控制」（PPPC）描述檔處理部分隱私權限，Apple 文件指出相關設定須透過裝置管理服務部署，且多份描述檔並存時採較嚴格者：https://support.apple.com/en-gb/guide/deployment/dep38df53c2a/web。但新制是否改變 MDM 核准能力、是否要求終端使用者再次確認，官方尚未交代。

容易忽略的限制

第一，收緊授權流程只能降低誤授權，不能保證獲准後的代理永不出錯。第二，全磁碟存取也不是代理風險的全部；輔助使用、輸入監控、螢幕錄製與自動化權限，分別可能讓 App 觀察輸入、讀取畫面或控制其他程式。只盯著單一開關，仍可能低估權限組合的效果。

作者觀點是，Apple 真正需要重畫的不是一個更嚇人的警告視窗，而是「能力」與「任務」的對應關係。若系統只問使用者是否信任某個品牌，卻沒有說明這一次要讀哪些資料、執行什麼動作、資料是否離開本機，再多一次確認仍可能淪為慣性點擊。

對台灣使用者與企業的意義

台灣使用者安裝桌面 AI 代理時，不應把「通過 Apple 公證」理解成「所有後續資料使用都已由 Apple 審核」。較務實的做法，是定期檢查「系統設定／隱私權與安全性」中的全磁碟存取、輔助使用、自動化、輸入監控及螢幕錄製清單；非必要即關閉，並避免讓實驗性代理直接運作於存有公司信件、客戶資料與私人訊息的主要帳號。

企業則應把 AI 代理視為具備操作能力的軟體身分，而不只是聊天工具。採購評估至少要問：能否不用全磁碟存取、資料是否上傳、權限能否集中撤銷、每次動作是否留下稽核紀錄，以及代理更新後是否沿用既有授權。這些問題往往比模型答題準確率更直接決定實際風險。

後續觀察指標

• Apple 何時公布適用的 macOS 版本，以及「非常明確的操作」究竟包含哪些步驟。
• 新制能否區分備份、資安工具與通用 AI 代理，而非對所有 App 採取相同摩擦。
• 權限是否支援限時、限資料夾、限資料類型或限單次任務，並提供可讀的存取紀錄。
• 企業 MDM 能否預先核准、只能拒絕，或仍須由使用者在裝置上完成最終確認。
• 代理業者是否主動提供最小權限模式，以及在撤銷權限後刪除已同步資料的機制。

醫療 AI 正從「提供答案」跨向「代替人執行工作」。當系統能自行讀取病歷、呼叫藥物資料庫、判斷續方是否符合規則，甚至再委派另一個代理完成任務，合規問題就不再只是模型會不會說錯話，而是：它以誰的權限行動、資料經過哪些服務、出了事能否重建完整過程。

事件背景：採用速度快過治理制度

來源事實：Tigera 的文章指出，Epic 正準備讓醫療機構自行建立與協調代理；文中引述的產業調查則稱，2026 年初已有 43% 受訪醫療體系測試代理型 AI，但真正進入正式流程者只有 3%。這些數字出自資安供應商的文章，仍應留意其選樣與商業脈絡，但「大量試驗、少量正式上線」本身呈現了一個合理訊號：技術部署已開始，治理能力卻仍在補課。原文：https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/

代理和一般聊天機器人的差別，在於後者通常只產生內容，前者還能呼叫工具、存取電子病歷 API、寫入系統或觸發後續流程。一次看似單純的掛號查詢，可能依序經過病人介面、代理、另一個代理、工具伺服器、病歷系統與外部模型。每多一跳，就多一組憑證、資料副本、供應商與責任邊界。

先校正：HIPAA 管的是組織，不是「AI 本人」

來源事實：HIPAA 的義務主體是受規範實體與商業夥伴，而不是一段軟體。美國衛生及公共服務部（HHS）已把替醫療提供者處理 PHI 的第三方 AI 聊天機器人列為商業夥伴範例；若雲端或模型供應商代表醫療機構建立、接收、保存或傳輸 PHI，通常必須有商業夥伴協議（BAA）及相應保護措施。官方說明：https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html

因此，「HIPAA 適用於代理」是方便理解的縮寫，更精確的說法是：醫療機構不能因工作改由代理執行，就卸下原有義務；而實際責任仍取決於資料、用途、契約關係與各參與者身分。並非所有健康 App 或模型供應商都自動受到 HIPAA 規範，未構成受規範實體或商業夥伴者，可能落在其他法律而非 HIPAA 之下。

「最少必要」也不能一概而論

查證修正：原文把每一次代理讀取病歷都直接套入「最少必要」原則，說法過度簡化。HHS 說明，該原則通常要求限制 PHI 的使用、揭露與請求，但醫療提供者為治療目的而提出的請求或相互揭露，存在明文例外；機構內部仍須依角色建立存取政策。官方解釋：https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

合理推論：這不代表代理可以取得無限制權限。若掛號代理共用一組可讀取完整病歷的服務帳號，即使最後只查地址，仍會擴大曝險面，也使角色控管、風險分析與事件調查更困難。工程上採取逐次授權、預設拒絕及欄位層級限制，是降低風險的合理作法；但這些是把法律要求轉譯成控制設計，不應誤稱為法條逐字指定的技術。

真正的難題是「誰做了什麼」

傳統系統通常記錄某位醫師登入後查閱某份病歷；代理鏈則可能只留下共用服務帳號與 API 呼叫。可稽核紀錄至少應串起代理身分、代表的使用者、所用工具、資料範圍、模型端點、政策判斷與時間。否則醫院看得到資料被讀取，卻回答不了是誰授權、為何讀取，以及資料是否又被送往下一家供應商。

HHS 的外洩通知規則要求，在發現未受保護 PHI 遭侵害後不得不合理延遲，且最遲須於 60 日內通知；這是「發現後」的上限，不宜簡化成事件發生當日一律起算。沒有跨系統紀錄，機構也很難確認受影響病人與資料範圍。官方規則：https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html

為何現在值得注意

2025 年公布的 HIPAA Security Rule 修法提案，擬要求書面技術資產清冊與網路圖，至少每 12 個月及環境變更時更新；官方文件也把採用新技術列為觸發重新檢視的情況。這仍是提案，不能當成已生效義務，但政策方向很清楚：稽核者愈來愈不會只接受一份原則聲明，而會要求知道資料實際流向何處。官方提案：https://www.govinfo.gov/content/pkg/FR-2025-01-06/pdf/FR-2025-01-06.pdf

作者觀點：代理治理最昂貴的部分不是購買另一套資安產品，而是把院內臨時實驗、視覺化工具建立的代理、模型端點及委外關係納入同一套生命週期。代理若能在數小時內建立，靠年度問卷維護清冊必然追不上。

容易忽略的限制

• BAA 只能界定契約責任，不能自動阻止代理把資料送錯端點。
• 完整日誌有助調查，但日誌本身也可能含敏感資料，仍須限制存取、保存期間與用途。
• 人工覆核若只是形式簽核，無法處理提示詞注入、錯誤工具呼叫或自動化偏誤。
• Tigera 原文同時推廣自家 Lynx 產品；其身分、授權與稽核架構可作為設計參考，不能視為 HIPAA 認證或唯一解法。

對台灣讀者的意義：缺口其實更直接

台灣衛福部於 2026 年 5 月發布《醫療機構應用生成式人工智慧指引》，要求從全生命週期檢視資料保護、資安、供應商與後續監測。值得注意的是，指引雖定義 AI 代理為可感知環境、自主或半自主決策並採取行動的系統，卻因病人安全、醫療責任及法規遵循風險較高，暫未納入適用範圍。官方資料：https://mohw.gov.tw/cp-7407-86695-1.html

作者觀點：「未納入」不等於免管，而是現有生成式 AI 指引尚未完整回答代理的自主行動問題。台灣醫院若開始讓代理介接病歷、排程或醫囑周邊系統，不宜等待專門規範才盤點；至少應先建立代理清冊、用途與資料流、獨立身分、最小權限、人工覆核點、停用機制及供應商事件通報條款。

後續觀察指標

接下來真正值得追蹤的，不只是又有多少醫院宣布導入 AI，而是正式上線的代理能否逐一回答五個問題：誰擁有它、代表誰行動、可接觸哪些資料、實際呼叫過哪些工具，以及異常時能否立即停止並重建紀錄。當醫療 AI 從建議者變成執行者，這五個答案才是合規是否落地的分水嶺。