定義資料可以流向哪裡

分開看兩條資料流

Vibe coding 很適合用虛構紀錄探索工作流程。真實公司資訊進入工具時，風險就會改變；這可能發生在應用程式還沒有任何使用者之前。

需要檢查兩條資料流。開發資料流包括提示詞、儲存庫上下文、附件、工具輸出和診斷記錄檔。應用程式資料流則包括使用者請求、資料庫、整合、遙測和備份。兩者可能有不同接收方與控制措施。

以虛構費用應用程式為例。資料庫在核准的雲端帳戶執行。開發者為了修正剖析器，把真實報銷申請貼到助手中，內容含員工姓名、收據和銀行資訊。資料庫位置獲准，不代表這次另行揭露也獲得許可。

檢查完整路徑

加入機密資料前，先畫出路徑，指出每一步實際使用的服務與帳戶。「企業版」這類產品標籤，不是資料流圖。

記錄適用契約和設定。相關時，檢查次處理者、刪除行為、訓練條款與國際傳輸。請負責隱私與資安的人員處理不確定事項。

GDPR 要求取決於處理情境。相關規定包括資料最小化、處理者安排、安全和影響評估。公司保密也涵蓋非個人資料，例如原始碼或商業計畫。閱讀法規。

先建立有用的虛構測試資料

安全範例仍需要符合實際的結構。替換姓名、識別碼和帳號，同時保留造成缺陷的條件，例如缺少欄位、特殊日期或很長的描述。

不要只改一個姓名，就把從正式環境複製的紀錄稱為「合成資料」。其餘欄位仍可能識別個人或揭露交易。應根據資料結構描述和失敗條件，建立全新紀錄。

不要把存取憑證放進提示詞或測試資料。如果任務需要機密值，使用核准且存取受限的機制。「請保密」這類指令，無法落實技術邊界。

先驗證，再擴大用途

寫一份簡短的允許使用決定，包括資料類別、核准服務設定、允許操作和負責人，並加上到期日或複查觸發條件。新增連接器、模型路徑或記錄設定，可能改變原本決定。

資訊到達未核准接收方時，停止進一步揭露，並遵循事件處理流程。記錄分享了什麼，以及流向哪裡，避免把敏感材料複製到更多工單或對話。

實際目標是受控使用。虛構資料支持快速探索；已驗證的處理邊界，則支持下一步進入公司工作流程。精緻展示或雲端區域，都無法回答所有必要問題。