01先區分兩件常被混為一談的事
談資料安全時，很容易把「加密」和「離院」這兩件事混在一起講，覺得只要有加密、有合規認證，資料就安全了。 但對診所來說，這兩件事的層次其實不一樣。先把它分清楚，後面的判斷才不會被話術帶著走。
資料有沒有加密 ≠ 資料有沒有出院
加密處理的是「資料在傳輸或儲存時，被第三方攔截後讀不讀得懂」；它是一道很重要的防護，但它不改變一個事實： 資料還是離開了診所、進到了別人的伺服器。 換句話說，加密回答的是「會不會被偷看」，而不是「資料現在人在哪裡」。 對醫療場景而言，後面這一題往往更關鍵——因為資料一旦離院，它的保存、調閱、刪除，就不再完全由您掌握。
雲端再安全，資料仍離開診所；地端的差別是「物理上不出門」
雲端服務當然可以做得很安全：大廠的機房、層層權限、各式認證。但「安全」和「在不在您手上」是兩回事。 雲端架構的本質，是把運算搬到外部伺服器，所以對話內容必須先送出去。 地端（on-premise）架構的差別，不是它「比較安全」這種程度上的形容，而是一個結構上的事實： 運算與資料都在診所自己的主機上完成，資料物理上根本不出這道門。 沒有送出去的資料，就沒有「在外部被怎麼處理」的問題——這是兩種架構的根本分界。
02病人資料出院，您要面對的三類考量
如果資料會離開診所，會牽涉到哪些層面？以下三類僅作中性整理，幫助您在評估時把問題問完整， 實際的法律適用與責任認定，仍應依個案並諮詢專業意見。
個資法——蒐集、處理、利用與跨境
病歷屬於高度敏感的個人資料。資料一旦離開診所交由外部服務運算，就涉及「蒐集、處理、利用」的環節由誰執行、 依據為何；若服務的伺服器在境外，還會多一層「跨境傳輸」的考量。 這些不是說雲端一定不行，而是說——當資料留在院內、根本沒有對外傳輸時，這一整串問題在源頭上就少了許多需要釐清的環節。
醫療法 · 電子病歷——保存與調閱責任在院所
依現行規範，病歷的製作、保存與調閱責任，最終是落在醫療院所身上。 當病歷資料的儲存與處理交由第三方時，「資料實際存在哪裡、保存多久、如何調閱、如何確保完整」這些責任並不會因此轉移出去， 反而會多出一層「您要對一個不在您手上的環節負責」的狀況。把資料留在院內，責任邊界相對單純。
實務風險——第三方服務中斷、外部留存的可控性
除了法規層面，還有很現實的營運考量。把核心流程綁在外部服務上，意味著對方一旦故障、維護、調整方案甚至停止營運， 都可能直接影響您的看診。而資料留存在外部，「到底還留著哪些、能不能完整刪除、誰碰得到」， 您能掌握的程度也相對有限。可控性，本身就是一種需要被算進去的成本。
03離線地端怎麼從結構上避開這些問題
前面講的考量，多半都源自同一個動作：資料離開了診所。 那麼把這個動作從一開始就拿掉，問題的源頭自然就少了。離線地端正是這個思路。
運算與資料都在診所主機，斷網照常運作
從收音、辨識到整理成病歷，整段流程都在診所自己的主機上完成，不需要把對話送到外部伺服器。 也因為不依賴外連，即使診所臨時斷網、網路不穩，系統照常運作——這是雲端方案在設計上做不到的。
語音檔轉錄完即可銷毀，SOAP 存在本機
對話轉成文字、整理成病歷之後，原始語音檔的角色就完成了，可在本機處理掉； 產出的 SOAP 病歷存放在診所自己的主機上。要保留多久、什麼時候銷毀，由院所自行決定， 不會有一份副本默默躺在別人的雲端裡。
不回傳開發商，資料治理權在您手上
因為流程不需外連，資料就沒有被回傳給開發商的環節。 誰能存取、保留或刪除哪些內容，決定權留在診所這一端。資料治理權在您手上， 而不是寄存在一份您看不到的服務條款裡。
想更全面地比較不同架構的取捨，可以延伸閱讀 國際 vs 台灣在地語音病歷 AI 比較； 若您還在猶豫「能不能直接用 ChatGPT 寫病歷」，也建議先看 用 ChatGPT 寫病歷可以嗎這一篇。
04但「離線」會不會犧牲體驗？常見三個顧慮
聽到「完全離線、不上雲」，很多醫師的下一個直覺是：那會不會比較慢、比較難更新、比較難整合？ 這三個顧慮很合理，我們一個一個回應。
速度——本機推論，30 秒生 SOAP
離線不等於慢。OPPA 在診所配置的主機上完成運算，看診結束後約 30 秒就能把對話整理成 SOAP 病歷初稿。 少了把資料來回上傳、等雲端回應的這段網路往返，體感上反而更穩定，不會因為外部網路忽快忽慢而卡住。
更新——模型與健保規範可隨版本更新，不等於要連網跑推論
「離線」指的是日常推論不需連網，不是這台機器從此與世隔絕。 系統本身、以及健保碼等行政資料，仍可透過版本更新的方式維護到最新狀態。 把「日常運作不外連」和「需要時可更新」分開看，就會發現兩者並不衝突——平常跑得安心，該更新時也更新得了。
整合——F9 直貼，不需改 API
導入新工具最怕要動現有系統。OPPA 產出的病歷，可以透過 F9 直貼的方式放進您現有的 HIS， 支援整份或分段（S / O / A / P）貼上，不需要去串接或改寫 HIS 的 API。 它配合您現有的看診流程，而不是逼您整套換掉。
05怎麼檢核一套「號稱離線」的 AI 是不是真的離線
「離線」「地端」「資料不外流」這些詞，現在幾乎每家都會講。但講法跟做法不一定一致。 以下是您可以直接拿去問、拿去驗的實用清單，幫您把行銷話術和真實架構分開。
把網路線拔掉，它還跑不跑得動？
這是最簡單也最誠實的一題。真正在本機運算的系統，斷網之後從收音、辨識到生成病歷都該照常完成。 如果一斷網就無法辨識、無法產生病歷，那它的運算其實是在外部進行的——資料勢必有離院。 這一題用問的不夠，請現場拔線實際看。
資料存在哪、誰能調閱、能不能銷毀？
請對方明確回答：對話與病歷實際存在哪一台主機？院所之外有沒有任何一份副本？ 誰有權限存取？要刪除時，能不能完整、確實地刪掉？ 這些答案應該是具體、可查證的，而不是一句「我們很安全，請放心」。
願不願意現場帶機、斷網實測？
願意帶機到您診所、當著您的面斷網跑一遍的廠商，等於把架構攤開來給您驗。 這比任何簡報、任何認證標章都更有說服力。如果對方對「斷網實測」面有難色，那本身就是一個值得留意的訊號。
如果您想把整個導入前的準備一次盤點清楚，這篇也很適合搭配閱讀： 診所導入語音病歷 AI 要準備什麼。
06OPPA 的離線地端定位（客觀說明與邊界）
把上面這些原則放回 OPPA 自己身上，我們也用同樣的標準說明，包括它能做什麼、以及它刻意不去碰的邊界。
100% 離線、資料不出院，是設計的初衷
OPPA 從第一天就是為「資料不出診所」而設計的：所有運算與資料都留在診所主機，不上雲、不外連，斷網照常運作。 這不是後來補上的附加功能，而是整個產品的出發點—— 因為這正是雲端 AI、一般線上服務在結構上做不到、而台灣診所最在意的一件事。
定位界線——文書行政工具，非醫療器材，不做診斷判讀
同樣要把話講清楚的，是 OPPA 不做什麼。 OPPA 定位為醫師的文書／行政效率工具，把醫病對話整理成病歷、把代碼查找變快； 它不是醫療器材，不做診斷、不做判讀、不替醫師下任何臨床判斷。 系統產出的是病歷初稿，最終的評估與認定，永遠是醫師的專業；健保碼也只是行政層面的查找輔助，供醫師逐筆確認。 守住這條界線，跟把資料守在院內一樣，都是我們認為負責任的產品該做的事。
07最有說服力的驗證，是拔掉網路線
關於離線地端，文字能說的就到這裡。但「資料不出院」這件事，最終不該靠誰的保證，而該靠您親眼看見。
所以我們很願意做一件多數雲端方案做不到的事：帶機到您的診所，當場把網路線拔掉，再跑一遍從醫病對話到 SOAP 的完整流程。 斷了網，它照樣聽得懂、照樣 30 秒生病歷、照樣 F9 直貼回 HIS——那一刻，「資料不出院」就不再是一句宣傳，而是您看著它發生的事實。 如果您正在評估醫療 AI，這場斷網實測，會是最直接的一次驗證。