Day 05｜真實資料不能上雲端，那條線到底畫在哪 | Real Data Can’t Go to the Cloud — So Where Do You Draw the Line?

場景：「丟去哪？」

那天我拿著一個想法去找老周。

想法很單純。事件通報——院內同仁遇到差點出事、或已經出事的狀況時填的那張單子——每個月進來的量，靠人工分類分級已經很吃力。我想試試看讓模型先做一輪初步分類，人再接手。

我講了大概三分鐘。講完，他只問了一句：

周資訊室｜老周

「丟去哪？」

三個字。

我當場答不出來。而接下來好幾個星期，這件事就停在那裡——不是技術上卡住，是這個問題答不出來之前，什麼都不能開始。

後來我才明白那是唯一該先問的問題。工具選型在它面前完全是次要的，因為：

工具是可以換的，資料出去了換不回來。

今天這篇是工具箱，但如果你只帶一件事走，帶那句話。下面所有的選擇都是從那句話推出來的。

還有一條邊界要一起講，因為它決定了這 30 天能做到哪裡：這個系列裡所有的應用都停在管理端——稽核、通報分類、報告評分、指標彙整。它不進入臨床決策路徑，不對任何一位病人的診斷、用藥或處置給建議。這條線是刻意畫的，而它同時解釋了為什麼這個系列裡不會出現任何一張影像。

品管的資料，外洩的不是資料

談醫療資料分級，第一直覺是病人。這當然對，但品管工作的資料還有一個額外的性質：它幾乎全部是關於錯誤的紀錄——我這條線上的每一份文件，都是一則 incident。

• 事件通報寫的是哪裡差點出事
• 稽核紀錄寫的是誰沒做到
• 根因分析報告寫的是一件事怎麼一步一步走到那個結果

所以這批資料的敏感度有兩層。

第一層是病人。這一層有法規、有去識別化流程、有 IRB（人體研究倫理審查委員會，任何要動到真實病人資料的研究都得先過這一關），大家都知道要處理。

第二層是人——通報的人、被通報的單位、被檢討的那段流程。

而第二層的風險不是法律風險，是制度風險。

醫院的通報文化建立在一件事上：通報不是為了究責。這句話印在每一份宣導資料上，但它真正的地基不是宣示，是同仁的實際經驗——上一次有人通報之後，有沒有因此被找麻煩。這個地基要花很多年才建得起來，可以在一次外洩裡崩掉。而一旦崩掉，你損失的不是那批資料，是訊號源——之後所有本來會被通報、現在不會了的事件。等於有人把 instrumentation 拆掉了，而且不會有人告訴你是哪一天拆的。

所以我做資料分級的時候，問的問題不是「這算不算機密」，是：

這份東西如果被還原到某一個人身上，誰會受傷？

一般的資料分級問的是合規——外洩會不會違法、會不會賠錢。品管資料多一層：外洩會不會讓下次沒有人敢通報。這一層問的是下次還有沒有人願意送 log 上來。

這一層不會出現在任何一份合規檢核表上，但它是我畫邊界時真正在保護的東西。

四層資料，四條路

實際的分流長這樣。層級是照「還原到個人的風險」分的，不是照「機密等級」分的。

這套分層在你們那邊對應的不是三個環境，是「prod 資料不准往下游環境複製」那一條。差別只在於，你們那是最佳實務，我這裡是不能有例外的線——因為違反它的代價不是資料庫髒掉，是一個花很多年建起來的通報文化。

邊界不能靠自律

線畫在哪裡其實不太重要，線怎麼被守住才重要。

「我記得不要把病歷貼進去」是一個會失敗的機制。它依賴一個累了一整天、剛好在趕明天要交的東西的人，在那個當下記得。用 Day 13 會談到的講法，這是強度最低的一種對策。

實際守住邊界的方法是讓路徑本身不同：

• 走地端的流程和走雲端的流程，用不同的資料夾、不同的執行入口、不同的輸出目錄
• 真實資料的目錄從第一天就排除在版本控制之外。不是「記得不要 commit」，是它根本不在追蹤範圍裡
• 兩條路徑中間不共用暫存區——暫存區是所有邊界最常見的破口

真正的問題是，這些事在醫院裡被歸類成「資訊的事」——於是它們不會出現在品質的檢核表上，也不會有人在第一天就問「丟去哪」。

還有一條規則，是寫給模型看的

上面那些都是給人設計的。但這個工作流裡有一個新的參與者：一個會讀檔案、會執行指令、會自己決定下一步做什麼的 agent。

所以專案根目錄有一份規則檔，跟著 repo 走，每次開工都會被讀進去。第一條就是：

真實資料絕不送雲端。
真實資料階段只用本地模型。

這條規則不在我腦子裡，不在交接文件裡，它在一份每一次執行都會被讀到的檔案裡。

這件事我認為是這幾年最實質的一個變化：

當你的協作者是一個 agent，你的安全規則必須是它讀得到的檔案，不是你的習慣。

