For 15 years, public cloud providers have defined the industry for most enterprises: on-demand, automatically metered services delivered over the open internet that give developers immediate access to storage, databases, compute, application development platforms, and AI capabilities. That model remains dominant because it is simple, well-instrumented, and universally supported. Yet an adjacent reality has always existed. Large-scale, off-market capacity deals where technology companies with surplus GPUs, storage, and compute sold blocks of capacity in bulk to other firms under nondisclosure agreements were once common. Those were cloud transactions in substance, since you were using somebody else’s servers. However, they lacked the automation, metering, and governance that define public cloud services, and they operated entirely outside the frameworks enterprises rely on for budgeting, compliance, and accountability.

A shadow market becomes visible

These arrangements are now becoming more visible and more formalized. Some are even openly auctioned. Meta’s entrance into the cloud capacity space, essentially offering its excess compute infrastructure to outside buyers, represents the maturation of a market that has existed in back rooms for years. Large, multiyear capacity commitments are no longer whispered about during boardroom lunches. They are being announced, financed, and tracked by analysts. This shift is creating a distinct layer in the cloud landscape, one that sits between traditional hyperscalers and true private clouds, and one that enterprises can no longer afford to ignore.

The practical implication is that the cloud market you thought you understood now has a parallel track. When a large enterprise needs maximum GPU capacity for model training or inference, it has more options than a year ago, and those options come with genuinely different trade-offs. You can go to a hyperscaler and pay the published rate for metered GPU as a service, receiving a fully managed platform with all the tools, governance, and integration you need. Or you can reach out to a technology provider that happens to have idle or excess GPU capacity and negotiate a bulk deal at a fraction of the published rate. The first option provides predictability and depth of service. The second offers raw cost savings if you have the operational capability to handle less-managed infrastructure.

This bifurcation is muddying procurement decisions. The gap in pricing between bulk off-market capacity and public cloud offerings can be substantial. Some analysts cite differentials ranging from 10 to 100 times. But headline GPU rates are only part of the evaluation. Bulk deals tend to come with minimal metering, limited monitoring, and a do-it-yourself culture around incident response and optimization. You are, in effect, purchasing wholesale energy. It is robust and capable, but it requires your own wiring and maintenance. Organizations accustomed to the instrumentation and service-level agreements of hyperscalers may find such a different operational reality a bit jarring. Those with mature cloudops teams may find the economics compelling.

Who benefits and who adjusts

The hyperscale incumbents will not be displaced overnight. They offer the complete ecosystem, not just GPU frameworks but development tools, hundreds of managed services, identity, compliance, and integration layers that are genuinely difficult to replicate. However, they are now facing a market where customers with intensive computational needs can source raw GPU capacity from alternative suppliers, particularly for bursty or cost-sensitive workloads. This is not necessarily a threat to hyperscaler dominance, but it is a complication. The hyperscalers will likely respond through partnerships, capacity-coverage agreements, and possibly acquisitions of promising capacity players. Effectively, they will become customers of the same off-market ecosystem they once ignored.

The cloud market is adding a new axis of choice: managed breadth versus specialized efficiency. Enterprises will increasingly construct hybrid operating models, keeping steady-state, security-sensitive, and toolchain-dependent workloads on hyperscaler platforms while offloading cost-intensive training runs and elastic inference to bulk-capacity providers. This is not a binary choice. It is an expanding continuum of sourcing options that demands more sophisticated procurement and architecture planning.

How to take advantage

Know your actual workload cost before you negotiate. If your AI workloads are compute-intensive, model training-heavy, or require burst capacity at unpredictable intervals, the economics of bulk capacity deals can be compelling. Run a pilot that captures total cost of ownership, including data movement, integration effort, operational overhead, and potential downtime during self-managed troubleshooting before you assume bulk is simply cheaper. Compare fully loaded costs, not GPU-hour sticker prices.

Build portability into your AI stack from the start. Bulk-capacity providers often lack the governance, compliance tools, and model life-cycle management enterprises need. Mitigate this risk by standardizing on containerized inference runtimes, open model formats, and CI/CD pipelines capable of deploying across multiple targets. This type of discipline turns vendor diversity into negotiating leverage rather than operational liability. It also ensures you can shift workloads as capacity markets fluctuate.

Treat capacity sourcing as a strategic procurement function. Bulk cloud capacity is not a niche quirk. It is becoming a recognized market that rewards supply-chain thinking. Diversify your supplier base, negotiate multi-vendor commitments where possible, and develop a reserve strategy for critical workloads. Keep your hyperscaler relationship for reliability and breadth, but maintain at least one secondary capacity arrangement for cost-sensitive or elastic workloads. The enterprises that treat capacity as a variable asset, rather than a fixed infrastructure decision will be better positioned as this market continues to expand and formalize.

The cloud market is no longer a simple fork between public and private. A defined middle ground of negotiated bulk capacity is now attracting billions in investment and reshaping how AI infrastructure costs are allocated. Enterprises that understand this landscape and build flexible, portable architectures that can span it will capture more value from AI investments than those who default to the familiar hyperscaler menu alone.

Losing access to your Google account might just be the epitome of a modern-day nightmare.

Especially if you’re using Android and even more so if you’re invested in lots of different Google services on top of that, the amount of access and info connected to that one single sign-in is just staggering. Think about it: You’ve got everything from your Android apps and settings to potentially your email, your documents and spreadsheets, and all of your assorted files in Google Drive. And that’s to say nothing of all the images you might be backing up to Google Photos, the notes you might be storing in Google Keep, and even random things you might not think about like your browsing activity in Chrome or your location-related data in Maps.

