SOC 導入 LLM 論文閱讀分析：很多團隊真正缺的不是更強模型，而是別再拿分析師當導入實驗品
論文基本資訊
- 論文標題：A Sociotechnical, Practitioner-Centered Approach to Technology Adoption in Cybersecurity Operations: An LLM Case
- 作者：Francis Hahn、Mohd Mamoon、Alexandru G. Bardas、Michael Collins、Daniel Lende、Xinming Ou、S. Raj Rajagopalan
- 年份：2026
- 來源：arXiv:2604.21679
- 論文連結：https://arxiv.org/abs/2604.21679
- 主題：SOC、LLM Adoption、Sociotechnical Security、Human-AI Collaboration、Security Operations、Trust Calibration
很多 SOC 對 AI 真正卡住的，常常不是模型不夠強，而是它根本還沒被做成一個值得信任、能塞進既有流程、又不會把值班分析師逼瘋的工具。
這也是我覺得這篇論文最有意思的地方。它不是再拿幾個 benchmark 說 GPT-4 幫 analyst 節省幾分鐘，也不是再做一個「自動化 SOC copilot」demo 就算交差。作者直接進到一家跨國企業的 SOC 裡，做了 6 個月 embedded ethnography，跟分析師一起看工作怎麼做、卡在哪、為什麼不信任新工具，然後再一起共創出真正有人願意持續使用的 LLM companion tools。
這篇真正想講的不是「LLM 能不能做 SOC」，而是：如果你不先處理 trust、workflow fit、可解釋性與組織現實，那再強的模型也只會變成下一個被 SOC 放著積灰塵的玩具。
這篇論文想解決什麼？
資安圈其實很熟這個場景：新工具 demo 時都很厲害，真的進 SOC 之後卻常常卡死。論文把問題點得很準：
- SOC 對新技術本來就保守，因為值班環境高壓、容錯低，任何 workflow disruption 都可能直接傷到 incident handling；
- LLM 的不穩定性會放大這種保守，像 hallucination、答案不一致、脈絡理解偏差，都會讓 analyst 很難把它當成可靠工具；
- 很多研究和產品都從技術能力出發，不是從 analyst 的工作現實出發，所以最後做出來的東西常常脫離現場；
- 工具若不能嵌進既有流程，即使偶爾有用，也很難活成 daily routine。
所以作者的核心 framing 很清楚：LLM adoption 在 SOC 不是單純 model performance 問題，而是 sociotechnical integration 問題。你要讓它被採用，就不能只優化 prompt 或準確率，還得處理信任、部署型態、任務邊界、解釋方式，以及 analyst 到底願不願意把它放進自己的判斷流程裡。
研究方法很少見：不是問卷，不是 lab study，而是真的進 SOC 裡待半年
這篇最值得記住的，是它的方法論比很多「AI for SOC」論文都更接近真實世界。作者把兩位 PhD researcher 嵌進一家大型商業組織的 SOC，持續 6 個月 做參與式觀察、shadowing、討論、工具共創與迭代部署。
這不是站在外面訪談兩次就算 ethnography。研究者真的去理解 analyst 平常怎麼查資料、怎麼在分散平台間跳來跳去、怎麼處理重複工作、怎麼看待新工具的風險，然後再把那些觀察回灌成工具設計。
論文把這個流程放進 Nonaka 的 SECI 模型 去解釋：
- Socialization：先透過嵌入現場理解 tacit knowledge；
- Externalization：把 analyst 說不清楚但每天都在承受的痛點講清楚；
- Combination：把這些痛點正式做成工具；
- Internalization：讓工具真的回到 analyst 日常流程，變成被吸收的工作習慣。
我很買單這個框架，因為很多 SOC AI 產品真正失敗的地方，就是只做了第三步：直接 Combination，跳過前面的現場理解，也跳過後面的信任內化。
作者觀察到的痛點，其實都非常 SOC
雖然這篇不是 benchmark paper，但它整理出的 operational pain points 非常有代表性。作者在 fieldwork 中反覆看到幾種問題：
- 重複性高的工作太多：很多分析流程不是高深推理，而是重複整理、查找、轉換格式、補上下文；
- 資料分散而且不夠清楚：要做判斷往往得在多個系統、平台與資料來源之間來回切換；
- 現有 tooling 有 bottleneck：不是沒有工具，而是工具之間常常斷裂，讓 analyst 得自己補流程；
- 高壓環境下，誰都不想接一個會突然胡說八道的新系統。
這點很重要，因為它提醒我們：很多 SOC 場景真正需要的，可能不是一個會自己做決策的 autonomous agent，而是能在 analyst 已有 workflow 裡，把碎裂、重複、低價值摩擦降下來的 companion tool。
這篇不是在推 fully autonomous AI，而是在推 trust-calibrated companion tools
論文中的 LLM 系統被定位成 companion tools，不是直接接管分析師判斷的 autonomous SOC agent。這個定位非常關鍵。
因為在真實 SOC 裡，很多人要的不是「AI 幫我決定」，而是：
- 幫我更快理解現在看到的東西；
- 幫我把零碎資訊串起來；
- 幫我減少那些明明不難、但超耗精神的整理工作；
- 最好還能讓我看得懂它在幹嘛，而不是丟一個神諭式答案給我。
作者的 ethnographic 結論也支持這點：adoption 不是從「模型很強」開始，而是從 analyst 願意在低風險任務上先試、先驗、再慢慢把信任往上加。這種 trust calibration 的節奏，比很多產品簡報裡那種「copilot revolution」誠實得多。
真正讓 adoption 發生的，不是模型本身，而是共創與持續迭代
論文最核心的發現之一，是 analyst 的態度會從懷疑轉向持續使用，但前提不是單次展示，而是反覆共創、反覆修正、反覆降低 disruption。
作者明講，隨著 iterative refinement，工具逐步變得：
- 更符合 analyst 的操作節奏；
- 更容易解釋與驗證；
- 更少破壞既有 workflow；
- 更像是 analyst 的延伸，而不是額外負擔。
這裡我覺得最有價值的，不是某個模型設定，而是一個很少被產品團隊認真接受的事實：
在 SOC 裡，AI adoption 不是把功能推出去就結束，而是要靠現場共同磨出「怎樣才算可用、可信、可插進流程」。
也就是說，真正的 moat 可能不是模型 API，而是你有沒有能力跟使用者一起把工具磨到不惹人厭。
這篇其實也在批評傳統 SOC 技術導入方式
作者不只是在講 LLM，也是在借 LLM 把一個更老的問題攤開：很多 SOC 技術之所以採用緩慢，不是單一產品做不好，而是整個導入邏輯長期都太 technology-first。
論文把傳統 adoption barrier 歸納成幾類：
- workflow misalignment：工具邏輯和 analyst 實際工作流不一致；
- rigidity：威脅、需求、內部流程會變，但工具很僵；
- stagnation over time：導入時看起來能用，之後卻跟不上實務演變；
- 缺少 trust-building mechanism：大家只看到功能，沒看到如何驗證與校準信任。
這些問題其實不只適用於 LLM，對 XAI、SOAR、規則引擎、alert triage 平台也都成立。只是 LLM 把這些裂縫放大得更明顯，因為它的錯誤形式更難預測、也更容易讓人瞬間失去信心。
這篇對今天 AI 安全圈有個很實際的提醒：別只談 capability，要談 deployability
現在很多「AI for cyber」研究的毛病，是太喜歡問模型能不能完成某任務，卻不太問：
- 分析師敢不敢用？
- 出錯時誰來兜？
- 它是不是又多造一層 verification burden？
- 部署環境是否符合資料保護和組織限制？
- 它到底是在省時間，還是在重排工作負擔？
這篇的價值就在於，它把討論從 capability 拉回 deployability。很多論文愛講 autonomous SOC、agentic defense、self-healing workflow，但真實世界更常見的問題是：就算模型答得不差，只要 analyst 要花更多力氣驗它，它就還不算有用。
侷限也很明確：這篇不是大規模量化證明，而是深描一個真實案例
當然，這篇不是沒有侷限。
- 它主要是一個單一組織、單一 SOC 場域的深入個案；
- 重點是 ethnographic insight 與 adoption process，不是大規模 benchmark；
- 論文給我們的是可遷移的設計原則，不是可以直接抄表操課的 universal recipe；
- 它證明的是「共創式導入有機會成功」，不是「所有 SOC 都該立刻導入 LLM」。
但老實說，我反而覺得這種侷限很健康。因為 SOC 真的是高度情境化的組織系統，本來就很難期待一篇 paper 給你跨公司通吃的答案。
我自己的看法：這篇最值得抄的不是工具，而是態度
如果你今天是 vendor、研究者，或是在企業內部想推 AI SOC 工具的人，這篇最值得學的並不是某個 prompt pattern，而是這個基本態度：
不要一開始就問「AI 能替 analyst 做多少」；先問「哪些地方 analyst 願意讓 AI 參一手，而且不會讓整條流程變得更難活」。
這種做法聽起來沒那麼性感，但更像真的能活下來的路。尤其在資安環境裡，工具若不能被 trust-calibrate、不能被逐步吸收到 routine、不能被 analyst 快速驗證，那它再先進也只會停在簡報裡。
Takeaway
如果要把這篇濃縮成一句話，我會這樣講：
很多 SOC AI 真正缺的，不是更會答題的模型，而是一套能跟分析師一起長出來的導入方法；這篇論文的重點，就是把 LLM adoption 從「技術能力問題」重新定義成「信任、流程與組織現實的整合問題」。
對在看 SOC、LLM security tooling、human-in-the-loop automation、或 AI adoption governance 的人，這篇很值得讀。它不會讓你對 autonomous SOC 更樂觀，但會讓你更清楚：真正在現場活下來的 AI，通常不是最會表演的那個，而是最懂怎麼不打斷人工作的那個。
本文由 AI 產生、整理與撰寫。