Security Alert Triage Agent 的需求文件只有兩頁。

第一頁最上面寫著：

Goal
Use AI to improve security alert triage efficiency and reduce SOC workload.

下面接著列出 Success Criteria：十秒內回覆、正確率超過 95%、Critical Miss 為零、每筆成本低於 0.05 美元、結論可解釋、可完全自主運作，六週內上線。

平台主管把文件投到會議室的大螢幕上。

「需求應該算滿清楚了吧？」

Security Team 點頭。Platform Team 也沒有意見。FinOps 看了一眼成本數字，說五分美金可以。

每一條都合理。Security Alert 當然要快，當然不能判錯；大量事件不能把成本燒掉；如果 AI 要做決定，最好能說明理由；既然目的是減少 SOC 工作量，最好自己處理完。

問題直到第三週才出現。

工程團隊帶來三個版本，而且每一個都說自己更符合需求。

最快的版本，Security 不敢用

Platform Team 先做完第一版。他們用較小的模型，限制 Context，只讀取 Alert 本身和最近五分鐘的 Log。

平均回覆 3.8 秒，單筆成本 0.021 美元。數字比文件要求還漂亮。

Security Engineer 卻拿了一筆真實案例測試。Alert 顯示的是 repeated authentication failure；只看當下，很像一般密碼輸入錯誤。

但同一個帳號兩小時前才從另一個國家成功登入，再往前還有一筆 MFA Reset。這些 Evidence 都不在五分鐘的範圍內。

Agent 最後給出：

Severity: Low
Recommended Action: Monitor

Security Engineer 看著螢幕問：「所以為了十秒，我們把前面的 Evidence 拿掉了？」

平台主管回答，Context 拉長之後，Latency 和 Cost 都會上去。

沒有人做錯。文件確實寫著十秒和五分美金。

最準的版本，不能完全自主

Security Team 做了另一版。它會查更長時間的 Authentication History、User Risk、Device Record 與近期 Case；資料不足時，還會要求補查。

Critical Alert 的判斷穩定得多，但平均處理時間變成四十多秒，成本超過原先兩倍。更麻煩的是，有些案例它不願意直接下結論。

Severity: Uncertain
Reason: Insufficient endpoint evidence
Required: Endpoint telemetry review

平台主管問：「這樣不是還是要人工？」

Security Engineer 說：「因為這筆本來就沒有足夠 Evidence。」

「可是 Requirement 是 Fully Autonomous。」

「那你要它猜嗎？」

會議停了一下。

第三版什麼都有，只是不能六週上線

另一組工程師試圖把兩邊都留下來：小模型先分類，高風險事件再進大型模型；必要時自動調 Tool 抓完整 Evidence，所有結論保留 Source，成本則用 Cache 控制。

架構圖很好看。接著也多出新權限、Tool Integration、Audit Log、模型 Routing 測試，以及一個 Data Source 的 Rate Limit。

估算交付時間是 12 到 14 週。

平台主管看著原本的六週上線，問：「有沒有辦法先做簡單一點？」

Security Team 反問：「簡單哪一個？」

沒有人知道。需求寫了每一件想要的事，卻沒有寫這些要求衝突時，哪一件可以讓。

「全部都要」不是設計資訊

AI 專案很容易把速度、正確、成本、自主性、可解釋性與安全性分別量化。看起來比一般 IT 專案具體，卻仍不足以讓工程團隊做決定。

真正的設計問題出現在條件碰撞時。更多 Context 可能提高判斷品質，也會增加 Latency 與 Cost；更高的自主性可以減少人工 Touch，但資料不足時，也意味著系統要承擔更多錯誤風險；要求完整 Evidence 會增加處理步驟，而六週上線又限制可完成的 Integration。

因此，這些不是六個可以各自打勾的 Checkbox。真正需要被寫下來的是：

當它們不能同時最大化時，我們先保哪一個？

對 Security Alert Triage 來說，95% 的平均正確率也不夠。把 Low Alert 判成 High，代價可能只是多一次調查；把真正的 Critical Incident 判成 Low，代價則是讓攻擊繼續存在。

分數相同，營運結果完全不同。

這不是模型選型問題。組織得先決定，自己真正要買的是什麼服務。

他們把需求縮成一張 Service Profile

專案沒有重寫十頁 Requirement，也沒有新建一套 Quality Framework。團隊只把原本散在文件裡的承諾重新排了一次：

Service: Security Alert Triage
Primary Quality: Minimize Critical Miss
Secondary Quality: Evidence Traceability
Latency: Target under 60 seconds
Cost: Optimize after quality target is met
Autonomy: Not a primary objective
Acceptable Sacrifice: higher false-positive rate; longer response time for high-risk cases
Fallback: insufficient evidence → stop automated decision

十秒變成六十秒；Fully Autonomous 不再是 Launch Requirement。

不是團隊突然不在乎效率。而是在這個 Use Case 裡，最貴的錯誤不是多等三十秒，也不是多讓 Analyst 看一筆 Case，而是把真正需要處理的 Incident 安靜地放過去。

優先順序寫出來後，原本吵不完的技術問題反而變簡單。High-risk Case 可以慢一點、查得完整一些；Low-risk Event 可以走較便宜的路徑；資料不足時，Agent 不必假裝知道答案。

六週後，那支 Agent 還是上線了

Launch Review 前一天，平台主管重新打開最初那份 Requirement。

其中大部分文字還在，只是不再被當成同一層級的承諾。

上線版本平均回應二十七秒。有些 Case 仍會停下來交給 Analyst，單筆成本也比第一個 Prototype 高。

但 Security Team 願意把它接進正式 Alert Queue。

Launch Checklist 最後一頁，「Fully Autonomous」被主管劃掉。下面那一行「Production Launch: Friday 22:00」，反而第一次沒有再往後延。