It’s a lot, to say the least. And that’s precisely why it’s so important to think about your Google account security proactively and do everything you can to (a) make sure no one else ever gains access and, equally important, (b) make sure you never lose access to that all-encompassing sign-in.

At this point, you’re hopefully already doing smart stuff like using a unique and secure password and relying on two-factor authentication to add an extra layer of security beyond that — or maybe using a passkey for an alternate form of two-factor protection.

But even with all of those layers, the issue still remains of what happens if for any reason you aren’t able to get into your own Google account one day. And now, Google’s got a new option to help you make sure that nightmare never actually comes to pass.

Suffice it to say, it’s well worth your while to consider. But there are some important things you should know about it first.

[Get fresh Googley insight in your inbox with my free Android Intelligence newsletter. One new and useful tip every Friday!]

The ins and outs of Google selfie sign-in

The system of which we speak is an option to use a sophisticated selfie of yourself to sign into your Google account in an emergency — if all of your usual methods are for whatever reason not getting you through the gate. It happens more often than you’d think. And having multiple secure workarounds in such a scenario could be a massive lifesaver if it ever happens to you.

Depending on where you look, the option is called “selfie for sign-in,” “video verification,” or sometimes just “selfie video.” (Hey, this is Google we’re talking about here. Branding has never been a strength.) The system was announced in a random blog post a couple weeks back and has been slowly but surely showing up under the hood for accounts around the world ever since — but you’d never know it unless you happened to poke around in the exact area of your Google account settings where the option appears.

In my experience so far, it seems most average Android-owning animals are woefully unaware of its existence — and those who are aware of it are mostly perplexed by how exactly it works and if or when it’s advisable to use.

I’ve set it up on my own personal Google account, and I’ve explored every last nook and cranny. Here’s everything there is to know:

1. Selfie sign-in is super simple to set up

Seriously — it couldn’t be much easier. Just go to this page within the Google account settings site on a device with a camera (like, y’know, your phone or maybe an Android tablet).

Provided the feature is available on your account now, you’ll just click a couple o’ quick buttons to get the process started, then you’ll follow some simple prompts to stare into your camera longingly for a few moments.

The system will ask you to turn your head in specific directions. Then, it’ll take a handful of seconds to process and save your stunning turn on the virtual runway.

And — well, that’s pretty much it.

2. Your selfie video is only for access to your Google account — not your phone or tablet

This is slightly confusing, since most modern Android devices offer the ability to use biometrics on the lock screen and show your face to unlock the phone itself — but the selfie sign-in system we’re speaking of here has nothing to do with any of that. It won’t unlock your device in any scenario or have any connection to any specific phone or tablet.

It’s connected purely to your Google account, and its sole purpose is acting as a mechanism to let you sign into that account — not to unlock or access any specific piece of hardware.

Speaking of which…

3. It’s only there as a last resort

Once you set up your selfie sign-in, odds are, you’ll never actually think about it again or have a reason to use it. Anytime you sign into your Google account, you’ll still use your standard password, passkey, and any two-factor authentication you’ve placed on the account.

The selfie path is there only in the event that all those regular methods are for some reason failing you. It’s unlikely, but it’s not impossible. And with your selfie video saved, if that situation ever arises, you’ll have an easy alternate way to prove your identity — by submitting a live on-the-fly selfie video and allowing Google to match it with your original saved one — so you can avoid getting locked out.

4. The selfie sign-in is designed to be both private and secure

When it comes to matching a saved selfie video and a new live one, Google requires different movements to verify validity and avoid any impersonation attempts.

Google says the data from your saved selfie video is always encrypted, too — not just in transport but also at rest, when it isn’t actively being used — which means no one else should ever be able to access it or do anything with it. You can always opt to delete a saved selfie video entirely, if you want, via that same Google account settings page.

And on that note…

5. You can prevent your selfie video from being used for any form of training

Lots of folks are understandably uneasy about the idea of their personal data — including their personal faces! — being used for any manner of machine learning these days. Google does ask for permission to do that and anonymously lean on your submission to help improve its facial recognition systems when you sign up for the selfie sign-in option, but critically, you can easily say no thanks.

When you’re in the midst of the selfie sign-in setup, look for the option to “Improve Google services.” It’ll appear at the bottom of the initial service agreement.

As long as you don’t check the box in that area, your selfie sign-in data will never be used for anything other than its primary intended purpose. And if you ever change your mind or are unsure of how you initially answered, you can also always revisit and revise that decision on that same Google account settings page.

6. Selfie sign-ins are (so far) only for individual Google accounts

With this initial rollout, Google’s selfie sign-in option is not available for accounts that are part of a Google Workspace team or organization. That kind of makes sense, since in any such situation, you could always turn to an admin for help if you were ever to lose account access, anyway.

This is something more intended for individual Google accounts, where you’re on your own and largely out of luck if you ever lose access. So whether you’re conducting business from an individual account or using an individual account alongside a Workspace-connected company sign-in, it’s something to consider for that part of your online identity.

The only other noteworthy asterisk is that selfie sign-ins won’t work with accounts where Advanced Protection is enabled. Advanced Protection is an extra-heightened form of Google account security created for people in the public eye or otherwise at an elevated risk of a targeted attack, and so it deliberately makes it much more difficult to get into an account in ways that go above and beyond what’s necessary for most ordinary organisms. If you have Advanced Protection on for your Google account, selfie sign-in won’t be available for you.

But for the rest of us, it’s a powerful new path that could prevent an unthinkable nightmare — and all you’ve gotta do is take two minutes to set it up now and then hopefully forget all about it.

Got Android? Check out my free Android Intelligence newsletter to get an exceptional new tip in your inbox every Friday.

