Quantum vs Classical Computing: What CTOs Need to Know in 2026
Enterprise Technology
Quantum Computing vs Classical Computing: The 2026 Enterprise Reality Check
By NeuralWired Staff · June 30, 2026 · 12 min read
A CISO at a mid-size healthcare company asked us a blunt question last month: should she be worried about data her organization encrypted five years ago? The honest answer is yes, and the reason has nothing to do with quantum computers being fast. It has to do with quantum computing vs classical computing working on fundamentally different principles, and one narrow but consequential category of problems where that difference now matters enormously: breaking the encryption protecting your archives.
That’s the story most coverage gets backwards. Quantum machines aren’t about to replace your CRM, your payroll system, or your e commerce backend. They’re about to (eventually) break the math those systems rely on to keep data private. Here’s what’s real, what’s hype, and what enterprise leaders should actually do about it in 2026.
The Real Technical Difference (And Why “Faster” Is the Wrong Frame)
Quantum computers don’t beat classical machines on raw speed, clock for clock. They exploit superposition and entanglement to explore certain solution spaces in a structurally different way, and that only produces an advantage on problems with a specific shape: ones where the solution space scales exponentially. Molecular simulation. Certain optimization problems. Integer factoring, the math behind RSA encryption.
For everyday enterprise computing, the workloads running your business right now, quantum offers nothing. Harvard Quantum Initiative researchers reported in May 2026 that this distinction is precisely why fault tolerance advances are reshaping timelines in some areas and not others. It’s not a general purpose computer that happens to be expensive. It’s a specialized tool, and right now there’s exactly one application area where that specialization has turned into urgency: cryptography.
Why Washington Just Got Involved
On June 22, 2026, the White House issued Executive Order 14413, “Ushering in the Next Frontier of Quantum Innovation.” It establishes the Quantum Computer for Application Development and Discovery Science effort, coordinated through the President’s science and technology advisory structure, aimed at delivering a working quantum computer to a Department of Energy facility. The order also directs federal agencies to stand up a national benchmark assessment center within 180 days.
Government interest at this level is a signal worth reading correctly. It’s not proof that commercial quantum computing has arrived. It’s confirmation that the national security calculus around cryptography has shifted enough to justify a presidential order, which tracks with everything else happening in the field this year.
The Money: Who’s Actually Spending, and How Much
According to McKinsey’s fifth annual Quantum Technology Monitor, released April 20, 2026, more than 300 companies, including Airbus, JPMorgan Chase, and Boehringer Ingelheim, are now actively working with quantum vendors. Quantum computing companies generated over $1 billion in global revenue in 2025, and investment in quantum startups hit $12.6 billion that year, a 6.3x jump from 2024.
McKinsey projects the technology could generate $1.3 trillion to $2.7 trillion in global economic value by 2035, with the underlying hardware and software market itself reaching $43 billion to $71 billion.
“2026 is the year in which quantum computing goes from a mere promise to a strategic management issue.”
Henning Soller, Partner, McKinsey & Company, Quantum Technology Monitor 2026
Here’s the budget benchmark worth knowing: of the companies McKinsey analyzed, 33% spend over $10 million annually on quantum initiatives, 7% spend over $50 million, and the largest single budget identified was $200 million. If your competitors are in that range, a small evaluative pilot makes sense. If they aren’t, building an in house quantum team right now is a real talent market risk, not a strategic head start.
That risk is sharper than it sounds. McKinsey’s own talent analysis found there’s only one qualified quantum candidate for every three open roles, and under half of quantum computing jobs currently get filled.
Worth noting too: 72% of enterprise quantum activity happens at privately owned companies, not public research institutions, and Europe currently leads in actual adoption (43% of analyzed companies) ahead of the US (29%) even though the US pulls in 64% of global investment dollars. Money and deployment aren’t flowing to the same places.
The Encryption Threat: A Number That Keeps Shrinking
This is the part of the story that should be on every CISO’s radar, and it’s moving faster than almost anyone expected. In 2019, Google researcher Craig Gidney estimated it would take roughly 20 million physical qubits to break RSA 2048 encryption using Shor’s algorithm. In a 2025 update, he revised that figure down to under 1 million qubits, a 95% reduction, with the actual attack taking under a week rather than years.
Why this matters today, not in 2030: “Harvest now, decrypt later” is the practice of adversaries collecting encrypted data now with the intent of decrypting it once sufficiently powerful hardware exists. If your organization handles data that needs to stay confidential for a decade or more, healthcare records, government contracts, financial archives, intellectual property, that data is potentially exposed right now, even though no current quantum computer can break it yet.
A March 2026 preprint from researchers at Caltech, Berkeley, and Oratomic, reported by ScienceAlert, estimated Shor’s algorithm could run with as few as 10,000 to 20,000 atomic qubits on neutral atom hardware, with around 26,000 qubits enough to break Bitcoin’s elliptic curve encryption (secp256k1) within days. Separately, a startup called Iceberg Quantum proposed in early 2026 that RSA 2048 could fall to fewer than 100,000 physical qubits using a different error correction approach, though that claim remains unvalidated at scale.
Google took its own warning seriously enough to set an internal 2029 deadline for migrating its infrastructure to post quantum cryptography, announced in a March 25, 2026 company blog post.
The Skeptic Who Changed His Mind
If you only follow one voice in this space, make it Scott Aaronson. He holds the Schlumberger Centennial Chair of Computer Science at UT Austin, co-founded the university’s Quantum Information Center, and sits on the US National Academy of Sciences. For most of the past decade he’s been quantum computing’s most credible skeptic, regularly pushing back against overhyped commercial claims.
“There are these claims about how quantum computing will revolutionize machine learning and optimization and finance and all these industries, where I think skepticism was always warranted. If people are just now coming around to that, well then, welcome.”
Scott Aaronson, UT Austin, IEEE Spectrum
So it matters that on May 1, 2026, Aaronson published a post titled “Will you heed my warnings?” stating that colleagues whose technical judgment he trusts more than his own now expect fault tolerant, crypto breaking quantum computers around 2029. When the field’s biggest doubter starts moving his own estimate forward, that’s a stronger signal than another optimistic vendor press release.
Not everyone in the industry agrees the broader commercial case is there yet. Sebastian Leichenauer, quoted in Forbes in March 2026, put it plainly:
“There is no offering on the market for quantum computing that is really where you need the quantum computer. None of them are really at the point where they can be sort of useful in the sense of, like, you would definitely use it for, say, a commercial application.”
Sebastian Leichenauer, quoted in Forbes, March 26, 2026
Leichenauer identified quantum chemistry, drug and materials discovery, as the one area with genuine near term value, and dismissed AI-on-quantum-instead-of-GPUs as far future thinking. That’s a useful filter: if a vendor pitch isn’t about molecular simulation or cryptography, treat it with real skepticism.
What CTOs and CISOs Should Actually Do in 2026
Strip away the noise and there are really two actions that matter this year, not five.
1. Start post quantum cryptography migration planning now
NIST’s post quantum cryptography standards are already published. You don’t need a working quantum computer to start this work, you need an inventory of where long-lived sensitive data lives and a migration roadmap, the same kind of project Google has already committed to completing by 2029. Pair this with internal linking to your existing compliance coverage, our breakdown of the GDPR AI fines and EU AI Act situation covers the regulatory side of data protection that overlaps directly with this risk.
2. If you’re in pharma, materials, chemicals, or finance, pilot through the cloud, don’t buy hardware
Since 72% of enterprise quantum activity already happens through cloud access rather than owned hardware, via AWS Braket, Azure Quantum, or IBM Quantum, that’s the lower risk entry point. It also avoids the talent trap: you don’t need to hire scarce quantum error correction specialists to run a bounded pilot. For the infrastructure side of this decision, our piece on the AWS and Azure shared responsibility model is relevant background reading.
What not to do
Don’t chase quantum for generic optimization, AI training, or anything pitched as a “quantum CRM.” That’s square hype, and Leichenauer’s quote above is the cleanest possible rebuttal to it. If a sector peer just raised a quantum startup round, that’s a venture capital story, not necessarily a signal your company needs to follow, our 2026 venture capital trends coverage has more context on where that $12.6 billion actually went.
The Critical Perspective: Is the Tipping Point Real?
Not everyone buys the “commercial tipping point” framing, including critics of McKinsey’s own numbers. An analysis published at postquantum.com argues that comparing 2035 quantum capability against 2026 classical capability misleads readers, and that the widely cited $1 billion revenue figure mostly reflects research contracts and development partnerships rather than production deployments generating real ROI. Even McKinsey’s report concedes most current applications remain experimental or hybrid.
There’s also a structural bottleneck the optimistic headlines tend to skip: programming a quantum computer requires fundamentally different skills than classical software engineering, unitary transformations, constraints from the no-cloning theorem, concepts most software teams have never touched. A sudden hardware breakthrough wouldn’t translate into immediate enterprise value, because there simply aren’t enough people who know how to write the algorithms yet.
Our read: the cybersecurity case for action is more solid and more urgent right now than the optimization or AI commercial case, and most coverage blurs the two together in a way that does readers a disservice. The encryption-breaking timeline has compressed faster than the general commercial timeline. Treat them as two separate decisions with two separate clocks.
Worth remembering too: this is at least the third “quantum is finally arriving” wave in a decade, following IBM’s early cloud access push and Google’s 2019 quantum supremacy claim. “Five years away” has been a recurring prediction for over a decade. If error correction engineering stalls again, as it has before, the $1.3 trillion to $2.7 trillion 2035 projections won’t hit on schedule, and companies that over-invested in dedicated quantum teams in 2026 will be sitting on sunk costs with no near term return.
Frequently Asked Questions
Is quantum computing faster than classical computing?
Not in general. Quantum computers use superposition and entanglement to explore certain large solution spaces differently, which only creates an advantage on narrow problem types: molecular simulation, specific optimization problems, and integer factoring. For everyday computing, they offer no benefit over classical machines.
Can quantum computers break RSA encryption?
Theoretically, yes, using Shor’s algorithm on a fault tolerant quantum computer. Google researcher Craig Gidney’s 2025 estimate puts the requirement at under 1 million physical qubits, down sharply from 20 million in 2019. Today’s largest systems hold only thousands of noisy qubits, well short of that.
What is “harvest now, decrypt later”?
It’s the practice of adversaries collecting encrypted data today with the intent of decrypting it once powerful enough quantum hardware exists. It’s a real present-day risk for any organization whose data needs to stay confidential into the 2030s.
What industries benefit most from quantum computing today?
Drug discovery, materials science, and chemistry lead because molecular simulation scales exponentially for classical computers. Finance (portfolio optimization, fraud detection), logistics, and post quantum cybersecurity planning follow as earlier stage but emerging use cases.
How big is the quantum computing market?
McKinsey projects quantum computing could generate $1.3 trillion to $2.7 trillion in global economic value by 2035, with the core hardware, software, and services market reaching $43 billion to $71 billion by the same year.
Where This Leaves Us
The headline most readers expected, “quantum computers are about to replace classical ones,” was never accurate, and it still isn’t in 2026. What’s actually true is narrower and arguably more urgent: the cryptography that protects long lived enterprise data is on a compressed timeline, the federal government just formalized that concern with an executive order, and the field’s most credible skeptic stopped being skeptical about the 2029 estimate.
Watch three things over the next 6 to 18 months: whether NIST’s post quantum standards see faster enterprise adoption following Google’s 2029 deadline announcement, whether the qubit-count estimates for breaking encryption keep shrinking the way they have for the past two years, and whether any of the 300+ companies McKinsey tracked move from pilot programs to genuine production deployment. That last one is the real tipping point. We’re not there yet.
Want this kind of analysis before it hits the rest of the industry? Subscribe to The Neural Loop at neuralwired.com/newsletter.
IBM’s Quantum Roadmap Gives Enterprises a 4-Year Window to Act on Post-Quantum Migration
By NeuralWired Editorial | June 29, 2026 | 12 min read
Your organization’s most sensitive encrypted data, customer records, financial transactions, intellectual property, could already be sitting in an adversary’s archive. It was captured yesterday. It will be decrypted in 2029, or 2031, or 2033. The exact date is uncertain. What is not uncertain is that the migration away from today’s encryption standards takes 42 to 54 months once an organization actually starts. And fewer than 5% of enterprises have started.
IBM’s quantum computing roadmap, Google’s dramatic security warning published March 25, 2026, and a new research paper that cut prior qubit estimates by a factor of 20 have together shifted this conversation from theoretical risk management to operational urgency. This article breaks down exactly what has changed, what the NIST post-quantum cryptography standards require, and what a CISO or CTO at an enterprise organization needs to do before the end of 2026.
The Real Threat Is Not the Qubit Count
When IBM announced Condor, its 1,121-superconducting-qubit processor, in December 2023, it made headlines. The 1,000-qubit barrier was crossed. But fixating on that number misses the actual story of 2026, which is about timelines, compliance clocks, and a harvest-now-decrypt-later threat that is already happening.
Qubit counts alone do not break encryption. What matters is logical qubits, fault-tolerant gates, and error correction at scale. IBM’s own engineers recognize this: after Condor, the company shifted its focus from raw qubit counts toward error resistance. State-of-the-art error correction currently requires roughly 1,000 physical qubits per logical qubit, which explains why the cryptographically relevant threshold is still years away from Condor’s 1,121 physical qubits.
Key Distinction
A 1,000-qubit quantum computer does not break RSA-2048 today. Breaking RSA-2048 likely requires around one million physical qubits running for approximately a week, based on Google’s latest research estimates. The urgency is about migration timelines, not imminent decryption.
The actual story of 2026 is that organizations which have not started post-quantum cryptography migration will mathematically fail to meet regulatory deadlines. That is the operational reality driving this article.
What IBM’s Quantum Roadmap Actually Says
IBM has published a detailed hardware roadmap that provides the clearest public signal of where quantum capability is heading and on what schedule.
Year
IBM Milestone
Key Capability
2023
Condor (1,121 qubits)
First processor crossing 1,000 physical qubits
2026
Kookaburra (1,386 qubits, multi-chip)
Three chips linked via IBM Quantum System Two, yielding a 4,158-qubit combined system
2028-2029
IBM Quantum Starling
Fault-tolerant system with roughly 200 logical qubits from approximately 10,000 physical qubits; 100 million gate operations
2029
Near-term quantum advantage tools
IBM targets delivery of tools for near-term quantum advantage by end of 2026, first large-scale fault-tolerant machine by 2029
The Kookaburra milestone in 2026 is significant not for its qubit count alone but for the multi-chip architecture. Linking processors is how IBM intends to scale toward the hundreds of logical qubits needed for cryptographically relevant computation. Every step on this roadmap narrows the gap between current machines and the systems that security teams are building their migration timelines around.
Our read IBM’s pivot from qubit maximalism to error-correction depth signals something important: the people closest to the hardware believe the engineering path to fault tolerance is now a matter of execution, not discovery. That is a different kind of confidence than the field had three years ago.
Google’s 2029 Alarm and What It Means for You
On March 25, 2026, Google’s security leadership published a formal announcement setting 2029 as the company’s internal deadline to secure its systems against quantum threats using post-quantum cryptography. The post was authored by Heather Adkins, VP of Security Engineering, and Sophie Schmieg, Senior Staff Cryptography Engineer. This is a full year ahead of NIST’s 2030 deprecation date and six years ahead of the 2035 final federal deadline under NSM-10.
Five days later, on March 30, 2026, Google Quantum AI released a 57-page paper with researchers from the Ethereum Foundation and Stanford University. The finding that drew immediate industry reaction: breaking 256-bit elliptic curve cryptography, the algorithm protecting Bitcoin and Ethereum, would require fewer than 500,000 physical qubits. That is nearly a 20-fold reduction from prior best estimates.
“It’s a real shock. We’ll need to speed up our efforts considerably.”
Bas Westerbaan, Applied Cryptography Lead, Cloudflare — TIME magazine, April 2026
Cloudflare accelerated its own post-quantum deadline to 2029 within days of the paper’s release. Westerbaan’s reaction is worth sitting with. Cloudflare processes a significant share of global internet traffic. When its cryptography lead describes a research paper as “a real shock,” that is not public relations language. That is a practitioner recalibrating a production timeline based on new data.
Google also announced that Android 17 is integrating post-quantum cryptography digital signature protection using ML-DSA, building on existing Chrome support. Our read this signals that PQC is no longer a future feature on Google’s roadmap. It is shipping code.
The Compliance Deadline Ladder: 2027 to 2035
The regulatory framework for post-quantum cryptography migration in the United States is built on NSM-10, the NSA’s CNSA 2.0 suite, and Executive Order 14144. Enterprises serving federal clients, contractors, and financial institutions with ties to regulated sectors need to treat this schedule as binding, not aspirational.
Deadline
Requirement
Who It Affects
Jan 1, 2027
All new National Security System acquisitions must support CNSA 2.0
Government contractors, defense suppliers, NSS vendors
Dec 31, 2030
Equipment unable to support CNSA 2.0 must be phased out; NIST deprecates RSA/ECC
All federal agencies, regulated critical infrastructure
Dec 31, 2031
CNSA 2.0 becomes mandatory across all National Security Systems (except exemptions)
NSS operators, contractors
2033
OS, cloud services, and custom applications must reach exclusive CNSA 2.0 use
Full quantum resistance required across all National Security Systems per NSM-10
Entire US national security supply chain
The January 2027 deadline for new NSS acquisitions is the one that commercial enterprises should pay attention to first, even if they are not themselves defense contractors. When government procurement requirements shift, vendor product roadmaps shift with them. Any software company, hardware manufacturer, or cloud provider that wants to remain in the government supply chain will need CNSA 2.0 support in new products by January 2027. That cascades into commercial product decisions within 12 to 18 months of announcement.
Procurement Action
CTOs should begin requiring CNSA 2.0 and post-quantum cryptography readiness clauses in vendor contracts now. The January 2027 government deadline will reshape commercial vendor roadmaps whether or not your organization is regulated. Get ahead of it in your next contract renewal cycle.
The Enterprise Readiness Gap Is Alarming
The data on enterprise preparedness is consistently grim across every survey and research source published in the past 12 months. The gap between awareness and action is wide enough to be a material risk that boards and audit committees should be asking about.
<5%
of enterprises have a formal quantum-transition plan (arXiv, September 2025)
69%
believe quantum will break current encryption within 5 years (DigiCert/Propeller Insights survey, 1,042 senior security managers)
41%
of organizations do not plan to address quantum computing at this time (ISACA 2025)
The DigiCert survey finding is particularly striking. Sixty-nine percent of senior cybersecurity managers believe quantum computers will break current encryption within five years. Only 19.2% describe themselves as “extremely prepared.” The gap between what people believe is coming and what they are doing about it is not a knowledge problem. It is an organizational inertia problem.
Scott Aaronson, Schlumberger Centennial Chair of Computer Science at the University of Texas at Austin and a newly elected member of the US National Academy of Sciences, offered the sharpest framing of this inertia in a PYMNTS interview in February 2026:
“The time to start thinking about migrating to quantum-resistant methods of encryption is now. Even optimistic estimates place practical quantum attacks five to ten years out, but the migration itself, not the threat, is the actual bottleneck for large institutions.”
Scott Aaronson, Schlumberger Centennial Chair of Computer Science, University of Texas at Austin — PYMNTS, February 20, 2026
Aaronson matters here for a specific reason. He has spent more than a decade as quantum computing’s most prominent skeptic, the researcher other researchers cite when they want to explain why hype outruns reality in this field. His May 1, 2026 blog post, titled “Will You Heed My Warnings?”, noted that some of the most reputable people in quantum hardware and error correction now believe a fault-tolerant, cryptographically relevant quantum computer “ought to be possible by around 2029.” His words, not a breathless press release.
Banking and telecom lead enterprise sectors in preparedness, with 45 to 47% of respondents in those sectors having budgeted and planned for near-term post-quantum cryptography transition. Every other sector is significantly behind.
The CTO Action Plan: What to Do in the Next 90 Days
The migration timeline math is straightforward and unforgiving. Enterprise PQC migrations realistically take 42 to 54 months from the moment an organization is properly resourced and underway. An organization that has not started a cryptographic inventory by the end of 2026 will struggle to hit NIST’s 2030 deprecation date. An organization that has not started by mid-2026 has already put Google’s 2029 internal deadline out of reach.
Step One: Cryptographic Asset Inventory
Every major guidance document from NIST, Capgemini, and Fortinet identifies this as the step that enterprises consistently skip or underestimate. You cannot migrate what you have not mapped. This means cataloguing every certificate, SSH key, code-signing key, embedded cryptographic algorithm in firmware and IoT devices, and any third-party library that handles encryption. For most large enterprises, this inventory alone takes three to six months.
This is the present-tense risk that gets underweighted because its consequences are future-tense. Nation-state adversaries are capturing encrypted traffic now and storing it for future decryption. Any data with a confidentiality shelf-life beyond approximately seven to eight years is already exposed if it is encrypted with RSA or ECC today. That includes healthcare records, defense contracts, M&A negotiations, and anything classified at the top end of most organizations’ data hierarchies. Prioritize migration of those data classes first.
Step Three: Pilot NIST-Standardized Algorithms Now
NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203, FIPS 204, and FIPS 205. These are not draft standards. They are ready for implementation. IBM’s z16 mainframe already includes hardware acceleration for post-quantum algorithms. Microsoft has published a detailed migration roadmap targeting full PQC transition by 2033, with core infrastructure migration beginning in 2026. Use these as benchmarks and start pilot deployments in lower-risk environments this quarter.
Step Four: Update Procurement Requirements
Begin requiring CNSA 2.0 and PQC readiness clauses in vendor contracts on renewal. Build a vendor questionnaire that asks suppliers to disclose their own PQC migration plans, target dates, and which NIST-standardized algorithms their products will support and when. The January 2027 government procurement deadline will accelerate commercial vendor timelines regardless; getting this into your contracts now creates leverage and accountability.
Complete cryptographic asset inventory across all systems, firmware, and third-party libraries
Identify all data with confidentiality requirements beyond 7 years and prioritize for immediate migration planning
Pilot FIPS 203, 204, or 205 in at least one production-adjacent environment before Q4 2026
Add PQC readiness requirements to vendor contract renewals starting this quarter
Establish a crypto-agility architecture so algorithm replacement does not require full system rebuilds
Present quantum readiness status to the board or audit committee with a formal risk register entry
The Skeptic’s Case: Why 2029 Might Be Too Early
Any responsible analysis of this topic needs to include the genuine scientific minority view, and not as a dismissal of urgency but as a calibration of certainty.
Gil Kalai, a mathematician at Hebrew University of Jerusalem and one of quantum computing’s most technically rigorous skeptics, has published conjectures arguing that fundamental noise correlations in highly entangled quantum systems may make fault-tolerant quantum computing impossible, not merely difficult. His argument is not that the engineering is hard. It is that correlated errors in large quantum systems may violate assumptions that fault-tolerance proofs rely on. This is an unresolved scientific dispute, not a fringe view.
RAND Corporation’s institutional assessment places cryptanalytically relevant quantum computers in “at least the 2030s,” and RAND explicitly warns policymakers against messaging that suggests such computers could already secretly exist. A hostile actor running a cryptographically relevant quantum computer against unsuspecting victims undetected for years is, in RAND’s assessment, highly unlikely.
Even Craig Gidney, the Google researcher whose work contributed to the March 2026 ECC paper, has described the probability of a cryptographically relevant quantum computer by 2030 at roughly 10%, characterizing that level as “unacceptably high” rather than likely. Google’s 2029 internal deadline is a risk management decision at 10% probability, not a forecast that Q-Day happens in 2029.
Calibration Note
The correct framing is not “quantum computers will break encryption by 2029.” It is “the risk is high enough by 2029 that Google, Cloudflare, and Scott Aaronson now treat 2029 as the responsible deadline for completing migration, regardless of whether Q-Day arrives that early.” That is a different claim, and it supports the same action.
The practical upshot: whether Q-Day lands in 2029, 2032, or 2037, the migration timeline of 42 to 54 months means the decision about when to start is already overdue for most enterprises. The uncertainty about the threat date does not reduce urgency. It increases it, because organizations betting on the later end of the range are taking on risk they cannot adequately price.
FAQ: Post-Quantum Cryptography Migration
When will quantum computers break encryption?
Expert consensus places Q-Day, the point at which quantum computers can break RSA and ECC encryption, in the early-to-mid 2030s. However, Google and Scott Aaronson have identified 2029 as an accelerated risk window based on recent hardware progress and revised qubit estimates. This is not a prediction of Q-Day in 2029; it is a risk-management threshold that justifies completing migration before that year.
What is harvest now, decrypt later?
It is an adversarial strategy where encrypted data is intercepted and stored today with the intent to decrypt it once a sufficiently powerful quantum computer exists. Any organization whose data carries confidentiality requirements beyond seven to eight years should treat this as a current-tense risk, not a future one. Nation-state actors with long planning horizons are the primary concern.
What is CNSA 2.0 and when does it apply?
CNSA 2.0 is the NSA’s Commercial National Security Algorithm Suite, the successor to CNSA 1.0. It mandates quantum-resistant algorithms for federal national security systems. New NSS acquisitions must support CNSA 2.0 from January 1, 2027. CNSA 2.0 becomes mandatory across all National Security Systems by December 31, 2031, with full quantum resistance required by 2035 under NSM-10.
Which NIST post-quantum cryptography standards should enterprises implement?
NIST finalized three standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme). These are production-ready and should be piloted in enterprise environments now, with deployment priority given to systems handling long-shelf-life confidential data first.
How many enterprises have a quantum readiness plan?
Fewer than 5% of enterprises currently have a formal quantum-transition plan, according to a peer-reviewed arXiv survey published in September 2025. Separately, ISACA’s 2025 poll found that 41% of organizations do not plan to address quantum computing at this time, and 37% have not discussed it internally at all.
How long does post-quantum cryptography migration take for a large enterprise?
Realistically, 42 to 54 months from the moment an organization is properly resourced and underway. The cryptographic asset inventory phase alone typically takes three to six months. An organization that has not started by the end of 2026 faces serious risk of failing to meet the NIST 2030 deprecation deadline, even if it begins in January 2027.
What You Know Now That Most Organizations Don’t
IBM’s quantum hardware roadmap, Google’s accelerated 2029 internal deadline, and a research paper that cut the qubit threshold for breaking elliptic curve cryptography by a factor of 20 have together changed the calculus of this field in the first half of 2026. The story is not that a quantum computer has broken encryption. It is that the organizations responsible for the internet’s security infrastructure are treating 2029 as the prudent completion date for post-quantum migration, and fewer than 5% of enterprises have a plan.
In the next 6 to 18 months, expect three things. First, government contractor compliance pressure from the January 2027 CNSA 2.0 acquisition deadline will cascade into commercial vendor roadmaps, making PQC readiness a de facto procurement requirement across more of the market than current regulations technically require. Second, more industry practitioners will follow Cloudflare and Google in publicly accelerating their timelines, creating reputational and audit risk for organizations that have not started. Third, cyber insurance underwriters and financial regulators will begin asking formal questions about quantum readiness in the same way they now ask about multi-factor authentication.
Three specific things to watch: the release of IBM’s Quantum Starling technical specs when they arrive in late 2028, NIST’s progress on IR 8547 (which addresses transitioning from currently deployed algorithms), and whether the EU’s regulatory framework develops parallel quantum-resistance mandates timed to the 2025 to 2030 NIS2 implementation period.
The organizations that complete post-quantum cryptography migration before Q-Day is demonstrably close will not win prizes. They will simply avoid the ones that do not.
Stay Ahead of What’s Coming
Get NeuralWired’s weekly briefing on quantum computing, enterprise security, and the technology decisions that matter for CTOs and CISOs.
Subscribe to The Neural Loop
AWS, Azure, and Google Cloud’s Shared Responsibility Gap Caused 61% of Enterprise Breaches in 2024
Cloud Security
AWS, Azure, and Google Cloud’s Shared Responsibility Gap Drove 61% of Enterprise Breaches in 2024
By NeuralWired Cybersecurity Desk | June 28, 2026 | 9 min read
A contract that splits security duties between a cloud provider and its customer sounds sensible in theory. In practice, that contract quietly became the most exploited gap in enterprise security, and 2024 proved it at scale. According to SentinelOne, 61% of organizations reported a major cloud security incident in 2024, up from just 24% in 2023, a 154% year-over-year surge that correlates directly with the operational confusion built into the cloud security shared responsibility model that every hyperscaler uses.
If you’re a CISO, cloud architect, or DevSecOps lead managing workloads across AWS, Azure, or Google Cloud, this article is for you specifically. Not because the model is fraudulent. It isn’t. But because the gap between what the contract says and what your team actually does is where attackers are setting up camp, and the data on dwell times, breach costs, and misconfiguration rates makes that devastatingly clear.
What the Shared Responsibility Model Actually Says
Before naming the problem, it’s worth being precise about what the model is. All three major hyperscalers operate on the same foundational principle: the provider secures “of the cloud,” the customer secures “in the cloud.”
AWS states it plainly: AWS manages security of the cloud, covering physical infrastructure, the host operating system, the virtualization layer, and networking down to the data center level. The customer assumes responsibility for the guest operating system, application software, and security group firewall configuration.
Microsoft Azure documents nearly identical logic but breaks it down further by service model. In IaaS, customers carry full responsibility for deployed applications. In PaaS and SaaS, Microsoft absorbs parts of the stack, but the customer remains responsible for application configuration, code security, and access controls. Crucially, for every deployment model without exception, the customer always owns data and identities.
That last sentence is worth reading twice. Always. Data and identities. That’s not a technicality in the fine print. It’s the front door.
Responsibility Area
AWS / Azure (IaaS)
AWS / Azure (PaaS/SaaS)
Google Cloud (Shared Fate)
Physical infrastructure
Provider
Provider
Provider
Virtualization / hypervisor
Provider
Provider
Provider
Guest OS / patching
Customer
Shared / Provider
Shared (active partnership)
Application configuration
Customer
Customer
Customer (Google advises)
Data encryption and classification
Customer
Customer
Customer
Identity and access management
Customer
Customer
Customer
Network firewall / security groups
Customer
Shared
Customer (Google advises)
The documentation is actually more transparent than critics give it credit for. AWS and Azure spell out the dividing lines with precision. The problem isn’t that providers hide this information. The problem is that most engineering teams never operationalize it, and in a multi-cloud environment where the same DevOps engineer might touch AWS Lambda, Azure App Service, and Google Cloud Run in the same sprint, the responsibility matrix shifts three times with no visible alert.
Google Cloud Breaks Ranks: Shared Fate vs. Shared Responsibility
Here’s the development that most cloud security coverage has underreported. Google has publicly, explicitly rejected the “shared responsibility” framing entirely. Not softened it. Rejected it.
Google’s official documentation describes the traditional model as drawing “a line in the sand,” arguing that this creates an “unhealthy, adversarial dynamic leading to finger-pointing and blame.” Google’s alternative is called “shared fate,” in which the company commits to not being the delineator of where its responsibility ends and the customer’s begins.
“The shared responsibility model [is] where a cloud provider runs the underlying infrastructure and is responsible for the security of that, and then on the other side of that line is what the customer is responsible for. That clearly is contractually and legally correct, but it doesn’t, in our opinion, embody the right philosophical approach for security.”
Phil Venables, CISO, Google Cloud — SDxCentral, March 2024
That’s one hyperscaler’s CISO, on record, saying the model that the other two hyperscalers still use as their official framework is philosophically inadequate for real-world security.
Our read: this is significant not as a marketing position but as a signal. When Google Cloud’s CISO goes on the record calling the shared responsibility model’s dynamics “adversarial,” they’re describing something practitioners have experienced for years. Whether “shared fate” resolves that in practice, or simply rebrands it, is an open question. But the candor itself tells you something about where the industry knows the model is breaking.
The Numbers Behind the Gap
The scale of the shared responsibility gap problem isn’t anecdotal. The data from 2024 and 2025 is specific enough to bring to a board meeting.
61%of organizations suffered a major cloud security incident in 2024, up from 24% in 2023
99%of cloud security failures through 2025 will be the customer’s fault, per Gartner’s forecast
276average days to identify and contain a breach spanning multiple cloud environments
Each of those numbers deserves context. The 61% figure from SentinelOne (measuring 2024 incidents) represents a 154% jump in a single year. That’s not a statistical blip. It tracks directly with the 88% of organizations now running hybrid or multi-cloud environments (Fortinet, 2026), each of which multiplies the responsibility matrix complexity.
Gartner’s “99% customer’s fault” forecast has circulated for nearly a decade and remained stubbornly unchallenged by AWS or Azure, which tells you something about whose interests the liability framing serves. The underlying mechanism is almost always misconfiguration: exposed storage buckets, over-permissive IAM roles, unmonitored API endpoints, and security groups left open “temporarily” until they’re not.
Key Metric for Budget Conversations
Misconfiguration-driven breaches take an average of 186 days to identify and an additional 65 days to contain, at a cost of roughly $3.86 million per incident. That dwell time number alone justifies continuous posture validation tooling in most enterprise environments.
The IBM Cost of a Data Breach Report 2025, conducted by the Ponemon Institute across 600 organizations and 3,470 security leaders in 16 countries, puts the average global breach cost at $4.44 million. For U.S. organizations, that figure climbs to $10.22 million once regulatory fines and detection costs are included. A counterintuitive finding: public cloud breaches average $4.18 million while private cloud breaches average $4.68 million, likely because hyperscalers’ investment in provider-side tooling reduces containment time on the infrastructure layers they do control.
What the providers don’t control, and what those breach costs confirm, is everything in the customer’s column: 70% of cloud breaches in 2024 originated from compromised identities, which sits squarely in customer-owned territory under every version of the shared responsibility model, including Google’s “shared fate.”
The Toyota incident from 2023 remains the cleanest proof point. A misconfiguration, not a provider infrastructure failure, exposed data on approximately 260,000 customers across two separate disclosures. The exposure persisted for over seven years before detection. That’s the real-world illustration of a 276-day dwell time: customer-side gap, customer-owned data, customer’s fault, years of blind spot.
Where the Model Breaks Down in Practice
The documentation is clear. The failure is operational. Here’s specifically where the breakdown happens at the team level.
Multi-cloud multiplies the matrix
88% of enterprises now run hybrid or multi-cloud architectures. That means the same security architect who understands the AWS shared responsibility model for EC2 must mentally context-switch to a different matrix for Azure App Service, and again for Google Cloud Run, often within the same week. Each abstraction level (IaaS to PaaS to serverless) shifts the provider-customer boundary, and there’s no automated notification when it moves.
IAM sprawl is the direct consequence
Identity is always the customer’s responsibility. But in a multi-cloud, multi-team environment, IAM configurations accumulate technical debt faster than any other security control. Over-permissive roles granted for a deployment sprint six months ago become the attack vector next year. The 70% of breaches originating from compromised identities isn’t surprising once you map it to this operational reality.
The “temporary” configuration problem
Security groups opened for testing. S3 buckets left public for a data pipeline handoff. Firewall rules adjusted for a migration and never reverted. These aren’t ignorance failures. They’re process failures, and they occur in teams that know the shared responsibility model perfectly well. Knowing who owns something doesn’t guarantee it gets done.
“The complexity of cloud environments makes it difficult to maintain visibility and control, while reliance on third-party services introduces additional risks.”
Oli Buckley, Professor of Cyber Security, Loughborough University — Infosecurity Europe
Buckley has separately argued that the shared responsibility model is one of the main weaknesses in cloud security, not because CSPs hide their infrastructure security failures, but because the framework gives organizations a false ceiling. Once the boundary is defined, teams often treat their side as something to audit at deployment rather than something to validate continuously.
AI workloads are propagating the gap before the original one closes
Microsoft and Google have both published “AI shared responsibility” addenda, extending the same dividing-line model into AI workloads: prompt injection prevention, model integrity, and training data governance. The customer-side obligations here are even less understood than the original cloud model, and most organizations don’t have the governance tooling to enforce them. IBM’s Cost of a Data Breach Report 2025 found that 61% of organizations lack AI governance technologies altogether, and only 34% of those with policies conduct regular audits for unsanctioned AI usage.
The Critical View: “Shared” Is Doing Too Much Work
The sharpest critique of the shared responsibility model isn’t that it’s wrong. It’s that the word “shared” is misleading about the nature of the arrangement.
“Shared responsibility models are absolutely part of the answer, but also part of the problem. Clearly defining who is responsible for what is complex. A shared responsibility model might suggest you can negotiate the terms and decide where each responsibility lies, but this is misleading. Hyperscalers generally just describe where their own responsibility lies.”
Sander Nieuwenhuis, GRC Advisory Global Lead, Nordcloud
Nieuwenhuis’s framing is the most structurally honest critique available. What gets called a “shared” model is actually a unilateral declaration by the provider about what they will and won’t cover. Customers don’t negotiate the boundaries. They inherit them. And because the boundaries shift by service type, by deployment model, and by abstraction level, the practical effect is that organizations are responsible for a moving line they didn’t draw.
Google’s “shared fate” rebranding addresses the adversarial tone of the original. But Nordcloud’s critique applies there too: “shared fate” could set the wrong expectation in the opposite direction, implying that you should trust the other party to do the right thing, when what regulated industries actually need is documented governance that goes far beyond fate. In healthcare, finance, and critical infrastructure, “we’ll figure it out together” is not a compliance posture.
There’s also a commercial incentive layered into this debate that practitioners should keep in mind. The lion’s share of “shared responsibility gap” literature is produced by security vendors selling CSPM, CNAPP, and IaC scanning tools. The Wiz reports, the CrowdStrike state-of-the-cloud documents, the SentinelOne statistics roundups: these are directionally accurate, but they’re not neutral. Treat the direction as real and the precision with appropriate skepticism.
What CISOs Should Actually Do Now
The shared responsibility model isn’t going away. AWS and Azure’s documentation is unusually precise, and the underlying logic of splitting infrastructure from configuration ownership is sound. What has to change is operationalization.
Build per-service responsibility documentation
For every cloud service in your environment, document the boundary explicitly: what the provider owns, what your team owns, and who on your team owns it. This is tedious and non-automated. It’s also the only way to prevent “I thought they handled that” from becoming your breach postmortem’s opening line.
Treat IAM as a continuous control, not a deployment-time check
70% of cloud breaches start with compromised identities. If your IAM review cadence is quarterly or annual, you’re validating a configuration that may have drifted significantly since the last audit. Continuous CIEM tooling, with alerting on privilege escalation and dormant high-permission accounts, is the direct operational response to the data.
Price the dwell time into your tooling budget
Misconfiguration-driven breaches average 186 days to detect and cost $3.86 million. That’s the number to put in front of a CFO when requesting CSPM tooling budget. The math on continuous posture validation versus one breach contained 50 days earlier is not close.
Watch Google’s “shared fate” model carefully
Google’s explicit break from the “shared responsibility” framing is the first time a major hyperscaler has publicly acknowledged the model’s philosophical inadequacy. Whether AWS and Azure follow, whether through language or through actual shifts in default configurations and tooling, will define the next evolution of cloud security architecture. CISOs evaluating multi-cloud strategy should treat Google’s position as a genuine industry signal, not as a sales pitch.
What is the shared responsibility model in cloud security?
It’s the framework dividing security duties between cloud provider and customer. The provider secures “of the cloud,” meaning physical infrastructure, hardware, and virtualization. The customer secures “in the cloud,” meaning data, identities, applications, and configuration. AWS, Azure, and Google Cloud each publish their own version, with boundaries that shift depending on whether you’re using IaaS, PaaS, or SaaS services.
Who is responsible for security in AWS, Azure, or Google Cloud?
All three split responsibility by service type. In IaaS, customers manage significantly more, including the OS, patching, and network rules. In PaaS and SaaS, the provider absorbs more of the stack. One boundary remains constant across all three and all service models: the customer always owns data and identity. Google Cloud alone rejects the “line in the sand” framing, calling its alternative model “shared fate.”
Why do most cloud breaches happen if providers secure the infrastructure?
Because the infrastructure is not where most breaches occur. Gartner projected that through 2025, 99% of cloud security failures would be the customer’s fault, driven primarily by misconfiguration, weak IAM, and unmonitored access controls rather than provider-side infrastructure compromise. The 61% breach rate surge in 2024 reflects customer-side execution failures, not provider failures.
What is Google Cloud’s “shared fate” model?
Google’s alternative to the traditional shared responsibility model, in which Google commits not to act as a hard delineator between its security obligations and the customer’s. Instead, it partners more actively on secure-by-default configurations and customer security outcomes. Google Cloud CISO Phil Venables has called the traditional shared responsibility model contractually correct but philosophically inadequate for real-world security partnerships.
What is the average cost of a cloud security breach in 2025?
The IBM Cost of a Data Breach Report 2025, covering 600 organizations across 16 countries, puts the global average at $4.44 million. U.S. organizations average $10.22 million when regulatory fines and extended detection costs are included. Misconfiguration-driven breaches specifically average $3.86 million and take 186 days to identify plus 65 more to contain.
How can organizations close the shared responsibility gap?
The most effective starting points are per-service responsibility documentation, continuous IAM review rather than periodic audits, and cloud security posture management tooling to detect misconfigurations before they become dwell-time events. The core shift is treating the shared responsibility boundary as a live, continuously validated control rather than a contractual fact you read once during onboarding.
Where This Goes in the Next 12 to 18 Months
Three things to watch closely.
First, the AI shared responsibility extension. Microsoft and Google have already published AI-specific addenda to their shared responsibility models, covering prompt injection, model integrity, and training data governance. These are areas where customer-side obligations are even less understood than the original cloud model, and the governance tooling to enforce them barely exists at enterprise scale. The 61% of organizations lacking AI governance technologies will become a breach statistic inside the next 18 months.
Second, whether AWS and Azure adopt any of Google’s “shared fate” language, or more importantly, whether they back it with default-secure configurations that reduce the operational burden on customers. The philosophical debate is secondary to whether providers start shipping services that are misconfiguration-resistant by default rather than misconfiguration-prone by default.
Third, the regulatory response. As cloud breaches continue to accelerate, the 45% of all data breaches now occurring in cloud environments will draw regulatory attention to the shared responsibility model itself. Whether GDPR enforcement actions, SEC cybersecurity disclosure requirements, or sector-specific rules start holding customers accountable for model misunderstanding versus willful negligence will shape how enterprises document and audit their responsibility boundaries.
The shared responsibility model is not a broken concept. It’s an under-operationalized one. The gap isn’t in the contract. It’s in the space between what the contract says and what your team does on a Tuesday afternoon during a production incident. That gap is where 61% of 2024’s cloud breaches lived. Closing it doesn’t require a new model. It requires treating the existing one as a living operational document rather than a one-time compliance checkbox.
Stay Ahead of the Next Cloud Security Shift
Get NeuralWired’s weekly intelligence brief on cloud security, AI risk, and enterprise infrastructure delivered to your inbox.
Subscribe to The Neural Loop
GDPR AI Compliance 2026: €7.1B Fines & August DeadlineAI Regulation & Compliance
GDPR AI Compliance 2026: €7.1B in Fines and the August Deadline Your Legal Team Is Already Dreading
By NeuralWired EditorialJune 28, 202612 min read
Key Numbers at a Glance
€7.1B+
Cumulative GDPR fines since 2018
€530M
TikTok fine, May 2025 (largest of the year)
Aug 2, 2026
EU AI Act chatbot transparency deadline
92%
Global orgs subject to GDPR (whether they know it or not)
Your AI is eating personal data right now. The question is whether it has the legal authority to do so. GDPR AI compliance 2026 is not a checkbox exercise anymore: cumulative GDPR fines have crossed €7.1 billion, the EU AI Act’s August 2026 deadline is days away, and regulators across Europe have stopped waiting for complaints before they knock. They’re investigating AI training practices as a matter of course.
If you’re a CTO, DPO, or AI engineering lead at a company that touches EU user data, this article is your accelerated briefing. What’s changed, what’s enforceable right now, and the ten-point compliance checklist your team needs before August 2.
The Enforcement Reality: €7.1 Billion and Counting
Cumulative GDPR fines have exceeded €7.1 billion since enforcement began in May 2018, according to DLA Piper’s 8th Annual GDPR Fines and Data Breach Survey. In 2025 alone, regulators issued €1.2 billion in penalties. That matches 2024 levels, which itself was a record year. Anyone who expected enforcement fatigue to set in has been watching the wrong graph.
The Irish Data Protection Commission deserves a specific mention here. It has issued €4.04 billion of the cumulative total on its own, more than four times all other EU member states combined. Ireland is the registered home of Meta, TikTok’s EU entity, LinkedIn, and Google. The DPC is, in practical terms, Big Tech’s lead regulator in the EU, and it has become progressively more willing to use that authority.
“From growing enforcement in sectors away from big tech and social media, to the use of the GDPR as an incumbent guardrail for AI enforcement as AI-specific regulation falls into place… GDPR enforcement remains a dynamic and evolving arena.”
John Magee, Global Co-Chair, Data Privacy and Cybersecurity Group, DLA Piper (January 2025)
Magee’s point about “sectors away from big tech” matters more than the headline fine numbers. The 2,245 documented GDPR fines now on record (CMS GDPR Enforcement Tracker, early 2026) span healthcare, financial services, telco, and utilities. This is no longer a problem for only platform giants. If you process EU personal data at scale for any commercial purpose, the regulatory risk has arrived in your sector.
Data breach notifications reinforce the pattern. EU DPAs received 443 breach notifications per day in the 2025-2026 period, a 22% year-over-year increase and the first time daily reports have exceeded 400 since GDPR came into force. More breaches mean more investigations, more cross-department scrutiny, and more opportunities for regulators to discover adjacent data processing violations, including AI training practices.
Landmark AI-Specific GDPR Cases (2024-2025)
The pattern of AI-training enforcement crystallised through a specific set of decisions over the past eighteen months. These aren’t hypotheticals. They’re the precedents your legal team will be citing in the next compliance review.
OpenAI / ChatGPT (Italy, December 2024): €15 Million
Italy’s Garante concluded a nearly two-year investigation that began with the first-ever temporary AI ban (March 2023) by imposing a €15M fine on OpenAI in December 2024. The violations were foundational: no adequate legal basis for processing personal data used to train ChatGPT; failure to meet transparency obligations under Articles 5, 12, 13, 24, and 25 GDPR; no age verification for minors; and failure to notify the Garante of a March 2023 data breach affecting 440 Italian users.
OpenAI called the fine “disproportionate” and noted it was “nearly 20 times the revenue we made in Italy during the relevant period.” The Garante’s response was direct:
“ChatGPT users and non-users should be made aware of how to oppose the training of generative artificial intelligence with their personal data and, therefore, be effectively placed in the position to exercise their rights under the GDPR.”
Garante per la Protezione dei Dati Personali, December 20, 2024
Read that carefully. The obligation extends to non-users. Anyone whose data appears in a training corpus has GDPR rights, regardless of whether they have an account with you.
TikTok (Ireland, May 2025): €530 Million
The largest single fine of 2025 landed on May 2, when the Irish DPC fined TikTok €530 million for illegally transferring EEA user data to China. The breakdown: €485 million for violating Article 46(1) GDPR (unlawful data transfers) and €45 million for inadequate transparency about those transfers. TikTok was ordered to bring data processing into compliance within six months or face suspension of all EEA data transfers to China.
The aggravating factor that hardened the decision: TikTok had told the DPC during the inquiry that it did not store EEA user data in China. In April 2025, TikTok admitted it had discovered servers in China containing limited EEA user data. That misrepresentation was treated seriously by regulators. TikTok cited its “Project Clover” European data security initiative in its defence; the DPC was unpersuaded.
Clearview AI (Netherlands, September 2024): €30.5 Million
Clearview AI has now been fined by EU data protection authorities seven times since 2020, accumulating more than €100 million in penalties. The Dutch DPA’s September 2024 fine of €30.5 million targeted the company’s scraping of more than 30 billion facial images from public websites to build a biometric identification database, with no mechanism for data subjects to exercise their rights. This is the clearest existing precedent that AI training on scraped public data, without a lawful basis, constitutes a GDPR violation.
LinkedIn (Ireland, Late 2024): €310 Million
LinkedIn’s €310 million fine centred on processing user behavioral data, including dwell time on posts and scroll speed, for targeted advertising without valid consent under Article 6(1)(a) GDPR. For any AI product that trains on engagement data or uses behavioral signals for personalization, this decision directly applies. The DPC found LinkedIn’s profiling practices lacked transparency, fairness, and purpose limitation.
X / Grok (Under Active Investigation)
The Irish DPC opened a formal inquiry in April 2025 into X Internet Unlimited Company for allegedly using EU user data to train its Grok AI chatbot without lawful basis. No fine has been issued yet. Watch this one: the investigation will produce a decision that fills in the legal gaps left by the OpenAI ruling and could become the definitive judgment on LLM training and GDPR in 2026 or 2027.
Enforcement Pattern to Understand
The DPC has now investigated OpenAI, TikTok, LinkedIn, Meta, and X within a two-year window, all with AI training or AI-driven personalization as a core element. The pattern is no longer emergent. It’s policy.
The August 2026 Deadline: What’s Actually Enforceable Now
The EU AI Act entered into force on August 1, 2024. The compliance clock has been running since then. August 2, 2026 is the next major enforcement threshold, and it activates requirements that many AI-deploying organizations haven’t fully internalized yet.
Here’s what’s enforceable from August 2, 2026 onward (these deadlines were NOT deferred by the May 2026 AI Omnibus):
Chatbot transparency: Users must be told they are interacting with an AI, not a human. This applies at point of interaction, not buried in terms of service.
AI-generated content labeling: Deepfakes and synthetic media must be visibly labeled as AI-generated. The label must be machine-readable as well as human-readable.
High-risk AI system obligations: For systems in employment, credit, healthcare, and critical infrastructure, organizations must have documented risk management systems, data governance frameworks, and human oversight mechanisms in place.
The maximum penalty under the EU AI Act for prohibited AI practices is €35 million or 7% of global annual turnover, whichever is higher. That exceeds GDPR’s maximum of 4%. For a company already under GDPR enforcement for AI training data violations, an AI Act violation on the same product creates compounding liability from two separate regulatory frameworks simultaneously.
What Was Deferred (and What Wasn’t)
On May 7, 2026, the EU reached a provisional agreement on the “AI Omnibus” amendments. The Annex III high-risk AI system obligations were pushed back to December 2, 2027. SME thresholds were expanded to companies with up to 750 employees and €150M revenue. However, the chatbot transparency rules and AI-generated content labeling requirements took effect August 2, 2026 on schedule. Deferral on high-risk systems does not mean deferral on transparency. These are separate obligations.
The general-purpose AI (GPAI) model obligations, covering systems like ChatGPT and Gemini, became enforceable on August 2, 2025. If you’ve integrated a GPAI model into a product, your obligations as a deployer have been active for twelve months already.
CNIL’s June 2025 Guidance: What It Resolves (and What It Doesn’t)
The single most contested compliance question in AI training has been this: can you legally scrape public web data to train an AI model under GDPR? On June 17-19, 2025, France’s CNIL published a definitive answer. Yes, with conditions.
CNIL confirmed that legitimate interest under Article 6(1)(f) GDPR is a viable legal basis for AI training on personal data from public sources. The CNIL explicitly acknowledged that “legitimate interest is the most likely legal basis for AI developers to rely upon, given the challenges in obtaining data subjects’ consent.” This is significant because it validated a compliance pathway that many legal teams had been treating as uncertain territory.
The conditions CNIL requires for that pathway to hold:
A documented proportionality assessment (legitimate interests test) showing the AI use case genuinely outweighs individual privacy interests
Article 14 transparency notices informing data subjects that their publicly available data may be used for AI training
An accessible opt-out mechanism for individuals who object
Honoring robots.txt restrictions and only scraping from sources that do not prohibit it
The firms that got fined did not do any of these things. OpenAI launched ChatGPT without public notices. TikTok misrepresented data storage. Clearview AI provided zero opt-out mechanisms for 30 billion scraped faces. A well-governed AI company following CNIL’s June 2025 guidance has a defensible legal position. A company that never updated its practices after 2023 does not.
Skadden’s analysis of the CNIL guidance adds an important caveat that organizations should carry into their legal assessments:
“The CNIL’s guidance reflects a practical application of what exists, rather than a wait for what’s next. [It] does not resolve the copyright, database rights, commercialisation or deployment-phase constraints that continue to shape the legality of training AI systems in practice.”
Skadden, Arps, Slate, Meagher & Flom LLP, June 2025
Translation: GDPR compliance on training data does not equal end-to-end legal compliance. Copyright exposure, database rights disputes, and deployment-phase obligations are separate questions that CNIL’s guidance does not touch.
The European Data Protection Board reinforced the technical side of this in its April 2025 report: large language models rarely achieve true anonymization standards. You cannot rely on a model “not outputting personal data” as a shield from input-side GDPR obligations. The data subject rights problem, including the right to erasure, attaches at the training stage, not just at inference.
The 10-Point AI-GDPR Compliance Checklist
Based on GDPR enforcement decisions, CNIL’s June 2025 recommendations, EU AI Act obligations effective August 2026, and the EDPB’s April 2025 LLM anonymization report. This is not a substitute for qualified legal review. It is the minimum your team should have documented before August 2.
Phase 1: Training Data
1
Document your lawful basis. Record the Article 6 legal basis for all personal data used in AI training. Legitimate interest is now viable per CNIL June 2025, but it requires a documented balancing test showing your AI use case outweighs individual privacy interests. “We assumed it was fine” is not a legal basis.
2
Publish Article 14 transparency notices. If you’re training on data from third-party sources, including web scraping or purchased datasets, you must inform data subjects. Public data does not equal consent. The Garante made this explicit in the OpenAI decision.
3
Build an opt-out mechanism. Anyone relying on legitimate interest as the training data basis must provide a genuine, accessible opt-out. This must be operational before training begins, not retroactively offered after a regulator investigates.
4
Apply Article 9 rules to special category data. Health data, biometrics, racial or ethnic origin, religion, and political opinions in training sets require explicit consent or a narrow statutory exception. Do not assume general legitimate interest covers these categories.
5
Implement web scraping compliance. Follow CNIL’s companion scraping recommendations: honor robots.txt, use only data from sites that permit scraping, apply data minimization during collection. Ignoring robots.txt is both a technical violation and evidence of bad faith in enforcement proceedings.
Phase 2: System Design and Deployment
6
Complete a DPIA before deployment. A Data Protection Impact Assessment is mandatory under Article 35 for high-risk AI processing. This includes any system doing large-scale profiling, biometric processing, or automated decisions with significant effects on individuals. The DPIA must be completed before deployment, not after launch.
7
Sign Data Processing Agreements with every AI vendor. Article 28 requires a DPA with every processor that handles personal data on your behalf. This includes your LLM providers (OpenAI, Anthropic, Google, Mistral). If a sub-processor trains on your customers’ inputs to “improve the model,” that’s your GDPR exposure, not theirs, if you haven’t contractually prohibited it.
8
Implement privacy by design at the input layer. Do not send full user records to an LLM when only a name and query are needed. Use PII detection and redaction tools before sending data to external models. Microsoft Presidio is one open-source option. Data minimization prevents both over-sharing with vendors and over-retention in model contexts.
9
Update your Records of Processing Activities. Your Article 30 ROPA must explicitly capture AI use cases, LLM integrations, and sub-processor chains. A ROPA last updated in 2022 that predates your AI stack is not evidence of compliance. It’s a documented gap waiting to be cited in an enforcement decision.
Phase 3: August 2026 AI Act Obligations
10
Deploy EU AI Act transparency requirements by August 2. If you operate AI chatbots, disclose AI interaction at point of contact. If you generate synthetic media or content, implement visible AI labeling. For high-risk AI systems in employment, credit, or healthcare, document your risk management framework, human oversight mechanisms, and technical specifications. These requirements are active from August 2, 2026. They were not deferred.
For a comprehensive step-by-step compliance framework, NeuralWired’s GDPR Compliance Checklist 2026 covers EDPB enforcement patterns and 14 technical implementation steps your DPO should run through before the August deadline.
Four Scenarios Where Companies Get This Wrong
These aren’t invented risks. Each maps directly to enforcement patterns visible in the 2024-2025 decision record.
The Anonymization Trap
An engineering team trains an internal LLM on historical customer service chat logs. The assumption: the model is anonymized at inference time, so GDPR doesn’t really apply. The EDPB’s April 2025 report says otherwise. LLMs rarely achieve true anonymization standards. A data subject requests erasure of their data under Article 17. The company cannot comply because the information is now embedded in model weights. The regulator investigates. Fine: up to 4% of global turnover, which for a mid-size SaaS company at $50M ARR means exposure of up to $2M for a decision made by an engineering team without legal review.
The Vendor Chain Liability Gap
An enterprise signs up an AI platform whose underlying LLM provider trains on customer inputs to improve the model. The enterprise’s DPO hasn’t updated the ROPA since 2022. The AI vendor’s sub-processor chain wasn’t checked. Under Article 28, the enterprise as controller is accountable for sub-processor actions. This is exactly the pattern that drove enforcement actions against vendors selling enriched scraped contact data, and it’s now the central risk in any enterprise AI procurement decision. Before you deploy a third-party AI product with EU customer data, confirm contractually what that vendor’s LLM provider does with inputs.
The US Startup Ignoring GDPR
A San Francisco-based SaaS company builds an AI hiring tool. Fifteen percent of users are EU-based. The company has no EU office and assumes GDPR doesn’t apply. Kiteworks data shows 92% of global organizations are subject to GDPR based on the data they collect. A German job applicant files a complaint to the BfDI. Without an EU representative (mandatory for companies outside the EU that process EU resident data), the startup’s legal position is essentially indefensible. Geographic distance from the EU provides zero regulatory protection. None. For a deeper breakdown of enterprise AI risk governance, see NeuralWired’s AI regulation coverage for the latest enforcement developments.
The AI Act and GDPR Pile-On
From August 2, 2026, an organization running an AI-driven HR screening tool faces: a mandatory GDPR DPIA for high-risk automated processing; EU AI Act high-risk classification with its own compliance requirements; a Fundamental Rights Impact Assessment under the AI Act; Article 22 GDPR rights for applicants who don’t want automated decisions affecting their employment; and Colorado’s AI Act impact assessment requirement (effective June 30, 2026) if the tool operates in that state. Missing any single one of these creates enforcement exposure from multiple authorities simultaneously. The legal cost of cleaning that up retroactively far exceeds the compliance cost of doing it right before launch.
Our Read
The four scenarios above share one root cause: AI deployment decisions made faster than legal and compliance review could follow. The companies that get fined aren’t usually doing something egregiously illegal. They’re doing something legal teams hadn’t caught up with yet. The August 2026 deadline is a forcing function. Use it.
The Counterarguments Worth Taking Seriously
A balanced reading of the GDPR AI enforcement landscape requires engaging with the strongest objections to the compliance panic narrative. There are real arguments that regulators and commentators on the other side make credibly.
Most Fines Are Never Actually Paid
The Irish DPC has issued €4.04 billion in fines since 2018. Only €20 million has been collected, according to RTE News reporting from January 2026. Meta, TikTok, and LinkedIn have all appealed their fines. Enforcement moves at litigation speed, not regulatory speed. Companies with serious legal resources can delay actual payment by years. This is a genuine limitation on the deterrence effect that regulators frequently claim.
The GDPR Omnibus Could Narrow Scope
The European Commission’s November 2025 Digital Omnibus Package proposed narrowing the definition of personal data in certain AI contexts and recognizing AI model training as a legitimate interest in some circumstances. If adopted through the formal process (expected 2026-2027), this could retroactively reduce the scope of current compliance obligations. Organizations investing heavily in compliance now could find some of that work made unnecessary by a legislative change in 18 months.
American political pressure, including explicit statements from US VP JD Vance at the Paris AI Summit in February 2025, runs directly counter to EU enforcement trends. Global AI companies operating in both markets face requirements that are not merely different but at times structurally incompatible. The geopolitical dimension of AI regulation is a real constraint that purely technical compliance frameworks can’t resolve. The TikTok fine, for example, is at least partly a story about data sovereignty politics between the EU and China, not purely about GDPR’s technical requirements.
None of these counterarguments eliminate the compliance obligation. But they are relevant to how organizations calibrate urgency and legal strategy, and they deserve inclusion in any honest assessment of where the AI training data privacy GDPR landscape actually stands.
FAQ: GDPR AI Compliance 2026
What is the maximum GDPR fine in 2026?
The maximum GDPR fine is €20 million or 4% of annual global turnover, whichever is higher, for the most serious violations. The EU AI Act, effective August 2026, adds a separate penalty layer of up to €35 million or 7% of global turnover for prohibited AI practices, which exceeds GDPR’s maximum. An organization facing violations under both frameworks simultaneously can accumulate penalties from two separate enforcement tracks.
Can AI models be trained on personal data under GDPR?
Yes, with conditions. France’s CNIL confirmed in June 2025 that training AI on personal data from public sources can be lawful under GDPR’s legitimate interest basis (Article 6(1)(f)), provided organizations conduct a proportionality assessment, publish Article 14 transparency notices, and offer accessible opt-out mechanisms. Scraping public data alone does not create automatic GDPR compliance.
Why was TikTok fined €530 million under GDPR in 2025?
Ireland’s Data Protection Commission fined TikTok €530 million in May 2025 for illegally transferring EU user data to China without adequate safeguards (Article 46(1) GDPR) and for inadequate privacy notices about those transfers (Article 13(1)(f)). An aggravating factor was that TikTok had told the DPC during the investigation it did not store EEA user data in China, then admitted in April 2025 that servers in China had contained limited EEA data.
What does the EU AI Act require by August 2026?
From August 2, 2026, organizations must disclose when users interact with AI chatbots, visibly label AI-generated content including deepfakes, and, for high-risk AI systems in employment, credit, and healthcare, implement documented risk management systems, data governance frameworks, and human oversight mechanisms. These obligations were not deferred by the May 2026 AI Omnibus agreement.
Does GDPR apply to US companies using AI?
Yes. GDPR applies to any organization processing personal data of EU residents, regardless of where the company is based. The Kiteworks 2026 Data Sovereignty Report found 92% of global organizations are subject to GDPR based on data collected. Clearview AI, a US-based company, has accumulated more than €100 million in EU fines. Geographic distance provides zero protection under the regulation.
What are the most common GDPR violations in AI systems?
Enforcement actions from 2024 to 2025 identify four recurring violations: (1) no sufficient legal basis for data processing used in AI training; (2) inadequate transparency and user information; (3) failure to verify user age, particularly for minors; and (4) unlawful cross-border data transfers. These four violations appear in the OpenAI, TikTok, Clearview AI, and LinkedIn enforcement decisions.
What is a Data Protection Impact Assessment (DPIA) for AI?
A DPIA is a mandatory document under GDPR Article 35 that assesses risks to individuals from high-risk data processing. For AI systems, it must cover the necessity and proportionality of data use, risks from automated decision-making or profiling, specific mitigation measures, and how data subjects can exercise their rights. Organizations must complete a DPIA before deploying any high-risk AI system, not after launch.
How much have total GDPR fines reached?
Cumulative GDPR fines exceeded €7.1 billion since the regulation took effect in May 2018, according to DLA Piper’s annual enforcement survey (January 2026). Ireland’s Data Protection Commission alone has issued €4.04 billion of that total. €1.2 billion in fines were issued in 2025, matching 2024 levels, with no sign of enforcement slowdown.
What Comes Next: The 6-to-18-Month Picture
The X / Grok investigation will produce a decision. When it does, it will be the most consequential AI training data GDPR ruling since the OpenAI case, because X’s product was explicitly built to train on user-generated content at scale, and the legal arguments OpenAI made in Italy will be tested again with a different fact pattern and a more mature enforcement framework.
The GDPR Omnibus adoption process will conclude sometime in 2026 or 2027. If the narrower personal data definition survives the legislative process, some current compliance obligations may be relaxed. If it doesn’t, the current framework holds and organizations that deferred compliance on the assumption of reform will be exposed.
Colorado’s AI Act took effect June 30, 2026. Maryland’s LLM training disclosure requirement took effect April 1, 2026. More than 20 US states now have comprehensive data privacy laws. The assumption that US-based AI companies operate in a regulatory-light environment is no longer accurate. For a deeper look at how US chip export controls and technology policy intersect with these data sovereignty questions, NeuralWired’s guide to Nvidia export controls and China data flows covers the geopolitical layer.
Three specific things to watch or act on before September 2026:
Run your LLM vendor contracts through Article 28. Confirm every AI vendor in your stack has a signed DPA that explicitly covers sub-processor chains and prohibits training on your customer inputs without your consent.
Update your ROPA to reflect your current AI stack. If your Records of Processing Activities predate any LLM integration in your product, you have a documented compliance gap that will surface in any DPA audit.
Watch the Irish DPC’s X / Grok decision. Whatever the DPC decides will set the practical standard for LLM training data compliance across Europe for the next several years.
The question your AI is answering right now is whether it has the legal authority to process the data it’s processing. That question has enforceable answers as of August 2, 2026. Now is the time to make sure yours is one of them.
Stay Ahead of AI Regulation
Get the AI Act deadlines, GDPR enforcement decisions, and enterprise compliance briefings that matter, every week, in plain language. No noise.
Subscribe to The Neural Loop
Your Cloud Is Misconfigured Right Now. 82% of Enterprises Are. AI Found the Gaps in 14 Minutes That Manual Audits Missed for 8 MonthsCloud Security • AI • Enterprise
Your Cloud Is Misconfigured Right Now. 82% of Enterprises Are. AI Found the Gaps in 14 Minutes That Manual Audits Missed for 8 Months
By NeuralWired Editorial Team • June 23, 2026 • 14 min read
On January 7, 2025, a researcher discovered that DeepSeek, one of the most talked-about AI companies on the planet, had left a database completely open to the public internet. No password. No authentication. No encryption. Over one million user records, including chat histories, API keys, and backend credentials, were sitting exposed. The breach didn’t require a sophisticated attack. It required a browser and a URL. DeepSeek suspended global signups the same day.
This wasn’t a nation-state operation. It wasn’t a zero-day exploit. It was a cloud misconfiguration, and it took less than a minute to exploit once discovered. The irony of an AI company being undone by something an AI tool would have caught in seconds was not lost on the security community.
Now consider this: DeepSeek’s misconfiguration almost certainly existed for weeks or months before anyone found it. That’s not unusual. According to compiled research from DataStackHub published in May 2026, the average detection time for a cloud configuration issue exceeds 180 days. Not 180 hours. Not 180 minutes. A hundred and eighty days. For context, that’s the time it takes for summer to turn to winter. Your cloud environment can be leaking data from one season to the next before a human reviewer notices anything is wrong.
AI-powered cloud security tools compress that window to minutes. The gap between those two realities is where this article lives.
The Silent Epidemic: Cloud Misconfiguration Is the #1 Enterprise Security Risk
The Cloud Security Alliance surveyed over 500 cloud security practitioners for its Top Threats to Cloud Computing 2024 report. Misconfiguration and inadequate change control ranked first. Not ransomware. Not nation-state intrusion. Not zero-day vulnerabilities. A mistyped setting. A forgotten public access toggle. An IAM policy that’s slightly too permissive.
Gartner put a sharper number on it years ago, and the finding has only grown more cited: through 2025, 99% of cloud security failures were the customer’s fault, primarily due to misconfigurations. The cloud platform didn’t fail. The configuration of it did.
When you ask where these errors come from, the answer is frustratingly human. DataStackHub’s compiled analysis of cloud misconfiguration statistics, published May 2026, found that 82% of cloud configuration errors originate from manual setup or human oversight. Engineers working fast. Scripts without peer review. Infrastructure spun up in a sprint that nobody went back to audit. The cloud didn’t create this problem. The pace of cloud adoption did.
The numbers compound. Ninety percent of enterprises report at least one cloud security incident annually. Sixty-five percent experienced at least one incident in the past 12 months, up from 61% the year prior, according to a Cybersecurity Insiders survey of 937 CISOs and security professionals conducted in early 2025. The trajectory is not improving.
“Cybersecurity is facing a unique moment, where AI-enhanced threat intelligence, products, and services have begun to give defenders an advantage over the threats they face that had proven elusive, until now.”
Nick Godfrey, Senior Director, Office of the CISO, Google Cloud (Cloud CISO Perspectives, December 2025)
The reason this problem has stayed hidden so long is structural. Cloud infrastructure scales exponentially. Security governance doesn’t. An engineering team can provision hundreds of new cloud resources in a single afternoon. The security team is still reviewing last quarter’s audit.
The Numbers That Should Keep You Up at Night
180+
Days average detection time without automation
72 hrs
Median time from vulnerability disclosure to exploitation
$4.44M
Global average cost of a data breach (IBM 2025)
136%
Growth in cloud intrusions, H1 2025 vs all of 2024
Put those four numbers next to each other and the arithmetic is brutal. Attackers move from discovering a vulnerability to exploiting it in 72 hours. Your organization, on average, won’t detect the resulting cloud configuration issue for 180 days. That’s not a detection gap. It’s a six-month open window.
The financial damage follows predictably. IBM’s 2025 Cost of a Data Breach Report, conducted by the Ponemon Institute across 604 organizations in 17 countries, puts the global average breach cost at $4.44 million. In the United States, that number climbs to $10.22 million. Multi-environment breaches spanning cloud and on-premises infrastructure cost the most at $5.05 million. These aren’t projections. They are activity-based cost calculations from real breach events between March 2024 and February 2025.
Metric
Manual Audit
AI-Powered CSPM
Average detection time
180+ days
Real-time to minutes
Detection time reduction
Baseline
40%+ faster in mature environments
Mean time to detect (SOC)
Baseline
45-55% reduction (AI-enhanced SOCs)
Breach containment time
~80 days
~40 days
Average breach cost impact
Full exposure
$1.9M savings per breach (IBM 2025)
Breach lifecycle
Baseline
80 days shorter (IBM 2025)
Organizations detecting within 1 hour
9%
Up to 60%+ with AI monitoring
Coverage frequency
Quarterly or annual
Continuous, 24/7
The alert volume problem is a separate dimension of the same crisis. Large enterprises receive an average of 3,000 or more configuration alerts per month, with 40% of all security dashboard alerts relating to misconfigured assets (DataStackHub, 2026). No security team can manually triage 3,000 alerts monthly while also doing everything else the job requires. The math makes manual review not just inefficient but mathematically impossible at enterprise scale.
Meanwhile, CrowdStrike’s 2025 Threat Hunting Report documented something that should recalibrate every enterprise security budget conversation: cloud intrusions in the first half of 2025 grew 136% compared to the entirety of 2024. Attackers have automated their cloud reconnaissance. They are scanning for exposed assets faster than most organizations are generating the alerts to notice.
The Manual Audit Is Already Dead. The Market Just Hasn’t Admitted It Yet.
Toyota learned this in 2023. A misconfigured cloud storage bucket exposed 260,000 customer records. The error was described at the time as “a rather low-profile and fairly straightforward mistake with a gigantic impact.” Toyota is not a company short on engineering talent. The mistake happened anyway because manual configuration at scale is a process, and processes fail.
Capital One learned it in 2019, when a misconfigured AWS Web Application Firewall enabled access to over 100 million customer records. The regulatory fine from the OCC was $80 million. The class action settlement reached $190 million. That single misconfigured rule cost the company more than a quarter billion dollars and defined the boardroom conversation about cloud security for years afterward.
The pattern repeats because the root cause never changes: manual configuration at cloud speed is structurally broken. Three forces made this inevitable.
Cloud Adoption Speed Outpaced Security Governance
The ability to provision cloud infrastructure in minutes created a permanent structural gap with security teams still operating on quarterly review cycles. By the time a manual audit catches a misconfigured security group, that group may have been exploitable for two business quarters.
Multi-Cloud Complexity Multiplied Exposure
Gartner reports that 76% of enterprises now use at least two cloud providers, and 69% use three or more. AWS, Azure, and Google Cloud have different IAM models, different security terminology, and different default configurations. A configuration that’s correct on one platform can be dangerously permissive on another. Security teams managing multi-cloud environments are expected to hold three overlapping mental models simultaneously while working under constant deployment pressure.
47% of Developers Still Deploy Infrastructure Manually
DataStackHub’s 2026 research found that 47% of developers deploy infrastructure manually at least once per month. Every manual deployment is a potential misconfiguration event. Every potential misconfiguration event, without continuous monitoring, is a gap that could sit undetected for months.
Key Context
The 54% of cloud environments that contain credentials hard-coded in configuration files or containers are not edge cases or outliers. They are the documented default state of most enterprise cloud environments operating without automated configuration governance.
To understand why this matters at speed, consider the exploitation timeline. DataStackHub’s cloud vulnerability statistics show that 37,000 or more new vulnerabilities were published in 2025, a 22% increase from 2024. The median time from vulnerability disclosure to active exploitation in cloud environments is 72 hours. Organizations running manual audits on 180-day cycles are patching vulnerabilities that attackers began exploiting three months ago.
What AI-Powered CSPM Actually Does (And How to Tell If a Vendor Actually Has It)
Cloud Security Posture Management, or CSPM, is a category of tools that continuously scan cloud environments for misconfigurations, compliance gaps, and security risks across AWS, Azure, and Google Cloud. The category has existed for years. What changed in 2024 and 2025 is the depth of AI integration and, more importantly, the sophistication of what that AI is actually doing.
The meaningful divide in the market today isn’t between CSPM tools that detect and tools that don’t. Most of them detect. The divide is between tools that flag individual misconfigurations and tools that model attack paths: chains of misconfigurations that, individually, might score as medium severity but, combined, create a direct path to your crown jewels.
Attack Graph Analysis vs. Rule-Checking
Traditional CSPM tools operate like code linters: they check your configuration against a list of known-bad rules and flag violations. This is useful. It is not sufficient. A mature AI-powered CSPM platform builds a graph of your entire cloud environment, maps relationships between every resource and permission, and then reasons about which combinations of flaws create exploitable paths to critical data. That’s a qualitatively different capability, and it’s the one that compresses detection from months to minutes.
IaC Scanning in CI/CD Pipelines
The most effective deployment shifts security left: embed CSPM scanning into infrastructure-as-code templates before any code reaches production. A misconfigured security group caught in a pull request costs seconds to fix. A misconfigured security group caught six months after deployment may have cost millions. Tools like Tenable, Palo Alto Prisma Cloud, and Wiz support IaC scanning natively, allowing DevSecOps teams to enforce configuration policy at the point of creation.
Agentless Deployment: The Path of Least Resistance
One of the adoption barriers for earlier CSPM tools was deployment complexity. Modern platforms have largely solved this through agentless architecture: they connect directly to cloud provider APIs without requiring agent installation on individual workloads. Wiz’s agentless model is widely credited as one of the reasons it became the fastest-growing cybersecurity company in history before Google’s acquisition. Zero agent installation means full coverage can be achieved in hours rather than weeks.
“Architecture beats features. An AI bolted onto a weak security foundation won’t save you. If identity is broken, data governance is unclear, or network visibility is fragmented, AI simply operates on bad inputs and produces unreliable outputs.”
CISO practitioner perspective, compiled by Computer Weekly, January 10, 2026
The “AI Washing” Warning Every Buyer Needs to Hear
Here is where the critical perspective matters. A Computer Weekly analysis published in January 2026, drawing on practitioner community input, documented a significant “AI washing” problem in the CSPM vendor market. Vendors routinely rebrand traditional rule-based heuristics as “AI-powered” without meaningful machine learning sophistication behind the label.
Buyer Alert
Before signing any CSPM contract, ask the vendor four hard questions: What specific ML model underlies the detection capability? How frequently is it retrained on new threat data? What is the documented false positive rate at enterprise scale? And what is the escalation path when the AI is wrong? Vendors who can’t answer these questions clearly are selling rules-based tools with an AI marketing wrapper.
The Lacework trajectory makes this concrete. The company raised $1.8 billion at an $8.3 billion peak valuation partly on AI-capability claims. In August 2024, Fortinet acquired it for an estimated $200 to $230 million. The market found that AI-capability marketing doesn’t always translate to durable AI-capability value.
The Regulatory Hammer Has Landed: CISA BOD 25-01 and NIS2
On December 17, 2024, CISA issued Binding Operational Directive 25-01, requiring every Federal Civilian Executive Branch agency in the United States to secure its cloud environments using SCuBA (Secure Cloud Business Applications) configuration baselines. This wasn’t a recommendation. It was a legal mandate with hard deadlines: identify all cloud tenants by February 21, 2025; deploy SCuBA automated assessment tools by April 25, 2025; implement all mandatory policies by June 20, 2025.
“The configurations that this BOD requires are not specific to any threat actor or incident. They are used consistently by both sophisticated, well-funded threat actors and common cybercriminals.”
Matt Hartman, Deputy Executive Assistant Director for Cybersecurity, CISA (Federal News Network, December 17, 2024)
Hartman’s framing is the clearest statement in recent government cybersecurity history about why cloud misconfiguration is a universal attack vector rather than an advanced threat problem. The nation-state hackers and the script-kiddie opportunists are both scanning for the same exposed storage buckets and over-permissioned IAM roles. Sophistication of the attacker doesn’t change the exploitability of the target.
The BOD’s lineage traces directly to SolarWinds. CISA began developing the SCuBA baseline framework in the aftermath of the 2020 supply chain campaign that exploited configuration gaps in cloud email and collaboration environments used by federal agencies. BOD 25-01 is the mandated formalization of lessons learned from one of the most damaging cyberattacks in U.S. government history.
For private sector organizations, BOD 25-01 is not legally binding. But it is directionally definitive. Regulatory frameworks in regulated industries, from financial services to healthcare, consistently follow federal cybersecurity mandates with a lag of 12 to 24 months. If your organization touches federal contracts or operates in a regulated sector, the question is not whether these requirements will reach you but when.
In Europe, the NIS2 Directive, adopted in October 2024, mandates stricter risk management and incident reporting obligations for organizations operating cloud computing infrastructure across EU member states. Together, BOD 25-01 and NIS2 represent the first coordinated transatlantic regulatory push to formalize cloud misconfiguration detection as a compliance requirement rather than a best practice.
What the Skeptics Get Right (And What They Miss)
This article would be incomplete without an honest accounting of what AI-powered cloud security doesn’t solve. The critical perspective isn’t a footnote. It’s load-bearing.
Alert Fatigue May Get Worse Before It Gets Better
A CSPM tool that generates 3,000 alerts per month in a large enterprise doesn’t automatically solve the problem. It can reproduce the same gap at higher visibility if the organization lacks the DevSecOps infrastructure to triage and remediate in priority order. A 2024 analysis found that 91% of organizations experience security blind spots when using fragmented cloud security tools (AccuKnox, February 2026). Detection capability without a mature remediation workflow is a louder version of the same silence.
The differentiator here is intelligent prioritization. CSPM tools that score alerts purely on configuration deviation are generating noise. Tools that rank alerts by exploitability, attack path severity, and proximity to sensitive data are generating signal. The buying decision has to account for this distinction.
Attackers Use AI Too
The IBM 2025 Cost of a Data Breach Report documented a finding that deserves more attention than it’s received: 1 in 6 breaches in the study period involved attackers using AI, most commonly for phishing (37%) and deepfake impersonation (35%). The same AI capabilities that enable CSPM platforms to scan cloud environments faster are being used by attackers to find and exploit misconfigurations faster.
Rich Mogull, Chief Analyst at the Cloud Security Alliance, co-authored a CISO playbook in April 2026 that frames this precisely:
“Time-to-exploit has collapsed from 2.3 years in 2018 to under one day in 2026. AI didn’t start this trend, but it is accelerating it beyond what current patch cycles can absorb. Static, manual defenses are structurally obsolete.”
Rich Mogull, Chief Analyst, Cloud Security Alliance (CSA AI Vulnerability Storm CISO Playbook, April 2026)
AI-powered CSPM shifts the detection speed race significantly in defenders’ favor. It doesn’t end the race. Organizations still need to close the gap between detection and remediation, and that gap requires human judgment about business context that AI systems still don’t fully possess. (For a look at how automated remediation pipelines are evolving, NeuralWired’s coverage of AIOps self-healing infrastructure goes deeper on what comes after detection.)
Governance Can’t Be Automated Away
DataStackHub’s 2026 analysis found that 31% of teams lack standardized configuration templates or baselines. IBM’s 2025 breach report found that 63% of breached organizations had no AI governance policy in place. Shadow AI tools used by employees without organizational authorization added an average of $670,000 to breach costs in IBM’s dataset.
Tools without governance are inputs without outputs. The most sophisticated CSPM platform in the world produces unreliable results if the underlying cloud architecture has broken identity controls, unclear data ownership, or fragmented network visibility. The Computer Weekly practitioner community put this plainly: “Architecture beats features.” That’s not skepticism of AI. That’s a prerequisite for it.
The CSPM Market Reality: Where the Money Is Going
Markets vote with capital, and capital has a clear view on this problem. Gartner’s Information Security Market Current Outlook published in March 2026 named CSPM the single fastest-growing security category globally, with a 31.23% compound annual growth rate. The CSPM market was valued at $4.7 billion in 2025 and is projected to reach $16.2 billion by 2030. Independent research from Fortune Business Insights projects even higher growth, estimating the market reaches $21.31 billion by 2034.
Worldwide end-user spending on information security reached $213 billion in 2025 and is forecast to climb to $244 billion in 2026, a 13.3% increase. Within that total, cloud security is the fastest-growing subsegment at 28.8% year-over-year growth (Gartner, July 2025).
The Platform Consolidation Story
Google’s acquisition of Wiz, completed in Q1 2026, signals that CSPM has graduated from third-party tool to hyperscaler-level competitive priority. Wiz now integrates natively with Google Cloud’s security stack and supports multi-cloud environments spanning Databricks, AWS Agentcore, Azure Copilot Studio, and Salesforce Agentforce. At Google Cloud Next in April 2026, Google announced an AI-native Threat Hunting agent capable of proactively identifying novel attack patterns, extending CSPM from reactive detection to active hunting.
Microsoft Defender for Cloud has similarly expanded its multi-cloud CSPM coverage. Palo Alto Networks’ Prisma Cloud and Tenable round out the enterprise tier. Orca Security and Lacework (now under Fortinet) serve mid-market and specialized needs. The market is consolidating around platforms, not point tools.
Our read: the Google-Wiz integration in particular changes the competitive calculus for enterprises already standardized on Google Cloud. CSPM isn’t an add-on purchase anymore. It’s a default capability of the platform. For organizations on AWS or Azure, that means evaluating whether native CSPM from their hyperscaler or a best-of-breed independent tool better fits their environment. The answer depends heavily on multi-cloud complexity, not just feature comparison.
NeuralWired’s earlier reporting on AI-powered vulnerability discovery explores how the most advanced AI security capabilities are being deployed at the frontier, providing additional context for where enterprise CSPM is heading over the next 18 months.
What CISOs and CTOs Should Do This Week
The research case is complete. Here is the operational translation.
