當創新遇上不信任：數位轉型三年的挫折與反思

過去三年推動數位轉型，最深刻的感受，是技術進步的速度，與企業建立信任的速度，出現了明顯落差。

生成式 AI 快速成長，企業也急著尋找新的應用方式：加快研發、整理知識、協助分析，或改善日常作業。然而，新模型、新工具與新服務不斷出現，資訊量的增加，未必讓決策更加容易。有時候，選擇越多，組織反而越猶豫。

這種矛盾，在研發團隊與 IT 部門之間尤其明顯。

研發看見的是機會，是原本需要數天完成的工作，可能縮短為數小時；IT 看見的則是資料流向、存取權限、供應商責任，以及系統發生問題之後，誰必須處理後果。

雙方碰撞最激烈的地方，經常集中在兩個問題：企業能不能信任雲端工具？語言模型的行為能不能受到控制？

這些擔憂有其必要。但當擔憂沒有被拆解成具體風險與處理方式，便可能成為長期停滯的理由。專案在反覆討論中消耗時間，團隊逐漸失去試驗的動力，企業也難以累積真正的使用經驗。

走過這三年，越來越清楚的一件事是：生成式 AI 的導入，需要組織重新理解資訊流動、風險責任與安全管理的關係。

一、研發與 IT 的衝突，背後是責任與衡量方式的差異

從研發的角度來看，生成式 AI 是新的生產工具。團隊需要透過試驗，才能知道哪些工作適合交給 AI、哪些模型足以勝任，以及哪些流程值得重新設計。

如果每一次試驗，都必須先完成與正式系統相同程度的審查，探索成本便可能高到讓人放棄。

但從 IT 的角度來看，一個看似簡單的 AI 工具，背後可能牽涉外部服務、帳號權限、文件上傳、紀錄保存，以及第三方連接功能。展示畫面中的幾個操作，未必能呈現完整的風險。

雙方於是容易出現理解落差。

研發認為：「只是想先測試效果。」

IT 想的是：「上傳了哪些資料？誰能看到？會保存多久？出了問題能不能追查？」

這些問題都合理。困難在於，雙方承擔的責任與接受評價的方式，往往不同。

研發被期待交付成果、縮短時程、提出創新；IT 則被要求維持穩定、避免外洩、確保可追查。創新的成果容易被展示，避免事故的成果較難被看見；延誤創新的成本，也未必會進入既有的資安決策流程。

若管理階層一方面要求研發加速，另一方面要求 IT 保證沒有任何風險，兩個部門自然很難取得共識。

企業需要共同決定：哪些風險可以接受，哪些必須降低，以及為了降低風險，願意投入多少成本與時間。這項決策需要業務主管與管理階層參與，不能全部留給研發與 IT 在個別專案中協商。

二、資安管理需要掌握資訊流動，也需要保留前進的空間

在數位轉型現場，最容易採取的管理方式，是限制資訊流動：禁止上傳、禁止連線、禁止使用外部工具。

面對明確的高風險情境，這些限制可能必要。但若逐漸把「資訊不能出去」當成所有問題的共同答案，組織便容易失去判斷不同情境的能力。

資安管理的核心，應包括讓必要的資訊流動受到授權、可以追溯，並且具有可評估、可處理的風險。

企業需要知道：資料從哪裡來，由誰存取，經過哪些系統，傳送給哪些服務，產生什麼結果，以及最後保存或刪除於何處。這些資訊，是風險判斷、異常偵測與事件處理的基礎。

不過，可追溯也有其限制。事件發生後查得到原因，並不能挽回所有損失。因此，追溯機制還必須搭配事前授權、資料最小化、權限限制與必要的阻擋措施。

值得警惕的是，當企業只追求把資訊路徑堵到密不透風，卻沒有建立安全使用新工具的方法，封住的也可能包括學習、協作與改善工作的路徑。

對正在尋找新方法的團隊而言，一句「不能用」很容易理解，卻沒有提供下一步。長期下來，組織可能出現兩種結果：部分人放棄探索，另一些人則轉向未經核准的工具。後者反而讓資訊流動更加難以掌握。

因此，每一項限制都應盡量說明適用範圍、風險依據，以及可以採取的替代方式。必要時，也應設定重新檢視的時間。

安全管理若能提供一條可走的路，才更有機會獲得使用者配合。

三、「資料出了公司就不安全」，需要拆成可以查證的問題

企業內部經常存在一種直覺：資料留在公司裡比較安全，一旦送往雲端，就可能被竊取、被留存，甚至被拿去訓練模型。

這些情境都值得檢查，但它們是不同問題。

資料傳輸到外部，是資料處理位置的改變；資料遭到未授權存取，是安全事件；資料是否被用於模型訓練，則取決於服務條款、產品類型與設定。不能只因為使用雲端 AI，就把三者直接畫上等號。

以 Microsoft 對 Azure 銷售模型的官方說明為例，客戶輸入與輸出不會在未經許可或指示下，用來訓練生成式 AI 基礎模型。不過，特定功能可能保存對話或上傳內容，濫用監控也有另外的處理機制，資料處理區域則受到部署類型影響。

