金融機構的 AI 治理閘道

每一次 AI 呼叫,
都寫入可查驗的稽核紀錄。

FinAI Gateway 位於既有應用與模型之間。換一個 endpoint,就能統一管理模型存取、敏感資料處置與稽核紀錄,並產出可交付內稽與主管機關的證據包。

  • OpenAI、Claude 相容
  • 可部署於企業機房
  • 敏感資料即時處置
Lychee FinAI Gateway 管理主控台總覽,顯示今日請求、政策違規、敏感資料事件與趨勢
req_01J9...7M2假名化
Requestedfinancial-safeActualinternal-gemma敏感資料2 個欄位
  • 既有應用與工具照常運作
  • 政策先判定,資料才送出
  • 成功、擋下、錯誤都留一筆證據

Why now

AI 接得上線之後,
接著要管清楚誰在用、資料送去哪裡。

每個應用各管一套

金鑰、log 與敏感資料防護規則(Data Loss Prevention,DLP)分散在不同系統,團隊需要花時間彙整完整紀錄。

每筆資料流向都該看得見

資料送出前,團隊能確認目標模型、實際模型供應商,以及當下套用的政策。

稽核證據需要集中管理

稽核來時,團隊得花時間整理分散在各系統裡的 AI 使用紀錄。

One governed entry point

所有 AI 應用改走同一個入口,模型端維持原設定。

Gateway 在內容送出前,依固定順序完成身分、權限、敏感資料防護與政策判定;接著把請求送往核准的模型,並寫入一筆稽核事件。

Same workflow

換一個 endpoint,既有流程照常跑。

OpenAI 與 Claude 相容的應用可沿用原本的 SDK 與程式流程。PoC 先接入一個內部應用,確認政策、延遲與稽核結果,再依驗證成果規劃正式導入範圍。

  • base URL 與 API key 兩個參數改完,即刻納入治理。
  • 每次回應都附上請求編號與政策處置結果,方便追蹤及查驗。
  • 內部自建應用、Claude Code、Codex CLI 等可自訂 API endpoint 的工具皆可逐步接入。
app.py只有這兩個參數變了
from openai import OpenAI

client = OpenAI(
  base_url="https://gateway.bank.internal/v1",
  api_key="fk-..."
)

response = client.chat.completions.create(
  model="financial-safe",
  messages=messages,
  stream=True
)

Policy in action

同一句含個資的提問,四個部門得到四種結果。

每個部門可以採用不同處置。Gateway 依情境改送本地模型、直接封鎖、先遮罩,或換成能維持語意關係的替身。

研究部政策:要求 public-gpt,實際路由至 internal-gemma。 畫面採用情境範例資料。

Structured pseudonymization

假名化保留格式與關係,模型可以照常工作。

Gateway 以單向 HMAC 產生穩定的格式化替身,整個運算在 Gateway 內完成。同一位客戶在多輪對話中會維持同一個代號。

遮罩

遮罩把敏感內容換成固定字元

A12******9

兩筆身分證都會呈現成 A12******9,模型會把它們視為相同字串。

假名化

格式繼續可用,真值留在 Gateway 內

A123456789 → F232745108

替身通過檢核碼,同一個值也會固定對應同一個替身。模型因此能理解欄位與多輪關係,真值則留在 Gateway 的安全邊界內。

系統支援身分證、卡號、帳號、電話與 Email 等有格式資料;PoC 會依使用情境確認其他資料類型與處置規則。

Verifiable evidence

AI 使用紀錄,一鍵匯出證據包。

每筆成功、擋下與錯誤請求都會寫入一筆稽核事件,再以 SHA-256 串成單一鏈。驗證時直接比對 hash chain,內容全程維持加密;匯出的 zip 內含摘要、事件明細、鏈驗證結果與檔案 manifest。

內容維持加密,照樣驗證完整性

重算整條或指定區間的 hash chain,直接顯示斷點。

一份可交付的證據包

繁中 PDF、CSV、JSON、驗證結果與 SHA-256 manifest。

管理者能讀,稽核者能查

摘要與機器可讀明細放在同一份交付物中。

畫面中的 81,486 筆事件與統計數字為情境範例,用於說明產品流程。

Operations console

AI 使用狀況與資料流向,一頁看完。

資訊、法遵與稽核用同一個主控台查看營運狀態、搜尋請求、檢視完整交易並掌握用量與延遲。

