合規唔應該再係「人肉翻文件工程」

每次客戶 send security questionnaire、ISO 要內審、GDPR 要 readiness review，你公司係咪都出現呢種情況？

• IT、HR、Ops 一齊翻文件
• 不停問：「呢段有冇寫？證據喺邊？」
• 改完 policy 又要再對一次條款

你唔係冇做合規，而係：

你冇一條可重複、可追溯、可自動化嘅合規檢查流程。

真正消耗時間嘅唔係寫幾段說明，而係：

• 對照條款
• 搵證據
• 列缺口
• 保持文件一致性
• 重複做相同嘅檢查

而家用 AI + RAG + Rule Engine，可以將「文件地獄」變成一條可運行 workflow：

文件上傳 → 自動解析 → 對照 GDPR / ISO / ESG → 標示 Gap → 輸出 Dashboard 報告

今篇會完整拆解：

• 系統架構設計
• 技術堆疊比較
• Rule-based vs LLM 分工原則
• 私隱與風險提醒
• 可直接複製使用嘅 Prompt Template

讀完你可以即刻砌 MVP。

一、完整系統架構設計

整體流程可以拆成 7 層。

1️⃣ 文件上傳層（Upload Layer）

目標：

• 統一入口
• 控制權限
• 保存版本

支援格式：

• PDF
• DOCX
• SOP
• 合約
• Evidence 截圖或紀錄

關鍵設計：

• 文件分類（Policy / SOP / Contract / Evidence）
• 版本號（v1.0, v1.1）
• Owner 標記
• 敏感級別（Internal / Restricted）

如果冇 metadata，後面全部會亂。

2️⃣ Parsing Layer（解析層）

將文件轉成可搜尋、可引用、可切分嘅結構化文本。

必要功能：

• OCR（處理掃描 PDF）
• 標題層級解析
• 語意 chunk 切分（唔好固定 500 token）
• 保留頁碼與段落 ID

建議輸出格式：

chunk_id
source
page
section
text
metadata


如果冇 citation，你唔應該俾 LLM 做合規判斷。

3️⃣ Vector Database（語意搜尋層）

用於支援 RAG（Retrieval Augmented Generation）。

常見選擇：

Pinecone

• 託管型
• 高穩定
• 易擴展

Weaviate

• 開源
• 可自建
• 功能多

Supabase Vector（pgvector）

• 成本低
• 易整合 Postgres
• 易做審計 log

中小團隊做 MVP，Supabase 通常已經夠用。

4️⃣ RAG Query Flow

流程如下：

1. 將某條 GDPR / ISO / ESG 要求轉成 query
2. 去向量庫抓 top-k chunks
3. 將 evidence + citation 傳給 LLM
4. 限制 LLM 只能基於 evidence 回答

目標係減少幻覺，而唔係完全消滅。

5️⃣ Rule Engine（硬規則層）

適合處理：

• 是否包含特定章節
• 是否寫明資料保留期
• 是否列出 incident 通報時限
• 是否存在 access review 記錄

優點：

• 穩定
• 成本低
• 一致性高

Rule Engine 應該優先於 LLM。

6️⃣ LLM 分析層

LLM 適合處理：

• 條款精神是否被滿足
• 文件之間是否矛盾
• 風險敘述
• 整改建議

重要原則：

LLM 只可基於 evidence 回答。

輸出必須為 JSON。

7️⃣ Dashboard 報告層

輸出包括：

• 合規評分
• Gap 列表
• 風險等級
• 證據引用
• 文件版本比較

真正有價值唔係分數，而係「優先處理順序」。

二、技術堆疊比較

OpenAI Embeddings vs BGE

OpenAI

• 穩定
• 多語言強
• 快速部署
• 需考慮資料上雲

BGE（本地部署）

• 可 on-prem
• 私隱控制佳
• 需自行維護

如果文件極度敏感，優先 on-prem embeddings。

n8n vs Make

n8n

• 開源
• 可內網部署
• 適合企業治理

Make

• 易上手
• MVP 快速搭建
• SaaS 為主

要快試 → Make
要可控治理 → n8n

Rule-based vs LLM 分工

任務類型Rule EngineLLM必填章節檢查✅❌條款精神判斷❌✅文件矛盾分析❌✅欄位格式驗證✅❌

黃金原則：

Rule engine 管一致性，LLM 管語意判斷。

三、風險與合規聲明

1️⃣ LLM 不能代替法律意見

• 系統應定位為自查工具
• 最終審批需法律顧問或 DPO

2️⃣ Data Privacy 注意事項

• TLS 傳輸加密
• Encryption at rest
• RBAC 權限控制
• 審計 log

3️⃣ 內部文件加密建議

• KMS 管理金鑰
• Tenant 分 key
• PII tokenization
• 最小權限原則

四、可直接複製使用 Prompt Template

以下 Prompt 可直接 Copy 使用。

✅ Gap Detection Prompt

你係合規分析員。
你只可以根據我提供嘅 evidence 判斷，不可以推測或使用外部知識。

目標：
對照「Requirement」，檢測公司文件是否覆蓋到該要求，
並列出所有缺口（gaps）。

如果 evidence 不足，請標記 insufficient_evidence=true。

Requirement:
<貼入 GDPR / ISO / ESG 某條要求文本>

Evidence:
- [chunk_id: xxx | source: 文件名 | page: P | text: "..."]
- [chunk_id: xxx | source: 文件名 | page: P | text: "..."]

請輸出 JSON：

{
 "covered": true/false,
 "insufficient_evidence": true/false,
 "gaps": [
   {
     "gap": "...",
     "risk_level": "low/medium/high",
     "why": "...",
     "missing_evidence": "..."
   }
 ],
 "supporting_citations": ["chunk_id:..."]
}


✅ Compliance Scoring Prompt

你係審計前自查工具。
請根據 evidence 對 control 進行 0-5 評分：

0 = 完全沒有
1 = 有提及但無流程
2 = 有流程但無證據
3 = 有證據但唔一致
4 = 完善但可改進
5 = 完善並持續監控

Control:
<control 描述>

Evidence:
- [chunk_id: xxx | text: "..."]

輸出 JSON：

{
 "score_0_to_5": 0,
 "score_reason": "...",
 "what_to_improve_next": ["...", "..."],
 "supporting_citations": ["chunk_id:..."],
 "confidence_0_to_1": 0.0
}


✅ Risk Explanation Prompt

你係風險顧問。
請用商業語言解釋如果唔整改會帶來什麼風險，
並提供可落地整改步驟。

只可以引用 evidence。
如果 evidence 不足，必須說明。

Issue:
<gap 描述>

Evidence:
- [chunk_id: xxx | text: "..."]

輸出 JSON：

{
 "risk_story": "...",
 "likely_impact": ["法規風險","客戶審查風險","營運風險"],
 "recommended_actions": [
   {
     "action": "...",
     "owner_role": "...",
     "effort": "S/M/L",
     "expected_days": 0
   }
 ],
 "supporting_citations": ["chunk_id:..."]
}


五、如何由 0 開始砌 MVP

建議順序：

1. 先選 20 條最常被問 control
2. 完成 Parsing + Citation 系統
3. 建立 Rule Engine
4. 加入 RAG + LLM 判斷
5. 輸出簡單表格報告

唔好一開始做完整 ISO 全套。

結論

AI 合規自動化唔係為咗取代人，而係：

• 加快檢查
• 統一格式
• 減少重複
• 提升可追溯性

如果你設計好：

Rule Engine + RAG + LLM 分工清晰，

你就可以由「翻文件地獄」變成「可重複流程」。