The organizations deepest into AI report the most incidents. Jamf's Q2 2026 survey of 687 IT and security leaders found that 27.1% of organizations with deeply integrated AI have already had an AI-related incident, compared to 19.4% of those still exploring. That is a 40% higher incident rate at the mature end of adoption.
Exposure scales with adoption, not against it. That single finding should reshape how security teams sequence their AI work.
The sample matters here. Jamf surveyed IT and security leaders across Apple enterprises, organizations that already manage and secure endpoints at scale. These are not teams that ignore fundamentals. 22.0% have already had a cost or security incident tied to AI, another 59.7% expect one, and only 18.3% say AI is not currently a concern.
The survey's sharpest reasoning is about where visibility ends. Network monitoring shows which cloud AI services users reach and how often, but the signal stops at the network edge. The access itself happens on the device: which tools are installed, what processes they spawn, what files they touch, none of which appears in a DNS log.
That reasoning is correct. It is also incomplete, because the same blind-spot pattern repeats one layer down.
A process list tells you an AI tool is running. It tells you nothing about what the model is doing at inference.
Device telemetry cannot detect supply chain tampering inside a model. It cannot tell you an attacker hijacked an agent mid-task while every process it spawned looked legitimate. It cannot explain why a model produced an output that looked normal by design. A backdoored model passes every benchmark you run and activates only under trigger conditions your eval suite will never encounter.
Most AI security tools observe outputs and infer intent. Starseer looks inside, using mechanistic interpretability methods like activation analysis and behavioral probing to detect threats that never surface in outputs, processes, or network traffic. Network logs miss the device. Device telemetry misses the model. The industry has already accepted the first half of that sentence. The second half is where AI security actually gets decided.
Respondents' open-ended answers about preventing incidents clustered into four themes. Each one traces back to the same root cause: teams cannot see what their AI is doing at the layer where it operates.
Establishing AI governance ranked as a top priority for 36.7% of respondents, nearly level with deploying AI productivity tools at 41.0%. Governance is not trailing enablement. It is moving alongside it, which means the teams pulling ahead treat both as the same project.
The incident data makes the sequencing argument for you. If exposure grows with integration depth, waiting to add security until AI is mature guarantees you add it at the moment of maximum risk. Validation belongs before deployment, which is the role of AI-Verify (AI Model Validation): confirm model integrity before it ships, so the baseline you monitor against at runtime is one you trust.
One honest caveat on the data. The survey covers Apple enterprises specifically, and its two collection waves used different selection rules on the priorities question, both disclosed in the methodology. Jamf reports the directional findings hold in both samples independently. Treat the numbers as a strong signal from a security-mature population, not a census of the whole market.
The survey closes on the idea that the governance you build is only as strong as what your tools can see. Starseer's version of that sentence goes one layer deeper: your AI security is only as strong as your visibility into the model itself. Interpretability is the method. Security is the outcome.