```
AI adoption in security operations has effectively reached saturation: 40% of security teams use it every day, 56% are testing it, and just 4% have no plans at all. Those figures come from a survey of more than 250 CISOs, SOC leaders and practitioners run by AI security operations vendor Prophet Security, whose findings were reported by The Hacker News on 2 November 2026.
The number worth pausing over is not the adoption figure but the 4%. With 96% of teams somewhere on the adoption path, the conversation has shifted from "should we?" to "are we ready?" — and for the 56% still running trials, the candid answer is frequently no.
Adoption is not readiness
The 40/56/4 split measures intent and usage, not capability. Pilots rarely surface the failure modes that appear once an AI agent is working against production telemetry, ticketing systems or response playbooks. Those problems tend to emerge mid-incident, when the cost of an unexplained output is highest.
Readiness splits into two halves, and they fail differently.
Technical readiness asks whether the SOC's data foundations can carry an agent: telemetry coverage across endpoint, network, identity and cloud sources; integration depth with SIEM, EDR, identity providers and ticketing; and signal hygiene — whether alerts and logs are clean enough that a model's summaries and enrichments rest on anything trustworthy.
Organisational readiness is the half that routinely gets skipped. It covers decision rights: a written escalation contract defining what the system may act on alone, what needs human approval, and what is permanently out of bounds. It covers auditability — inputs, outputs and human overrides logged from day one rather than retrofitted later. It covers analyst trust, and it covers having a named, accountable owner responsible for evaluating AI output instead of an unowned tool sitting between the alert and the analyst.
Licences address only the first half. The second is where incidents expose gaps.
Three actions for teams still testing
For the 56% cohort, architectural choices made during pilots have a habit of quietly becoming permanent. Three steps are worth taking now:
- Pick one high-volume workflow — triage summarisation or alert enrichment are the usual candidates — and measure it against a baseline agreed in advance, before the tool is switched on.
- Write the escalation contract. What can the system do unattended, what needs a human sign-off, and what is off-limits entirely. If it is not written down, it does not exist during an incident.
- Instrument the deployment: accuracy, override rates and time-to-decision. Teams that cannot report those numbers are measuring enthusiasm rather than performance — and cannot defend the investment internally when budget season arrives.
Relevance for regulated environments
This section offers general context, not a specific regulatory requirement. Security teams at banks and financial institutions operate under comparatively demanding expectations around control evidence and accountability, which makes the organisational half of the readiness check particularly consequential. The controls that satisfy an auditor — logged decisions, named owners, documented override paths — are the same controls that make an AI agent operable under stress. Teams that build them during pilots avoid rebuilding them under audit.
The window
The 4% of teams with no plans are now the outliers. For everyone else, readiness — not adoption — is the differentiator. The window to set those foundations is while pilots are still in flight, not after an agent has been wired into production systems.
Source: Prophet Security's "State of AI in Security Operations 2026" survey, as reported by The Hacker News. Prophet Security is a commercial vendor in the AI security operations market; readers should weigh the findings accordingly.
```
安全營運領域的 AI 採用實際上已達飽和：40% 的安全團隊每天使用 AI，56% 正在測試，完全沒有計劃的僅佔 4%。上述數字來自 AI 安全營運供應商 Prophet Security 對逾 250 名 CISO、SOC 負責人及從業人員所作的調查，調查結果由 The Hacker News 於 2026 年 11 月 2 日報道。
值得停下來深思的數字並非採用率，而是那 4%。當 96% 的團隊已踏上採用之路，討論焦點已由「我們應否採用？」轉為「我們是否準備就緒？」——而對於仍在進行試點的 56% 團隊，坦白的答案往往是「尚未」。
採用並不等於準備就緒
40/56/4 的比例衡量的是意願與使用情況，而非實際能力。試點計劃很少暴露那些在 AI agent 對着生產環境 telemetry、票務系統或應變 playbook 運作時才會出現的失效模式。這些問題往往在事故處理中途才浮現，而此時一個無法解釋的輸出所造成的代價最高。
準備就緒可分為兩部分，而兩者的失效方式各不相同。
技術層面的準備就緒，考驗的是 SOC 的數據基礎能否支撐 agent：包括端點、網絡、身份及雲端各來源的 telemetry 覆蓋範圍；與 SIEM、EDR、身份提供者及票務系統的整合深度；以及 signal 衛生——告警與日誌是否夠潔淨，令模型生成的摘要與 enrichment 內容有可信基礎可依。
組織層面的準備就緒則是經常被略過的一環。它涉及決策權限：一份以書面寫成的升級協議（escalation contract），界定系統可自行處理的事項、需經人工批准的事項，以及永屬禁止範圍的事項。它涉及可審計性——輸入、輸出及人工 override 自第一天起便須記錄，而非事後補做。它涉及分析員的信任，亦涉及須有具名、問責的負責人評估 AI 輸出，而非任由一個無人負責的工具夾在告警與分析員之間。
採購 licence 只解決了第一部分。第二部分，才是事故中暴露漏洞之處。
仍在測試的團隊可採取的三項行動
對於佔 56% 的這一群體，試點期間作出的架構選擇，往往會悄然變成長期定局。現階段值得採取三項步驟：
- 揀選一個高流量的工作流程——分流摘要（triage summarisation）或告警 enrichment 通常是常見選項——並在工具啟用之前，按事先協定的 baseline 進行衡量。
- 撰寫升級協議。 系統可否在無人監督下運作、哪些事項需人工簽署批准、哪些完全屬禁區。若沒有白紙黑字寫下來，在事故發生時等於不存在。
- 為部署建立量度指標： 準確率、override 比率及決策所需時間。無法匯報這些數字的團隊，量度的是熱情而非表現——到預算季節來臨時，亦無法在內部為這項投資辯護。
對受規管環境的啟示
本節提供的是一般背景，並非具體的監管規定。銀行及金融機構的安全團隊，在控制措施證據及問責方面須面對相對嚴格的要求，這令準備就緒檢查中的組織層面尤為關鍵。能夠通過審核員檢視的控制措施——有記錄的決策、具名的負責人、有文件載明的 override 路徑——正好就是令 AI agent 在高壓情況下仍可運作的同一套控制措施。在試點期間便建立這些措施的團隊，可避免日後在審核期間由零重建。
時機
那 4% 沒有任何計劃的團隊，如今反成異類。對其餘所有人而言，決勝關鍵在於準備就緒——而非採用率。奠定這些基礎的時機，是在試點仍在進行之際，而非在 agent 已接入生產系統之後。
資料來源：Prophet Security《State of AI in Security Operations 2026》調查，由 The Hacker News 報道。Prophet Security 是 AI 安全營運市場的商業供應商；讀者宜據此衡量該調查結果的參考價值。