SEAP
AI 只負責判斷，每個判斷都附證據，權限和執行交給一般程式控制。
我們只讀系統 log、不錄螢幕，找出可以自動化的工作。AI 只負責判斷，權限和執行都交給一般程式控制。
SEAP 接 ERP、CRM、ITSM 的事件，做正規化和案例關聯，再用 process mining 找模式，用 LLM 推導業務目的。
每個推論都是結構化輸出，附證據和不確定性。證據不夠就回 insufficient_evidence，不硬猜。
不錄螢幕，不在 PoC 階段碰正式系統，也不執行 AI 產生的程式碼。
收尾問一句：你們的系統事件，現在有集中收在哪裡嗎？
傳統導入是一次一個專案，SEAP 是持續運作的迴圈
| 階段 | 傳統導入 | SEAP |
|---|---|---|
| 找需求 | 等人提出；沒人提的工作就一直靠人工 | 從跨系統事件主動發現，附證據與預期效益 |
| 盤點流程 | 顧問訪談、觀察作業，靠受訪者的記憶 | 從事件還原實際流程與變體，推導業務目的 |
| 設計與開發 | 人畫流程圖、寫規則與例外 | AI 產生結構化流程定義，未確認的規則標記出來 |
| 測試 | 人寫測試案例為主 | 自動產生正常、異常、權限不足、中斷、重複觸發等情境 |
| 上線決策 | 人工核准，每條流程都要排會議 | 依風險政策：低風險自動放行，高風險送人核准 |
| 成功判定 | 程式跑完、沒報錯 | 業務狀態真的改變，例如訂單建立、帳務對上 |
| 維護改善 | 系統改版就壞，再開維護單 | 分析失敗原因，提出新版本，回歸測試後發布；舊版可回復 |
| 人的角色 | 發現、設計、開發、維護 | 設定目標、政策、授權範圍，處理重要例外 |
SEAP 欄是產品目標。Phase 1 PoC 只驗證「發現」到「業務審查」；產生流程與自動測試在 Phase 2，依政策部署與自我修復在 Phase 3。
四個平面，責任分離
AI Planning
理解工作、推導目的、提出流程與改善。
Execution
依結構化規格執行、重試、管理狀態。
Governance
獨立判斷操作是否符合政策。
Evidence
保存觀測、驗證與稽核證據。
MVP 元件（Phase 1）
| Application Server | Rust。API、授權、資料管理、審核、任務協調 |
| Discovery Worker | Rust。事件正規化、關聯、Process Mining、意圖推論、機會評估 |
| AI Gateway | Rust library，內嵌於 Worker。模型路由、Schema 驗證、成本上限、推論紀錄 |
| Outbox Publisher／Job Sweeper | 資料庫 outbox 送入佇列，回收逾時工作 |
| 儲存 | PostgreSQL、Redis |
| 契約 | contracts/ 為 Rust 與前端 TypeScript 共用的唯一來源 |
LLM 不做它不擅長的事
確定性處理
格式驗證、時間排序、去重、已知物件關聯、指標計算、權限判斷。
統計／Process Mining
活動模式、流程變體、重複性、異常偵測。
LLM 推論
業務目的推導、語意摘要、機會解釋、不確定事項辨識。
模型輸出契約
每個推論輸出 JSON：Result Type、Model Version、Input References、Outcome（supported／insufficient_evidence）、Hypothesis、Supporting Evidence、Missing Information、Uncertainty。
通過 Schema 不代表推論正確。另外做證據檢查與獨立評估。證據不足時系統必須拒答，不得把推測寫成事實。
模型可替換（AP-005 Provider Independence）。依資料分級限制可用模型，支援地端模型。
只要事件紀錄，不錄螢幕
每筆事件需要的欄位
- Timestamp、Source System
- Activity
- Actor ID（可去識別化）
- Case ID（有則更好）
- Business Object ID、Attributes
- Source Reference
缺 Case ID 時以推論關聯，或標為無法判定。時間相近不視為同一工作。
PoC 建議規模
- 3 個業務場景
- 每場景 ≥ 100 個可辨識案例
- ≥ 30 天紀錄
- ≥ 20 個經獨立審查的候選或反例
接入方式：每個來源寫一份 Mapping Profile，約 1–2 小時。
不可信資料不能跨進有控制權的邊界
身分與授權
OIDC／OAuth 2.0；RBAC 為基礎，ABAC 處理租戶、來源、部門、資料分類。授權一律在伺服器端判斷。
租戶隔離
查詢、背景工作、物件儲存、快取、佇列、AI 上下文、稽核全部帶 Tenant Context。不信任 Request Body 的租戶識別。
提示注入防護
區分可信系統指令與不可信工作資料。事件內容不能改寫執行權限。參照 OWASP Agentic AI 指引。
稽核
來源授權變更、資料存取、Discovery 執行、AI 推論版本、審查決策、政策拒絕、管理操作全部記錄。
定義 7 條信任邊界：企業系統 → Ingestion、外部資料 → 正規化事件、工作資料 → AI、AI 輸出 → 持久資料、UI → API、AI Planner → Policy Engine、Policy Engine → Execution。
用凍結測試集與基準方案說話
Opportunity Precision
Opportunity Recall
Intent Accuracy
證據可追溯
- 資料分成 Development、Validation、Held-out Test。測試集只在最終驗收跑一次。
- Discovery 執行前，客戶先封存 Expectation Register（雜湊）。之後由兩名審查者獨立標註 Ground Truth，不一致時裁決。
- 新增機會另做盲審，避免審查者因為是 AI 提出而偏高評分。
- 基準：頻率法、規則法、PM4Py Inductive／Heuristics Miner、LLM-only，以及一套商用流程挖掘產品。
已經有這些產品，為什麼還要選 SEAP
| 對手 | 它的強項 | 選 SEAP 的理由 | 什麼情況該選它 |
|---|---|---|---|
| ServiceNow AI Agent Advisor | 已上線：掃描紀錄 → 排序機會 → 產生 agent | 資料來源跨供應商，不限單一平台；依風險政策放行，不是人工按鈕；驗證業務結果 | 主要流程都在 ServiceNow 裡，而且內建功能已經夠用 |
| UiPath Task／Process Mining | 發現、產生、執行、編排的完整產品線；Automation discovery（2026-09 預覽版）已能從訊息、email、業務系統產出排序的自動化 backlog | 查不到驗證業務結果與依風險自動放行；SEAP 補上這兩段，執行可以交給 UiPath | 已有 UiPath 授權與 RPA 團隊，缺的是執行量 |
| Microsoft Power Platform | M365 客戶可能不另外付費 | 沒有找到從挖掘結果自動產生 agent 的功能；SEAP 可私有部署，資料不出境 | 全公司都在 M365 上，可以接受 SaaS |
| Celonis | ERP 流程挖掘的深度 | Celonis 只供給流程資料給其他 agent 平台；SEAP 從事件推導業務目的、排好順序，再產生流程 | 主要需求是 ERP 流程分析與 KPI 監測 |
| 桌面錄製類 Skan、Mimica、Worktrace 等 | 大量真實操作資料、募資快 | SEAP 只用系統事件與稽核日誌，不錄螢幕，員工隱私與工會阻力小 | 工作大多在沒有 log 的桌面程式裡 |
不錄螢幕
只用系統本來就有的紀錄。
不綁平台
ERP、CRM、ITSM 來自哪家都能接，執行層用現有工具。
可私有部署
可以裝在客戶自己的機房，資料不出去。
競品資料截至 2026-11-02 公開資料，來源與可信度見 SEAP-MKT-001。SEAP 欄是產品目標，PoC 前尚未實測。
先講清楚：什麼情況不該選我們
選 UiPath 或 ServiceNow
- 主要流程都在 ServiceNow 裡，內建功能已經夠用
- 已經有 RPA 團隊和 UiPath 授權，缺的是執行量，不是發現
- 現在就要上線，需要 SLA、在地支援與成功案例
- 已經請顧問或內部團隊盤點好，該做的清單也排好了
SEAP 值得試
- 沒人有空盤點，不知道該先自動化什麼
- 流程多到人工逐條核准跟不上，需要依風險政策放行
- ERP、CRM、ITSM 來自多家廠商，單一平台看不到全貌
- 法規或內部政策要求私有部署、資料不出境
成熟度風險
PoC 期間只讀取授權資料，不碰正式系統。失敗也不影響營運。
效果不確定
業務窗口先封存預期清單，結果由您的專家判定，並和商用產品用同一份資料比較。
被綁住
產出是結構化流程定義，執行層用您自己的工具。