過去的存取控制全部是為人設計的——權限、稽核軌跡、教育訓練。現在有一部分必須寫成模型讀得懂的敘述。而這兩者的失效方式不一樣：人是知道規則但偷懶，模型是沒讀到就當作不存在。

順帶一提，這也是為什麼我不太擔心 agent「自己亂來」，比較擔心的是規則檔沒有涵蓋到的情況。一個新來的同仁在規則沒寫到的地方會猶豫，會回頭來問你。模型不會猶豫。

那實際上用什麼

這一段不是評測，而且我要把它寫得很短。

工具三行講完：專案中樞是一套跑在本機的 CLI agent（我用 Claude Code），負責讀寫檔案、串流程、管版本——它不是「聊天視窗」，它是這條流程實際的執行環境；評判者是幾個不同系列的雲端模型，彼此獨立，只吃 L0；L1 與 L2 走地端，用 Ollama 離線跑；統計與排序交給 Python，不經過模型。

我沒有在同一組控制條件下比較過它們，這個系列也不會出現那種內容——那需要一整套實驗設計，結果會另外發表。而且這份清單半年後一定會變，所以它不是重點。會變的是名字，不會變的是下面這一段。

因為分流不是從工具推出來的，是從工作性質推出來的。這條線上有三種性質完全不同的工作：

第三列常常被忽略。把一堆判定變成排序、算出分佈、產出報表——這些是確定性運算，交給模型只會多一層不確定性、多一層要驗的東西。

一條 AI 流程裡，最不該用模型的那幾步，通常就是這條流程有沒有想清楚的證據。

而第一列和第二列之間有一條硬規則：

生成的模型和評判的模型不能是同一個。

如果造題的人跟改考卷的人是同一個，你量到的不是能力，是自我一致性。這件事 Day 23 整篇談，這裡只講它對工具選型的直接影響：它決定了我至少需要兩個不同來源的模型，而且最好是不同系列——同一個系列的兩個模型，共享的東西比你以為的多。

至於 prompt 怎麼命名、怎麼編版本、怎麼登記進一份清單——那是 Day 27 的題目，這裡先不展開。

這個架構自己帶了一個裂縫

把分流講得這麼乾淨，聽起來像是問題解決了。其實沒有。這個架構在設計上就內建了一道裂縫，我認為值得寫出來，因為任何人照這個原則做都會撞到。

裂縫在這裡：判準在雲端、對自己編的案例調出來；上線要在地端，對著真實的通報單跑。

講白一點，我這條線從第一天就沒有 dev/prod parity。而且這不是我懶，是資料邊界逼出來的。

所以我在雲端量到的一致性，是 staging 的數字，我不能拿它去 claim 上線後的行為。同一套判準，換一個模型讀，可能讀出不一樣的嚴格程度——而且我沒有真實資料的標準答案可以對。

這一整條困境是第四週的主題，也是我為什麼那麼在意那些自己編的通報案例的原因：

當你不能把真實資料搬去測，你就得把測試搬到真實資料那邊去。

這句話講起來輕鬆，實際做法是 Day 22 的內容。

我把這道裂縫寫在這裡，是因為分流架構最容易給人的錯覺，是「邊界畫好就安全了」。邊界確實保護了資料，但它同時把驗證的難度整個往上推。

你為了保護資料付出的代價，最後會以驗證成本的形式回來收帳。

這個系列談的是規則寫不下來的那一半。而規則寫不下來的東西有一個共同的麻煩：它沒辦法被打包帶走。一段規則可以複製到任何一台機器上跑出一樣的結果；一組自然語言判準不行——它的行為綁在模型上，模型綁在你能不能把資料送過去。

所以資料邊界對規則寫得下來的那一半只是搬運問題，對寫不下來的這一半是能力問題。邊界一畫，這一半就更難了。這不是可以繞過去的東西，只能把它算進設計裡。

地端的代價，不在「笨一點」

最後講一件我一開始想錯的事。

我原本以為地端模型的代價是能力打折。實際跑下來，真正的代價幾乎全在工程面：

• 一次能吃多長的文字
• 跑一批要多久，一個晚上跑不跑得完——它不是效能問題，是 batch window 塞不下
• 機器在誰手上、誰維護、壞了誰修——那台機器沒有 owner，也沒有人 on-call
• 模型檔案怎麼更新，更新之後判準還準不準（Day 26 整篇談這個）——每一次更新都是一次沒有 regression test 的 deploy

但醫療端在規劃的時候常常只想到「地端就是安全」，然後在第一次跑批次的時候發現整件事在時間上不可行——不是不能跑，是跑完的那天，品管室要用它的那場會議已經開完了。

而工程面的代價會轉化成一個心理面的代價，這才是真正危險的地方。

地端跑得慢，人就會開始想「這一份應該還好吧」。

邊界最常見的破口不是駭客，是趕時間的自己人。

所以「慢」本身就是一種資安風險。這也是為什麼那條「真實資料只走地端」必須寫成路徑上的隔離，而不是寫成一句提醒——提醒擋不住一個趕著在下班前跑完的人。

明天是這一週的最後一篇：把這 30 天要跑的整條線攤開來，包括那條最容易被砍掉的迴路。