這說明了：不拿去訓練，不等於完全不保存，也不等於資料一定只在指定地區處理。 這些承諾也不能直接套用到所有 AI 產品。（參考：Microsoft 資料、隱私與安全說明）

因此，企業評估雲端工具時，至少應回答以下問題：

同樣地，自行部署模型，也需要管理伺服器、漏洞、帳號、備份、模型來源及維運人員權限。資料留在內部，可以降低某些外部處理風險，但安全程度仍取決於實際管理能力。

部署位置是評估條件之一，企業還需要檢視完整的資料處理過程，以及自己能否有效管理它。

四、安全責任應落在有能力控制風險的人身上

另一項值得反思的現象，是企業有時把過多資安判斷留給使用者。

員工被要求自行確認工具是否安全、自行理解供應商條款、自行判斷哪些資料可以上傳，最後再透過切結或使用規範，承擔操作後果。

使用者當然需要遵守規則，也必須對自己的行為負責。但一般員工很難查證服務商後端如何保存資料、哪些人員可以存取、資料是否經過其他處理者，以及系統發生事件後能否完整刪除內容。

如果組織沒有提供足夠資訊與可用工具，只強調「出事要負責」，很容易讓員工懼於投入。原本希望鼓勵的創新，最後變成個人必須自行承擔的不確定性。

安全責任的分配，應與控制能力相匹配。

掌握服務設計、資料處理與系統權限的一方，應承擔相應的安全義務。這裡的服務提供方，既包括外部雲端與 AI 服務商，也包括企業內部建置平台、提供共用服務的團隊。

具體而言，可以分為三個層次：

這樣的責任分配，需要落實到採購條件、契約、技術設定與維運流程。單靠教育訓練或一份使用者同意書，無法處理服務本身的設計缺失。

對員工而言，理想的使用環境應該容易理解：哪些工具可以使用、哪些資料可以處理、哪些操作需要核准，遇到不確定情況時，可以找誰協助。

組織把這些基礎做好，使用者才有條件安心投入。

五、語言模型的不確定性，需要透過整個系統管理

IT 對語言模型「不受控」的擔心，有實際依據。

語言模型可能產生看似合理、實際錯誤的內容；也可能受到使用者輸入，或文件、網頁中夾帶的惡意指令影響。NIST 的生成式 AI 風險文件，將虛構內容、資料隱私與資訊安全等問題納入風險管理範圍。（參考：NIST 生成式 AI 風險管理文件）

但確認模型可能出錯之後，企業還需要追問：它出錯時，能造成多大的影響？

協助撰寫內部草稿，與自動寄送客戶信件，承擔的風險不同；整理文件，與修改正式資料庫，所需的控制強度也不同。

OWASP 指出，提示注入可能透過外部文件或網站影響模型，而 RAG，也就是先檢索資料再生成答案的做法，以及微調，都不能完全消除這項風險。（參考：OWASP 提示注入風險說明）

因此，控制重點可以放在三個邊界。

第一，模型可以讀到什麼。資料存取應依使用者身分與任務需要決定。建立 AI 知識庫時，必須保留原有的文件權限，並在檢索階段確認使用者是否有權取得內容。

第二，模型可以執行什麼。查詢、草擬、修改、寄送與刪除，應具有不同權限。高影響操作需要額外驗證，必要時由人員核准。

第三，模型出錯後如何停止與復原。系統需要保留必要的追查紀錄，也要有停用功能、撤銷權限及回復作業的方法。

這些控制必須落實在應用程式與基礎設施中。提示詞可以協助引導行為，但完整的安全責任，仍需要由系統設計承擔。

六、讓導入停滯的，經常是風險沒有被轉成可完成的工作

回顧這三年的推動經驗，許多挫折來自同一個地方：大家知道有風險，卻不知道完成什麼，才能繼續往前走。

當有人提出資料可能外洩，如果討論就停在這裡，團隊便很難採取行動。究竟需要更換服務、遮蔽資料、限制功能，還是補上合約條件？若沒有明確答案，專案便可能一直等待。

相對地，研發也需要提出證據。工具能完成展示，只能證明某個情境下有效，尚不足以說明它已具備正式上線的條件。

每一項風險意見，都應盡量轉成四個要素：

• 具體情境： 什麼資料，可能透過什麼途徑，發生什麼問題？
• 影響程度： 會影響誰，後果有多大？
• 改善條件： 完成哪些措施，可以降低風險？
• 決策責任： 由誰驗證改善結果，由誰接受剩餘風險？

例如，「這個工具有外洩風險」可以進一步轉成：「這項服務尚未確認附件保存期限，因此試辦階段只允許使用公開與合成資料；完成保存與刪除條件確認後，再評估是否開放內部文件。」

後者提供了可執行的下一步，也保留了試驗空間。

審查有明確的完成條件，研發才知道要補什麼，IT 也有依據說明為什麼能開放，或為什麼仍需限制。

七、依資料與行動風險分級，建立可走的導入路徑