It’s a sign of the times: Security conference DefCon has added smart glasses to its list of banned audio- or video-recording devices.

The organizers have said that, with no consistent way to understand whether smart glasses are recording or not, they have taken the step to ban them in their entirety on the grounds that they erode trust and invade people’s privacy.

Putting corrective lenses in the smart glasses will be no excuse: DefCon insists that visitors bring a pair of glasses without the smarts instead.

The smart glasses ban has been added to DefCon’s already strict rules on photography, which among other things ask visitors not to take group shots and to use “portrait” mode (or a low F-stop for those with old-fashioned cameras) to focus on the foreground, so that people in the background appear blurred.

The smart glasses market has gone up a notch lately. Google and Samsung have both announced Gemini powered eyewear running on Android. Apple is looking to launch its new generation of smart glasses next June, citing privacy concerns as the reason for the delay.

It is not only tech conferences that are getting jumpy about smart glasses. CISOs are beginning to get wary about their impact on organizations and whether their data is secure.

This article first appeared on CSO.

Every cloud architect, every financial services executive, and frankly every enterprise CTO should be paying attention to what is going on in the United Kingdom right now. Britain has formally designated Microsoft, Google, Amazon Web Services, and Oracle as “critical third parties” to the financial sector, meaning they are now subject to direct oversight by UK financial regulators rather than being treated as distant infrastructure suppliers outside the regulatory perimeter.

The designations took effect on July 13, 2026, and the oversight will be carried out by the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority. The point is straightforward. If these platforms underpin critical banking and financial operations, then their resilience is no longer just a procurement issue. It is now a matter of financial stability.

This is a bigger deal than many people understand. For years, enterprises have treated cloud platforms as outsourced technology providers. Regulators are now making a different argument. They are saying that when enough banks, insurers, payment firms, and market infrastructures depend on the same small group of cloud providers, those providers become systemic infrastructure whether they like the label or not. Reuters reported that the UK’s framework will bring requirements such as resilience testing, self-assessments, and incident reporting directly to these providers. In other words, this is not just more policy language. It is operational oversight aimed at the platforms themselves.

The first thing to understand is that this move is not anti-cloud. It is the opposite. It is an acknowledgment that cloud has become too important to remain lightly touched when it comes to systemic risk. Regulators are not trying to unwind cloud adoption in financial services. They are accepting the reality that core financial operations now depend on a concentrated set of external platforms. When that happens, the conversation changes from vendor management to infrastructure resilience.

Systemic cloud concentration

The market has spent years talking about cloud concentration risk as if it were some vague future concern. It is no longer abstract. The UK is acting because concentration at this level means that a disruption at one major provider can ripple across multiple institutions simultaneously. That is the core issue. It is not whether Microsoft, Google, Amazon, or Oracle are competent operators. In many cases, they are exceptionally good at what they do. The problem is that too much critical activity depends on too few shared platforms.

This is a concept many business and technology leaders still struggle to internalize. A single bank can do a fine job managing its own vendor exposure and still be part of a broader systemic vulnerability if every other bank is relying on the same provider, the same region, the same identity layer, or the same operational dependencies. Regulators are stepping in because the risk is collective, not just institutional. That is why this matters well beyond the UK. It provides a framework for thinking about cloud not as outsourced capacity, but as part of the plumbing of the financial system itself.

Regulators expand their reach

Traditionally, regulators focused on the bank, insurer, or market institution and expected that entity to manage the risks created by outside suppliers. That approach still exists, and financial institutions remain accountable for their own resilience. However, the UK now says that, in some cases, this indirect model is not enough. If a third party becomes critical enough, regulators want direct line of sight into that provider’s resilience posture as well. This is probably the most important architectural and policy signal in the entire move.

That changes the relationship between the financial sector and the cloud providers in a meaningful way. Direct oversight means cloud providers are increasingly being treated less like optional technology partners and more like essential utilities that support national economic confidence. Once that happens, architecture decisions start to carry a different weight. Decisions about control planes, failover models, identity dependencies, regional design, observability, and incident response are no longer just internal engineering choices. They become part of a broader resilience conversation that may now include regulators.

A lot of enterprises have been behind the curve. They built architectures under the assumption that the cloud was simply a faster and cheaper hosting model. It is not. At scale, cloud is shared critical infrastructure. The UK has now made that point explicit.

More scrutiny isn’t more safety

It’s tempting to read this and assume the problem has now been solved. It has not. Direct oversight of hyperscalers does not remove the responsibility of banks or other enterprises to architect well. In fact, it should push them to architect better. A regulated provider can still be a concentration point. A resilient platform can still be used in a fragile way. And a well-run cloud service can still become part of a badly designed dependency chain.

If you are in a regulated or highly sensitive industry, you should take this as a warning that resilience can no longer be treated as a side topic. You need to know exactly which services are business-critical, which control planes are shared, which identity systems create cross-platform dependencies, and how your recovery assumptions actually work in the real world. Most organizations are much weaker here than they believe.

The UK’s move should also force a hard conversation about operational transparency. If regulators are requiring incident reporting and resilience evidence from major providers, enterprises should be demanding clearer dependency mapping and better architectural visibility inside their own environments. You cannot build true resilience on top of assumptions and vendor slide decks.

The start of a much larger shift

The deeper message is that cloud is crossing a line from enterprise technology choice into national and sector-level infrastructure policy. Once a few governments and central regulators start treating cloud this way, the rest of the world tends to follow in some form. We have already seen comparable concern in Europe, and now the UK has made its own move with direct designations and direct oversight.

