從 AI 使用到資訊公開 釐清審查責任與發布關卡
文／游政卿
關於近日競選網站的新聞，讓外界注意到公開的 AI 提示詞（Prompt）可能洩漏網站建置脈絡。媒體報導指出，平台上一件作品公開其製作提示詞，內容提及參考另一個網站，該專案的開發紀錄亦對外公開。
後續報導引述平台相關人士說法，平台鼓勵創作者提供提示詞供他人參考，該作品資訊頁亦設有提示詞欄位。至於該段提示詞如何上架、何時首度公開，目前仍待釐清。
單憑此則新聞，尚難認定已構成企業資料外洩。對企業而言，工作資料一旦置入專案，究竟由誰判定何者可隨專案公開，成為治理關鍵。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
假設行銷同仁請 AI 製作活動報名頁面，為說明需求，將尚未公布的優惠方案、客戶專案背景與內部測試網址一併交給 AI。網站完成後，部分需求說明仍留存於專案文件。若發布網站時一併上傳這些文件，或將整個專案公開，其中的工作資料便可能外流。企業須先明定由誰審查、由誰核准公開；在授權尚未釐清前，亦須有人能暫緩發布。
我建議企業從四個環節把關：資料交由外部 AI 服務處理前，先確認是否已獲准由該服務處理；準備公開時，由負責人審查內容並釐清授權；發布前，由工程或平台人員核對內容、版本與目的地，再由發布人員依核准結果放行；平時亦須檢視帳號權限與暫停程序，必要時驗證審查未完成時能否暫停發布。
審查時點，要看資料何時對外開放
檔案一旦推送至公開儲存庫分支，外界即可能檢視。即使程式碼尚未通過合併審查、網站亦未上線，資料仍可能已公開。企業須依專案發布方式，決定何時完成檢查。
若專案原置於私有儲存庫，擬將儲存庫公開或將內容推送至公開儲存庫前，須先完成審查。至於原本即在公開儲存庫協作的專案，每次推送前皆須檢查。平時更新，檢視本次新增或異動內容即可；首次公開或擴大公開範圍時，則須一併檢視將隨之公開的歷史紀錄。
網站對外發布前，亦須先完成檢查。即使儲存庫未公開，網站上線的內容與服務，仍可能遭外界存取。
資料交由外部 AI 服務處理前，亦須確認是否已獲准。資料可交由 AI 處理，不等於可公開上網。
AI 讓文件與操作權限都成為審查重點
開發團隊本就以文件與筆記記錄需求及開發過程。部分 AI 開發工具會讀取專案中的指令檔與提示檔，據以執行任務。開發者亦可能請 AI 協助彙整需求，或撰寫操作說明與交接紀錄。這些紀錄利於日後維護與交接，卻也可能將僅供開發參考的內部資訊留存於專案。指令寫入專案檔案後，提交時便可能一併進入儲存庫；若儲存庫為公開，外界即可能檢視。前述新聞中的提示詞出現於作品資訊頁，尚難據此認定係透過 GitHub 公開。
工程或發布人員應先列出本次擬公開的所有檔案與頁面，再檢視是否包含開發階段使用的資料，例如需求說明、提示詞或測試資料，皆可能隨之釋出。接著由專案負責人對照清單，確認本次擬公開項目。先前核准若已涵蓋本次公開的具體內容、用途與範圍，得以沿用；超出原核准範圍者，須重新取得授權。
對話內容是否存檔或上傳，取決於所用工具與實際操作方式。
部分 AI 開發工具取得權限後，即可讀取檔案或執行指令，亦能協助推送程式碼或部署網站。例如員工輸入「做好後幫我發布」，工具便可能連續執行多個動作。企業除審查內容外，亦須限制工具可讀取的資料範圍與對外連線目的地；哪些操作須經人員核准後始得執行，亦須事先明定。提示詞可提醒 AI 保密，企業仍須透過帳號權限與執行環境，限制工具操作。
程式碼審查之外，還要判斷內容能否公開
在我參與的研發資安工作中，部分團隊曾於特定專案導入 AI 輔助程式碼安全審查。開發者先於本地端檢查程式碼，提出或更新合併申請時，系統即啟動 AI 審查。審查人員檢視結果後，自行判定是否放行本次異動，或請開發者再調整。團隊當時亦定期掃描這些專案的原始碼。
導入過程中，團隊發現 AI 有時誤判，或提出超出本次審查範圍的問題，審查人員仍須檢視結果，判斷何者須修正。在我看來，程式碼安全檢查完成後，專案文件中資料能否公開，仍須由了解用途與授權範圍的人員判定。
[ 推薦閱讀：從告警到可決策：企業還要四小時 ]
假設開發筆記載有客戶名稱，並提及尚未公布的合作內容，即使程式碼本身無誤，公開仍須授權。掃描工具可協助找出部分金鑰或憑證，但業務資料的公開授權，仍須人工判斷。
我建議專案負責人對照發布清單，彙整每項內容用途。內容超出原核准範圍時，即請資料所屬單位指定的授權人審查；涉及客戶或合作方資料者，公開前須取得相應授權，必要時可會同資安或法務人員審查。
專案負責人可彙整授權結果，註明何者已獲准公開、何者尚待處理。一份文件若含多個單位資料，亦須載明各單位同意公開的範圍。客戶資料未獲公開授權、檔案留存可用憑證，或內部文件用途尚未釐清時，專案負責人應先退回處理，發布人員則暫緩發布。
核准的內容，要與實際發布的版本一致
發布前，工程或平台人員須核對擬送出的內容、版本與目的地，確認符合核准紀錄。發布人員檢視核對結果與公開授權後，再決定是否放行。核准後若新增檔案、異動內容或擴大公開範圍，異動部分須送回審查。例如活動頁面獲准上線，是否代表整個開發專案亦可公開，皆須明確載明。
平台管理者可從帳號權限著手，限制何者可建立公開儲存庫、變更公開範圍或部署至正式環境。AI 可先於權限受限的環境中產生檔案並執行測試，對外發布再使用公司管理的帳號，依核准程序進行。具體設定取決於平台功能與公司方案，亦須檢視其他帳號或發布管道是否可能繞過審查。
上述公開審查與權限設定，即我對企業的建議。既有安全開發指引雖已列出測試與審查要求，導入時仍須於發布流程中落實檢查。
專案首次公開前，亦須檢視歷史版本紀錄。若將長期使用的私有儲存庫直接公開，舊版資料亦可能一併曝光。必要時，可以已審核內容另建公開版本，並先決定擬公開的歷史範圍。外露憑證若仍有效，須優先撤銷或更換；即便刪除現行檔案，憑證仍可能留存於版本紀錄或他人副本。
臨時專案也要有發布窗口
回到前述活動網站的假設，負責同仁未必熟悉版本管理或研發審查流程，若還須自行洽相關單位取得核准，流程恐難順利推動。
我建議企業提供公司管理的專案空間，並指定發布窗口。負責同仁先提供擬公開頁面，說明資料來源與網站用途，再由專案負責人安排內容審查與必要檢查。若為靜態頁面，僅置入已公開且有權使用的資訊，得視風險簡化流程；涉及客戶資料、會員登入或連接內部系統者，則須增加檢查。
急件發布前，專案負責人須先列出尚未完成的檢查。企業可先縮小發布範圍，例如先上線已核准的活動介紹，資料蒐集或系統串接則暫緩。若須調整審查時程，須依程序處理，專案負責人亦須記下調整範圍與期限。
[ 閱讀所有 游政卿 的文章 ]
即使調整審查時程，發布內容仍須具備必要的公開授權。客戶資料的公開依據尚未釐清者，先自本次發布內容移除；檔案中留存可用密碼或金鑰者，亦須先行移除，並視情況撤銷或更換。
企業亦須要求外包團隊遵循此套發布流程，業務單位自行建置的網站亦須納入管理。若專案所用帳號與環境皆不受公司管控，即無法確保每次發布皆經檢查。發現此類專案後，企業須先盤點清楚，再納入管理，必要時啟動事件處理流程。
資安長要確認暫停發布能否生效
資安長可挑選一個近期完成的 AI 開發專案，請專案負責人提供當時實際發布內容，再對照當時的公開授權、版本核對與發布紀錄，確認送出資料是否皆在核准範圍內。資安長亦可檢視發布權限與暫停程序，必要時安排受控測試，驗證審查未完成時能否攔下發布。
若無法判定由誰決定資料能否公開，須先釐清責任並指定負責人；已發布內容超出核准範圍者，須先限制外界存取，再重新審查。帳號於審查未完成前即可直接發布者，亦須調整權限與流程。資訊公開前須先完成審查，發布人員亦須有權依審查結果暫緩發布，如此企業方有機會攔下未獲授權的內容。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