企業可以依資料敏感程度，以及 AI 能採取的行動，建立分級導入方式。

資料敏感程度與操作權限需要分開判斷。即使只使用公開資料，若 AI 可以直接執行正式系統操作，仍可能帶來重大影響。

這套分級的價值，在於讓低風險實驗有清楚的通道，同時讓高風險應用取得足夠的審查與資源。

對使用者而言，分級也應轉化成容易遵循的操作方式。例如，核准平台可以依資料類型限制可用服務，或在敏感操作前提供清楚提示與核准流程，減少使用者每次都要重新判斷的負擔。

八、研發與 IT 應共同建立可以重複使用的基礎

如果每個專案都重新選工具、談條款、設權限、建紀錄，導入成本很難下降。

企業可以先建立一套共用的 AI 使用流程：員工透過公司帳號登入，系統依身分限制資料與功能，再使用經核准的模型服務，並依風險需要檢查輸出與記錄操作。

紀錄本身也需要管理。為了追查而無限制保存完整提示詞與文件，可能產生新的資料風險。應依目的決定記錄內容、保存期限與存取權限，必要時採取遮蔽或去識別處理。

在分工上，研發負責定義任務、建立測試案例、評估效果，以及設計人工覆核流程；IT 負責身分、權限、網路與維運控制，並協助確認供應商及資料處理條件。

資料擁有者需要決定哪些內容可供使用，業務主管則必須對使用目的、效益與剩餘風險負責。

英國 NCSC 的 AI 安全開發指引，將安全工作涵蓋到設計、開發、部署與持續維運。對企業而言，這意味著 IT 應在需求形成時就參與，研發也需要把安全條件納入設計。（參考：NCSC AI 安全系統開發指引）

共同基礎還應包含變更管理。供應商更新模型，或團隊加入新的資料來源、連接工具與操作能力時，都需要判斷是否重新測試。

原本核准的摘要工具，加上寄送與修改功能之後，已經需要重新評估風險。

九、用九十天建立第一個可驗證的成果

企業不必一開始就完成龐大的治理架構。以下九十天安排，可以作為依資源調整的起步方案。

前三十天：選定問題，畫清邊界。

選擇一個有明確負責人、效果可衡量、失誤可補救的任務。記錄目前人工處理時間與品質，確認可用資料、供應商條件、禁止操作及試辦範圍。

此階段應產出一份各方都能理解的試辦說明，列出資料流向、風險處理方式，以及服務提供方與使用者各自的責任。

第三十一至六十天：在有限範圍內驗證。

以少數使用者和受控資料試辦，測試一般問題、資料不足、錯誤文件、越權查詢及惡意指令等情境。

除了答案品質，也要確認系統在不該回答、不該讀取或不該執行時，是否能守住邊界；操作發生異常時，能否找到必要紀錄並採取處置。

第六十一至九十天：依證據決定擴大、修正或停止。

比較導入前後的整體成果，包括使用者檢查與修正 AI 產出的時間。確認維運負責人、成本、支援方式及停用條件，再決定是否擴大。

有些試辦應該停止。若覆核成本高於節省時間，或資料條件不足以支持可靠結果，停止也是有價值的決策。重點是企業能說明原因，並把經驗用在下一個情境。

十、衡量成效，也要衡量治理是否支持工作

導入成效不能只看開通多少帳號、舉辦多少課程，或完成多少次展示。

企業可以同時觀察三類指標：

其中，治理效率值得被認真看待。

若員工需要投入大量時間，才能確認一項日常操作是否被允許，代表規則或工具仍有改善空間。若每次使用都要由個人重新承擔供應商安全判斷，也代表組織尚未提供足夠支持。

同樣地，沒有通報事故，不一定代表沒有風險，可能只是缺乏偵測；攔截次數增加，也不一定代表安全變差，可能是監控開始發揮作用。

指標需要搭配使用規模、測試條件與事件內容判讀，才能支持正確決策。

十一、三年的反思：讓安全成為企業前進的能力

過去三年，企業對生成式 AI 的期待，與實際導入的猶豫，始終同時存在。

技術持續進步，組織卻需要更多時間理解資料如何流動、模型如何出錯，以及責任應如何分配。這些問題不會因為全面開放就自然解決，也不會因為全面禁止而消失。

資安管理需要掌握必要的資訊路徑，辨識風險，設下適當邊界，並具備追查與處理異常的能力。把所有資訊去路封死，可能同時封住改善工作的機會。

同樣地，企業需要把安全要求落實在服務與平台上，讓掌握技術、資料處理與權限控制的一方，承擔相應責任。使用者需要清楚的規則、可用的工具與可靠的支援，才有條件負責任地投入創新。

走過這三年，我逐漸體會到，數位轉型的難處，經常出現在組織如何面對不確定性。

當研發能提出效益證據，IT 能提供可完成的安全條件，服務提供方承擔應有義務，管理階層也願意做出風險決策，團隊才有機會從反覆爭論，走向持續累積。

這樣建立起來的信任，會讓企業在面對下一個新工具、新模型與新機會時，更有能力判斷，也更有信心前進。