Architects, CIOs, and boards need to mature their thinking quickly. The conversation is no longer limited to feature depth, discounts, migration speed, or which provider has the best AI story this quarter. The conversation is now about resilience, concentration, transparency, control, and systemic dependency. Those are bigger issues, and they are not going away.

The UK is telling the market something very clearly. Microsoft, Google, Amazon, and Oracle are not just selling cloud services into the financial sector. They are becoming part of the infrastructure on which that sector depends. Once you understand that, everything changes, including how we architect for the future.

For years, the public cloud was the default for new workloads because its convenience, elasticity, and breadth of services made sense. However, as AI’s strategic importance grows, its economics and infrastructure are changing. Tesla is one of the clearest examples of a company deciding that AI is too important, too expensive, and too central to its business to leave largely in the hands of a third-party cloud provider.

 At the center of Tesla’s strategy is a simple idea. If AI is key to how you build your products, run your business, and define your future, the infrastructure that powers AI becomes a strategic asset. It is no longer just plumbing but part of the product itself. Tesla’s models, databases, applications, and workflows increasingly rely on infrastructure that is built, hosted, and managed by Tesla. That means the company has direct control over the hardware, the software stack, data movement, performance tuning, and security posture. For a company that depends on AI to support autonomy, robotics, manufacturing intelligence, and future product direction, that control matters.

This is the real heart of the matter. Tesla is not treating AI as a side project or a feature layer added on top of an existing business. AI is central to Tesla now and into the future. It is a force multiplier, but more than that, it is an essential aspect of product development, operational efficiency, automation, and competitive differentiation. Once a company reaches that level of dependence on AI, the conversation around infrastructure changes very quickly.

Public cloud is attractive because it provides a complete AI ecosystem on demand. You can provision compute, storage, training environments, managed services, orchestration tools, and deployment pipelines without building much yourself. That is why I often call public cloud “the easy button” for AI. It is fast, convenient, and feature-rich. But convenience comes with a premium, and for many companies moving deeply into AI, that premium is becoming very hard to justify.

Cost is driving AI out of the cloud

One of the biggest forces driving this shift is price. Many enterprises moving into AI are shocked by what public cloud providers charge for AI infrastructure. Training clusters, inference engines, storage, networking, observability, and support services all add up quickly. What begins as a convenient path to experimentation can become an extremely expensive operating model when AI moves into production at scale.

In my experience during the past 15 years, public cloud is often at least twice as expensive as comparable private infrastructure for sustained workloads. That is not true in every case, and it depends heavily on utilization patterns, architecture, and operational maturity. However, for large, predictable, always-on AI workloads, public cloud economics often become difficult to defend. The markup associated with convenience, elasticity, and managed ecosystems is substantial.

In response, companies are increasingly exploring alternatives. Some are moving toward neoclouds that specialize in AI infrastructure. Others are evaluating sovereign cloud options for control, locality, or compliance reasons. Many are revisiting private cloud infrastructure for the most strategic and cost-intensive workloads. Tesla is becoming the poster child for how successful that approach can be when a company has the scale, the sophistication, and the long-term commitment to execute it well.

Control, governance, and security

Cost is only one part of the equation. Control is the other major driver. When Tesla runs its AI infrastructure on equipment it owns and operates, it gains much tighter control over performance, data handling, workload placement, governance models, and operational priorities. That matters a great deal when the workloads involved are mission-critical and directly connected to the future of the company.

A privately controlled AI environment can provide better security because the organization has direct oversight of the infrastructure stack. It can provide better governance because data, models, and workflows remain inside systems the enterprise fully controls. It can also improve reliability and performance tuning because engineering teams can optimize specifically for their own AI pipelines rather than adapting to the generalized patterns of a shared cloud environment.

Of course, many people are quick to point out that running your own private infrastructure comes with significant labor and cost. They are not wrong. Building and operating private AI infrastructure requires capital, engineering skill, facilities, procurement discipline, operational excellence, and long-term commitment. This is not a shortcut, nor is it easier than public cloud. In many ways, it is harder.

However, the point is that for sophisticated companies with large-scale, steady-state AI needs, it can be worth it. Better control, better governance, better security, and ultimately lower cost can justify the additional operational burden.

The future of AI infrastructure

What makes Tesla so important in this discussion is that the company chose this route because AI is inseparable from its business strategy. Many other enterprises are heading in this same direction. As AI becomes less experimental and more operational, the infrastructure conversation shifts from convenience to economics, control, and differentiation.

Not every company should follow Tesla’s path. Many enterprises are not ready to build, host, and manage their own AI environments. Many lack the scale to justify it. Many still benefit tremendously from the agility of public cloud. But for organizations where AI is becoming central to products, services, and competitive advantage, Tesla’s strategy is increasingly relevant.

There are three things every enterprise should think about when considering ownership of its own AI infrastructure:

• First, understand the operational burden in full. Private AI infrastructure requires teams, processes, facilities, and discipline that many organizations underestimate.
• Second, know the economics of your workload patterns. If AI demand is large, steady, and strategic, the cost advantages of ownership may be compelling.
• Third, think beyond cost alone and focus on control. If AI is core to your future, owning the infrastructure may offer strategic benefits in governance, security, optimization, and long-term independence that public cloud cannot easily match.

Tesla’s strategy is not for everyone, but it is a persuasive example of what happens when a company decides that AI is too important to rent forever. Public cloud remains the easy button, and for many organizations, that will be enough. But for companies that see AI as fundamental to how they will compete, private infrastructure may turn out to be the smarter choice.

