What is the most useful AI security statistic for a CISO?

No single number covers the control problem. IBM's 20% figure helps frame breach linkage inside a breach sample. Verizon's 15% figure helps frame observed workforce use on corporate devices. A CISO should pair external context with an internal measure tied to a named control, such as the share of approved HTTP model routes producing complete identity and policy records.

Can the IBM 20% figure be applied to all companies?

The source population consisted of 600 organizations that had experienced a breach. The figure means one in five organizations in that studied breach population had an incident linked to shadow AI. An all-company rate would require a sample that also includes organizations without known breaches.

Does Verizon's 72% figure mean 72% of all employees use personal AI accounts?

The 72% figure describes account identifiers among the generative AI users observed in the partner telemetry. It is not a workforce-wide adoption rate. Verizon separately reported that 15% of employees in that telemetry routinely accessed generative AI on corporate devices.

Should raw prompts be copied into a SIEM for measurement?

A general SIEM can become a second store of sensitive material if every prompt is copied into it. The event should retain the minimum evidence needed for its review purpose, such as identity, route, classification, policy, outcome, and protected content references. Raw payload handling needs its own access and retention controls.

AI Security Statistics Need Their Denominators Attached

A security slide becomes unreliable the moment its percentages lose their denominators. IBM studied breached organizations. Verizon measured employee access to generative AI from corporate devices. Those populations answer different questions, even though both sets of figures often appear under the heading AI security statistics.

I want to keep the source year and measured population attached to each number, alongside its control boundary. That turns a statistic into a control question a CISO can test.

TL;DR

IBM's 2025 analysis covered 600 breached organizations across 17 industries. One in five had a breach linked to shadow AI.
IBM reported up to USD 670,000 in added average breach cost for shadow-AI-linked incidents.
Verizon's 2025 DBIR reported that 15% of employees in partner telemetry routinely accessed generative AI on corporate devices.
Among those observed users, 72% used non-corporate email identifiers and 17% used corporate email without integrated authentication.
Device access, account identity, breach linkage, data exposure, and cost are separate measures. They should remain separate in a board pack.

IBM measured breach impact

IBM's 2025 Cost of a Data Breach analysis examined 600 breached organizations in 17 industries. The population matters: every organization in the study had already experienced a breach. The figures describe conditions and outcomes inside that breach sample. They are not a prevalence estimate for every enterprise.

IBM reported that one in five studied organizations, or 20%, experienced a breach linked to shadow AI. Those incidents added as much as USD 670,000 to average breach cost. Customer PII appeared in 53% of breaches across the study and 65% of the shadow-AI-linked subset. IBM also reported USD 178 per record for exposed intellectual property in shadow-AI-related breaches.

The incident team should be able to identify which unsanctioned AI route carried the affected data and which identity used it. Our shadow AI monitoring tools review maps the evidence available at browser, CASB, network, and routed API surfaces.

Verizon measured workforce access

The 2025 Verizon Data Breach Investigations Report used partner telemetry to examine generative AI access from corporate devices. Verizon found that 15% of employees routinely accessed generative AI systems, defined as at least once every 15 days.

Among the observed users, 72% used non-corporate email identifiers. Another 17% used corporate email without integrated authentication. Together, those figures describe an identity-control problem on managed devices. They do not show how much sensitive content entered a model, and they do not establish that each observed session caused a security incident.

Picture two browser windows on a security analyst's 27-inch monitor. One session uses enterprise SSO and the other uses a personal Gmail account. Both reach the same AI service from the same laptop, yet the identity, contract, retention settings, and audit trail can differ. The employee ChatGPT monitoring guide explains which inspection points can distinguish those sessions and which can inspect prompt content.

Five numbers, five control questions

Each statistic should produce a test rather than a larger dashboard tile.

20% of IBM's breached organizations had shadow-AI-linked breaches. Test the incident taxonomy. Confirm that responders can label the AI service, route, data class, and accountable owner without relying on a free-text note.

USD 670,000 was the reported added average cost, stated by IBM as "as much as." Preserve that qualifier. Test the cost model against investigation time, legal review, notification, business interruption, and provider evidence gaps instead of treating USD 670,000 as a universal surcharge.

Customer PII exposure rose from 53% across IBM's breach sample to 65% in the shadow AI subset. Test prompt and response handling with synthetic PII. Record where classification ran and what action followed.

15% of employees in Verizon's partner telemetry routinely accessed generative AI on corporate devices. Test discovery coverage across managed browsers, desktop applications, direct APIs, and approved SaaS integrations. One network counter will miss at least one of those paths.

The fifth figure is that 72% of observed users used non-corporate email identifiers. Test identity binding. A DNS event can show a destination, while a routed request can preserve the authenticated corporate principal supplied by the application. The AI egress monitoring guide shows the record fields needed for that request-level view.

My opinion is that a board slide containing five percentages and zero denominators should be sent back to the author. A percentage without its population invites a decision the source never supported.

The source year belongs beside the figure

IBM published its analysis on 12 November 2025. Verizon's report is also the 2025 edition. A 2026 security review can still use both when it displays the source year and checks the publisher for a newer measurement. Relevance and recency need separate labels.

The review should retain four fields beside every number: publisher and report, publication date, measured population, and the exact claim supported. Add the collection method when the source exposes it. For Verizon's workforce figures, the phrase "partner telemetry" belongs in the note because the result is not a census of every employee. For IBM, "breached organizations" belongs beside the sample size.

NIST's current AI Risk Management Framework resources provide the governance structure for turning external evidence into owned risk work. The statistics can inform mapping and measurement. They cannot set an organization's risk tolerance or prove that a control operated.

Request records answer a narrower question

The IBM and Verizon figures establish exposure patterns at study level. A per-request record answers what happened inside one routed model interaction: which authenticated identity initiated the request, which model received it, which data classification applied, which policy version ran, and which outcome followed.

That record has a strict boundary. It covers authenticated HTTP traffic deliberately sent through the enforcement point. Native consumer chat sessions, local models, endpoint clipboard activity, and AI features operating entirely inside a SaaS vendor require evidence from their own control planes. Coverage reporting should name those gaps rather than projecting one routed-traffic statistic across the whole enterprise.

A useful monthly measure is the proportion of known HTTP model routes producing complete identity-bound decision records. Keep its denominator stable and list excluded paths. That operating measure belongs to the organization and should never be presented as an industry benchmark.

DeepInspect

DeepInspect governs authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates application-supplied identity, prompt classification, destination, and policy before the model receives the request, then writes a per-decision audit record.

Those records let a security team measure its own routed coverage without pretending to observe native SaaS sessions or local execution. The result is a defensible denominator covering paths in scope, evidence completeness, and traffic assigned to another control owner.

Book a technical deep dive at deepinspect.ai.