AI 日誌架構

AI 系統日誌應擷取什麼——提示詞、補全、延遲、符元、工具呼叫——以及儲存策略、保留政策與隱私考量。

為何 AI 日誌與眾不同

AI 系統日誌超越傳統應用日誌。在標準 Web 應用中,您記錄 HTTP 請求、回應與錯誤。在 AI 應用中,「請求」是可能含有敏感資訊的細緻自然語言提示詞,「回應」則是可能含 PII、幻覺內容或安全違規的生成文字。AI 日誌的內容在本質上與傳統應用日誌不同,這改變了擷取、儲存與處理它們的一切方式。

應擷取什麼

核心互動資料

每次 AI 互動都應擷取下列欄位:

護欄決策資料

工具呼叫資料

對代理式系統而言,工具呼叫需詳細記錄:

檢索資料 (RAG 系統)

日誌架構

架構模式:雙重管線

建議架構使用兩條並行管線——一條用於即時營運資料,一條用於完整對話記錄:

┌─────────────────┐
│  AI Application  │
└────────┬────────┘
         │
    ┌────┴────┐
    │         │
    ▼         ▼
┌────────┐ ┌──────────────┐
│ Real-  │ │ Full Content │
│ time   │ │ Pipeline     │
│Pipeline│ │              │
│        │ │ Prompts +    │
│Metrics,│ │ Completions  │
│Counts, │ │ + Tool Calls │
│Latency │ │              │
│        │ │ ┌──────────┐ │
│        │ │ │PII Redact│ │
│        │ │ └────┬─────┘ │
│        │ │      │       │
└───┬────┘ └──────┼───────┘
    │             │
    ▼             ▼
┌────────┐  ┌──────────┐
│Metrics │  │Encrypted │
│Store   │  │Log Store │
│(Prom.) │  │(S3/GCS)  │
└────────┘  └──────────┘

即時管線

即時管線擷取可低延遲查詢的結構化指標:

• 時間序列資料庫 (Prometheus、InfluxDB、Datadog) 存放數值指標
• 串流處理器 (Kafka、Kinesis) 進行即時模式偵測
• 告警引擎 (Alertmanager、PagerDuty) 提供即時通知
• 保留期:全解析度 30-90 天、聚合後 1 年

完整內容管線

內容管線擷取互動的完整文字,供鑑識調查使用:

• 前處理:儲存前進行 PII 偵測與可選之遮蔽
• 加密:所有對話資料在儲存與傳輸中皆加密
• 存取控制:對話內容採嚴格的角色為基礎存取控制
• 保留期:依政策,通常為 30 天至 7 年,視法規要求而定

儲存策略

分層儲存

運用儲存層在成本與存取速度間取得平衡:

結構描述設計

設計日誌結構時應考量可查詢性。AI 安全調查中的常見查詢模式:

-- Find all interactions where the guardrail was triggered
-- but the user eventually received a response
SELECT request_id, user_id, user_prompt, completion
FROM ai_interactions
WHERE guardrail_triggered = true
  AND response_delivered = true
  AND timestamp > NOW() - INTERVAL '7 days';
 
-- Find users with unusually high refusal rates
-- (may indicate active jailbreak attempts)
SELECT user_id,
       COUNT(*) as total_requests,
       SUM(CASE WHEN finish_reason = 'content_filter' THEN 1 ELSE 0 END) as filtered,
       ROUND(100.0 * SUM(CASE WHEN finish_reason = 'content_filter' THEN 1 ELSE 0 END)
             / COUNT(*), 2) as filter_rate
FROM ai_interactions
WHERE timestamp > NOW() - INTERVAL '24 hours'
GROUP BY user_id
HAVING filter_rate > 20
ORDER BY filter_rate DESC;

隱私考量

AI 日誌之所以獨特敏感,是因為包含人與 AI 系統完整對話文字。隱私處理並非可選——它是法律與倫理上的要求。

資料分類

PII 處理策略

1. 1

   儲存前偵測 PII

   對所有提示詞與補全,在進入內容管線前執行 PII 偵測 (NER + 正則表達式)。對含 PII 的互動加註以強化處理。

2. 2

   決定:遮蔽、假名化或保留

   依資料處理政策,選擇遮蔽 PII (以 [REDACTED] 取代)、假名化 (以一致的假值取代) 或強化存取控制後保留。

3. 3

   加密並限制存取

   所有對話日誌靜態加密。實作嚴格的角色為基礎存取控制。存取對話內容須提供理由 (break-glass 程序)。

4. 4

   稽核存取

   記錄對對話內容的所有存取,包含誰存取、何時、為何 (理由),以及檢視了什麼。

法規要求

用於事件回應的日誌

當安全事件發生時,您的日誌必須在數分鐘內回答下列問題:

1. 發生了什麼? —— 對抗性互動的完整文字
2. 何時發生? —— 精確時間戳
3. 誰做的? —— 使用者識別與認證細節
4. 如何繞過控制? —— 護欄決策與分數
5. 衝擊為何? —— 曝光了哪些資料或生成了哪些有害內容
6. 是否仍在進行? —— 是否有其他使用者呈現類似模式

事件回應查詢

為常見事件類型建立預寫查詢:

• 系統提示詞萃取:搜尋含已知系統提示詞片段的補全
• PII 洩露:搜尋被 PII 偵測標記的補全
• 越獄活動:依使用者、時間窗、技術彙總護欄觸發模式
• 工具濫用:搜尋異常工具呼叫模式 (非預期工具、高風險引數)
• 資料外洩:搜尋具高輸出符元計數與萃取相關模式的互動

應避免的反模式

相關主題

• AI 監控與可觀測性 —— 更廣泛的監控脈絡
• 異常偵測 —— 在日誌資料中偵測模式
• 執行時監控 —— 將監控作為安全控制
• 安全 AI 開發生命週期 —— 日誌在開發生命週期中的位置

參考資料

• "Logging and Monitoring for ML Systems" - Google SRE (2024) —— 生產 ML 系統日誌與監控實務的完整指引
• "Privacy-Preserving Machine Learning Logging" - Tramèr et al. (2024) —— 記錄 ML 系統行為同時最小化隱私衝擊的技術研究
• "GDPR Compliance for AI Systems" - European Data Protection Board (2025) —— 將 GDPR 要求套用至 AI 系統 (含資料記錄與保留) 之指引
• "Building Secure and Observable LLM Applications" - OWASP (2025) —— 以安全為核心之 LLM 應用日誌與可觀測性指引