Trust Center
Trust Center
資料治理與資安保證
資料最小化 · 權限分層 · 版本封存 · 可追溯留痕
以金融機構治理規範為準
信任聲明
我們以資料最小化、權限分層、版本封存與可追溯留痕為核心原則，協助金融機構把氣候財務風險揭露做成可運行、可回放、可被採信的交付能力。
我們不提供法律意見與法定確信/審計服務；相關服務由具資格且具獨立性的專業提供者執行。
Trust Center 四大支柱
資料安全
加密
- ▸傳輸加密：TLS 1.3，確保資料在傳輸過程中安全
- ▸儲存加密：AES-256，敏感資料靜態加密
備份與復原
- ▸備份頻率：依客戶政策，建議每日自動備份
- ▸復原機制：版本封存點可隨時回溯
資料最小化
僅賀集與處理必要資料，優先採用最小範圍完成交付骨架，避免早期接觸敏感系統。
權限管理
RBAC 模型
- ▸角色分層：檢視 / 編輯 / 審核 / 核准
- ▸最小權限原則：Need-to-know，僅授予必要權限
- ▸權限矩陣：清楚定義「誰該做什麼」
存取控制
- ▸身分驗證：支援 SSO、多因素認證（MFA）
- ▸存取日誌：記錄所有重要操作，可審計
- ▸重要動作授權：版本封存、輸出發布需二次確認
版本控制
雙軌版本策略
- ▸運行態（Operating View）：近即時更新，用於監控與預警
- ▸封帳態（Reporting View）：按月/季封存，用於揭露與確信
版本封存機制
- ▸版本號：YYYY-QX-vX.X 語意化版本
- ▸封存內容：完整資料集、運算環境、參數配置
- ▸不可變性：封存後禁止修改，任何調整需建立新版本
變更管理
當有假設或方法論更新時，建立新版本並保留舊版，變更摘要清楚記錄「改了什麼、為什麼改」。
稽核軌跡
留痕機制
留痕的目的不是監控個人，而是讓交付可回放、責任可追溯。
- ▸操作日誌：重要資料/假設的新增與更新（含時間與人）
- ▸變更追蹤：版本封存與核准（含理由或變更摘要）
- ▸完整性證明：重要輸出的發布（誰發布、何時、對應版本）
證據路徑索引
每個關鍵敘述/數字，都能對回「來源、版本、責任、位置」。把「找得到」升級成「說得清楚」。
稽核支援
- ▸季度交付包給董事會/管理層審閱
- ▸證據路徑索引給稽核/內控抽查
- ▸版本封存點確保同一把尺同一份交付
常見問題
Q:你們是 SaaS 還是可以部署在我方環境？▸
A: 兩種皆可依合作模式調整：低摩擦模式（用公開版工具包與回放資源，不接敏感系統）、企業模式（可配合你方治理要求，採用你方指定的資料存放與存取方式）。我們的原則是：資料處理方式以金融機構既有資安與資料治理規範為準。
Q:你們會不會拿到我們的客戶資料、交易資料或授信明細？▸
A: 不一定，也不鼓勵在早期就碰敏感資料。我們優先採用最小化原則：先用最小範圍完成「I/O（輸入輸出）＋版本封存＋證據路徑索引」的交付骨架；若需要更深的運算與整合，才在明確授權與治理下擴充。
Q:資料是誰的？你們會拿去訓練模型或二次利用嗎？▸
A: 資料所有權與使用權以合約約定為準；原則上：資料歸客戶所有、未經授權不做二次利用、不以客戶資料作為對外公開或案例內容（除非客戶明確同意）。
Q:權限如何管理？能不能做到分層與最小權限？▸
A: 可以。我們把權限視為治理底座：角色分層（例如：檢視/編輯/審核/核准）、最小權限（need-to-know）、重要動作需授權（例如版本封存、輸出發布）。重點不是「誰都能做」，而是「誰該做什麼、誰負責什麼」清楚可追溯。
Q:你們怎麼做「版本治理」？避免口徑漂移？▸
A: 我們採用「雙軌版本」原則：運行態（Operating View）近即時/高頻更新用於監控與預警、封帳態（Reporting View）按月/季封存版本用於對外揭露審閱與確信準備。每個封存版本都應具備：版本號、封存日期、變更摘要、核准角色。
Q:什麼叫「留痕（Audit Trail）」？你們會留哪些痕？▸
A: 留痕的目的不是監控個人，而是讓交付可回放、責任可追溯。常見留痕範圍包括：重要資料/假設的新增與更新（含時間與人）、版本封存與核准（含理由或變更摘要）、重要輸出的發布（誰發布、何時、對應版本）。留痕內容會依客戶政策與權限設定而定。
Q:資安層面：有沒有基本控制與做法？▸
A: 我們建議（也會配合客戶要求）至少具備：身分驗證與權限分層、重要動作核准/二次確認、版本封存與變更紀錄、存取紀錄（log）與異常追蹤、資料最小化與目的限定。具體控制項會依合作模式、部署方式與客戶政策調整。