金融業 AI-Driven CTI 論文閱讀分析：真正卡住落地的，往往不是模型不夠強，而是整個信任與治理鏈根本還沒補齊

論文基本資訊

• 論文標題：Security Barriers to Trustworthy AI-Driven Cyber Threat Intelligence in Finance: Evidence from Practitioners
• 作者：Irdin Pekaric 等
• 年份：2026
• 來源：arXiv:2603.23304
• 論文連結：https://arxiv.org/abs/2603.23304
• 主題：CTI、Financial Security、AI Governance、Operational Trust、Adversarial Risk、SOC

如果最近這波 sectools.tw 的主線，一路都在問「LLM / agent 到底能不能進 SOC、CTI、IR 這些真實工作流」，那這篇 Security Barriers to Trustworthy AI-Driven Cyber Threat Intelligence in Finance 剛好把問題拉回更殘酷、也更接近現場的那一層：不是 AI 看起來能不能幫忙，而是金融機構到底憑什麼敢把它放進去。

這篇論文很值得寫，因為它不是再做一個新模型或 benchmark，而是直接對準一個常被 hype 蓋掉的事實：AI-driven CTI 的落地障礙，很多時候根本不是模型分數，而是治理、整合、信任與可稽核性。 對金融業這種高監管、高責任、高攻擊壓力的場域來說，這些東西如果沒補齊，再強的模型也很難真正進 production。

這篇論文想解決什麼問題？

作者的出發點很明確。金融機構面對的不是抽象的 AI adoption 問題，而是很具體的資安現實：

• 攻擊壓力高，CTI 對 detection、response、strategic planning 都很重要
• 監管要求重，任何自動化判斷都得能被解釋、被追查、被審計
• 營運流程複雜，AI 就算能產出答案，也未必接得進既有 workflow
• 若 AI 自身成為攻擊面，風險不只是不準，而是會變成新的治理責任

因此，這篇 paper 真正要回答的不是「AI 能不能強化 CTI」，而是：

在金融機構裡，哪些 socio-technical barriers 正在阻止 AI-driven CTI 變成一個可信、可治理、可正式部署的能力？

方法：這不是單點案例，而是 practitioner-centric 的混合研究

這篇研究採用的是 mixed-methods 路線，而且很明顯不是只看論文、不看現場。作者把方法拆成三塊：

• systematic literature review：篩了 330 篇 2019–2025 的文獻，最後保留 12 篇與 finance CTI 真正相關的研究
• semi-structured interviews：做了 6 場訪談
• exploratory survey：收到來自銀行與顧問公司的 14 份回覆

這個設計的價值很高，因為它讓論文不會只停在「研究界說 AI 很有前景」，而是真的把研究、現場採用經驗、以及實務顧慮疊在一起看。對 CTI 這種高度流程化、又高度依賴 analyst judgment 的工作來說，這比單看 benchmark 分數有意義得多。

作者找到的四個反覆出現的 failure modes

整篇論文最值得記住的，是它整理出的 四種 recurrent socio-technical failure modes。這四條幾乎可以直接當成現在很多企業導入 AI security tooling 的照妖鏡。

1. Shadow use：員工自己偷偷用公有 AI，繞過制度

第一個 failure mode 是 shadow use of public AI tools outside institutional controls。白話一點，就是分析師或相關人員明明有工作需求，但組織內部沒把受控工具、資料邊界與使用政策整理好，於是大家開始直接拿公開 AI 服務處理 CTI 任務。

這件事危險的地方不只是資料外流，而是：

• 輸入內容可能帶有敏感 threat data、內部事件資訊或客戶脈絡
• 組織無法保證資料 retention、後續再利用或訓練去向
• AI 的回答被拿來影響分析判斷，但沒有正式留痕與稽核鏈
• 真正的風險不是「有人違規」，而是工作需求已經逼著大家繞過制度

這種現象其實很真實。很多組織不是不知道要治理，而是治理速度永遠慢於使用衝動。對金融業來說，shadow AI 幾乎等於把 CTI 工作流裡最需要受控的那段，直接搬到制度外面。

2. License-first enablement：先買授權，再假裝它已經算整合

第二個 failure mode 很刺，但非常準：license-first enablement without operational integration。也就是組織買了 AI 工具、開了帳號、甚至宣布「我們開始導入 AI」，但實際上：

• 沒有把它接進 CTI / SOC 的既有流程
• 沒有定義哪些步驟可以用、哪些不可以
• 沒有把輸出接到 ticket、case、evidence 或 review chain
• 沒有建立 analyst 如何驗證與覆核 AI 結果的標準

這類導入的最大問題，就是它很容易把 AI 變成一個「看起來有在用、其實不進主流程」的邊緣工具。短期內這也許很安全，因為它還碰不到真正高風險任務；但長期看，這會讓組織卡在一個很尷尬的位置：買了、試了、展示了，卻沒有形成可信的 operational capability。

3. Attacker-perception gap：只從 defender 視角想，沒把 adversary 想進來

第三個 failure mode 是 attacker-perception gaps that limit adversarial threat modeling。這點我很喜歡，因為它提醒的是一個常見盲區：很多團隊在導入 AI 做 CTI 時，只問它能不能摘要、分類、關聯、加速工作，卻沒真的把攻擊者視角放進 threat model。

結果就是：

