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.
