一、前言

在過去幾天中，我們成功為考前複習工具發布了手機端 Web App，並實測了外掛連網搜尋的資料管線與降級機制。看著系統能在幾秒內消化大量內容並產出全套複習包，確實讓人感受到生成式 AI 的強大效率。
然而，當我們沉浸在 No-Code 工具帶來的便利時，身為醫學資訊學系的學生，心中必須敲響一記警鐘：

• 「我們丟進 Dify 知識庫的教材，會不會在雲端留下痕跡？」
• 「如果未來把醫院的脫敏病歷或臨床指引丟給公有雲 AI 整理，是否已經觸犯了法規紅線？」

功能做出來是一回事，用得合規安全又是另一回事。今天 Day 27，我們不碰畫布接線，專注回到醫資人的專業本質，深入探討在使用雲端 AI 輔助學習時不可忽視的三大資安與隱私防線！

二、雲端 AI 處理資料的三大潛在隱憂

當我們使用 Dify Cloud 搭配 Google 或 OpenAI 的雲端 API 時，資料本質上已經離開了本地端，這會衍生出以下合規風險：

1. 資料是否被拿去二次訓練？
   • 使用者隱私政策差很大：一般網頁版的免費聊天機器人（如直接使用一般 ChatGPT），其對話預設常會被作為模型微調或訓練素材。
   • API 層級的承諾：正規的商業 API（例如透過 Google AI Studio 或 OpenAI 官方 API 串接）通常在服務條款中明訂「不會將 API 輸入的 Prompt 與 Context 資料納入公開模型訓練」。因此，使用正規 API 串接工作流比在公開網頁直接貼資料相對安全。
2. 智慧財產權與教材版權界線
   • 大學教授的授課簡報、醫院內部的 SOP 或未公開題庫，皆屬於受保護的著作財產權。
   • 將整份未授權的完整教材公開掛載於所有人都能自由訪問的公開 Web App 上，本質上存在侵權外洩風險。
3. 機敏健康資訊（PHI）的絕對紅線
   • 醫療資訊領域最神聖的法規是美國 HIPAA 與台灣《個人資料保護法》。
   • 姓名、身分證號、病歷號、檢查影像等具備可識別性的健康資料，嚴禁未經合規處理即傳輸至公有雲大型語言模型。

三、醫資學生實務上的「安全合規防護指南」

在平時打造學習助手或未來開發臨床輔助工具時，可以落實以下安全原則：

1. API Key 絕不裸奔（金鑰保護）
   • 金鑰等同於系統的最高權限通行證。在截圖分享技術文章或將工作流匯出為 DSL 檔時，務必將 API Key 字串徹底打碼遮蔽。
2. 去識別化與脫敏（De-identification）
   • 若測試素材包含個案報告或衛教案例，必須在進入知識庫前執行去識別化，抹除所有可連結至特定個人的直接或間接識別標籤（如姓名、年齡、就診日期）。
3. 區隔公有雲與地端部署（On-Premise）
   • 課堂學習階段：使用 Dify 雲端版搭配公開指引（如衛福部公開技術文件）進行原型驗證。
   • 臨床與院內實務：若涉及敏感醫療資料，實務上必須在院內私有網路使用 Docker 自建地端 Dify，並掛載本地私有化開源模型（如 Llama、Qwen 等），確保醫療數據全程不出院區。