The European Commission’s latest push to reduce dependence on foreign technology providers is not surprising. If Europe believes that critical digital services could be disrupted by foreign governments, foreign legal systems, or foreign-owned providers, it will, of course, respond. That concern is now being expressed in the language of “kill switch” risk, meaning the fear that the cloud, AI, or semiconductor services that Europe depends on could be interrupted or constrained by forces beyond its control.

At a high level, that concern is valid. Europe is right to worry about strategic dependence. If critical public services, regulated workloads, or national-interest systems rely on infrastructure controlled elsewhere, sovereignty becomes more than a policy slogan. It becomes an architectural issue. However, I am skeptical of the leap from identifying the problem to assuming that a policy response will produce a cleaner, safer, or even more sovereign market. There is a good chance it may do the opposite.

What Europe is trying to protect

The motivation behind this effort is clear. Europe wants to reduce its dependence on cloud computing, artificial intelligence, and semiconductors from providers it does not fully control. It wants to ensure that core digital services cannot be switched off, legally constrained, or strategically influenced from outside the region. That is the public policy objective, and from a government standpoint, it makes sense.

The problem is that cloud markets don’t often respond to political intent as policymakers hope. The public cloud market is concentrated among a few big providers because scale matters. The hyperscalers have built global infrastructure, extensive services, ecosystems, and operating models that smaller regional players can’t match. Enterprises chose them for operational advantages, not geopolitical reasons.

Europe now finds itself in a difficult position. It wants sovereignty, but it also wants the benefits of scale, reliability, feature depth, and cost efficiency that usually come from very large cloud providers. Those goals do not always align.

Sowing enterprise confusion

One likely outcome of this push is that European enterprises will become increasingly confused about which public clouds they should select or avoid. That is not a minor point. Most enterprises already struggle with cloud strategy when the drivers are technical, financial, and operational. Add political sovereignty requirements, and the market becomes even harder to navigate.

Enterprises will now need to ask a more complex set of questions. Is a US-based hyperscaler with a localized European operating model acceptable? Is a European-branded sovereign cloud built on American technology better? Is a regional provider safer simply because it is smaller and local, even if it offers fewer services, weaker security tools, less resilience, and a less certain long-term future? At what point does “sovereign enough” become a legal or political judgment rather than a technical one?

This is where the market gets muddy. Policy discussions often imply a binary distinction between foreign and sovereign. In reality, cloud architectures are full of hybrids, partnerships, licensing arrangements, embedded dependencies, and supply chain layers, making neat categorization difficult. Enterprises do not buy cloud services based on a political slogan. They must navigate stacks of contracts, services, support structures, compliance obligations, and technical capabilities. The more politics enters that decision process, the less clarity there may be for buyers trying to make rational platform choices.

Sovereign clouds may not fix things

There is another reality that I think policymakers underestimate. Increased investment in sovereign cloud providers does not automatically create a durable sovereign cloud sector. In fact, history suggests the opposite.

Governments and enterprises may push investment toward smaller sovereign providers, but those providers still face the same brutal economics of the cloud market. They need capital, scale, customers, engineering depth, and ecosystem gravity. Many smaller providers will struggle to compete over time. Some will fail. Others will narrow their focus. Many will eventually be acquired, directly or indirectly, by larger players, including the very US-based cloud providers Europe is trying to reduce dependence on.

That’s the irony. Political pressure may spark a burst of sovereign cloud activity, but market gravity tends to reward scale. Sovereign cloud investment may create a temporary diversification, but in the long run, it could still end in concentration.

Sovereignty is not a bad goal, but the cloud business is structurally difficult. Running a competitive cloud platform is expensive. Matching hyperscaler capabilities is even harder. Enterprises eventually notice the gaps in services, AI tools, ecosystem support, geographic resilience, and operating maturity. When they do, they drift back toward the biggest and most capable providers.

Fragmentation comes before security

My concern is that Europe may be entering a period when cloud architecture is driven less by technical fit and more by political signaling. That rarely leads to simplicity. It usually results in fragmented strategies, duplicated platforms, inconsistent governance, and long procurement cycles.

Some organizations will choose a sovereign-first model for political reasons. Others will remain with hyperscalers but add contractual and architectural safeguards. Others will adopt a multicloud approach purely to avoid appearing overly dependent on one provider. Still others will split workloads by regulatory sensitivity, which sounds sensible until integration costs and operational complexity add up.

This is how confusion mounts. The question shifts from “Which platform best supports my workload?” to “Which platform is politically safest this quarter?” That is not a stable architectural framework.

Skeptical but attentive

I understand exactly why Europe is raising this issue. No responsible government wants critical digital services held hostage by external dependencies. That concern is rational, but rational concern does not guarantee rational market outcomes. My skepticism is not about whether digital sovereignty matters. It does. But can policy alone produce genuine long-term autonomy or will it create a more confusing procurement environment? At the same time, the market will quietly continue to consolidate around the largest global platforms.

The uncomfortable truth is that sovereignty is easier to announce than to implement. Cloud sovereignty is especially difficult because cloud markets reward scale, capital, ecosystem strength, and breadth of services. Those forces do not disappear simply because a regulator seeks more regional control. I think this issue will become more important over the next few years as cloud, AI, and geopolitical power become even more tightly linked. Europe is right to ask hard questions about dependence. But the answers are likely to be messy, and market outcomes may not look as sovereign as policymakers hope.

I don’t expect to see a clean break from foreign cloud providers. I do expect more hybrid arrangements, more sovereign branding, more enterprise uncertainty, more investment in regional providers, and eventually more consolidation than many people currently anticipate. That is not a failure of the idea. It is just the reality of how cloud markets tend to work.

The real challenge for Europe is not identifying the risk. It is building a response that does not create more confusion than the problem it is trying to solve.

