涵蓋完整流程的指南
如何在受監管企業中開發軟體
協助人們用 AI 建立原型。授予真實資料或 API 存取前，先驗證安全，再依企業要求交付與維運軟體。
簡要答案
提供時間、工具選擇、合成資料，以及從有用原型走向持續維護服務的途徑。授予真實 API 存取或機密資訊前，驗證應用程式、平台和資料流。使用內部平台或軟體工廠，連結安全交付、法遵證據和維運。在整個生命週期保留明確責任歸屬。
協助更多人把想法變成軟體
CTO 可以邀請組織各部門用 AI 建立原型。財務團隊了解核准流程的問題，營運團隊了解重複人工作業。提供時間與工具，讓他們展示更好的流程。
在安裝、帳戶和允許輸入都有明確規則的前提下，允許使用不同工具探索。提供合成資料集、沙盒 API 和實際協助。人們應有清楚途徑，在不連接正式環境系統的情況下展示價值。
接著定義下一個決定：應用程式收到機密資訊、真實 API 權限或正式環境流量前，必須驗證什麼？讓建立原型的人也能理解這條途徑。
原型需要真實存取權時，什麼會改變？
能運作的功能只是服務的一部分。組織還必須說明誰能使用、如何處理資料，以及如何復原。發布後，這些責任仍會持續。
適用要求取決於服務、產業、司法管轄區、契約和資料。請負責法務、隱私與資安的專業人員辨識。開發框架或供應商認證，不能證明特定服務已符合法規。
以下步驟提供工程流程，用來連結要求、決定和證據。NIST SSDF提供能支持既有 SDLC 的安全開發實務，但不能取代適用義務的辨識。
1. 將有用原型轉成服務說明
請建立者描述問題、展示流程，並記錄使用者學到什麼。讓建立者繼續以領域專家身分參與。技術評估與持續維運，則交給承擔這些責任的團隊。
寫下使用者任務、預期結果和失敗後果。指定產品負責人、服務負責人、資安聯絡人，以及有權接受剩餘風險的人。議定誰能停止發布。
例如，客戶資料匯出需要的不只是下載按鈕。定義誰能匯出哪些紀錄、用途是什麼，以及保留多久。指出誰調查未授權匯出。這是虛構範例。
應保留的證據： 服務說明、責任分工，以及核准的驗收條件。
2. 授予資料或 API 存取前，先驗證邊界
辨識機密資訊、個人資料、存取憑證和其他受限材料。畫出提示詞、檢索上下文、記錄檔與生成輸出的去向。檢查選定服務的保留、訓練、存取和區域處理條款。
探索想法時，使用合成或核准測試資料。原型成功，不代表提供者可以處理正式環境資料。逐一檢查提供者與部署設定。
星期二建立的虛構銀行儀表板，使用虛構交易時可能運作良好。唯讀帳戶存取仍可能暴露機密紀錄，付款權限則可能增加財務後果。啟用連線前，驗證實際範圍、存取憑證處理、授權和失敗行為。練習銀行原型範例。
審查必須在第一次敏感輸入或真實服務連線之前進行。把應用程式稱為原型，不會減少它已持有的權限。
只授予代理程式任務所需的工具與權限。將儲存庫檔案和檢索文件視為不可信輸入。機密值不要放入提示詞。
應保留的證據： 資料流圖、提供者評估和權限政策。
3. 提供受支援的正式環境交付途徑
將服務納入組織的身分、網路、記錄和部署控制。定義受支援環境，以及以程式碼管理的基礎架構。容器與資料庫，不能構成完整維運環境。
政策要求使用自己的基礎架構時，驗證部署確實進入自有雲端帳戶或網路。分開檢查執行期控制，以及開發與模型資料流。在自己的帳戶代管，不代表符合法規，也不代表每個 AI 請求都留在該帳戶內。
受支援途徑可以使用內部平台、軟體工廠，或兩者搭配。定義各方為驗證、部署、弱點修補和維運提供什麼。原型可能需要修改或替換程式碼，才能使用這條途徑。
議定可接受的中斷時間與資料損失，也就是 RTO 和 RPO。依目標選擇可用性與復原機制。Multi-AZ、多區域和備份，處理不同故障情境。測試完整復原流程，包括相依服務與還原資料。
應保留的證據： 架構決策紀錄、環境定義和實測復原結果。
4. 依可驗證需求建置小型變更
提供開發者或代理程式清楚任務與驗收條件。將需求連結到實作、測試和審查。控制變更規模，讓人可以檢查。
測試前定義安全要求。OWASP ASVS提供應用程式安全驗證要求。選擇相關要求並記錄範圍。只有掃描結果，不能驗證應用程式行為。
同時測試拒絕操作與成功操作。在匯出範例中，驗證未授權使用者無法請求另一個客戶的紀錄。
應保留的證據： 需求、變更差異、測試結果和審查決定。
繼續閱讀將測試作為證據與審查 AI 生成程式碼。
5. 讓發布決定可重現
從已審查的修訂版本建置可識別產物。記錄目標環境、設定、必要檢查、剩餘風險和發布決定。在需要之前，先測試版本回復或復原方法。
決定何時需要人工授權。保留例外的負責人、理由、範圍和到期日。不要將已核准例外，當成永久政策變更。
應保留的證據： 產物身分、發布紀錄、核准或政策決定，以及版本回復指示。
6. 部署後持續維護軟體
掃描相依項目與已部署元件，檢查新揭露的弱點。沒有新程式碼 commit，服務也可能出現弱點風險。為每項發現的問題指定負責人與修補決定。
驗證修正、部署它，並確認執行中版本。記錄已接受風險，條件改變時再次審查。把原型當成完成產品時，這項持續工作經常形成缺口。
應保留的證據： 元件清單、掃描日期、分類處理決定、修補變更和部署驗證。
依持續弱點管理流程操作。
7. 維運、應變與改善
監控有用服務結果、故障和資安訊號。議定事件角色、升級途徑，以及 SOC 與 SIRT 的責任，再演練這些安排。
NIST 資安框架將風險管理連結到治理、保護、偵測、應變和復原。定義維運模式時，採用這種生命週期觀點。
將事件與反覆問題轉成已審查變更。自動復原只限於已授權、可驗證且有停止條件的操作。自動重啟，不代表原始缺陷已修正。
應保留的證據： 服務衡量、事件紀錄、復原結果，以及經驗證的改善變更。
探索事件管理與有明確邊界的自動復原。
8. 決定哪些責任要自建或採購
依相同要求，比較內部平台、程式設計助手和 AI 軟體工廠。詢問誰執行每項任務、有哪些證據，以及哪些仍是自己的責任。納入維護、復原、整合和退出成本。
人們可以保留偏好的探索工具，同時由組織維護共同的正式環境交付途徑。檢查哪些程式碼、規格和測試能在工具間移轉。要求展示部署到必要基礎架構，以及完整維護流程。
Taiga 發布治理資訊與共同責任說明。將它們視為一家供應商的資料，對照自己的要求評估。本學習網站由 Taiga 發布，這些連結不是獨立背書。
從責任比較開始。Taiga 學習路徑接著說明，這些問題如何對應具體產品流程。
常見問題
可以在受監管企業使用 vibe coding 嗎？
可以。在明確組織邊界內，提供合成資料、沙盒 API 與工具選擇。讓人們測試想法，並將有用原型帶入受支援的交付途徑。授予機密資料或真實系統權限前，就要驗證控制，即使還沒正式上線。請看vibe coding：用途與限制。
AI 生成程式碼需要不同驗收條件嗎？
必要行為與風險控制仍然適用。AI 增加了上下文、資料處理、權限和輸出可靠性的問題。無論由誰或什麼工具產生，都要審查實際變更與證據。
應先準備什麼？
準備含合成資料的探索環境，並指定下一步的聯絡人。原型有用後，記錄目的、預定資料、負責人、要求和復原目標。擴大存取前，使用軟體生命週期練習，找出缺少的決定。