DORA Report: AI Code Review Time Jumps 441% | NeuralWired
DevOps & Engineering
DORA Report: AI Code Review Time Jumps 441%
By the NeuralWired Engineering Desk · Updated July 2026 · 11 min read
Your team ships AI generated code faster than ever. Your review queue is where that speed goes to die. New data from Google’s DORA team and a 22,000 developer telemetry study from Faros AI both point to the same uncomfortable number: median time spent in code review is up 441.5% as AI adoption climbed, not down. If you’re an engineering leader who assumed AI code review would fix the bottleneck AI code generation created, the 2026 numbers say otherwise, and you need to see them before your next tooling decision.
Every AI coding tool vendor is currently selling some version of the same promise: write code faster, review it faster, ship it faster. The generation half of that promise is real. The review half is where the story falls apart.
Faros AI’s “AI Engineering Report 2026: The Acceleration Whiplash” is the most current dataset available on this question. It draws on two years of telemetry from 22,000 developers across more than 4,000 teams, comparing each organization’s lowest AI adoption periods to its highest. The headline findings:
Median time to first PR review is up 156.6%
Average time spent in code review is up 199.6%
Median time in review overall is up 441.5%
AI code acceptance rate rose from 20% to 60%
Faros AI sells engineering analytics software built on DORA metrics, so treat this as vendor research with a stake in the outcome, not a neutral academic study. Still, the direction of the finding lines up with Google’s own 2025 DORA State of AI Assisted Software Development report, produced with GitHub and IT Revolution. DORA’s framing is that AI acts as an amplifier: it strengthens teams that already have solid engineering practices, and it exposes the weaknesses of teams that don’t. Roughly 90% of developers now use AI daily, according to the report, but nearly a third, 30%, say they have little to no trust in AI generated code.
That distrust has a name in the DORA report: the “verification tax.” Time saved writing code gets spent auditing it instead, and that tax lands squarely on reviewers.
A note on the “4.2 hours vs 90 seconds” claim you might have seen elsewhere. That comparison doesn’t hold up against any primary source we checked. Real human review times range from roughly 4 hours at Google internally to 3 to 5 days at typical enterprise teams, and AI review tools themselves range from about 30 seconds (GitHub Copilot) to several minutes for deep-index tools like Greptile. We’re using the sourced numbers above instead.
Why Review Time Is Exploding, Not Shrinking
Kent Beck, the creator of Extreme Programming and a co-author of the Agile Manifesto, put it about as bluntly as anyone in the industry has:
“We’re accumulating code faster than we are accumulating trust.”
Kent Beck, “Trust Factory” newsletter, newsletter.kentbeck.com
That’s the whole problem in one sentence. AI generated code is, by multiple accounts, superficially convincing. It’s idiomatic. It’s well named. It reads like something a competent engineer wrote. Which is exactly why surface level review, the thing AI review tools are best at, becomes less useful over time: the bugs living in that code tend to be structural, not stylistic. Faros AI’s analysis makes the point directly, arguing that the engineers with the deepest system knowledge are the ones spending their most valuable hours unraveling plausible looking code that should never have reached them in that state.
An independent academic study published on arXiv in December 2024, still the most cited empirical study of its kind as of mid-2026, tested an LLM based automated review tool in real production repositories. Average PR closure time rose from 5 hours 52 minutes before the bot to 8 hours 20 minutes after, a statistically significant increase. Results varied by project. One project’s closure time dropped from 6 hours 6 minutes to 3 hours 7 minutes. Another rose from 20 hours 22 minutes to 30 hours 51 minutes. Roughly 73.8% of the tool’s comments were acted on, and developers reported a modest quality improvement, but the bot also introduced faulty reviews and irrelevant comments that added friction of its own.
Stack Overflow’s 2025 Developer Survey backs this up from the sentiment side: 84% of developers use or plan to use AI tools, yet 66% say their biggest pain point is AI output that’s “almost right,” and 45% say debugging AI generated code takes longer than debugging their own. Sonar’s State of Code 2026 survey of 1,149 developers found 96% don’t trust that AI generated code is functionally correct, but only 48% say they always review before committing. That gap between distrust and actual review discipline is worth sitting with.
The Benchmark Problem: Nobody Agrees What “Accurate” Means
Here’s the part that should worry anyone about to sign a contract with an AI code review vendor: the bug catch rate numbers those vendors publish don’t agree with each other, and they don’t agree with independent testing either.
Tool
Vendor-reported catch rate
Independent benchmark result
Greptile
82% (own 50-PR benchmark)
24% (Martian benchmark)
GitHub Copilot
54% (Greptile’s benchmark)
Not independently ranked in same test
CodeRabbit
44 to 51% (varies by benchmark)
46% (Macroscope’s ranking)
Cursor BugBot
Not separately vendor-reported
42% (Macroscope’s ranking)
Macroscope
Self-reported top performer
48% (its own ranking)
Source: Augment Code’s tool comparison, which flags the discrepancy directly, and buildmvpfast.com’s 2026 tool roundup. There is currently no independent, consensus benchmark for AI code review accuracy. Every number circulating in vendor decks was either run by the vendor or selected by the vendor. Treat any single “catch rate” claim as a marketing input, not a procurement fact, and run a short pilot against known bugs in your own codebase before you buy anything.
CodeRabbit’s own analysis of 470 pull requests, worth noting as vendor data about a competitor’s output rather than its own, found reviewers spend 91% more time reviewing AI generated code than human written code, with three times more readability problems and 75% more logic errors.
What This Means If You Run an Engineering Org
If you’re a VP of Engineering, a Director, or a staff engineer sitting on a tooling decision right now, here’s the shift that matters. Review is the bottleneck now, not code generation. If you’ve been measuring success by PRs merged or deployment frequency alone, you’re getting a misleading picture, because DORA’s and Faros’s data both show throughput metrics improving at the exact same time that stability metrics, change failure rate and rework rate especially, get worse.
DORA’s response to this was structural: the framework expanded from four metrics to five in 2024, adding “rework rate” specifically because AI driven throughput gains were making the old four-metric picture insufficient. That’s the metric to start tracking alongside deployment frequency, not instead of it.
GitHub’s own product team has landed on a position that’s becoming the de facto industry norm: a human always owns the merge button. From GitHub’s official blog:
The team’s interviews with developers found something specific worth stealing for your own workflow: running a Copilot self-review before opening a PR eliminated roughly a third of trivial back-and-forth comments. That’s the actual win available right now, catching the small stuff before a human ever sees the diff, not replacing the human’s judgment call on whether the change should exist at all.
Jon Wiggins, a machine learning engineer at Respondology, put the accountability question in plain terms:
“If an AI agent writes code, it’s on me to clean it up before my name shows up in git blame.”
Jon Wiggins, ML Engineer, Respondology · via github.blog
Any team that’s dropped the human merge gate entirely should be treated as an outlier taking on real production risk, not a leading indicator of where the industry is headed.
The Contrarian Case: 19% Slower, Not 20% Faster
The single strongest piece of contrarian evidence in this entire dataset comes from METR, the nonprofit Model Evaluation and Threat Research group. Its randomized controlled trial, reported in MIT Technology Review, found experienced developers believed AI made them 20% faster. Objective measurement of the same developers found they were actually 19% slower.
That’s not a survey. It’s a controlled study, which makes it much harder to wave away than the productivity claims coming out of vendor marketing. Mike Judge, a principal developer at the software consultancy Substantial, described the gap between perception and reality from the inside:
“I was complaining to people because I was like, ‘It’s helping me but I can’t figure out how to make it really help me a lot.’”
Mike Judge, Principal Developer, Substantial · via MIT Technology Review
Is the “AI review saves time” story realistic on a 2026 timeline? Not straightforwardly. The one controlled academic production study we found (the arXiv paper above) showed AI review increasing PR closure time. Any claim that AI review is a simple time saver needs that caveat attached, because in the best documented empirical test available, it wasn’t one.
GitHub Code Quality’s July Launch: A Real Test Case
There’s a genuinely useful stress test coming. GitHub Code Quality, the governance and quality gate product bundling CodeQL analysis with Copilot code review, moves from public preview to a paid, generally available product on July 20, 2026. More than 10,000 enterprises used the preview. Pricing lands at $10 per active committer per month on enabled repositories, plus usage based consumption for AI powered features like Copilot code review and Copilot Autofix.
Watch what happens to review time metrics at organizations adopting this over the next two quarters. If GitHub’s human-gated model actually closes the gap the data above describes, that’s the strongest real-world signal we’re likely to get all year.
What to Actually Do About It
Track rework rate and time-in-review, not just deployment frequency. A team that ships faster while rework climbs isn’t actually faster.
Keep a mandatory human merge gate. This is GitHub’s own stated product philosophy, not just an internal best practice.
Run AI self-review before human review, not instead of it. GitHub’s data shows this cuts trivial back-and-forth by roughly a third.
Pilot any review tool against your own codebase’s known bugs before trusting a vendor’s published catch rate.
Cap PR size. Multiple sources point to growing PR size, not tooling choice, as the actual driver of review slowdown.
FAQ
Does AI code review replace human code review?
No. Every credible source, including GitHub’s own product team, treats AI review as a first-pass filter for mechanical issues like typos and unused imports, while reserving architecture decisions and merge accountability for human reviewers. GitHub’s official position is that developers will always own the merge button.
How much time does AI code review actually save?
Results are mixed and contested. Vendor claims report time savings, but the most rigorous data, DORA’s 2025 report and Faros AI’s 2026 telemetry from 22,000 developers, found overall review time increasing, with median time-in-review up 441.5% as AI-generated code volume outpaced human review capacity.
What is the most accurate AI code review tool?
There is no independent consensus benchmark. Vendor-run tests and independent benchmarks disagree sharply. Greptile scores 82% bug-catch-rate on its own benchmark but 24% on the independent Martian benchmark. Pilot tools against your own codebase rather than trusting a published leaderboard.
Do AI code reviews catch more bugs than human reviewers?
AI reviewers are strong at mechanical pattern matching, things like missing awaits or unused variables, but consistently weaker at architectural and cross-file reasoning unless built around full-codebase indexing. No tool currently matches an experienced human reviewer’s judgment on whether a feature should exist at all.
Is AI-generated code more likely to have bugs than human-written code?
Yes, per multiple 2026 sources. CodeRabbit’s analysis of 470 pull requests found AI-generated code produced 75% more logic errors and three times more readability problems than human-written code, alongside rising bug rates as AI-code acceptance climbed from 20% to 60%.
Where This Goes Next
Here’s what the 2026 data actually tells you, stripped of the vendor gloss: AI hasn’t made code review faster. It’s made code review the bottleneck the rest of the pipeline is now waiting on, and the tools built to fix that problem haven’t closed the gap yet. Median time-in-review is up 441.5% at the same moment AI review tooling has proliferated across the industry. Those two facts sitting next to each other are the story.
Over the next 6 to 18 months, watch three things. First, whether GitHub Code Quality’s July 20 general availability launch actually moves review-time metrics at scale, since it’s the first major product to bundle static analysis and AI review under one governance umbrella with real enterprise adoption behind it. Second, whether an independent, non-vendor benchmark for AI review accuracy finally emerges, because right now buyers are flying blind. Third, whether DORA’s rework rate metric becomes standard practice at more organizations, since it’s currently the best early warning signal available for exactly the kind of quality debt this article describes.
Our read: this signals a market correction is coming for AI code review vendors who’ve been selling speed as the headline benefit. The winners over the next year will be the tools that reduce rework, not the ones with the flashiest catch-rate slide.
Want data-backed engineering and AI coverage like this in your inbox every week? Subscribe to The Neural Loop at neuralwired.com/newsletter.
Cloud Repatriation 2026: The Data Behind the CIO Shift
Cloud Infrastructure / 2026 Data
Cloud Repatriation 2026: The Data Behind the CIO Shift
By The Neural Loop Desk · NeuralWired.com
GEICO’s infrastructure team ran the numbers and found something uncomfortable: storage in the cloud was one of the most expensive things they were doing, with AI workloads close behind. So the third largest auto insurer in the country started moving pieces of its stack back home. That single decision is a small window into a much bigger story: cloud repatriation is real, it’s measurable, and in 2026 it’s reshaping how enterprises decide where a workload actually belongs.
This isn’t the “cloud is dead” narrative some headlines are chasing. It’s messier and more useful than that. Below is what the 2025 and 2026 survey data actually shows, who’s really moving workloads and why, and where the skeptics have a point worth taking seriously.
Hybrid cloud isn’t a transitional phase anymore. It’s the default. Flexera’s 2026 State of the Cloud Report, based on 753 cloud decision makers, found that 73% of organizations now operate a hybrid estate, up three percentage points year over year. Among organizations with more than 5,000 employees, that number climbs to 78%.
At the same time, public cloud spending keeps climbing. Gartner forecasts worldwide public cloud end user spending will hit $723.4 billion in 2025, a 21.5% increase. Those two facts sound contradictory until you understand what repatriation actually looks like on the ground: it’s workload by workload, not company by company.
Why this matters
Repatriation and cloud growth are rising at the same time because net new cloud adoption still outpaces the workloads moving out. This isn’t an exodus. It’s a correction, and it changes how every infrastructure team should evaluate a new deployment.
The Numbers: Planned vs. Actual Repatriation
The gap between intent and action is the most important, and most underreported, part of this story.
Metric
Figure
Source
CIOs planning some workload repatriation in 2025
86% (highest ever recorded)
Barclays CIO Survey
Cloud workloads actually repatriated so far
21%, up 2 points YoY
Flexera 2026 Report
Organizations planning a full cloud exit
8% to 9%
IDC Server and Storage Workloads Survey
Cloud infrastructure spend considered wasted
27%, down from 32% four years ago
Flexera 2026 Report
Read those four rows together and a clearer picture forms. Most CIOs are open to moving something. Very few are moving everything. And the underlying driver, wasted spend, is actually improving as FinOps practices mature. That’s not the framing most “cloud is dying” articles use, but it’s the one the data supports.
Years ago, people talked about repatriation, but “no one was doing it, it just wasn’t a thing.”
Brian Adler, Senior Director of Cloud Market Strategy, Flexera · CIO Dive
What changed since then is measurement. Adler’s colleague Jay Litkey, SVP of Cloud and FinOps at Flexera and a governing board member at the FinOps Foundation, put it plainly: teams have gotten good enough at cost allocation that “FinOps is providing the data to make repatriation decisions.” Before, repatriation was a hunch. Now it’s a spreadsheet.
Why Enterprises Are Rethinking Cloud-First
Four drivers show up consistently across the survey data and the case studies:
Cost at scale. A third of surveyed organizations now budget $12 million or more a year for public cloud, according to CIO Dive’s reporting on Flexera’s survey. At that spending level, even small percentage savings translate into real capital.
AI and GPU workloads. Steady, high utilization AI workloads often price out better on owned infrastructure than on elastic cloud billing, which is one reason GEICO named AI spend as a specific pain point alongside storage.
Data sovereignty and compliance. Regulatory frameworks like the EU AI Act are pushing some workloads toward infrastructure with clearer jurisdictional control.
Vendor lock-in fatigue. After a decade of cloud-first defaults, some infrastructure teams are simply asking whether “cloud” was ever the right answer for a specific, predictable workload, rather than a blanket policy.
IDC’s Natalya Yezhkova, Research VP in the firm’s Enterprise Infrastructure Practice, frames the shift as a change in posture rather than a reversal. Cloud only is “becoming a less prevalent approach,” she told Data Center Dynamics, replaced by what she calls a “cloud also” mindset.
Real Case Studies: GEICO, 37signals, Dropbox
GEICO: The Insurer Rethinking a 600-App Migration
GEICO began migrating to the cloud in 2013 across more than 600 applications. Over a decade later, Rebecca Weekly, VP of Platform and Infrastructure Engineering, confirmed to The Stack that the company is repatriating workloads as part of a broader architectural overhaul. Her reasoning was direct: “storage in the cloud is one of the most expensive things you can do.”
37signals: The Most Cited Number in Every Repatriation Article
37signals, the company behind Basecamp and HEY, pulled its infrastructure off AWS and Google Cloud starting in 2022. It now reports roughly $1.3 million to $1.5 million in annual savings, or close to $7 million over five years, according to figures compiled by HyScaler. It’s the go-to proof point in nearly every article on this topic, and for good reason. But it comes with a catch, more on that below.
Dropbox: The Original Case Study
Dropbox’s build out of its own storage system, known as Magic Pocket, starting around 2013, is widely considered the founding example of large scale repatriation, predating the current wave by roughly a decade.
The Counterargument: Is This Overstated?
Not everyone buys the resurgence narrative, and the skeptics deserve equal airtime here.
Corey Quinn, Chief Cloud Economist at The Duckbill Group, has argued that “cloud repatriation isn’t a thing” in any broad sense, and points out that the loudest advocates for leaving the cloud often have a commercial stake in that outcome. It’s worth noting Quinn’s own firm sells cloud cost optimization services, meaning his incentive runs the opposite direction: keep clients on the cloud, just spend less. Both sides of this debate have a horse in the race.
Gartner has gone further, publishing research titled “Moving Beyond the Myth of Repatriation,” arguing that on-premises vendors are pushing a false narrative and that most repatriation projects that fail were poorly scoped from the start, not doomed by the cloud itself.
There’s also a semantic wrinkle worth flagging. Gartner analyst Rene Buest calls much of what gets reported as European repatriation “geopatriation” instead, meaning companies are moving to local or regional cloud providers, not back to private infrastructure. In a survey of 241 Western European IT leaders conducted between May and July 2025, 61% said geopolitical factors would increase their reliance on regional cloud providers. That’s a real trend, but it’s a different trend than the one most headlines describe.
The honest caveat on 37signals
37signals runs steady, predictable, well understood workloads, which is close to the textbook best case for repatriation. Most enterprises have a far messier workload mix: bursty traffic, legacy dependencies, uneven ownership across teams. The $7 million savings figure is real, but treating it as a universal template is where a lot of repatriation projects go wrong.
What CTOs and FinOps Leads Should Do Now
The practical shift for infrastructure leaders isn’t “leave the cloud.” It’s building a documented, ongoing framework for deciding where each workload belongs, evaluated on cost, compliance, latency, and data gravity, rather than defaulting to cloud-first for everything new. We broke down exactly that process, including a five-step workload placement model and ROI benchmarks, in our companion piece on a five-step AI workload placement framework for structuring that shift.
A few things worth doing before committing capital to any repatriation project:
Get real cost-per-workload data before deciding anything. Litkey’s point stands: FinOps maturity is what makes these decisions defensible instead of reactive.
Separate “predictable and steady” workloads from “bursty and uncertain” ones. The former are repatriation candidates. The latter usually still favor elastic cloud pricing.
Factor in the 27% cloud waste figure before assuming repatriation is the only lever. Flexera’s data suggests a meaningful chunk of the cost problem can be solved without moving anything.
Treat compliance-driven moves and cost-driven moves as separate decisions with separate criteria, since they often point to different infrastructure choices entirely.
Cloud repatriation is the process of moving applications, workloads, or data from public cloud providers like AWS, Azure, or Google Cloud back to on-premises infrastructure, private clouds, or colocation facilities. It’s rarely a full exit. Most organizations move only specific, cost-sensitive workloads.
Why are companies leaving the cloud?
The leading drivers are unpredictable costs at scale, data sovereignty and compliance requirements, performance needs for AI and latency-sensitive workloads, and vendor lock-in. Flexera reports 27% of cloud spend is considered wasted, while IDC finds cost and compliance are the top repatriation motivators.
How many companies are doing cloud repatriation?
Roughly 86% of CIOs planned some level of workload repatriation in 2025, the highest rate ever recorded, per Barclays’ CIO Survey. But only about 8% to 9% plan a full exit, per IDC, and actual repatriated workloads sit at 21%, per Flexera’s 2026 report.
Is cloud repatriation a real trend or hype?
Both views have credible backing. Gartner and cloud cost consultants like Corey Quinn argue repatriation is overstated and often vendor driven. Flexera’s survey data shows a real, measurable two point year over year increase in actual repatriated workloads, suggesting a modest but genuine shift, not a mass exodus.
What companies have done cloud repatriation?
The most cited examples are Dropbox, which built its own Magic Pocket storage system starting in 2013, 37signals (Basecamp, HEY), which left AWS and Google Cloud in 2022 and reports close to $7 million in five year savings, and GEICO, which is moving workloads back amid a major infrastructure overhaul after cloud storage and AI costs rose sharply.
Where This Goes Next
The two numbers to watch over the next 12 to 18 months are the 21% actual repatriation figure and the 27% cloud waste figure. If FinOps maturity keeps chipping away at waste, some of the pressure driving repatriation eases on its own. If it doesn’t, expect the 21% to keep climbing toward the 86% intent figure, and expect AI and GPU workload economics specifically to be the next flashpoint.
Three things worth tracking:
Whether Flexera’s next report shows the 21% figure accelerating or plateauing
How many enterprises follow GEICO’s lead on AI workload placement specifically, separate from general storage costs
Whether “geopatriation” becomes its own tracked category in 2027 surveys, separate from true on-premises repatriation
What’s clear now, and wasn’t as clear a year ago, is that this isn’t a binary choice between cloud and on-premises. It’s a workload-by-workload calculation, and the companies getting it right are the ones treating it as an ongoing discipline rather than a one-time migration decision.
On June 25, 2026, the European Commission did something it had never done before: it named Amazon Web Services and Microsoft Azure as candidate “gatekeepers” under the Digital Markets Act, the same law that already cost Apple and Meta hundreds of millions in fines. The reason is one word your procurement team already knows too well: cloud vendor lock-in.
If you run infrastructure, own a cloud contract, or sign off on FinOps budgets, this isn’t a policy footnote. It’s a negotiating lever you can use this quarter, and a deadline (January 12, 2027) that changes what your vendor is legally allowed to charge you for leaving.
The Digital Markets Act has spent its first few years going after consumer platforms. App stores. Messaging apps. Ad targeting. The June 25 preliminary finding against AWS and Azure is the first time Brussels has pointed the DMA at cloud infrastructure specifically, and the underlying logic will sound familiar to anyone who has tried to move a production workload off S3: enormous customer bases, deep integration into everything downstream, and switching costs steep enough to keep customers in place even when they’d rather leave.
Nothing is final yet. AWS and Microsoft can respond in writing and request an oral hearing, and the Commission is expected to issue a final designation before the end of 2026. But the stakes are not small. Non-compliance under the DMA can trigger fines of up to 10% of global annual turnover, a ceiling that would dwarf the €500 million fine Apple has already faced and the €200 million levied against Meta.
Why this matters to your contract, not just the headlines
This is the first regulatory body treating cloud switching costs as an antitrust issue rather than a pricing detail. Procurement teams at regulated industries, especially finance, already answer to exit-strategy rules under frameworks like DORA. This ruling gives every other industry the same kind of leverage in a renewal conversation.
What Cloud Vendor Lock-In Really Means
Vendor lock-in isn’t a single fee. It’s a structural dependency that builds up quietly across years: proprietary APIs your engineers have written against, managed database formats that don’t export cleanly, IAM and identity systems wired into everything, and staff expertise that only transfers within one platform’s ecosystem of tools. Individually, none of these look like a trap. Together, they make switching providers too costly, too slow, or too risky to be a real option, even when a competitor is cheaper.
The concern is close to universal now. According to Parallels’ 2026 State of Cloud Computing Survey, 94% of organizations report concern about vendor lock-in, a figure that’s climbed year over year across a panel of 540 IT professionals in the US, UK, and Germany.
The Real Cost of Leaving, in Dollars
Egress fees, the charge you pay to move your own data out of a cloud provider, are the most visible piece of the lock-in problem, and they scale fast.
Provider
Standard egress price
Cost to move 1 petabyte
AWS S3
$0.09/GB (first 10TB)
$90,000–$120,000 (industry estimate)
Microsoft Azure
$0.087/GB
Comparable range
Google Cloud
$0.12/GB
Comparable to slightly higher
Cloudflare R2
$0.00
$0
Pricing verified June 2026 via egresscost.com, cross-checked against provider documentation.
That math is not theoretical. When Basecamp’s parent company 37signals exited the cloud entirely in 2023 and 2024, AWS reportedly waived roughly $250,000 in egress fees as part of the departure, a number widely reported by DHH and the company itself. 37signals has since projected $7–10 million in savings over five years from running its own hardware instead.
The UK Cabinet Office has run the same math at government scale. Its analysis estimates that overreliance on a single cloud provider could cost UK public bodies £894 million, a figure cited across multiple 2026 explainers tied to the UK Competition and Markets Authority’s cloud market investigation.
The “free egress to leave” programs are narrower than they sound
All three hyperscalers now offer free egress for customers who fully exit their platform, a move that predates the EU’s enforcement push and rolled out back in 2024. Here’s the part most coverage skips: these waivers require discretionary approval from the vendor’s own support team, apply only to a complete exit, and explicitly do not cover data you move for ongoing multi-cloud use. If your strategy is “run workloads across two providers permanently,” the free-egress headline doesn’t apply to you at all.
Multi-Cloud and Repatriation: Two Different Bets
Enterprises are responding to lock-in risk in two very different ways, and it’s worth being precise about which one you’re actually running.
Multi-cloud is the dominant approach. Flexera’s State of the Cloud 2026 report found that 89% of enterprises now run a multi-cloud strategy, with 42% naming lock-in avoidance as the primary driver. It’s a hedge: spread workloads across providers so no single vendor holds all the leverage.
Repatriation is the opposite move: bringing workloads back from public cloud to on-premises or private infrastructure. Barclays’ Q4 2024 CIO survey found 86% of CIOs plan to repatriate at least some workloads, and IDC independently put the figure at 80% within 12 months. Broadcom’s own internal shift off public cloud database services and onto VMware Data Services Manager reportedly saved the company over $10 million, with Broadcom’s broader analysis suggesting modern private cloud can deliver 40 to 50% lower total cost of ownership for steady-state workloads.
Read those repatriation numbers carefully, though. They describe intent to move some workloads, not a wholesale exodus from public cloud. Synergy Research still put public cloud spend growth at 35% year over year in Q1 2026. Both trends are true at once: enterprises are repatriating specific, predictable workloads while continuing to grow their overall public cloud footprint for everything else.
“Despite the enormous scale of the cloud market, in Q1 the cloud market growth rate increased for the tenth successive quarter.”
John Dinsdale, Chief Analyst, Synergy Research Group · via Statista
That growth is concentrated. AWS, Azure, and Google Cloud together hold an estimated 63 to 68% of global cloud infrastructure revenue, with Synergy’s most directly sourced Q1 2026 breakdown putting AWS at 28%, Azure at 21%, and Google Cloud at 14%. European alternatives like OVHcloud, Hetzner, and Scaleway combined hold roughly 15% of EU cloud market revenue, which tells you how limited the “just switch to someone else” option really is inside Europe today.
The Contrarian Case Against Multi-Cloud
Not everyone thinks the multi-cloud hedge is worth it. Corey Quinn, Chief Cloud Economist at The Duckbill Group and one of the most-cited voices on AWS billing and contracts, has argued the opposite of conventional wisdom for years.
“the worst practice to be avoided by default”
Corey Quinn, Chief Cloud Economist, The Duckbill Group, on multi-cloud strategy · via InfoQ
His argument, in plain terms: running two or three clouds to avoid depending on one means paying twice for security tooling, twice for skills training, and twice for the operational overhead of keeping teams fluent in different platforms, and you rarely get to use the redundancy you’re paying for. Managing the friction between providers, in his view, often costs more than the lock-in it was supposed to prevent.
Our read: Quinn’s position isn’t an argument against caring about lock-in. It’s an argument that the fix has to match the actual risk. A payments company with regulatory exit requirements needs a different answer than a 40-person startup running a single web app.
The New Lock-In Layer: AI Workloads
Traditional lock-in ran through storage formats and compute APIs. In 2026, a second layer has stacked on top of it. GPU access, managed AI services like Amazon Bedrock, Google Vertex AI, and Azure AI Foundry, and proprietary model integration are creating dependencies that didn’t exist three years ago. Move your inference pipeline off one provider’s managed AI stack and you’re not just fighting egress fees anymore, you’re rebuilding prompt orchestration, fine-tuning pipelines, and often the model access itself.
Google Cloud, for what it’s worth, positions itself as the exception. Jeanette Manfra, Senior Director for Global Risk and Compliance at Google Cloud, has publicly framed the original promise of cloud computing as open and elastic, free of artificial switching barriers, and said Google Cloud continues to support customers’ ability to choose their provider. Whether that public positioning matches actual contract terms and pricing behavior is exactly the kind of gap regulators are now starting to test.
What to Do With Your Contract Right Now
Add an exit-cost line item to every renewal. Not just the renewal price, the documented cost to leave, including egress, migration engineering, and parallel-run overhead.
Cite the regulatory timeline in negotiations. The EU Data Act’s January 12, 2027 deadline for eliminating switching-related egress fees is a real, dated commitment. Vendors are already moving ahead of it. Use that.
Read the free-egress waiver terms before you rely on them. They cover full exits only, need discretionary approval, and don’t apply to ongoing multi-cloud operation.
Separate the AI stack from the IaaS conversation. Your managed AI services may be creating a lock-in risk your existing cloud governance policy has never evaluated.
Match your strategy to your actual regulatory exposure. If you’re not under DORA or a similar exit-strategy mandate, Corey Quinn’s warning about multi-cloud complexity is worth weighing seriously before you default into it.
UK CMA research offers a sobering reality check on timing: one documented Azure-to-AWS migration ran from March 2023 to September 2024, over a year, with the enterprise running both environments in parallel throughout. Planning for portability before you sign is dramatically cheaper than engineering an exit after the fact.
Frequently Asked Questions
What is vendor lock-in in cloud computing?
Vendor lock-in happens when switching cloud providers becomes too costly, slow, or technically risky to be practical, usually due to proprietary APIs, data formats, egress fees, and staff expertise built around one platform. It turns a technology choice into a long-term structural dependency.
How much does it cost to switch cloud providers?
It scales with data volume. Moving 50TB can run $3,500 to $7,000 in egress fees alone; a full petabyte off AWS S3 can cost $90,000 to $120,000. Add migration engineering and parallel-running costs, and large enterprise switching bills can reach into the millions.
Are cloud providers eliminating egress fees?
AWS, Azure, and Google Cloud now offer free egress for customers fully exiting the platform, driven by EU Data Act pressure. The Act mandates egress fee elimination for switching customers by January 12, 2027, but current waivers are narrower and exclude ongoing multi-cloud use.
Is multi-cloud the best way to avoid vendor lock-in?
It’s the most common approach. 89% of enterprises now run multi-cloud, per Flexera. But it’s contested: cloud economist Corey Quinn argues it often trades lock-in risk for operational complexity that costs more than the risk it prevents, making it the wrong default for many organizations.
What is cloud repatriation and why is it happening in 2026?
Cloud repatriation means moving workloads from public cloud back to on-premises or private infrastructure. It’s accelerating due to cost overruns, egress fees, data sovereignty rules like DORA, and AI-driven data gravity. 86% of CIOs report plans to repatriate at least some workloads, per Barclays.
Where This Goes Next
The core fact hasn’t changed: three companies still control roughly two-thirds of global cloud infrastructure, and the technical dependencies that keep customers in place, proprietary APIs, managed data formats, identity systems, are largely untouched by any current regulation. What’s new is that a regulator with real fining power is now treating those dependencies as a competition problem rather than a private pricing decision.
Watch three things over the next 6 to 18 months: whether the DMA gatekeeper designation becomes final before year-end, whether AWS and Azure restructure egress pricing ahead of the January 2027 deadline rather than waiting for enforcement, and whether AI-service lock-in becomes the next target once IaaS switching costs come down. The contract you sign this year should assume all three are coming, not just the one already in the headlines.
Canada Just Ruled ChatGPT’s Training Broke Privacy Law
Regulation & Compliance
Canada Just Ruled ChatGPT’s Training Broke Privacy Law
By NeuralWired Staff · Published July 1, 2026 · 9 min read
Four Canadian privacy regulators looked at the same evidence and reached four different verdicts on whether OpenAI broke the law training ChatGPT. All four agreed it did. They just couldn’t agree on whether OpenAI had fixed it.
That split, buried inside a joint ruling called PIPEDA Findings #2026-002, is the first formal decision by a G7 regulator on how an AI company built its training data, not what the model outputs, not a breach, the pipeline itself. If your company trains models, buys API access to one, or embeds a chatbot into a product, this ruling just became the reference document your legal team will be citing for years.
On May 6, 2026, the Office of the Privacy Commissioner of Canada (OPC), Quebec’s Commission d’accès à l’information (CAI), the BC Office of the Information and Privacy Commissioner, and Alberta’s OIPC published the results of a joint investigation that began back in May 2023, shortly after ChatGPT’s public launch triggered a wave of complaints across the country.
The investigation focused narrowly on GPT-3.5 and GPT-4, the models that powered ChatGPT from launch through most of 2024. The regulators identified five separate problems: OpenAI collected far more personal information than its stated purpose required, it lacked valid consent and transparency for that collection, the resulting outputs were riddled with factual inaccuracies about real people, individuals had no meaningful way to access, correct, or delete their information, and the company had no accountability structure governing any of it.
The regulators’ own language on the core issue was blunt. Publicly accessible does not mean fair game.
“The fact that personal information is accessible does not represent a carte blanche to collect and use it without limits.”
Joint finding, PIPEDA Findings #2026-002, Office of the Privacy Commissioner of Canada
Federal Privacy Commissioner Philippe Dufresne put the broader stakes in plain terms after the findings landed, framing the case as evidence that Canada’s decades-old privacy statute is straining under generative AI.
Why Four Regulators Reached Four Different Verdicts
Here’s the part that should worry compliance teams more than the fine print of the violations themselves: Canada does not currently have one answer to “was this legal.” It has four, and they don’t match.
Regulator
Law Enforced
Verdict
OPC (Federal)
PIPEDA
Well-founded, conditionally resolved. OpenAI’s remediation plan was accepted as sufficient going forward.
OIPC-BC
PIPA-BC
Well-founded, unresolved. Found the scraped training data cannot retroactively meet consent requirements.
OIPC-AB
PIPA-AB
Well-founded, unresolved. Reached the same consent conclusion as BC.
CAI (Quebec)
Quebec Private Sector Act
Partially unresolved, with consent and retention issues still outstanding.
British Columbia and Alberta’s reasoning is the sharpest line in the whole document. Their statutes are more specific than the federal law on what counts as valid consent, and under that stricter reading, the two provincial offices concluded OpenAI’s models are built on scraped data for which consent was never obtained and cannot now be obtained, no matter what OpenAI changes going forward. That’s not a fixable compliance gap. That’s a permanent asterisk on GPT-3.5 and GPT-4 specifically, within those two provinces.
The practical result: OpenAI avoided a fine, but it did not walk away with a clean bill of health. Two of four Canadian regulators are on record saying the underlying models cannot be brought into compliance retroactively, only deprecated and replaced.
The Opt-Out Trap Buried in the Findings
One detail from the findings deserves more attention than it’s gotten. Until April 2024, OpenAI’s opt-out mechanism required users to give up their entire chat history in order to stop their conversations from being used as training data. Want out of training? Lose your data. Regulators flagged this specifically as a deceptive design pattern, the kind of interface choice that technically offers a control while making it costly enough that almost nobody uses it.
OpenAI decoupled the two settings after the fact. But for roughly the first eighteen months of ChatGPT’s existence, the exact window when it grew from zero to hundreds of millions of users, opting out came with a real penalty attached.
Why This Isn’t Just a Canada Story
The timing here is not a coincidence. PIPEDA Findings #2026-002 lands inside a five-week window that includes the biggest AI enforcement deadline on the calendar: the EU AI Act’s high-risk system obligations become enforceable on August 2, 2026, with penalties reaching up to €35 million or 7% of global turnover for prohibited practices and up to €15 million or 3% for high-risk non-compliance. Multiple trackers, including Kasowitz LLP’s 2026 compliance update, note the European Commission has floated a possible delay, so treat that specific date as directionally firm but not fully locked.
South Korea’s AI Basic Act took effect January 22, 2026, becoming the second binding, comprehensive AI regulatory regime globally after the EU. Italy’s data protection authority, the Garante, fined OpenAI over similar ChatGPT training practices back in 2024, a precedent the Canadian ruling explicitly builds on and exceeds in depth and specificity.
Put together, this is not four unrelated headlines. It’s one regulatory wave arriving from four directions inside the same three-month window.
Why the Money Is Moving Fast
Gartner projects global spending on AI governance platforms will roughly double, from about $492 million in 2026 to over $1 billion by 2030, as regulatory fragmentation spreads to an estimated 75% of the world’s economies. Distinguished VP Analyst Rita Sallam put the pace of change bluntly at Gartner’s 2026 Data and Analytics Summit.
“The pace of change in data and artificial intelligence is so rapid that each year feels like stepping into a new chapter of a science-fiction novel.”
Rita Sallam, Distinguished VP Analyst, Gartner · Gartner Newsroom, March 2026
The Case Against the Ruling
Not everyone thinks Canada got this right. Daniel Castro, president of the Information Technology and Innovation Foundation and a former GAO IT security auditor, argues the regulators applied a consent standard from a pre-AI era to a problem it was never built for. Canadian privacy law’s exceptions for “publicly available” information predate internet-scale datasets entirely, he notes, and forcing AI developers to obtain express consent from billions of individuals whose public data ends up in a training set isn’t a stricter privacy rule so much as an unworkable one.
“That standard is unworkable.”
Daniel Castro, President, Information Technology and Innovation Foundation · ITIF, May 2026
Castro’s broader point is worth sitting with regardless of where you land on it: a ruling that four regulators, applying similar facts, couldn’t agree on isn’t just a statement about OpenAI. It’s evidence that “AI training data compliance” doesn’t yet have one stable legal definition, even inside a single country.
There’s also a limit the more optimistic “buy a governance platform and you’re covered” narrative tends to skip over. Software fixes forward-looking data pipelines. It cannot retroactively re-license a dataset that GPT-3.5 and GPT-4 were already trained on, years before any of these tools existed. Any company building on top of a foundation model inherits that legacy exposure no matter how much it spends on its own tooling.
What This Means for Your Company
If you’re a CTO, chief data officer, or the person your legal team calls when a vendor contract mentions AI, the operating assumption has changed. Training-data provenance used to be a data-science housekeeping detail. It is now a boardroom-visible compliance artifact, and this ruling gives regulators a template for asking about it.
The exposure isn’t limited to companies training their own models. As MLT Aikins’ legal analysis puts it, the decision applies to any organization developing, deploying, or using generative AI tools, meaning the company that simply calls a foundation model’s API inherits the same underlying data-provenance question as the company that built the model.
Update vendor diligence now. Ask model vendors directly for their filtering methodology, the legal basis for their training consent, and their retention and deletion schedule. If they can’t answer, that’s your answer.
Assume audit logs are the weak point. Roughly 61% of organizations report fragmented audit logs across systems, according to Kiteworks’ 2026 forecast, meaning most companies could not produce a unified compliance record if a regulator asked tomorrow.
Build toward an AI Bill of Materials. A structured, machine-readable inventory of training data sources, model versions, and dependencies is emerging as the practical artifact auditors expect to see, not a policy document, an actual record.
Don’t over-correct blindly. Matching BC and Alberta’s stricter standard might put you out of step with how the EU AI Act’s implementing guidance eventually treats publicly available data. Build for defensibility, not for the single strictest headline.
Frequently Asked Questions
Did OpenAI break the law training ChatGPT?
Yes, according to Canadian regulators. A May 6, 2026 joint finding by four Canadian privacy authorities concluded OpenAI’s training of early ChatGPT models violated federal and provincial privacy laws on consent, transparency, accuracy, and retention, though the company avoided a fine by agreeing to corrective measures.
What is AI data governance?
AI data governance is the set of policies, controls, and documentation practices that track how data is collected, consented to, filtered, and used to train or run AI systems, covering provenance, retention, access rights, and audit trails so organizations can demonstrate compliance on demand.
When does the EU AI Act’s high-risk enforcement start?
The EU AI Act’s high-risk system obligations are set to become enforceable on August 2, 2026, covering AI used in critical infrastructure, employment, education, and essential services, with penalties reaching €35 million or 7% of global turnover for the most serious violations, though the European Commission has signaled possible delays.
What is an AI Bill of Materials (AIBOM)?
An AI Bill of Materials is a structured, machine-readable inventory documenting an AI system’s components, including model versions, training data sources, dependencies, and deployment environments. It’s increasingly expected by auditors and regulators as concrete evidence of governance, not just a policy statement.
Where This Goes Next
What you now know that you didn’t before: Canada’s ruling didn’t just penalize one company’s past decisions, it exposed that even inside a single country, regulators can’t yet agree on what “compliant AI training” actually looks like. That ambiguity is now the default operating condition for anyone building or buying generative AI, not a temporary gap that resolves once one big ruling lands.
Watch three things over the next six to eighteen months. First, whether the EU AI Act’s August 2 deadline holds or slips, since that will set the tone for how aggressively other jurisdictions move. Second, whether OpenAI’s quarterly compliance reporting to the OPC becomes a public template other regulators start requiring from other vendors. Third, whether AIBOM-style documentation moves from “nice to have” to a standard line item in enterprise procurement contracts, the way SOC 2 reports did for cloud vendors a decade ago.
The companies that get ahead of this won’t be the ones with the biggest governance budget. They’ll be the ones who can actually answer the question Canada’s regulators just asked out loud: show us your filtering practices, your consent basis, and your retention schedule, before you’re asked twice.
Stay Ahead of the Next Regulatory Wave
Get the Neural Loop in your inbox: the AI governance, infrastructure, and enterprise stories that matter, before they’re everywhere else.
Subscribe to The Neural Loop
Real-Time Data Pipelines: Build vs. Buy in 2026 | NeuralWired
Enterprise Data Infrastructure
Real-Time Data Pipelines: Build vs. Buy in 2026
By NeuralWired Staff · July 1, 2026 · 11 min read
IBM just closed an $11 billion acquisition of Confluent, the company behind the Kafka platform running inside 40% of the Fortune 500. If you’re the person who has to decide whether your team spends the next two years operating a Kafka cluster or signing a vendor contract instead, that deal just changed your negotiating position and your risk profile at the same time.
This isn’t another explainer on what real-time data pipeline architecture looks like. It’s the cost and procurement question underneath it: should your organization build this infrastructure in-house, or buy it? The answer depends less on technology and more on talent, timeline, and what problem you’re actually solving.
On March 17, 2026, IBM completed its acquisition of Confluent for $31 a share in cash, a deal worth roughly $11 billion that was first announced back in December 2025. Confluent’s Kafka-based streaming platform sits inside more than 6,500 enterprises, and Confluent itself claims over 40% of the Fortune 500 run its commercial platform, up from 27% a few years ago (that figure is vendor-reported, worth noting, but the trend direction lines up with everything else happening in this market). Confluent delisted from Nasdaq. CEO Jay Kreps stayed on to run the business; the board did not survive the transition.
Why does this matter to you if you’re not a Confluent customer? Because it confirms real-time data infrastructure has graduated from “specialized add-on” to core enterprise plumbing, the kind large vendors pay double-digit billions to own outright. IBM has done this playbook before, with Red Hat and with HashiCorp. Pricing and packaging tend to shift toward IBM’s enterprise contract structure within 12 to 18 months of close. If you’re renewing a Confluent agreement this year, read the fine print now, not at renewal time.
“Real-time data is the fuel for AI.”
Jay Kreps, Co-founder & CEO, Confluent (now an IBM company)
Two days before the deal closed on the calendar of relevant 2026 news, Databricks launched LTAP, its lake transactional and analytical processing platform, at its Data + AI Summit on June 16. We covered that architecture in depth in our Databricks LTAP breakdown. This piece picks up where that one leaves off: not how the stack works, but whether you should build one yourself or hand the problem to a vendor.
The Real Question Isn’t “Real-Time or Not”
Here’s the framing most vendor content skips. The decision in front of you isn’t whether real-time data matters. Confluent’s fifth annual Data Streaming Report, which surveyed 4,625 IT leaders across 14 countries, found that 72% say a lack of real-time infrastructure is stalling their AI scaling efforts. That number is now close to consensus.
The decision that actually determines your budget, your headcount, and your risk exposure for the next three years is whether you build that infrastructure yourself or buy it from someone who already operates it at scale. Those are very different bets, and the research doesn’t point toward one obvious winner.
The number to actually use
Skip the round, dramatic “$19 million lost” figures floating around this topic. They don’t trace back to a named company or a disclosed methodology. Gartner’s substantiated estimate puts the annual cost of poor data quality and flawed decisions at $9.7 million to $15 million per organization, a real, citable figure worth anchoring your internal business case to instead.
The True Cost of Building In-House
Building your own real-time pipeline on open-source Kafka and Flink looks cheap on a licensing spreadsheet. It rarely looks cheap on a headcount spreadsheet.
Operating Kafka and Flink reliably in production, not just standing up a proof of concept, requires engineers who understand distributed systems, state management, and cluster operations under load. That talent is genuinely scarce, and the market has been telling you so. Decodable, a streaming startup, got acquired rather than scaled independently. Google retired its managed BigQuery Flink engine. Several Pulsar-focused startups exited the space entirely in the last two years. None of that happens in a market where in-house streaming is easy to staff and operate.
Adoption data backs this up from a different angle. Integrate.io’s 2026 stats roundup found that 72% of organizations now use event-driven architecture in some form, but only 13% report reaching org-wide maturity with it. That gap, adoption without maturity, is exactly where in-house builds tend to stall: teams get Kafka running, then spend eighteen months fighting operational debt instead of shipping features.
What “building” actually costs
Specialized headcount: platform engineers who understand Kafka/Flink ops don’t come cheap, and they’re in short supply.
On-call burden: streaming infrastructure that breaks at 2 a.m. is now your problem, not a vendor’s SLA.
Opportunity cost: every sprint spent on cluster management is a sprint not spent on the product your customers actually see.
Ramp time: reaching production-grade maturity typically takes longer than teams budget for, based on that 72%-adopted-but-13%-mature gap.
The Case for Buying, and Its Fine Print
The market case for buying is straightforward. Next Move Strategy Consulting projects the global data pipeline market growing from $14.5 billion in 2025 to $58.6 billion by 2035, a 16.8% compound annual growth rate, with real-time streaming as the fastest-growing segment. Separately, Integrate.io compiles market data showing data pipeline tools growing at a 26.8% CAGR toward $48.33 billion by 2030, well ahead of traditional ETL’s 17.1% growth rate. Capital is flowing toward managed platforms, not toward custom builds.
Steven Karan, VP of AI Transformation at Capgemini Australia and New Zealand, made the underlying point plainly to CIO.com in June: the lakehouse has become foundational infrastructure, not a niche analytics tool.
“The lakehouse isn’t just for analytics anymore.”
Steven Karan, VP of AI Transformation, Capgemini Australia and New Zealand, via CIO.com
For most enterprises, a managed platform, whether that’s Confluent Cloud, Databricks, or a cloud-native streaming service, wins on total cost of ownership once you factor in engineering time and talent scarcity. Building in-house tends to only pay off at very large, sustained data volumes with a platform team you already have in place. If that’s not your situation, buying is the less risky bet.
Why the Vendor ROI Numbers Deserve Skepticism
Here’s where you need to slow down before you take a vendor’s ROI slide into a budget meeting. Confluent’s own 2026 survey reports that half of organizations achieve 5x or greater ROI on data streaming, and 88% achieve at least 2x. Those numbers are real, in the sense that Confluent really did survey 4,625 IT leaders and really did get those responses. What they’re not is independent.
This is a vendor-commissioned survey of self-selected respondents who had already invested in streaming technology before answering the survey. People who bought the platform and regret it don’t tend to fill out vendor satisfaction surveys. Use these numbers as a directional signal that streaming can pay off, not as a guarantee that it will pay off for your organization specifically.
Gartner’s own research offers a more sobering counterweight. Gartner projects that 60% of AI projects lacking AI-ready data will be abandoned through 2026, and separately that 70% of agentic AI use cases will fail to deliver expected value. Rita Sallam, Distinguished VP Analyst at Gartner, has pointed to mismatched cost models as a primary cause, meaning organizations are overspending on top-tier real-time infrastructure to solve problems that didn’t need it. Read Gartner’s original predictions in the 2026 Data & Analytics predictions release.
Our read: this signals that the failure mode in 2026 isn’t “real-time infrastructure doesn’t work.” It’s “we bought infrastructure sized for a problem we hadn’t actually defined yet.” Sequencing, not tooling, is where most build vs. buy decisions go wrong.
That sequencing point shows up elsewhere too. Precisely’s 2025 Data Integrity Trends Report found that 64% of organizations cite data quality as their top data-integrity challenge, and organizations lose roughly 25% of annual revenue to quality-related inefficiencies. Buying a faster pipeline doesn’t fix bad data. It just delivers bad data to your AI agents faster than before.
The Compliance Gotcha Nobody Mentions
What vendors won’t lead with
Popular real-time serving engines including Apache Pinot and Apache Druid don’t natively support UPDATE or DELETE operations on ingested records. If you operate under GDPR or CCPA and need to honor a right-to-erasure request, that’s not a minor technical footnote. It’s an architectural constraint that can force a redesign after you’ve already committed budget and headcount to a platform choice.
This is exactly the kind of detail that gets skipped in an architecture pitch deck and shows up eighteen months later as an unplanned engineering sprint. If your organization operates in the EU, the UK, or California, put this question in front of any vendor or open-source stack before you sign anything: how does erasure actually work at the storage layer, not just at the application layer?
A Practical Build vs. Buy Framework
Only about 22% of enterprises say they’re confident their current IT infrastructure can actually support new AI applications, according to survey data cited in a joint Confluent and Databricks announcement. That confidence gap is where the build vs. buy decision actually gets made, usually under time pressure. Here’s a simplified way to think about it.
Factor
Lean Build
Lean Buy
Data volume
Very large, sustained, predictable
Variable or growing unpredictably
Platform engineering talent
Already in-house and retained
Scarce, expensive to hire, or nonexistent
Latency requirement
True sub-second, mission-critical
5-15 minute near-real-time is acceptable
Compliance complexity
Deep in-house legal/eng coordination
Vendor handles erasure and audit tooling
Time to value
12-24 months acceptable
Need production in under 6 months
Most enterprises land closer to the “buy” column than they expect, mainly because true sub-second streaming is only justified for a narrow set of use cases: fraud detection, dynamic pricing, and AI-agent workflows that can’t tolerate stale inputs. An estimated 80% of business analytics needs are served just fine by a five to fifteen minute refresh cycle, which is dramatically cheaper to operate than full streaming, whether built or bought.
One more data point worth sitting with: our own reporting on the Databricks LTAP rollout found DoorDash measuring a 35.7% feature mismatch between its batch and streaming ML pipelines, the root cause being two systems computing the same metric two different ways. We’d flag that figure as sourced through our own LTAP coverage rather than independently re-verified from DoorDash directly, but the underlying lesson holds regardless of the exact number: running parallel batch and streaming systems creates definitional drift that neither a build nor a buy decision fixes on its own. It has to be solved with a shared semantic layer.
Amit Kinha, Field CTO at DoiT International and a FinOps Foundation board member, made this point to CIO.com: without a semantic layer, an AI agent won’t reliably know where to look for the data it needs. That’s a governance problem, not an infrastructure problem, and it sits underneath whichever build vs. buy path you choose.
Frequently Asked Questions
What is a real-time data pipeline?
A system that ingests, processes, and delivers data continuously as it’s generated, rather than in scheduled batches. Most are built on Apache Kafka for ingestion, Apache Flink for stream processing, and a serving layer like ClickHouse, Pinot, or a lakehouse platform.
Is it cheaper to build or buy a real-time data pipeline?
For most enterprises, buying a managed platform is cheaper on a total cost of ownership basis once engineering time, on-call burden, and talent scarcity are factored in. Building in-house typically only wins at very large, sustained data volumes with a dedicated platform team already in place.
What is the ROI of real-time data streaming?
Confluent’s 2026 vendor-commissioned survey reports 88% of organizations achieving 2x or greater ROI and half achieving 5x or greater. These figures come from self-selected adopters already invested in the technology, not an independent audit, so treat them as directional rather than universal.
Does every enterprise need real-time data?
No. Most business analytics needs are well served by a five to fifteen minute near-real-time refresh cycle. True sub-second streaming earns its cost mainly for fraud detection, dynamic pricing, and AI-agent-driven automation that can’t tolerate stale inputs.
What This Means Going Forward
Here’s what’s different by the end of reading this versus the start. The build vs. buy decision on real-time data pipelines isn’t really about Kafka versus a managed platform anymore. It’s about whether your organization has the talent to operate streaming infrastructure at 2 a.m. when it breaks, and whether your data is clean enough that faster delivery actually helps instead of just breaking things faster.
Watch three things over the next 6 to 18 months. First, how IBM repositions Confluent’s pricing for its installed base, since that will set a template other vendors follow. Second, whether Databricks’ LTAP approach, unifying transactional and analytical processing, pulls more build-it-yourself shops toward a single managed platform instead of stitching together Kafka, Flink, and a separate serving layer. Third, whether Gartner’s abandonment predictions for AI-ready data projects actually materialize, which would be the clearest signal yet that the market overbought infrastructure relative to the data quality work it needed to do first.
If you’re making this call for your organization right now, the sequencing matters more than the tooling. Fix your data quality and semantic layer first. Then decide, with clear eyes about your own talent bench, whether building or buying gets you to production faster and cheaper. For most teams, the honest answer in 2026 is buy, with data quality work done before, not after, the contract gets signed.
The Cloud Native Readiness Audit CTOs Need in 2026
Cloud Infrastructure
The Cloud Native Readiness Audit CTOs Need in 2026
By the NeuralWired Editorial Team | July 1, 2026
Cloud native application architecture now runs 98% of enterprises, according to CNCF’s newest annual survey. So the question your team is actually facing in 2026 isn’t whether to adopt it. It’s whether you’re ready to run what you’ve already built. Most companies aren’t, and the data on why is more useful than any failure-rate headline could be.
A Note on the Number You Won’t See in This Article
You may have seen the claim that cloud native rebuilds fail at four times the rate of legacy rewrites in year one. We went looking for the source. CNCF, Gartner, Forrester, IDC, McKinsey, and the peer-reviewed literature don’t contain it. It traces back to statistics-aggregator sites whose raw data includes garbled figures like “841% of organizations,” which is a strong sign of scraped or fabricated content, not research. We’re not repeating it, and we’d suggest treating it as false anywhere else you see it cited.
The Adoption Number That Changes the Question
Here’s the number that matters. CNCF’s 2025 Annual Cloud Native Survey, covering 628 organizations and published through Linux Foundation Research on January 20, 2026, found that cloud native adoption has reached 98% of organizations. That’s not a growth statistic anymore. That’s saturation.
Kubernetes tells the same story from a different angle. Among companies using containers, 82% now run Kubernetes in production, up from 66% just two years earlier. A separate CNCF and SlashData census, released at KubeCon North America in November 2025, put a number on the workforce behind all of this: 15.6 million developers now work with cloud native technologies globally, with 77% of backend developers using at least one of these tools.
If you’re a CTO weighing whether to greenlight a cloud native migration this quarter, the honest answer is that your competitors already did. The question worth your time isn’t “should we.” It’s “are we set up to actually pull this off, or are we about to join the pile of teams who adopted the stack and never got the operating discipline to match it.”
What “Readiness” Actually Means
CNCF didn’t leave this vague. The organization maintains a public Cloud Native Maturity Model, scored across levels 0 through 4+, that grades an organization on three separate axes: technology, process, and culture. Most teams treat cloud native readiness as a purely technical checklist. Container orchestration, service mesh, observability stack, done. The maturity model says that’s maybe a third of the job.
Process and culture are where the audit in this piece spends most of its time, because that’s where the CNCF’s own leadership says the real gap has moved.
“This year’s data shows that the next phase of cloud native evolution will be as much about people and platforms as it is about the tech itself.”
Hilary Carter, Senior Vice President of Research, Linux Foundation Research, January 20, 2026
Read that quote again if you’re the person signing off on next quarter’s cloud budget. Carter runs the team that produces the industry’s most-cited adoption survey, and her framing isn’t “adopt more tech.” It’s “your org chart is now part of the architecture.”
The Case Against Building Cloud Native From Scratch
There’s a contrarian thread running through this whole conversation, and it comes from Martin Fowler, Chief Scientist at ThoughtWorks and one of the most cited voices in software architecture. Fowler’s long-standing position, laid out in his essay “MonolithFirst”, cuts against the instinct to build cloud native from day one.
“Almost all the successful microservice stories have started with a monolith that got too big and was broken up. Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.”
Martin Fowler, Chief Scientist, ThoughtWorks
Fowler’s related concept, the “microservice premium,” is the part CTOs tend to skip past. The idea is simple: distributed systems cost more to build, operate, and debug than monoliths do, and that cost only pays for itself once your organization has outgrown what a monolith can handle. Build cloud native before you hit that threshold, and you’re paying the tax without collecting the benefit.
This is worth sitting with, because it directly complicates the popular framing of “legacy equals risk, modern equals safety.” Fowler’s evidence points closer to the opposite. The successful systems he’s tracked over a decade mostly started as something simpler and grew into the complexity, rather than being born into it.
Why the Real Risk Isn’t Your Architecture
Put Carter’s and Fowler’s positions side by side and a pattern emerges. Neither one says the technology is the problem. Both point at organizational readiness, in different ways: Fowler at whether your team has actually earned the complexity, Carter at whether your platform and culture can support what you’ve already deployed.
That matters for how you frame an internal readiness review. A pure architecture comparison, native rebuild versus legacy rewrite, misses where the actual risk sits. If your 2026 audit only checks Kubernetes version compliance and service mesh configuration, you’re grading a third of the exam.
Cost Governance Is a Day-1 Decision Now
Here’s where the readiness argument gets financial teeth. Flexera’s 15th annual State of the Cloud Report, based on 753 global cloud decision-makers and published March 18, 2026, found that wasted cloud spend climbed to 29% of IaaS and PaaS budgets, the first increase in five years. Five years of steady improvement, reversed in one cycle, largely driven by AI workload complexity and pricing structures teams weren’t ready to model.
The same report found that 71% of organizations now run a formal Cloud Center of Excellence, and 63% have a dedicated FinOps team. That’s not a coincidence. It’s the shape of what readiness looks like in practice, and it’s also a signal about sequencing: the companies avoiding the waste spike built governance structures before they scaled, not after.
“Cloud is maturing and visibility across technology is increasing. We’ve moved beyond treating the cloud as a cost-cutting exercise and now see it as the essential foundation for growth. As AI is reshaping cloud economics and risk, having centralized oversight is more critical than ever.”
Brian Shannon, Chief Technology Officer, Flexera, March 18, 2026
There’s a hybrid reality check buried in the same dataset worth flagging: 73% of organizations run hybrid cloud, up three points year over year. The binary framing of “go all in or stay legacy” doesn’t match how real infrastructure actually looks in 2026. Readiness is about sequencing which workloads move and when, not an all-or-nothing bet.
AI Workloads Just Added a New Readiness Layer
If your last cloud native audit predates your AI initiatives, it’s already out of date. Flexera’s 2026 data shows 53% of cloud leaders now cite security and compliance as their top challenge specifically for AI workloads running on cloud infrastructure, with 40% citing data quality. Neither of these is a Kubernetes problem. Both are governance problems that sit squarely inside the “process and culture” axes of the CNCF maturity model, not the technology axis.
Our read: teams that treat AI workload governance as a bolt-on to an already-mature stack are underestimating the lift. It needs its own line item in the audit, not a footnote.
The 8-Stage Cloud Native Readiness Audit
This framework maps onto CNCF’s official maturity model axes: technology, process, and culture. Run through it before your next migration sign-off, not after.
Stage
What You’re Checking
Why It’s on the List
1. Kubernetes production posture
Version compliance, resource utilization, autoscaling configuration
82% of container users now run K8s in production; utilization gaps are the most common operational failure mode
Cloud waste hit 29% in 2026, the first rise in five years
6. Team topology fit
Does your org size and structure justify the microservice premium you’re paying
Fowler’s core argument: complexity should follow organizational scale, not precede it
7. Data quality for AI workloads
Pipeline governance, lineage tracking, model input validation
Cited by 40% of cloud leaders as a top AI-on-cloud blocker
8. Hybrid sequencing plan
Which workloads move first, which stay put, and why
73% of organizations run hybrid cloud; an all-or-nothing plan is already out of step with the market
Notice that only two of the eight stages are purely technical. That ratio isn’t accidental. It reflects where CNCF, Flexera, and Fowler all independently point: the technology has matured faster than most organizations’ ability to govern it.
Frequently Asked Questions
What is cloud native application architecture?
Cloud native application architecture builds and runs applications to fully exploit cloud computing, using containers, microservices, and declarative APIs like Kubernetes, rather than simply relocating existing software onto cloud infrastructure without redesigning it.
What is the CNCF Cloud Native Maturity Model?
It’s a staged framework, levels 0 through 4+, published by CNCF for assessing an organization’s technology, process, and cultural readiness for cloud native adoption. Teams use it to benchmark gaps before scaling further deployments.
Should I rewrite my legacy app as cloud native, or migrate it as-is?
Martin Fowler’s widely cited “Monolith First” guidance argues most successful cloud native systems began as a monolith before being broken up. Building cloud native from scratch carries a documented “microservice premium” in added cost and operational risk.
How much cloud spend gets wasted, and why does it matter for readiness?
Flexera’s 2026 State of the Cloud Report found 29% of IaaS and PaaS spend is wasted, the first increase in five years, driven largely by AI workload complexity. It’s evidence that cost governance needs to be assessed before scaling cloud native systems, not after.
Where This Goes Next
The number to remember from this piece isn’t a failure rate. It’s 98%. Cloud native adoption stopped being a strategic bet years ago and became table stakes, which means the competitive edge in 2026 has quietly moved from “did you adopt” to “did you build the governance to run it.” Watch three things over the next 6 to 18 months: whether the AI-driven cloud waste spike Flexera flagged continues into 2027, whether FinOps team headcount keeps climbing past this year’s 63%, and whether CNCF’s maturity model gets a dedicated AI-readiness axis in its next revision.
If you’re running your own audit this quarter, start with the 8-stage framework above, and weight the process and culture stages as heavily as the technical ones. That’s not a hedge. It’s what the primary research actually shows.
GitOps Kubernetes Deployment: Why 58% of Top Teams Use It Extensively (2026)Platform Engineering
GitOps on Kubernetes: Why 58% of Top Teams Now Run It Extensively
Your platform team just shipped a Friday afternoon change with a single kubectl apply, and nobody remembers exactly what the cluster looked like before. That’s the moment GitOps exists to prevent. According to CNCF’s 2025 Annual Cloud Native Survey, 58% of the most mature cloud native organizations now run GitOps extensively, compared to just 23% of mid-tier teams and effectively none of the newcomers. That gap is the story: GitOps has quietly become the line separating platform teams that scale Kubernetes confidently from teams that are still fighting their own infrastructure.
This piece breaks down what that 58% figure actually measures, what Argo CD’s dominance tells you about where the tooling market landed, and where the real operational risk still hides, because the marketing version of this story leaves out the part where your Git repository becomes a single point of failure.
Start with the number everyone’s going to misquote. CNCF’s 2025 Annual Cloud Native Survey, fielded in September 2025 and published in January 2026, segments organizations into three maturity tiers: explorers, adopters, and innovators. Among innovators, the most advanced tier, 58% report using GitOps extensively. Among adopters, that number drops to 23%. Among explorers, it’s effectively zero.
That’s an adoption maturity statistic, not an incident reduction statistic, and the distinction matters. GitOps isn’t a feature you switch on; it’s a marker of how far along a platform team’s practices already are. Hilary Carter, Senior Vice President of Research at Linux Foundation Research, framed the broader finding this way:
“This year’s data shows that the next phase of cloud native evolution will be as much about people and platforms as it is about the tech itself. Organizations that invest in both will have a clear advantage.”
Hilary Carter, SVP of Research, Linux Foundation Research, via CNCF, January 2026
That 82% production Kubernetes adoption figure (up from 66% in 2023) is the backdrop. GitOps is what mature teams are doing once Kubernetes itself stops being the hard part.
Worth knowing: An earlier 2025 CNCF wave (689 respondents, reported in April) found 77% of organizations had adopted GitOps “to some degree.” That’s a broader, unsegmented number measuring a different population than the 58% innovator figure above. Don’t treat them as the same statistic; they answer different questions.
Argo CD’s Quiet Takeover of Kubernetes Delivery
If GitOps is the practice, Argo CD is increasingly the default engine running it. The 2025 CNCF/Argo CD End User Survey, released July 24, 2025, found that Argo CD now runs on nearly 60% of Kubernetes clusters used for application delivery among respondents. Ninety-seven percent of those users run it in production, up from 93% in 2023. The tool posted a Net Promoter Score of 79, the kind of number SaaS companies build entire marketing campaigns around.
Metric
2023
2025
Production usage among Argo CD users
93%
97%
Share of GitOps-managed clusters running Argo CD
—
~60%
Net Promoter Score
—
79
Platform engineers as share of users
—
37%
Dan Garfield, VP of Open Source at Octopus Deploy and an Argo CD maintainer, put the results in plain terms:
“Argo CD is trusted, stable, and delivering real operational gains at scale. These trends reflect how central Argo CD has become to running reliable, efficient cloud native infrastructure.”
Dan Garfield, VP of Open Source, Octopus Deploy; Argo CD maintainer, CNCF press release, July 24, 2025
Garfield isn’t a neutral observer here. He’s also a co-creator of the OpenGitOps principles and joined Octopus Deploy through its acquisition of Codefresh, which gives him a foot in both the open source maintainer world and the commercial CD vendor world. That dual vantage point is exactly why his read on where teams still struggle (more on that below) carries weight.
Does GitOps Actually Improve Reliability?
Here’s the question every platform lead actually wants answered: does any of this make production more stable? The honest answer is “probably, but the data is correlational.”
Octopus Deploy’s State of GitOps Report, based on 660 survey responses and released June 17, 2025, found that teams with higher GitOps maturity scores show stronger DORA 4 performance (deployment frequency, lead time for changes, change failure rate, and recovery time) and better reported reliability, including less downtime and fewer slowdowns. Ninety-three percent of organizations surveyed plan to continue or expand GitOps adoption.
What the report doesn’t claim is a clean cause and effect line. Teams with mature GitOps practices also tend to have better observability, stronger staffing, and more disciplined engineering culture overall, any of which could be doing the heavy lifting on reliability. Our read: GitOps maturity is a reliable proxy for “this team has its act together,” more than it is a standalone fix you can bolt onto a struggling platform and expect DORA metrics to improve on their own.
What Actually Changes for Your Team
Production changes start happening through Git commits and pull requests instead of direct kubectl apply commands or ad hoc CI pushes. Your audit trail becomes commit history instead of a separate change ticket. A controller, usually Argo CD or Flux, continuously compares live cluster state against what’s declared in Git and corrects drift automatically, often before anyone notices a problem.
The Risk Nobody Puts on the Slide
Is it weird that the same property making GitOps powerful, a single source of truth in Git, also makes it dangerous? Not really, once you think about it: centralizing control always centralizes risk too.
The most cited operational risk across the security research is secrets sitting in Git repositories. Even encrypted secrets can be exposed if key management is sloppy, and a compromised cluster-specific key (with tools like Sealed Secrets) can cascade across every secret tied to that cluster. Per the 2025 Verizon Data Breach Investigations Report, as cited by Keeper Security, 39% of secrets exposed in public Git repositories were tied to web application infrastructure. Layer on AI tooling and the problem accelerates: GitGuardian’s internal research found AI-service credential leaks grew 81% year over year in 2025.
Then there’s the part marketing decks skip entirely: the platforms GitOps depends on are getting less reliable, not more. GitProtect.io’s DevOps Threats Unwrapped Mid-Year Report 2025 tracked 330 incidents across GitHub, GitLab, Bitbucket, Jira, and Azure DevOps in just the first half of 2025. GitHub incidents alone rose 58% year over year, climbing from 69 to 109. Azure DevOps suffered a single 159-hour global degradation in January 2025, the kind of outage that would stall any GitOps pipeline depending on it. Greg Bak, Head of Product Enablement at GitProtect, didn’t soften the warning:
“We are witnessing a clear upward trend in outages and disruptions across DevOps platforms, demonstrating that traditional perimeter security is no longer sufficient. Anticipating failures before they happen, paired with self-healing infrastructure, will redefine how organizations safeguard uptime and business continuity.”
Greg Bak, Head of Product Enablement, GitProtect, via Channel Insider, September 2025
This is the contrarian point platform leaders genuinely need to sit with: GitOps gives you a clean source of truth, but that source of truth now lives on infrastructure that fails more often than the previous year, not less. Teams that don’t budget for secrets architecture (External Secrets Operator, HashiCorp Vault, or SOPS) as a deliberate decision, not an afterthought, are building their reliability story on a foundation they haven’t actually secured.
The Real Barrier Isn’t the Tooling Anymore
The CNCF 2025 survey surfaced something that should reframe how engineering leaders budget for GitOps rollouts: for the first time, cultural and organizational challenges (47%) overtook technical complexity as the top barrier to cloud native adoption. CNCF Executive Director Jonathan Bryce summarized the broader shift this way:
“Kubernetes isn’t just scaling applications; it’s becoming the platform for intelligent systems.”
Jonathan Bryce, Executive Director, CNCF, via PR Newswire, January 2026
Translate that into a practical takeaway: if you’re stalled on GitOps adoption, the blocker probably isn’t Argo CD versus Flux. It’s getting application teams to trust a pull-request based deployment model, documenting the new workflow, and giving platform teams the internal credibility to enforce it. Budget for change management the same way you’d budget for a tooling migration, because at this point, that’s what the data says actually determines success.
Frequently Asked Questions
What is GitOps in Kubernetes?
GitOps is an operational model that uses a Git repository as the single source of truth for Kubernetes infrastructure and application configuration. A controller like Argo CD or Flux continuously compares live cluster state to what’s declared in Git and automatically reconciles drift, making every production change reviewable and auditable.
What’s the difference between GitOps and DevOps?
DevOps is a broad cultural framework uniting development and operations. GitOps is a specific practice within it, using Git as the control plane for declarative infrastructure and deployment state, typically implemented with Argo CD or Flux on Kubernetes.
Is Argo CD better than Flux?
Neither tool is universally better. Argo CD offers a web UI, broader enterprise adoption (around 60% of GitOps-managed clusters per CNCF’s 2025 survey, with a 79 NPS), and stronger multi-tenancy features. Flux is lighter-weight and more CLI and automation-first. The right choice depends on team size and UI needs.
How does GitOps improve Kubernetes reliability?
GitOps continuously reconciles live cluster state against Git, catching configuration drift automatically instead of during an incident. Octopus Deploy’s survey data links higher GitOps maturity to better DORA 4 metrics, though this reflects correlation across surveyed teams rather than an isolated causal study.
What are the security risks of GitOps?
The most cited risks are secrets stored directly in Git (even encrypted secrets can be exposed through weak key management), excessive RBAC permissions, and the fact that one compromised repository can push unauthorized changes across every cluster it manages. Teams typically mitigate this with external secrets stores rather than committing secrets to the repo.
What to Watch Next
Here’s what you now know that you probably didn’t ten minutes ago: that “58%” headline number is real, but it measures adoption maturity among the most advanced cloud native teams, not a magic incident reduction rate. Argo CD has effectively consolidated the GitOps tooling market. And the infrastructure underneath all of it, GitHub, GitLab, Azure DevOps, is having a rougher year than the GitOps success stories let on.
Over the next six to eighteen months, watch three things: whether secrets management tooling (External Secrets Operator, Vault integrations) becomes a default part of GitOps reference architectures instead of an add-on; whether Argo CD’s enterprise lead over Flux widens further given Octopus Deploy’s backing; and whether platform teams start publishing real DORA metric improvements tied to GitOps rollouts, rather than satisfaction surveys, to finally settle the causation question.
If your team is still running manual kubectl apply deploys in 2026, the gap between you and the 58% isn’t a tooling problem anymore. It’s a roadmap problem, and the roadmap starts with picking a reconciliation engine and a secrets strategy before you write a single manifest.
Want this kind of breakdown in your inbox before it hits the front page of Hacker News?Subscribe to The Neural Loop at neuralwired.com/newsletter.
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.