Every organization has data scattered across data warehouses, data lakes, SaaS platforms, cloud drives, and data centers. Data fabrics enable organizations to centralize and control data access, making it easier for users, such as data scientists and citizen data analysts, to find and use trusted and governed data sources. 

Data fabrics, data meshes, and distributed data clouds are all platforms to help IT and data teams put some order to the chaos around the myriad of data sources they support. Large companies need data fabrics due to the volume and variety of their data sources.

“A data fabric can be thought of as the connective tissue that ensures consistent accessibility, availability, and understanding of data across an organization,” says Dominic Wellington, data and AI expert at SnapLogic. “Individual siloed platforms may have their own internal data transfer systems, and particular teams or departments may adopt interchanges that work for that domain, but a data fabric operates at a higher level, ensuring that unified data policies are applied end-to-end across the entire enterprise.”

Types of data fabrics

When reviewing data fabrics, it’s important to consider their primary use cases, supported data types, data processing capabilities, data management structures, and governance functions. Below are some considerations when reviewing data fabrics as features, platforms, and stand-alone products.

• Some data fabrics are optimized for analytics and machine learning use cases and may have limited support for unstructured data.
• Other data fabrics extend the functionality of data governance platforms beyond data cataloging and metadata management and now include persistent data management, data quality, and dataops capabilities.
• Many data integration and API connectivity platforms go beyond proxying, pipelining, and transforming data to include search, governance, and other capabilities from data centralization.
• Some SaaS platforms are extending their connectivity and data integration capabilities, enabling multicloud portability and persistent data.
• The more advanced data fabrics support features needed for AI agents and AI model training. These platforms create a semantic context layer for structured and unstructured data sources, support Model Context Protocol (MCP) integrations, have real-time query capabilities, centralize policy-driven governance, and track data lineage.    

Why data fabrics are needed for AI

Data fabrics are not just for enterprises, and today, even smaller companies need them as part of their AI democratization programs. Here are a few reasons why:

• AI agents in enterprise SaaS solutions need access to broader data sets than those core to their workflows. Platforms such as Adobe, Appian, Oracle, Salesforce, ServiceNow, SAP, and Workday offer data fabric capabilities to bring data outside of the business processes they manage into scope for their AI agents.
• Unstructured data is important for setting the context for AI agents, and data fabrics are now used to provide access to documents, emails, transcripts, and other media formats.
• Data fabrics provide data access standards for the devops teams experimenting with AI code generators, vibe coding tools, and spec-driven development approaches to develop applications and AI agents. 
• As companies use MCP servers to connect AI agents, data fabrics provide a standardized way for the agents to access governed, trusted data sources.

“As AI agents move from generating insights to taking action, the data fabric becomes foundational in the agentic era,” says Irfan Kahn, president and chief product officer of SAP Data & Analytics. “Most enterprises operate across scattered data sources and diverse data landscapes, and what’s needed is shared business context, governed access, and clear accountability for how data is used in decision-making. Without that context, agents can’t fully understand or coordinate across the enterprise to deliver meaningful value.”

Sanjay Koppikar, chief product officer and cofounder of EvoluteIQ, adds, “Multi-agent architectures become untrustworthy when a unifying data fabric architecture is missing, since agents will often work against each other in the service of their own objectives.”

Delivering context to AI agents

AI agents need a combination of real-time data, user information, problem details, and historical context to guide their decision-making. Vishal Sood, president of research and development at Typeface, says, “MCP and data fabrics give agents access, but the harder problem is contextualizing data across multiple sources and ensuring the underlying content, media, and unstructured data are trustworthy.”

Data fabrics are the foundational elements for providing current information and long-term memory to AI agents. They simplify the many-to-many problem of connecting multiple AI models, AI agents, and MCP server integrations to multiple structured and unstructured data sources.

“The data fabric does a beautiful job of encompassing three concepts needed to create applications and processes: the data catalog, the data model, and data access,” says Sanat Joshi, executive vice president of product and innovations at Appian. “But now add business rules, process models, APIs, security groups, the organizational model, and their interrelationships into one unified view of the enterprise, and that becomes your context layer.” 

Integrations with data fabrics

Devops teams just getting started on an AI agent proof of concept may want to connect directly to the optimal data sources and APIs. Michel Tricot, CEO and cofounder at Airbyte, says connecting agents to live APIs is a great start, but it creates two big problems: APIs only return data that an agent already knows to ask for, and every query is an expensive API call chain that, with overhead, can overwhelm infrastructure in production volumes.

Tricot says the data fabric for AI use cases must be dynamic, leveraging discovery of available information from replicated data, fetching live contextual information, and writing the data back to business applications to update records.

Moving data in and out of the data fabric requires an integration strategy. Zero-ETL (extract, transform, load) is one low-cost, efficient approach for connecting to structured data sourced without replicating information. Once information is accessed centrally, it also enables streamlined security and governance.

“The promise of AI agents breaks down when they’re stuck waiting on brittle ETL, dealing with poor data quality, and lacking the right context to perform analysis,” says Preston Wood, chief security and strategy officer at Databahn. “Generating AI-ready data within a data fabric gives agents real-time access to operational data without the latency and drift that undermine decision quality. A well-architected data fabric provides the governance and lineage controls that let you deploy agents confidently, knowing exactly what data they’re touching and why.”

Centralizing AI-ready data

Data fabrics centralize AI-ready data and help data governance teams address data quality issues, biased data concerns, privacy compliance, and other data governance non-negotiables. Data fabrics also help address integration issues, monitor for data pipeline errors, and report on performance latencies. The result is that AI agents, models, and other analytics capabilities can then connect to trusted data sources with consistency.