• 把 AI 當 productivity layer，而不是新的 attack surface
• 低估 prompt injection、data poisoning、manipulated OSINT、對抗樣本等風險
• 沒有針對 hostile input、deception、misdirection 做正式演練
• 以為 AI 是「用來看 threat 的工具」，忘了它自己也會被 threat 利用

這對 CTI 特別致命。因為 CTI 本來就大量吃外部資料：報告、論壇、新聞、IOC feed、社群情報。只要 ingestion 邊界沒想清楚，AI 在這裡很容易不是加速器，而是擴大器。

4. AI model security 缺位：模型本身幾乎沒被當成要被保護的系統

第四個 failure mode 是我覺得最關鍵的一個：missing security for the AI models themselves。作者點名的不是抽象風險，而是很實際的缺口：

• 缺少持續監控
• 缺少 robustness evaluation
• 缺少 audit-ready evidence
• 沒有把模型行為本身納入 assurance 流程

換句話說，很多組織在問「AI 能不能幫我們做 CTI」，卻沒有同步問「這個 AI 自己要怎麼被監控、驗證與舉證」。這會直接導致一個問題：當 AI 出錯時，組織往往沒有足夠證據說明它為什麼做出那個判斷、是否受到對抗性輸入影響、以及類似錯誤會不會再發生。

Survey 數字透露了什麼？

論文裡有幾個數字很值得直接記下來：

• 71.4% 的受訪者認為 AI 會在五年內成為核心能力
• 57.1% 表示目前仍然不常使用，主因是可解釋性與 assurance concerns
• 28.6% 表示已經直接遇過 adversarial risks

這組數字放在一起看，其實很有張力：大家普遍相信 AI 會變重要，但當下真正阻止它進主流程的，不是大家不想用，而是大家還不敢信。 這個「信」也不是情緒問題，而是非常具體的工程與治理問題：解釋、保證、監控、審計、對抗風險。

這篇論文真正重要的地方：把 adoption 問題重新翻成 security 問題

我認為這篇 paper 最值得肯定的地方，在於它沒有把 adoption failure 歸因成「文化保守」或「使用者抗拒改變」。它比較誠實地指出：很多 adoption friction 其實是合理的 security friction。

也就是說，當分析師質疑 AI 結論、當治理單位不願直接放行、當組織只敢做小規模試用，這未必是落後，而可能是因為下面幾件事本來就沒做好：

• evidence chain 不完整
• adversarial evaluation 不足
• integration 設計不成熟
• 責任邊界與審計能力不清楚

這個 framing 很重要。因為它把「為什麼大家還不敢大用 AI-CTI」從模糊的 adoption 話術，拉回成可以被工程化、被治理化的 security backlog。

作者提出的三個 operational safeguards

根據研究結果，作者最後提煉出三個 security-oriented operational safeguards。雖然摘要沒有把每一條展開成完整實作細節，但主線很清楚：要讓 AI-driven CTI 在金融場景裡變得可信，就不能只管模型輸出品質，而是要補三種能力：

• 受控使用與治理邊界：避免 shadow AI，把資料與工具拉回 institutional control
• 真正接進 workflow 的 operational design：讓 AI 不只是拿來試，而是有明確 evidence、review、handoff 與 escalation 位置
• 把模型本身納入 security assurance：持續監控、對抗評估、可審計證據都要補上

如果用更白話的方式總結，就是：別把 AI 當成會自己長出信任的黑盒功能；你得把它當成一個需要治理、監測、驗證與接流程的高風險新系統。

這篇論文的限制

它當然不是沒有侷限。至少有幾點閱讀時要保留：

• 樣本規模不算大，尤其訪談 6 人、問卷 14 份，本質上還是 exploratory
• 它主要是 practitioner evidence 與 barrier analysis，不是大規模實驗 benchmark
• 重點在 finance，雖然很多結論可外推，但監管強度與責任邊界可能與其他產業不同

但即便如此，這篇的價值還是很高。因為現在缺的往往不是第 N 個 benchmark，而是這種把「為什麼還沒真正上線」講清楚的研究。

重點整理

• 這篇研究不是再做模型，而是在分析 AI-driven CTI 在金融業為何難以被可信部署。
• 方法結合了 330 篇文獻篩選、12 篇 finance-relevant studies、6 場訪談、14 份問卷。
• 作者整理出四個核心 failure modes：shadow use、license-first enablement、attacker-perception gap、AI model security 缺位。
• 71.4% 受訪者認為 AI 五年內會成為核心能力，但 57.1% 目前仍少用，主因是 interpretability 與 assurance concerns。
• 28.6% 已直接遇過 adversarial risks，代表風險不是理論問題。
• 這篇論文最重要的訊息是：AI-CTI 的落地瓶頸，很多其實是 security 與 governance 問題，而不只是模型能力問題。

Takeaway

如果要用一句話收尾，我會這樣總結：

金融業不是不想把 AI 用進 CTI，而是這條線一旦真的要進 production，組織需要的就不再只是「看起來很聰明」的模型，而是能被控管、能被追責、能被對抗測試、也能真正接進安全營運流程的系統。

這也是這篇 paper 最有價值的地方：它把 AI-CTI 的問題，從功能想像拉回成可信部署。

免責聲明

本文由 AI 協助整理與撰寫，內容主要依據公開論文摘要與可取得之研究資訊進行彙整、解讀與摘要。雖已盡力確保內容可讀與準確，仍可能因資料可得性、摘要資訊限制或模型理解偏差而存在疏漏；實際方法細節與正式結論，仍應以原始論文與作者公開版本為準。