What the 2026 SANS AI survey reveals about the gap between the two
AI governance has a familiar cybersecurity problem: what exists on paper and what exists in the environment are often two different things. I have read a lot of policies that were not wrong, exactly. The access control policy says access to sensitive systems is restricted to authorized personnel, reviewed quarterly, approved by a named owner. It is well written and someone clearly thought about it. Then you export the actual permissions and there are accounts in there nobody in the room can account for, including a few belonging to people who left the year before. The policy wasn’t false. It described the control the organization intended to have — it just wasn’t describing the system.
I notice that gap more than most people because I came to this work from two directions that don’t usually meet: I read contract clauses and regulation as written, and I read system configuration as built. Most of my job lives in the distance between them.
That distance is now opening up around AI, and the 2026 SANS AI Survey Insights report puts a number on it. Half of senior security leaders say their organization has a formal AI risk management program. Among practitioners, that figure is 36%. Same organizations, same question, two different answers ,and neither group is lying.
It now does double duty as your visual hook near the top and as the featured image. That’s better placement than where I originally suggested.
That is the finding I kept returning to in Matt Bromiley’s Poisoned Wells and Pure Springs: Drawing Security and Compromise from the Same AI Source, which draws on 536 cybersecurity and IT practitioners worldwide plus a separate module completed by 57 senior security leaders including CISOs, CSOs, and security vice presidents. The adoption numbers got the headlines in July. This one matters more.
Leadership’s view and the operational view are not the same view
Roughly three-quarters of security practitioners now hold some governance responsibility for enterprise AI, and more than half say no established framework exists for auditing it. Meanwhile 63% report significant shortcomings in AI-driven threat detection and response, up from 45% the year before. Read together, those numbers describe a lot of people holding accountability for something they have no instrument to measure.
Handing someone responsibility for AI governance does not hand them the means to govern anything. To actually govern an AI system you need to know which systems use AI at all, what data those systems can reach, which models and providers sit behind them, what decisions they influence, how anyone validates the output, and what evidence would show the surrounding controls operate. Without that, governance is an administrative layer floating above a technical environment it does not describe.
This is the oldest problem in compliance work wearing new clothes. A policy says access is restricted; a configuration export tells you whether it is. A procedure requires logging; the retention settings tell you whether useful logs exist. A risk register names a control; an assessor still has to walk into the environment and test whether that control operates. AI deserves exactly the same skepticism, and in my experience it often gets less — partly because the technology is unfamiliar enough that people are reluctant to ask basic questions in front of colleagues who seem to understand it better. I have sat in those meetings. The question nobody asks is usually the one that matters.
Leadership’s view and the operational view are not the same view
The most useful decision SANS made was separating practitioners from senior leaders, because the two groups do not describe the same organization.
Half of security leaders report having a formal AI risk management program. Among practitioners, that figure is 36%. Bromiley calls the fourteen-point spread a perception problem, and told Cybersecurity Dive that while leaders believe real governance exists, the people running the tools cannot see any legitimate guardrails on the ground.
I would put it slightly differently: both answers are honest, and that is what makes the gap dangerous. Executives encounter AI through strategy, budget, vendor relationships, and approved programs — and at that altitude a program with a charter, an owner, and management sign-off genuinely exists. Practitioners encounter the same program through integrations, service accounts, data flows, alert volume, and the small daily compromises required to keep anything running. At that altitude, a governance program you cannot see operating in the system looks identical to one that was never built.
Which raises the question I would want answered before almost anything else. Does management’s understanding of AI use in this organization match what is actually happening in the environment? A board-approved policy cannot answer that. An inventory begins to, and so do access reviews, data-flow analysis, testing, monitoring, and the step most programs skip — sitting down with the engineers running these systems and asking what they have had to do to keep them working. That conversation has told me more than most document reviews.
The same tools sit on both sides
The report’s title earns itself. Whatever advantage AI gives defenders is equally available to the people attacking them, and the survey suggests that stopped being hypothetical some time ago: 78% of organizations reported confirmed or suspected AI-enabled attacks in the previous twelve months, and 95% of respondents believe threat actors are using AI in their operations. It appears across the attack lifecycle — reconnaissance, exploitation, deepfake-assisted social engineering — rather than concentrated in a single technique.
Defensive use is climbing at a similar rate. Red teaming moved from minority to majority practice in one year, with 61% of practitioners now using AI in red team work against 33% in 2025. But only 27% describe their AI deployments as mature production environments; most are pilots, or capabilities running in a supporting role.
That distinction gets collapsed constantly, particularly in vendor conversations. Deployment is not maturity.
A system producing useful output is not, on that evidence alone, a validated system. And a validated system is still not a governed one.
Human judgment did not go anywhere
The most reassuring finding is how firmly practitioners put people back at the center. Behavioral detection ranked among their most effective defenses against AI-enabled threats, alongside user awareness training and human analyst review. And 73% said AI changed their team’s training requirements this year, up from 51% in 2025.
That matches what the work looks like. As these systems get more capable the human role shifts rather than shrinks. Someone still has to notice when an output is implausible, understand what data should never have reached a model in the first place, investigate a missed detection, judge whether an automated action was appropriate, and decide when the system should not be trusted at all.
So governance cannot be reduced to selecting a framework and publishing an acceptable use policy. It requires people who understand enough about the technology, the environment, and the organization’s obligations to challenge what the system is doing — and who have enough standing internally that challenging it is safe. The second condition fails more often than the first.
From policy to evidence
If you are building an AI governance program, this is the question I would start with rather than end with: **if someone asked tomorrow to see how this AI system is governed, what could you actually show them?**
Not what the policy requires. What exists. The approved use case, the system owner, the model or service in use, the classification of information involved, the data sources and access permissions, validation results, logging, human-review requirements, incident procedures, third-party dependencies, evidence of periodic review.
This matters more in regulated and security-sensitive environments, where contractual, privacy, and cybersecurity obligations do not soften because a process now contains an AI component. The control still has to work, the evidence still has to exist, and the documentation still has to describe the environment you actually have rather than the one you meant to build.
SANS arrives somewhere similar, pointing toward validation infrastructure, precision, recall, continuous comparison, rather than more tools; operationalizing governance so that sensitive-data access and AI data exposure are treated as core controls instead of afterthoughts; and building the workforce needed to supervise any of it.
AI governance is often discussed as though you design the structure first and adopt the technology second. For most organizations that sequence is already gone. AI is in the environment — security teams are using it, employees are using it, vendors embedded it into products bought two years ago, and attackers are using it against those same organizations.
So the question becomes concrete. Can you explain what your AI systems do, what information they touch, what risks they introduce, and who is accountable — and then produce evidence that the controls around them work? If the answer lives only in a document, you do not have a governance program yet. You have the cover page.
*Source: Matt Bromiley, 2026 SANS AI Survey Insights: Poisoned Wells and Pure Springs: Drawing Security and Compromise from the Same AI Source, published 13 July 2026. The full white paper is free with registration and carries 5 CPE credits.*
[Read the 2026 SANS AI Survey Insights white paper](https://www.sans.org/white-papers/2026-sans-ai-survey-insights)Where this leads
The same question applies whether the system in front of you is an AI model or a file share holding controlled unclassified information. Can you show what it does, who owns it, what data it touches, and evidence that the control works — or only a document saying it should?
That gap is most of what I work on. At Cyber DSC the work is CMMC Level 2 and NIST SP 800-171 for defense contractors: documentation written against something an assessor can actually be shown, and evidence that matches what the systems do. At AI GRC Advisory it’s the same discipline applied to AI programs — EU AI Act, ISO/IEC 42001, and NIST AI RMF.
If you want a rough read on where you stand under 800-171 before talking to anyone, the 25-question SPRS self-check runs in your browser and takes about ten minutes. Nothing is sent to us. If you’d rather talk it through, book a call — thirty minutes, and you’ll leave knowing the two or three things worth doing first whether or not you hire me.