“As AI agents and MCP architectures increasingly rely on data fabrics as their golden source of truth, data quality stops being a hygiene problem and becomes a trust problem, as we all know that trust is foundational to autonomous decision-making,” says Kellyn Gorman, database and AI advocate and engineer at Redgate Software. “Organizations that invest now in semantic consistency, lineage tracking, and observable data contracts across data fabrics will be the ones whose AI agents can be trusted to act without constant human correction.”

Data fabrics that support zero-ETL and other bidirectional integrations with sources thus become an organizational knowledge base, the data source for training AI models, and a foundation for producing data metrics.

“AI agents are only as reliable as the data they’re built on, and most organizations underestimate how much implicit tribal knowledge lives in their transformation logic rather than their source systems,” says Tobias Ostwald, director of analytics at NMI. “If you’re exposing a data fabric to agents or MCP integrations, you need lineage, testing, and metric definitions baked into the layer itself, not just documented somewhere, because the agent can’t call a colleague to gut-check a number.”

Streamlining security and governance

With a data fabric in place, governance, security, and other risk management leaders have a central location to manage data security, centralize access controls, and fulfill other governance responsibilities. Miles Ward, CTO of AI in Solution Lines at Insight, says, “We have to move past security by isolation to a governance model where the fabric itself enforces the pavement and walls of compliance.”

The data fabric also governs entitlements for AI agents and their users. Centralizing these business rules can help organizations avoid creating AI debt, a risk if controls are implemented directly in data sources or consumers.

“The convergence of AI-generated code sprawl and autonomous MCP connectivity creates a ‘perfect storm’ of architectural drift and toxic permission combinations,” says Karen Cohen, vice president of product at Apiiro. “Effective governance requires a security data fabric that monitors these autonomous connections in real time to enforce intent-based policies and strictly limit agent scope to its specific purpose. By integrating guardrails that align AI-assisted development with secure architecture principles, enterprises can proactively secure their expanding attack surface without sacrificing developer velocity.”

Future considerations for data fabrics

Expect vendors to expand the scope of their data fabrics beyond text and documents. Some will include specialized document processing for common formats such as invoices, contracts, and product documentation. There will be skills and tools to support industry-specific documents such as health records and construction documents. Others will support multimedia file types and provide metadata extraction and search capabilities. 

“Enterprises are asking agents to reason across contracts, images, PDFs, and video, and this is where most data fabrics break,” says Dave Shuman, chief data officer at Precisely. “Multimodal data must be chunked, embedded, and governed with the same rigor as structured data, including lineage and access controls.”

Several other emerging capabilities include:

• Extended support for AI agent interfaces to aid in data discovery, and with greater contextual controls on where and when AI agents can access sensitive data
• Business ontologies, semantic layers, and knowledge graph capabilities, with management tools or integrations with third-party platforms
• Support for data contracts, service-level agreements, centralized data observability, auditing, and other functions that will enhance explainable AI capabilities
• Finops functions to track costs for data owners and consumers

As more companies depend on AI agents in their operations, expect top data fabric platforms to release capabilities to expand scope, scale, use cases, and governance.  

UK Prime Minister Keir Starmer’s speech on Monday insisting that tech companies create device controls to somehow block children from viewing or creating sexually explicit imagery has raised alarms among CISOs, who worry that the same technology could undermine enterprise security. Starmer gave tech firms three months to create and implement such restrictions voluntarily, at which point he said he would push for legislation to make it mandatory.

Behind the technical and logistical hurdles for tech firms to clear, such as how a device would determine that an image was inappropriate, and how it could reliably determine the subject’s age, is the issue of whether this process would interfere with encryption protections for enterprises worldwide. And that comes down to whether the required data analysis happens on the device or in the cloud. 

Starmer did not go into a lot of detail, preferring to let technology companies craft their own plans, but in this case the details matter. Analysts and consultants said that there has been a push for everything to happen on-device, which would avoid any encryption problems; if the inspected data never leaves the device, the encryption protection would stay intact.

But this plan for the process to stay on the device seems highly unlikely for multiple reasons. The first problem is device capabilities and hardware age. Although Apple and Google engineers would be working with the latest devices, much of the UK population is using much older and less capable hardware, analysts said. 

Although a 2-, 3- or 4-year-old phone might still be able to handle the additional load, it would likely suffer a dramatic slowdown sufficient to make users decidedly unhappy. That would mean that even if the execution of the data analysis began on the device, it would likely have to be shifted to the cloud for performance reasons. And once it moved into the cloud, the encrypted data problem begins. 

Trying to do this scanning on-device in the UK would fail, said Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group. “It will make unusable the majority of devices used in the UK today. It just can’t work on-device.”

However, Villanustre observed that on-device analysis for this kind of effort, which would need to scan everything that gets downloaded to the phone in search of prohibited images, might be viable in a few years, once the typical device becomes much more powerful. But not today.

Creates new risks

Leading secure messaging app provider Signal also issued a strong statement opposing Starmer’s proposal.

“The UK governmentʼs demand that all content on all devices sold or used in the UK be scanned on the presumption of nudity, using a dystopian combination of age verification and content scanning, will not safeguard children. It endangers us all, whilst strengthening Apple, Google and Microsoft’s market dominance and their control over our most personal information,” Signal said.  “Once created, [the program] will be expanded, forming a dangerous tool that will be wielded both in the UK and abroad to censor and surveil whatever they might consider ‘threats’ or ‘harmful content.’”

Signal has aggressively fought against such programs before. Similar privacy campaigns have also been launched in other parts of Europe. 

The long held fear is that moving encrypted data to the cloud, regardless of whether it remains encrypted or is converted to clear text, creates opportunities for attackers to access the sensitive data.