營運總覽,畫面採用情境範例資料。

Governed data asset

每筆稽核紀錄,都是未來整理自有資料集的起點。

每筆對話依組織、部門、應用、模型與政策結果結構化留存。原始與實際送出的去識別版本並存,未來評估自有模型與微調需求時,可以直接從整理好的紀錄開始。

資料的選取、使用與保存方式,可依企業內部資料治理規範設定。

Deployment & security

部署在企業指定環境,資料流向由團隊掌握。

支援企業機房、專屬雲端或混合環境;部署位置、模型連線、憑證、內容保存與稽核權限都能配合資安規範設定。

彈性部署架構

可部署於企業機房、專屬雲端或混合環境,配合既有網路與資安架構。

資料流向可控

每筆 AI 請求依政策前往核准的模型服務,流向與處置結果都有紀錄可查。

模型金鑰集中管理

上游模型金鑰集中設定,管理畫面與系統紀錄會遮蔽敏感資訊。

內容加密保存

提問與回覆以 AES-GCM 加密保存,稽核驗證期間維持加密狀態。

管理與應用介面分離

管理主控台使用登入驗證;應用端維持標準 API key 與 OpenAI、Claude 相容介面。

支援主流企業資料庫

支援 Microsoft SQL Server(MSSQL)、Oracle 等主流資料庫,配合既有維運與備援規範。

Start with one application

先從一個內部 AI 應用開始 PoC。

選擇最需要治理的場景,使用真實流程驗證政策、延遲與稽核成果,再依評估結果規劃正式導入。

研究部 · 改送

外部模型使用

命中敏感內容時自動改送核准的本地模型。

客服部 · 擋下

客戶資料邊界

違規請求即時擋下,回應直接指出違反的政策。

財富管理 · 遮罩

雲端模型遮罩

有格式敏感欄位遮罩後才允許送往雲端。

授信部 · 假名化

報告假名化

保留欄位格式與對話關係,真值則留在 Gateway 內。

PoC 導入流程

先用真實場景完成 PoC,再規劃正式導入。

PoC(概念驗證)會選定一個內部 AI 應用,使用實際流程驗證治理效果,讓導入決策建立在可查驗的成果上。

01

確認場景與驗收標準

一起選定應用、模型、資料邊界與政策需求,訂出 PoC 的範圍與驗收方式。

02

使用真實流程驗證

完成 Gateway 串接,實際驗證敏感資料處置、模型路由、效能與稽核證據。

03

依成果規劃正式導入

整理驗證成果與導入建議,再確認正式專案的應用範圍、環境與推行順序。

FAQ

導入前最常被問的問題。

已有 Azure OpenAI,Gateway 負責哪一層?

Azure OpenAI 負責模型服務。FinAI Gateway 負責身分、資料與政策,並記下每次呼叫的實際流向,方便後續查證。

應用端要改多少程式?

更換 base URL 與 API key 即可。既有 SDK 可直接沿用,串流與一般回應也維持相同格式。

現有 AI 工具怎麼接?

支援自訂 OpenAI 或 Claude 相容 API endpoint 的工具,可沿用原本介面。Claude Code、Codex CLI 與其他開發工具都能依團隊需求逐步接入。

支援哪些模型與供應商?

支援 OpenAI、Azure OpenAI、Anthropic Claude,以及 OpenAI 相容的本地模型服務(例如 Ollama,可承載 Gemma、Llama 或 Mistral)。

資料會傳去哪裡?

每筆請求依政策送往核准的模型服務。Gateway 可部署在企業機房,使用資料與遙測都留在部署端;原始與處置後內容則加密保存在自己的 Audit Vault。

遮罩與假名化差在哪裡?

遮罩把敏感內容換成固定字元,模型看到的是相同字串。假名化則換成同格式、可通過檢核的穩定替身,讓模型保留理解與推理所需的結構。

留下來的對話可以拿來訓練自己的模型嗎?

原始與去識別版本會結構化保存在企業環境,可依內部資料治理規範整理為模型評估、微調或知識應用的資料基礎。

PoC 怎麼進行?

先選定一個內部 AI 應用,確認部署環境、模型供應商、敏感資料規則與驗收標準;接著使用真實情境完成串接與驗證,再依成果規劃正式導入範圍。

從一個內部 AI 場景開始 PoC。

帶上預計接入的應用、模型與資料邊界,我們會一起確認 PoC 範圍、執行方式與驗收標準。