AI 工具最先改變的是個人的工作方式。工程師可以用 AI 理解程式、產生測試、重構函式與撰寫文件。產品角色也能用 AI 整理需求、補充驗收條件，或產生使用者故事（User Story）。這些做法能縮短個人處理工作的時間，讓任務推進得更快。
當 AI 產出的內容進入團隊共用的程式庫、產品文件、測試案例或決策紀錄後，它就會成為團隊交付成果的一部分，並影響後續開發、測試、維運與使用者支援。
開發者將 AI 生成的程式碼提交到拉取請求（Pull Request, PR）後，審查者需要確認邏輯是否正確、是否符合系統設計，以及是否帶來資安或授權風險。個人節省的時間，也可能轉成其他成員需要承擔的檢查工作。
資料使用也要有明確規範。有人會將錯誤訊息、資料片段、內部需求或客戶情境貼進 AI 工具，希望取得更符合情境的回答。這些輸入可能涉及資料外洩、合約限制與合規風險。若沒有共同規則，成員很難判斷哪些資料可以輸入、哪些內容需要遮蔽，以及哪些情境必須先完成確認。
AI 治理的目的，是讓團隊明確知道 AI 可以用在哪些工作、需要保留哪些紀錄、哪些內容必須經過人工確認，以及哪些資料不得放進提示詞。這些規則讓 AI 的使用方式可以被共同檢視，問題發生後也找得到追查線索。
治理不必一開始就建立成複雜制度。第一步可以先回答幾個直接問題：哪些資料可以提供給 AI？哪些程式區域允許 AI 協助修改？AI 產出的程式碼需要通過哪些檢查？拉取請求是否需要說明 AI 的使用範圍？這些答案被整理並寫下來後，團隊就有一致的判斷依據。
可信任的 AI 使用，取決於團隊能否掌握輸入內容、輸出結果與驗證方式。AI 可以協助產生程式碼、文件與需求內容，需求判斷、架構設計、安全檢查與品質驗證仍由團隊負責。
治理會把這些責任放進日常開發流程，避免只停留在口頭提醒。
AI 產出速度加快後，審查壓力也會隨之增加。過去審查者主要閱讀開發者親自撰寫的變更，還能從命名、提交紀錄與討論過程理解設計思路。AI 生成內容常具備完整結構、合理格式與順暢命名，審查者需要投入更多時間，確認內容背後的假設是否正確。
團隊缺少明確規則時，審查者每次都要重新確認：這段程式是否由 AI 產生？提交者是否理解其中的邏輯？實作是否符合既有架構？是否將尚未確認的假設寫進正式程式？
當這些問題全都留到審查階段處理，審查時間會被拉長，部分風險也可能在檢查過程中被忽略。
部分檢查可以移到審查之前。安全掃描、自動化測試、授權檢查、靜態分析與高風險區域標記，都可以納入提交程式碼的基本門檻。
拉取請求說明記錄 AI 的使用範圍後，審查者比較容易辨識需要加強檢查的區域，並把討論放在變更意圖、系統風險與設計判斷。
AI 治理的作用，是讓 AI 使用方式可以被信任、追蹤與調整。使用邊界、驗證規則與責任範圍被記錄下來後，分散在個人工作環境中的隱性風險才會浮上檯面。建立信任安全網後，團隊才能更放心且大規模地擴大 AI 使用。
團隊使用 AI 前，需要先確認哪些資料可以提供給 AI。
AI 工具需要足夠的上下文，才能產生較符合需求的回答。開發者在使用時，可能會貼上需求內容、程式碼、錯誤訊息、資料表結構、測試資料或客戶案例。這些內容有助於釐清問題，卻可能包含公司內部資訊、個人資料、商業機密或受合約限制的內容。
資料分級可以提供明確的判斷依據。公開資料、內部文件、受保護資料與敏感資料，應採用不同的處理方式。
公開技術文件、開源函式庫說明與一般錯誤訊息，可以作為 AI 輸入。內部架構圖、客戶資料、正式環境紀錄、交易內容與權限規則，則需要先確認使用限制。部分內容需要遮蔽，部分內容不得放進外部 AI 工具。
這項判斷若只交由個人處理，團隊成員之間容易出現認知落差。資深工程師可能熟悉高風險欄位，新進成員未必了解資料背後的限制。產品角色熟悉需求脈絡，也可能無法立即判斷哪些欄位能識別特定客戶。
團隊需要將資料使用規則整理成簡單、可查詢的準則，讓每位成員依照相同標準進行判斷。
常見資料類型可以先定義使用方式，例如程式片段是否允許貼上、Log 是否需要去識別化、測試資料能否由正式資料改寫，以及客戶名稱與訂單內容是否必須移除。規則先涵蓋使用頻率最高的情境，再依實際問題補充內容。
組織也需要檢查 AI 工具的採購條件。廠商資料訓練政策（Vendor Data Training Policy）應該被納入採購與資安審查。團隊評估工具時，需要同時確認功能適用性、廠商條款，以及輸入內容與模型產出是否會被用於模型再訓練，也就是資料退出訓練（Data Opt-out）。
組織應給出允許清單，讓成員知道哪些 AI 工具已通過組織審查，哪些工具只能用於公開資訊查詢，哪些工具不能處理工作內容。
系統中各個區域承受的風險並不相同。一般工具函式、畫面樣式、單元測試草稿與文件範例，可以由 AI 協助產生初稿。支付流程、權限判斷、資安控制、資料加密、稽核紀錄與法規相關邏輯，則需要提高人工設計與審查的比重。
AI 使用界線可以依照程式區域建立。低風險區域允許 AI 產生草稿，再由開發者整理、測試與確認。中風險區域要求開發者說明設計意圖，並補齊測試、錯誤處理與邊界條件。高風險區域應由人工主導設計，AI 可協助閱讀現有程式、整理替代方案，或產生測試案例草稿。
使用界線清楚後，審查者查看拉取請求時，可以依照變更區域決定檢查深度。變更涉及金流、權限或資料安全時，審查需要仔細確認規則來源、邊界條件與失敗處理。若變更內容只有低風險的顯示文字或文件範例，審查流程可以採用較簡化的方式。
AI 使用界線也需要納入完成定義（Definition of Done）。即使某個區域允許 AI 協助實作，團隊仍應要求自動化測試與靜態分析通過，並由開發者清楚說明關鍵邏輯。
所有變更在進入主分支前，都必須符合團隊既有的品質門檻。
提示詞常被視為臨時對話，在 AI 輔助開發中，它已經接近一種開發輸入。
提示詞可能包含需求背景、業務規則、架構限制、資料格式、錯誤訊息與驗收條件。這些內容會直接影響 AI 產出的方向與品質，因此團隊需要管理重要提示詞的來源、內容與版本。
若每位成員都只在自己的 AI 對話中累積提示詞，團隊很難知道某段程式依據哪些規則產生。
開發者可能在提示詞中加入特定假設，審查者看到的卻只有最後提交的程式碼。後續發生錯誤時，團隊也難以判斷問題出在需求理解、提示詞設計、AI 回答，或人工採用內容時的決定。
關鍵提示詞應被保留下來，特別是會反覆使用、影響產出規格，或用來生成程式與測試的提示詞。
提示詞模板可以放進文件庫或版本控制系統，記錄生成 API、測試案例、文件草稿與重構建議時需要提供的上下文，並標示禁止輸入的資料類型。
提示詞管理不需要涵蓋每一次 AI 對話。一般查詢、語法說明與錯誤訊息理解，可以維持輕量使用。
涉及需求規則、架構限制、安全要求與可重用生成流程時，提示詞就應納入團隊共同管理。個人的使用經驗經過整理後，才會變成其他成員也能採用的工作資產。
AI 參與開發後，安全風險較容易藏在看似合理的程式碼中。AI 可能產生缺少輸入驗證的 API、過度信任前端傳入資料、在錯誤處理中暴露系統細節，或在範例程式中採用不安全的預設值。
這些問題未必會立即造成執行失敗，卻可能在上線後形成系統弱點。
安全檢查需要在審查前先進入開發流程。靜態應用程式安全測試（Static Application Security Testing, SAST）、相依套件掃描、密鑰偵測、容器映像檢查與基礎設施設定檢查，可以加入持續整合（Continuous Integration, CI）流程。
明確問題先被工具攔下，審查者再確認業務邏輯、權限邊界與資料流向。
AI 產出的程式若涉及登入、授權、付款、個人資料、加密、稽核紀錄或跨系統存取，安全檢查需要採用較高標準。
這類變更應確認輸入來源、權限條件、失敗處理、資料遮蔽與日誌內容。拉取請求說明也可以標示 AI 是否參與安全相關邏輯，提醒審查者加強檢查。
安全治理可以先從基本規則開始。每次變更都要通過基本掃描，高風險區域要有明確審查條件，常見問題則回寫到提示詞限制、程式模板與完成定義中。安全要求需要出現在開發者每天會接觸的流程裡。
AI 可能根據大量公開資料產生程式碼、文件、範例與設計建議。
開發者取得可用的答案後，可能會直接套用到專案中。若生成內容接近特定開源專案的實作，或建議採用不符合公司政策的套件，就可能帶來授權風險。
授權問題不會直接反映在功能測試中。程式可以正常執行，測試也能通過，使用的函式庫卻可能限制商業用途、要求公開修改內容，或規定必須保留特定授權聲明。
團隊若沒有記錄來源，後續需要釐清某段程式、某個套件或某份文件如何進入產品時，就要投入大量時間追查。
授權檢查可以放進相依套件管理與拉取請求流程。新增套件時，需要說明使用目的、授權類型、可用替代方案，以及是否符合組織政策。
AI 建議採用新的函式庫時，開發者除了檢查使用範例，也要確認套件的維護狀態、授權條款與安全紀錄。
對於 AI 產生的大段程式碼，開發者應保留提示詞摘要、使用範圍與人工修改紀錄。這些資訊能保存內容進入產品時的判斷依據。當系統接受資安稽核、法務確認或客戶審查時，團隊才有資料說明程式、套件與文件的來源及採用過程。
合規要求若只存在於法務文件或政策頁面，開發團隊很難在日常工作中正確落實。
個人資料保護、資料保存期限、稽核紀錄、跨境資料傳輸、產業法規與客戶合約要求，都需要轉換成工程師能理解並執行的開發規則。
AI 的使用也會增加合規判斷的複雜度。開發者可能將需求、資料樣本或錯誤訊息提供給 AI，AI 也可能產生不符合資料保存、權限控管或稽核要求的實作。
合規要求缺少明確規則時，團隊只能依賴個人經驗判斷，成員之間也容易採用不同標準。
合規要求可以拆成開發流程中的檢查項目，例如哪些資料必須遮蔽、哪些操作需要留下稽核紀錄、哪些欄位不得出現在日誌、哪些資料不得提供給外部 AI 工具，以及哪些變更需要資安或法務參與審查。規則直接對應開發活動後，成員查詢與採用時就有具體依據。
合規要求也能納入測試與驗收條件。系統若需要刪除使用者資料，測試就要確認資料已被移除或匿名化。操作若需要留下稽核紀錄，驗收條件就要檢查事件內容是否完整。提示詞若不得包含特定資料，AI 使用政策也要明確記錄遮蔽與處理方式。這些要求轉成可執行規則後，才能減少臨場判斷造成的落差。
AI 使用政策若一開始涵蓋過多內容，團隊很難在日常工作中落實。
開發現場只需要幾個直接答案：哪些資料不能進入 AI？哪些程式允許 AI 協助產生？哪些變更需要額外審查？哪些輸出不得直接採用？
政策可以先針對使用頻率高、風險也高的情境建立規則。
例如禁止將正式環境資料、客戶個資、密鑰與內部合約內容輸入外部 AI 工具。涉及金流、權限、資安、稽核與個資處理的程式變更，應由人工主導設計。AI 產出的程式碼也必須通過測試、靜態分析與基本安全掃描，才能進入審查。
規則需要使用開發者能直接執行的語言。例如「注意資料保護」缺少明確判斷條件，團隊很難知道應該採取哪些動作。規則可以改寫成：「日誌含有使用者姓名、電子郵件、電話或訂單編號時，提供給 AI 前必須先遮蔽。」內容直接對應日常操作後，成員才能依照相同方式處理。
政策也需要搭配技術控管，避免出現影子 AI（Shadow AI）。影子 AI 指的是成員私下使用未經組織核准的第三方 AI 工具。這些工具的安全性、資料保存方式、隱私政策與模型訓練條款可能不夠清楚，也可能不符合組織的資安與合規要求。
團隊只發布禁止規範，仍不足以降低風險。成員在趕進度時，可能會把程式碼、錯誤訊息或需求內容貼到免費工具中，造成資料外流與權責追蹤困難。
組織需要提供經核准的 AI 工具，並搭配網路層級或端點層級的控管，例如雲端存取安全代理（Cloud Access Security Broker, CASB）、API 閘道（API Gateway）、端點防護與使用紀錄稽核，讓成員有安全可用的工具，也讓不合規的使用行為能被及早發現。
政策可以採用試行方式推動。先選擇一兩個專案或一種變更類型導入，觀察規則是否造成不必要的阻力，再依實際問題修正。
AI 使用方式與風險會隨工具、系統與團隊經驗改變，政策也需要保留調整空間，避免成為開發者選擇繞過的干擾。
拉取請求（Pull Request, PR）是團隊審查變更的重要入口，AI 使用聲明可以先放進拉取請求說明。聲明不需要太長，重點是讓審查者知道哪些內容使用了 AI，以及 AI 在這次變更中負責協助理解、產生草稿、撰寫測試，或修改正式程式碼。
AI 使用聲明可以減少審查階段的猜測。審查者知道測試案例由 AI 協助產生後，就能進一步確認測試是否符合需求規則。業務邏輯若由 AI 產生草稿，提交者需要說明規則來源、邊界條件與失敗情境。這些資訊會影響審查深度，也會標出風險較高的區域。
變更紀錄也可以保留 AI 使用脈絡。一般低風險修改，只需在拉取請求中簡單說明使用範圍。高風險修改則可以補充需求背景、關鍵提示詞摘要、人工調整內容，以及採用該方案的理由。後續維護者看到這些紀錄時，比較容易理解當時的變更依據。
這項做法也能提醒開發者保留判斷責任。當團隊要求拉取請求需要說明 AI 的參與範圍，提交者就必須先讀懂生成內容，完成整理與驗證，再交由團隊審查。
提示詞在 AI 輔助開發中，已經接近一種開發規格。它會描述需求背景、系統限制、輸出格式、測試條件與架構規則。
若某個提示詞會反覆用於產生 API、測試案例、文件草稿、資料轉換邏輯或重構建議，就不適合只留在個人對話紀錄中。
關鍵提示詞可以放進文件庫或版本控制系統，並補上使用說明。內容可以包含適用情境、必要上下文、禁止輸入的資料類型、預期輸出格式，以及產出後需要執行的檢查。
新成員使用 AI 時，可以依照既有內容操作，敏感資料被誤放進提示詞的風險也會降低。
版本管理能讓提示詞的變更被團隊看見。當某個提示詞反覆產生錯誤測試、忽略權限條件，或生成不符合架構慣例的程式碼時，就應修改內容並記錄調整原因。
後續有人遇到相同問題時，可以從修改紀錄看出當時的背景與處理方式。
提示詞管理不必涵蓋每一次臨時查詢。查詢語法、理解錯誤訊息與整理小段文字，可以維持輕量使用。
會影響正式交付、被多次重用，或引導 AI 產生程式與測試的提示詞，則需要納入共同管理範圍。管理對象界定清楚後，治理成本才不會失控。
AI 使用政策發布後，仍需要定期回顧。工具能力、團隊熟悉度、專案風險與公司要求都會改變，原本合適的規則經過一段時間後，可能失去原有作用。
定期回顧能協助團隊確認哪些規則有效、哪些規則阻礙開發流程，以及近期出現了哪些新風險。
回顧可以放進既有工作節奏，例如每月工程例會、自省會議（Retrospective），或資安與架構檢查會議。
討論應聚焦在實際案例：哪一次 AI 產出造成返工？哪一次審查發現未揭露的 AI 生成內容？哪一類提示詞容易產生錯誤？哪些安全掃描規則經常被跳過？
回顧結果需要轉成具體調整。團隊若發現 AI 經常漏掉授權檢查，就可以把新增套件的授權確認加入拉取請求模板。AI 若產生不符合架構慣例的程式碼，就更新提示詞模板與程式範例。高風險區域的審查壓力過高時，也可以縮小變更範圍，並重新安排審查人員。
AI 治理需要透過小規則、可追蹤紀錄與固定回顧落實。政策提供使用方向，拉取請求、測試、安全掃描、文件管理與日常討論則負責執行。
AI 使用能被看見、檢查與修正後，團隊才有條件在加快產出的同時維持系統可控。
iThome鐵人賽
看影片追技術