“The mechanism that flags and reports a match to external authorities creates a new, built-in exfiltration path,” said Jeff Valdes, a director at consulting firm Acceligence.

Could do more harm than good

Sanchit Vir Gogia, chief analyst at Greyhound Research, argued that the UK proposal is likely to do far more damage than good. He pointed to the short three month timeframe as evidence of a lack of good faith.

“Legislation of this complexity cannot be drafted in a quarter. The deadline is a pressure instrument, not a delivery schedule. Child safety is the destination. Device-wide inspection is the wrong vehicle,” Gogia said. “Apple and Google already run on-device nudity detection in bounded contexts, and it works: a child can be warned, an image blurred, a sharing attempt interrupted.”

Gogia pointed to another logistical problem, which is that some devices such as tablets are often shared between family members, which makes reliable age determinations all but impossible. 

“The deeper flaw is that the policy assumes a stable mapping between device, person, and age, and that mapping does not exist in real households,” Gogia said. “A device cannot know its holder has changed. The only architecture that survives this is default-child with recurring adult verification, which is surveillance arriving through the back door of household economics.”

In addition, he noted, “Children disproportionately inherit the old, out-of-support handsets the mandate cannot reach. Forcing churn manufactures electronic waste and punishes the families least able to buy new.”

Carmi Levy, an independent technology analyst, agreed that the computing overhead alone for such an effort could make this a deal-killer. 

“The compute requirements, particularly in light of the need to execute this kind of filtering in real time, would be immense. It is futile to assume this capability can ever be rolled out at scale without running into massive concerns on several fronts,” Levy said. “Simply deciding how to tune the filters is an almost impossible task. Although the overall definition of nudity, namely not wearing clothing, is generally agreed upon, the line where it becomes inappropriate for minors is neither static nor universally established. So it’s wildly optimistic to assume that a single threshold would be workable at the scale proposed by Prime Minister Starmer.”

Nidhi Luthra, a director at Acceligence, added that the logistical and technological roadblocks are also a big problem. 

“Technically, parts of this can work,” she said, but vendors would have to deal with age verifications, drifts in the models and false positives, and there is also the “lack of contextual information that truly would have let this work.” 

Puts CISOs in ‘an impossible bind’

The UK proposal also puts enterprise CISOs and IT directors who need to protect sensitive data in an impossible bind, Gogia said. 

They “can govern device management and conditional access. What they cannot govern is a mandatory inspection capability that updates according to political appetite rather than enterprise risk appetite,” he pointed out. “The proposal does not automatically create a breach inside Signal, WhatsApp, or Teams, but it creates the conditions for a new class of breach around them. The weakness need not live in the messaging protocol. It can live in the mandated inspection layer, the classifier update mechanism, the age-assurance workflow, or the logs that enforcement inevitably generates.”

Regime change could lead to abuse

Another common concern is that governments change hands, so limited capabilities granted today to one government might be used very differently by a future government. 

Brian Jackson, principal research director at Info-Tech Research Group, noted, “the current government may only use it to detect nudes, but what is to stop a future authoritarian government from using it to detect unfavorable political commentary? Creating a back door means there is potential for third parties — hackers — to exploit that back door to gain access to the user’s communications. This is exactly what encryption and on-device security measures are supposed to prevent.”

He added, “Apple’s Communication Safety feature, Google’s Family Link, and a range of parental control tools already use on-device AI to detect and restrict explicit imagery on children’s devices. The government is not filling a gap the market failed to address. It is proposing to transfer control of an existing capability from the device owner to the state. Parents can deploy this protection right now, on their terms. That is where the decision should sit.”

Ryan O’Leary, research director for privacy and legal technology at IDC, said the current proposal only involves the UK, and there’s no way to determine whether other governments will try something similar. He noted that the EU’s GDPR was widely expected to go global when it launched in 2016, but in ten years, it hasn’t.

O’Leary said that if this proposal is enacted in the UK, he would advise IT and cybersecurity executives to be extra cautious when sending team members to the region. 

“It would essentially be ‘China rules’” such as air gapping systems and traveling with disposable data-limited burner phones, O’Leary said. “It’s an exceptionally big deal if it goes through,” but, he added, the chance of it happening is very low. “It seems like the technology companies will call his bluff.”

This article originally appeared on CSOonline.

Researchers in Switzerland claim to have built a perfect random number generator from two quantum superconducting chips, a 30-meter-long pipe, and some software. The resulting device could be used to generate cryptographic keys, or to offer a “public randomness service” for lotteries or blockchain applications, they say.

They’re not the first to make the claim.

Many sources of randomness are biased. For example, coins or dice tend to favor one side. “Even modern random number generators, which are based on quantum mechanical effects like the reflection of photons from beam splitters, are not entirely immune to such a systematic error or ‘bias’,” said Andreas Wallraff, one of the leaders of the research team at ETH Zurich.

Similar biases can be found in purely software-based pseudo-random number generators. This has led to security problems in IoT devices and WhatsApp, among other applications.

To get around that, the researchers set up of two supercomputing chips, each representing one qubit, cooled to near absolute zero. The chips are connected by a 30-meter-long microwave guide, similarly cooled, and the microwave photons flying between them create a situation of quantum entanglement.

The results produced by this process are then transformed via a special algorithm to generate perfect randomness. “The resulting sequence of zeros and ones is now really perfectly random, and we can even certify that,” said Renato Renner, the other team leader. “The technical improvements allowed us to create random numbers that will remain perfectly random for all eternity.”

The team published their results this week in an article entitled “Experimental randomness amplification” in Nature.

This article first appeared on CSO.