In a groundbreaking development that could revolutionize the field of artificial intelligence and neuromorphic computing, researchers have unveiled a novel algorithm–hardware co-design approach featuring neuromorphic networks supported by dual memory pathways. This innovative framework, recently published in Nature Machine Intelligence, promises to overcome longstanding challenges in efficiently mimicking brain-like processing in silicon hardware. The fusion of algorithmic design and hardware architecture epitomizes a synergistic leap forward for neuromorphic systems, which strive to emulate the efficiency and adaptability of biological neural networks.
Neuromorphic computing, inspired by the structure and function of the human brain, seeks to replicate neural dynamics through specialized hardware that inherently supports parallel and event-driven processing. Unlike traditional von Neumann architectures, which segregate memory and processing units, neuromorphic systems integrate these functions, drastically reducing latency and energy consumption. However, a persistent limitation in current neuromorphic implementations lies in their constrained memory capacity and difficulties in sustaining stable learning over time. The new co-design method directly confronts these issues by introducing a dual memory pathway mechanism akin to the human brain’s approach to memory storage and retrieval.
The dual memory pathways conceptualized by the research team separate short-term and long-term memory processing within the neuromorphic network. Short-term memory pathways facilitate rapid, flexible adaptation to incoming data, echoing the brain’s working memory functions. Concurrently, long-term memory pathways enable the consolidation and retention of learned information over extended periods. This bifurcation fosters an architectural efficiency that mitigates memory interference and catastrophic forgetting—two notorious hurdles in neuromorphic learning systems and artificial intelligence at large.
Fundamentally, the innovative algorithm tailors synaptic plasticity dynamics to the hardware substrate, leading to more stable, biologically plausible learning rules. The researchers employ spike-timing-dependent plasticity (STDP) paradigms adjusted dynamically by the dual pathways, allowing the system to adapt continuously yet retain core learned information without overwriting. This hybrid plasticity approach is supported by circuits that facilitate separate yet interactive memory stores, closely emulating the hippocampus-neocortex complementarity observed in mammalian brains.
Critically, the design is optimized to leverage emerging non-volatile memory technologies such as resistive RAM (ReRAM), which afford dense, low-power synaptic implementation. The team’s hardware prototype integrates these resistive elements into the dual memory architecture, striking a delicate balance between speed, retention, and energy efficiency. By co-optimizing the algorithmic parameters with hardware constraints, the design attains a level of performance and scalability previously unattainable in neuromorphic networks.
Extensive benchmarking on machine learning tasks highlights the superiority of this co-design approach. Tasks demanding continual learning and domain adaptation—traditionally challenging due to interference effects—exhibit enhanced stability and precision. Notably, the dual pathways enable the neuromorphic system to segregate novel information from prior knowledge efficiently, supporting lifelong learning scenarios critical for real-world AI applications such as robotics, autonomous systems, and adaptive sensory processing.
The implications of this breakthrough extend beyond traditional AI. By more faithfully replicating the brain’s memory consolidation processes, these neuromorphic networks could yield insights into neurological disorders characterized by memory dysfunction. Additionally, the modularity of the dual memory pathways invites future customization and specialization for domain-specific tasks, envisioning a new class of adaptive hardware that evolves alongside its operational environment.
Moreover, the research addresses the formidable challenge of hardware variability and noise—a persistent bottleneck in neuromorphic device deployment. The co-designed algorithm inherently compensates for device-level imperfections through adaptive learning thresholds and redundancy in memory representations. This robustness not only ensures reliable operation over extended periods but also enhances manufacturability and cost-effectiveness for large-scale silicium implementations.
This co-design paradigm exemplifies a pivotal shift in neuromorphic engineering, moving away from generic algorithm deployment on fixed hardware towards integrated development of systems where both hardware and software are mutually optimized. This approach reflects an emerging philosophy in AI hardware: embracing the interdependence of physical substrate and algorithmic function to unlock previously constrained capabilities.
Such a sophisticated neuromorphic platform provokes exciting questions regarding the future landscape of artificial intelligence. Could dual memory pathways represent a standard architectural motif underpinning all next-generation AI chips? Might this design accelerate the creation of truly autonomous systems capable of continuous, context-aware learning within dynamic environments? The potential scale and impact of these mechanisms suggest transformative ripples across industry sectors reliant on AI, from healthcare and finance to autonomous vehicles and beyond.
While promising, challenges remain. Scaling the dual memory network to extremely large, brain-scale systems presents engineering complexities necessitating further innovations in materials, circuit design, and integration techniques. Additionally, fine-tuning the balance between memory consolidation and plasticity, ensuring both adaptability and stability, demands deeper theoretical understanding informed by neuroscience. Continued collaboration between multidisciplinary teams of neuroscientists, material scientists, electrical engineers, and computer scientists will be pivotal to this endeavor.
Looking ahead, this work may catalyze the proliferation of neuromorphic devices poised to operate at unprecedented energy efficiencies while offering continuous learning capability. By taking inspiration from the brain’s memory architecture and rigorously co-designing compatible hardware, the research ushers in an era where artificial intelligence systems can remember, adapt, and grow with a natural fluidity previously attainable only in biological organisms.
The dual memory pathway design stands as a milestone demonstrating that bridging the algorithm–hardware gap is an indispensable strategy for advancing neuromorphic computing. Its capacity to resolve persistent issues such as catastrophic forgetting and memory interference attests to an elegant merging of biological principles with cutting-edge technology. As AI advances toward greater autonomy and contextual sophistication, innovations like these could form the foundational building blocks of truly intelligent machines.
In sum, the synergy achieved by this algorithm–hardware co-design exemplifies the future of neuromorphic architectures — dynamic, adaptive, and deeply integrated with the physical medium of computation. It heralds a pivotal moment where the dream of brain-inspired computing inches closer to reality, promising devices that do not merely process information, but learn and remember in a resilient and energy-efficient manner akin to the human mind.
Subject of Research: Algorithm–hardware co-design in neuromorphic networks incorporating dual memory pathways to enhance learning stability and efficiency.
Article Title: Algorithm–hardware co-design of neuromorphic networks with dual memory pathways.
Article References:
Sun, P., Su, Z., Achterberg, J. et al. Algorithm–hardware co-design of neuromorphic networks with dual memory pathways. Nat Mach Intell (2026). https://doi.org/10.1038/s42256-026-01255-3
In the rapidly evolving realm of artificial intelligence and deep learning, conventional electronic computing architectures are increasingly strained by the demands of large-scale data processing and intricate computational tasks. Optical computing has risen as a compelling alternative, leveraging the inherent physical phenomena of light—such as interference and diffraction—to execute computations fundamentally differently from traditional electronics. By harnessing these optical effects, optical computing systems (OCS) promise unparalleled advantages: notably superior processing speeds, heightened energy efficiency, and a natural aptitude for massive parallelism. These attributes make optical computing especially attractive for intensive applications like image processing, machine learning, and big data analytics, holding transformative potential across these domains.
Yet, despite these promising characteristics, contemporary optical computing platforms grapple with a significant bottleneck rooted in their hardware-centric development workflows. Conventionally, researchers must directly engage with physical OCS hardware to develop, tune, and validate computational tasks. This process entails sequential access to a limited number of costly and often heavily utilized devices. Users must physically occupy the system to load parameters, fine-tune configurations, and iteratively calibrate the hardware—an intrinsically tedious and time-consuming cycle. Each new user or task demands resetting the system state, leading to protracted queues, repetitive adjustments, and redundant calibrations. The resulting workflows impose long hours of equipment occupation and elevated trial-and-error expenses, stifling the possibility for concurrent task development and drastically curtailing research throughput and system agility.
To surmount these entrenched challenges, cutting-edge research has introduced the concept of the Digital Twin Optical Computing System (DT-OCS). This innovative approach establishes a high-fidelity digital replica—a “digital twin”—of the physical OCS that accurately models its input-output behavior under varying configuration parameters. Crucially, the digital twin allows researchers to perform extensive offline simulations, training, and optimization without the constraints of physical hardware availability. Analogous to a digital simulator software that mirrors a complex “real machine,” DT-OCS enables extensive task development and parameter tuning within a virtual environment, dramatically decoupling software development from hardware dependency. Consequently, optimized parameters validated digitally can be seamlessly transferred back to the physical system for deployment, bypassing numerous iterative hardware trials.
The implications of DT-OCS extend well beyond mere time savings. By effectively creating a “digital development toolkit” for optical computing, this framework revolutionizes the research ecosystem—transforming optical computing platforms from isolated, hardware-bound experiments to versatile, shareable research infrastructures. Researchers can now conduct task training, performance benchmarking, and method comparisons entirely within a unified digital realm, fostering collaborative innovation. Distinguished from legacy OCS paradigms, DT-OCS supports parallel task development workflows, allowing multiple computational problems to be advanced simultaneously without hardware conflicts. This capability markedly enhances flexibility, reduces development bottlenecks, and accelerates the maturation and practical adoption of optical computing technologies.
Envisioning the trajectory of optical computing, the integration of digital twin models with physical hardware appears indispensable. Contemporary transportation systems, for instance, benefit from the synergy between tangible road networks and dynamic digital mapping platforms. Similarly, next-generation optical computing platforms should embody dual representations: a robust physical computing infrastructure supplemented by perpetually updated digital twins. This paradigm champions accessibility, reproducibility, and scalability—cornerstones for fostering broad-scale collaboration. It paves the way for unified validation standards and equitable performance comparisons, catalyzing optical computing’s evolution into a general-purpose, widely deployable resource rather than a niche experimental setup.
The DT-OCS framework’s hallmark is its strategic decoupling of task development from hardware constraints. In traditional optical computing, task training and parameter fine-tuning necessitate iterative hardware engagements involving adjustments, diagnostics, and recalibrations. This approach encumbers the process with inefficiencies and precludes simultaneous multi-task development. DT-OCS obviates these impediments by faithfully modeling the physical system’s responses across parameter spectra, enabling exhaustive offline optimization. This digital-first workflow increases research agility, minimizes hardware occupancy, and substantially compresses the development timeline. Consequently, DT-OCS amplifies the throughput and adaptability of optical computing research endeavors.
The real-world efficacy of the DT-OCS framework has been experimentally validated using a cutting-edge high-speed optical computing system incorporating silicon photonic feature-computing chips. These empirical studies demonstrated DT-OCS applications in diverse computational domains, including image classification and sequential decision-making. Notably, configurations optimized within the digital twin translated flawlessly to the physical hardware, with observed task performance closely mirroring digital forecasts. This underscores not only the high fidelity of the DT-OCS model but also its robust transferability across practical scenarios. Moreover, by enabling parallel task development within the digital domain, DT-OCS expedites the overall research workflow, markedly elevating efficiency.
An illustrative application of the DT-OCS system involved offline training and deployment for the Fashion-MNIST image classification task—a benchmark dataset widely used in machine learning. This practical demonstration affirms DT-OCS’s capacity to bridge digital model development with real-world optical computing implementations. Beyond efficiency gains, DT-OCS signifies a conceptual shift toward disentangling computational task design from the idiosyncrasies of physical system constraints. Historically, optical computing research has been hamstrung by its dependence on specific hardware platforms and accessibility limitations, hindering reproducibility and cross-task comparisons. The introduction of an open-source digital twin framework surmounts these barriers by democratizing access and standardizing evaluation protocols.
By openly releasing the DT-OCS framework alongside associated task datasets, the research fosters a community-driven ecosystem where software-based task design, training, and validation can proceed independently of physical system constraints. This openness engenders scalability, reproducibility, and collaborative potential that traditional optical computing architectures cannot easily achieve. Researchers worldwide gain the freedom to explore broader task horizons, perform comprehensive benchmarking, and validate innovative approaches within a consistent computational substrate. Such a paradigm shift propels optical computing from isolated experimental configurations into accessible and extensible platforms, expediting technological advancements and practical deployments.
This pioneering work advocates a transformative application paradigm for optical computing platforms: the symbiotic coexistence of physical hardware and computationally equivalent open-source digital twin models. Only by embracing such dual-system architectures can the field transcend limitations imposed by experimental variability and hardware scarcity. The resultant platforms will be shareable, replicable, and adaptable to a diverse array of research challenges. As optical computing moves towards becoming a mainstream computational resource, the principles embodied by DT-OCS may well establish the foundational infrastructure that underpins scalable, collaborative innovation in photonic information processing.
Subject of Research: Not applicable
Article Title: Digital twin optical computing system
Nvidia’s new RTX Spark is one of the most interesting personal computing announcements in years. That’s because it’s not just another PC platform, but tries to redefine the role of the personal computer in the age of AI. Announced at Computex 2026, RTX Spark is Nvidia’s new platform for slim Windows laptops and compact desktops, designed to combine an Arm-based CPU, Blackwell-based RTX graphics, and a large, unified memory architecture into a single AI-first computing system.
We have all grown accustomed to a cloud-centric AI model over the past few years. We open an application, send a request over the network, and a hosted service in a distant data center provides the intelligence. ChatGPT, Grok, Gemini, and similar systems have trained the market to think of AI as something that lives elsewhere. RTX Spark proposes a different model. It asks a simple yet disruptive question: What if the model, the agent, the data, and the application could all live on your own machine? Nvidia is not just selling a faster PC. It is selling a new architectural premise.
Features, functions, and prices
On paper, RTX Spark is designed to be a highly capable local AI system. Nvidia has described the platform as combining AI acceleration and RTX graphics on a single chip for thin laptops and small desktops. Public specifications for the platform indicate configurations with up to 6,144 Blackwell GPU cores, up to a 20-core CPU, up to 1 petaflop of FP4 AI performance, and up to 128GB of unified memory. These are not ordinary PC numbers. They are clearly intended to support serious local AI workloads.
The unified memory approach is especially important. In traditional PC architecture, the CPU and GPU often use separate memory pools, which can become a bottleneck when running large models. By contrast, RTX Spark’s design is intended to make it easier for the system to host and run AI models locally. This enables Nvidia to position the machine as capable of hosting persistent AI agents, supporting local inference, and even allowing users to customize or fine-tune certain classes of language models.
Nvidia is also careful not to frame the system as only an AI box. In a smart move, the company is marketing RTX Spark for gaming, creative applications, AI development, and agentic workflows. This has been designed not as a one-trick pony, but as a capable computer first and an AI workstation second. Otherwise, it remains a niche developer experiment.
Pricing remains uncertain because Nvidia hasn’t published a universal price for every RTX Spark laptop or desktop. The platform will appear in products from different manufacturers, which means prices will vary. The best indicator comes from the related DGX Spark desktop, listed at about $4,699, though early estimates placed it between $2,999 and $3,999.
That probably gives us the right way to think about pricing for this broader category. These are unlikely to be inexpensive mainstream PCs, at least not at launch. They are more likely to arrive as premium systems aimed at developers, technical professionals, creators, and early adopters willing to pay for high-end AI capabilities on the device. Over time, that may broaden. For now, however, this looks like a new high-value, high-cost category rather than a commodity PC refresh.
What is its real purpose?
The most important thing about RTX Spark is not the chip. It is the purpose behind the chip. This machine is ultimately built to run AI agents locally, and that is a bigger deal than it may seem at first glance. An AI agent is more than a chatbot. It persists state, accesses tools, works across applications, remembers context, automates tasks, and increasingly acts as a software-based worker. Nvidia is explicitly positioning Spark systems to run personal AI agents directly on the local machine, potentially around the clock. That creates a very different computing model from what most of us use today.
There is another important layer to this story. These systems are also being positioned as platforms on which users can build and run smaller, more limited, locally tuned versions of large language model systems. Put plainly, you may be able to create your own model-based assistant that runs directly on the RTX Spark. It will not be as broadly capable as a frontier model operated by OpenAI or another hyperscaler. It is likely to be less generally capable, narrower in its expertise, and more constrained by local hardware limits. But it will be yours, it will be local, and it will respond without relying on a remote API call to a hosted AI service hundreds or thousands of miles away.
Such a shift is conceptually significant. For years, the AI industry has conditioned us to believe that serious intelligence must be centralized. RTX Spark suggests a future in which at least some intelligence becomes personal, portable, and self-contained.
Welcome to the revolution
The breakthrough here is not that local models will instantly outperform remote models. They will not. But the architecture of AI use may begin to diversify. Today, the default assumption is centralization. We assume the model, the knowledge base, and the application stack will all live in the cloud, and the user is simply a client. With systems like RTX Spark, that assumption starts to weaken. The model can run on the local machine. The agent can run on the local machine. Sensitive data can remain on the local machine. The application logic can be executed on the local machine. This changes latency, privacy, resiliency, and cost models. It also changes who controls the AI.
That does not mean the cloud goes away. Far from it. Enterprise use cases that benefit from centralized models and data will continue to exist. Businesses want the same knowledge base, business rules, database consistency, and governance model available to everyone. Centralization remains powerful because it reduces fragmentation and keeps systems aligned. Yes, a single-tenant, RTX Spark-based AI environment can be useful for certain projects, but it can also create islands of intelligence that do not easily share knowledge across teams and systems.
Possible use cases
I see the strongest potential use cases in disconnected or semi-disconnected environments. Think about physicians doing diagnostics support in privacy-sensitive contexts, field engineers collecting and interpreting data in remote areas, military and public sector users operating at the edge, or professionals who need highly private, self-contained AI assistance without relying on constant connectivity. In those scenarios, the value proposition is very strong. Having the model, data, application, and agent all on one portable system is not a limitation. It is the point.
The bigger question is whether mainstream enterprise AI will migrate in that direction. I remain skeptical that most organizations want hundreds or thousands of individually tuned, locally hosted models to replace centralized AI services. I predict that this category will complement the cloud rather than displace it. The more likely future is hybrid: centralized AI where shared knowledge and governance matter, and local AI where privacy, portability, latency, or disconnected operations matter more.
For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.
The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.
Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.
Failures at the operational level
Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.
This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.
The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.
Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.
That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.
This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.
Better change management
The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.
Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.
Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.
Design with outages in mind
What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.
Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.
The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.
For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.
The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.
Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.
Failures at the operational level
Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.
This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.
The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.
Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.
That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.
This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.
Better change management
The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.
Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.
Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.
Design with outages in mind
What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.
Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.
The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.
Australia should learn from the mistakes of the resources boom and set the terms for the AI and datacentres boom, the assistant minister for the digital economy, Andrew Charlton says.
Growth in datacentres has exploded in the past two years, Charlton told the Sydney Institute on Wednesday night, with 44 projects in the pipeline in New South Wales alone seeking 11GW of capacity on the electricity grid.
A new Chinese quantum computing system pairs two independent neutral-atom arrays in one processor, aiming to boost stability, efficiency and scalability.
The Netherlands blocked a U.S. company from buying a Dutch firm that handles its national ID system, saying it would create a “threat to the public interest.”
We’re seeing an interesting infrastructure tug of war today where GPU clouds are being pulled in two directions. For the economics of AI to work, the enterprise market needs to carve expensive hardware into smaller, shareable units and hand it to customers on demand, similar to how CPUs are doled in public cloud infrastructure. But the more the providers push GPUs to behave like elastic cloud infrastructure, the more they run into the reality that this GPU hardware was never built for safe multitenant use, fast fault recovery, or clean isolation between workloads. That tension is becoming one of the defining operational problems of the AI infrastructure market.
When a gamer launches Steam or the Epic Games Store on their laptop, they don’t have to worry about which GPU is being scheduled, how memory is going to be divided, or really any of the security boundaries or hardware assignment issues on their PC. For consumer PCs, these issues are not just hidden from view, they are irrelevant.
But for today’s IT teams managing GPU-driven AI workloads across distributed systems, those types of allocations and partitions need to be managed manually and carefully. This includes deciding which GPU to assign to each workload, how to divide memory, how to isolate tasks, and how to maximize utilization of this very expensive hardware. That’s why you heard so much about “Day 2” AI infrastructure themes around Nvidia’s GTC event this year.
The legacy hardware bottleneck
GPUs were originally developed to speed up graphic rendering and to perform local compute via shaders in service of graphical rendering. Their design assumes a trusted computing environment in which a single application controls the device. When a user runs an application on a GPU, it accelerates that particular workload.
But while GPUs are optimized for throughput, and therefore have thousands of simple cores designed to execute the same instruction over large datasets, this design paradigm creates several major technical limitations regarding context switching and memory isolation. GPUs were designed to produce pixels, not to run sensitive AI applications from multiple tenants using the same hardware.
As a result, GPU infrastructure today behaves less like elastic cloud infrastructure and more like carefully managed hardware appliances.
The partitioning paradox
Today’s AI infrastructure requires GPUs to behave like shared, elastic cloud resources. As inference workloads begin to outstrip large-scale training runs, the ability to slice and share expensive hardware among multiple tenants in real time while maintaining acceptable fault tolerance is no longer optional.
Hardware vendors have introduced new approaches to dividing GPUs into multiple isolated compute slices. Other frameworks approach partitioning through schedulers and container runtimes. But resource partitioning is just one slice of the overall GPU operations pie.
There is currently no widely adopted, cross-vendor operating model for achieving this safely at scale. Most providers are faced with either dedicating a single customer to a physical machine (thus wasting available capacity), or accepting the multi-tenancy security risks currently without a known solution. The current engineering challenge has moved from beneath the model layer and into the infrastructure layer. Success now relies on the ability to quickly launch new workloads and to rapidly contain hardware faults so that a single GPU failure does not bring down all workloads running on the server.
Untrusted code and tenants
The vast majority of current GPU programming models rely on the idea that the driver has complete control over memory protection and that no user will act maliciously. Unfortunately, that assumption completely falls apart in a cloud environment where one VM or container can leave behind data remnants in memory that another VM or container may access. Especially considering that how GPUs execute code is often completely opaque.
A single faulty workload or a single faulty driver failure in a shared GPU environment can also take down every workload (job) that was being run on the same server, increasing the amount of damage caused by an operational failure.
Currently, there are immature options for runtime inspection or behavioral auditing, limiting both visibility and control for security teams. GPU drivers provide a large attack surface and generally limited telemetry from the hardware. In these shared environments, embeddings, weights, prompts, and tokens are now all sensitive data points, creating significant blind spots for those attempting to protect intellectual property.
The high cost of cold starts
The real constraint in many GPU clouds is not model performance but operational efficiency. Right now GPU operations looks like 30 minute tenant spin-up times, 70% idle rates, and engineers continuously debugging infrastructure stacks. Today’s GPU clouds are stalled not due to inferior models, but because the infrastructure layer underpinning these clouds was never designed to support such a high degree of scale.
A 30 minute cold start is a fundamental limitation on the modern AI business model. Those GPU clouds that can spin up workloads in seconds will ultimately win against those that do not. Multitenancy is the only viable means of producing sufficient unit economics to make this very expensive hardware viable for the long term.
Bridging the orchestration gap
Platform teams are beginning to recognize that GPUs require a specialized operating layer between the hardware and workloads. Operators need a unified operating model that supports multiple hardware vendors and GPU models. Cloud providers need a method to safely slice and share servers among tenants, and to prevent cascading failures, while rapidly launching new workloads.
Enterprises are increasingly seeking to run sensitive AI applications with stronger isolation guarantees, and thus are turning to newer categories of software designed specifically to manage the “dirty work” of hardware orchestration.
The race to make GPUs more operational
Prior to Kubernetes standardizing container orchestration, the industry was constantly debating the efficiency of container scheduling and bin packing across clusters. Those operational concerns were eventually automated and incorporated into infrastructure layers that made the complexities invisible to the end user.
A similar evolution is occurring around GPUs today. While platform teams continue to argue over placement strategies and memory tuning, these decisions will likely be automated within five to 10 years. As AI infrastructure evolves, the most valuable layer may not be the GPUs themselves but the operating layers that make them secure, elastic, and efficiently sharable. So the winners in the AI race won’t necessarily be just those with the most silicon, but those who have the best operating models for making that silicon secure and elastic.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
Enterprises are moving aggressively into generative AI. On the surface, that seems like the right call. The technology is powerful, accessible, and increasingly embedded in how businesses build applications, automate processes, and support decision-making. A development team can connect an application to a large language model in days. A product team can add AI features in weeks. Business leaders see quick wins, faster innovation, and a path to modernizing nearly every part of the company.
These are the upsides everyone is talking about. The part we don’t discuss enough is the economic trap forming underneath all this convenience.
Most enterprises think of tokens as a technical billing detail. They are not. Tokens are the unit of economic dependency in generative AI. Every prompt, response, summarization, retrieval step, workflow action, and agent decision is measured and monetized through tokens. Tokens are not just part of the plumbing. They are the tollbooth between your enterprise and a provider’s intelligence platform. The more AI becomes central to your operations, the more power that tollbooth holds over your future costs.
Tokens are not just a pricing unit
A token is usually described as a chunk of text processed by a model. That is accurate enough for developers, but it misses the bigger issue for CIOs, architects, and corporate boards. In the enterprise, tokens are the mechanism by which AI capabilities are rented. They are the meter attached to the intelligence itself.
That distinction matters because token usage grows faster than most companies anticipate. A simple user prompt rarely remains simple in production systems. It can trigger retrieval from internal knowledge stores, multiple model calls, tool use, post-processing, policy checks, and agent loops. What appears to be a single transaction to the user may involve several layers of token consumption behind the scenes. As a result, enterprises often underestimate the true operating cost of AI-enabled systems, especially as those systems mature and spread across departments.
Today, those costs still feel manageable. In many cases, they feel surprisingly low. That is exactly why the trap is so dangerous.
The market is in a subsidy phase
Current token pricing is giving enterprises a false sense of comfort. Many remote LLM providers are aggressively competing for market share. They want developers building on their APIs. They want enterprise applications tightly coupled to their platforms. They want AI agents, copilots, workflows, and customer experiences to depend on their models. To make that happen, pricing remains highly attractive relative to the value delivered.
That does not mean the economics of generative AI are stable. It means the market is still being shaped by investor capital, strategic pricing, and growth expectations. Providers are racing to establish position, and enterprises are benefiting from that race. But no market stays in that phase forever. At some point, investors will expect durable profitability. At some point, weaker providers will disappear, consolidate, or retreat. At some point, the survivors will have more leverage and much less reason to price primarily for adoption.
That’s when the token trap closes.
Enterprises that build deep dependence on remote models during the subsidy phase may find that what seemed inexpensive at pilot scale becomes punishing at enterprise scale. The application that costs $1,000 per month today may cost 10 or 20 times that amount a few years from now, not only because usage has increased, but also because the market has repriced the dependency.
Easy to adopt, expensive to exit
Cloud computing followed a similar path, with many enterprises mistaking short-term convenience for long-term economics. In the early years, the case was compelling and largely accurate. Move faster, reduce friction, avoid capital spending, and scale with ease. Those benefits were real. Many organizations made architectural decisions that prioritized speed over leverage. They became dependent on managed services, provider-specific tools, and operating models that were easy to adopt but expensive to unwind.
Years later, many enterprises discovered that their cloud bills were much higher than expected and their exit options much narrower than advertised. That was not because the cloud failed. Architectural dependency eventually became financial dependency.
Generative AI is repeating that pattern, only faster. The integration barrier is lower, the pressure to adopt is higher, and the pace of enterprise experimentation is far greater. As a result, companies are wiring remote LLMs into applications, workflows, and agentic systems with very little thought about how these costs will behave in the next five to 10 years.
Agentic AI makes things worse
The more enterprises move from simple prompt-response systems to agentic architectures, the more dangerous the token trap becomes. Agents are not single-call systems. They plan, deliberate, retrieve information, invoke tools, evaluate results, retry steps, and often coordinate with other agents. Each of those actions consumes tokens. Costs no longer rise in a neat linear fashion. They compound.
This matters because agentic AI is increasingly being presented as the future of enterprise automation. It’s true in many cases. But if an enterprise builds agentic systems primarily on remotely hosted intelligence, it is also building future business processes on top of someone else’s pricing model. That is a major strategic risk. The more successful those systems become, the harder they are to replace. The harder they are to replace, the more pricing power shifts to the provider.
This is how businesses end up operationally dependent on a cost structure they do not control.
The appeal of AI sovereignty
The answer is not to reject public models or pretend that external providers play no role. They clearly do. There will always be cases where renting frontier AI capabilities makes sense. But enterprises need to stop assuming that renting is the default for every workload.
AI sovereignty is the alternative that deserves much more attention. That means building, tuning, deploying, and governing models inside the enterprise for use cases where long-term control matters more than access to the absolute frontier. Enterprises need to recognize that most business applications do not need a world-class general-purpose model. They need a model that is good enough for a specific purpose, aligned to the enterprise’s data, governed by the enterprise’s rules, and operated at a predictable cost.
It’s a very different way of thinking.
A self-hosted or enterprise-controlled model may not match the rich feature set of the largest public offerings. It may lack the same breadth, polish, or marketing appeal. But for many internal business tasks, those factors do not matter.
Here’s the most critical question to guide your architectural direction: Can a sovereign AI model solve the problem reliably, securely, and economically over time? If the answer is yes, owning that capability may be far more strategic than forever renting something with more power than you need. In effect, the enterprise becomes its own provider for the workloads that matter most.
Prepare for changing markets
Too many companies still treat generative AI architecture as a tactical IT issue. It is not. These decisions directly affect cost structure, operating flexibility, data control, and long-term competitiveness. If AI becomes a force multiplier across the business, the economics of AI become strategic to the business itself.
The companies that get this right will not necessarily be the fastest adopters. They will understand the difference between experimentation and dependency. They will use external models when it makes sense, but they will also invest in sovereign capabilities where ownership matters. They will think like architects, not consumers.
Here’s the takeaway: Cheap tokens come with strings. They are a gateway to a dependency model that will typically look very different once providers stop pricing for growth and start pricing for leverage. Enterprises cannot keep mistaking today’s bargain for tomorrow’s reality. Boards and executive teams need to act now to get ahead of this issue. The key question is not whether generative AI creates value. It clearly does. The real question is whether the enterprise can still afford and control the value it creates once the market matures.
Datacentre off Shanghai coast uses less power and water than land-based equivalent
The world’s first wind-powered underwater datacentre has started operations off the coast of Shanghai, as China presses forwards with solutions for energy challenges created by the country’s artificial intelligence boom.
The Shanghai Lingang undersea datacentre demonstration project, which launched in May, has a capacity of 24 megawatts. It is a joint effort between HiCloud Technology and China Communications Construction, a state-owned company.
The European Commission published its tech sovereignty package last week, including the clearest signal yet of its intention to strengthen European cloud sovereignty and reduce its dependence on US hyperscalers.
But any shift toward local, sovereign cloud providers will necessarily be gradual, analysts, said as the Cloud and AI Development Act (CADA) proposals leave plenty of room for US providers to continue supplying cloud computing services to European public sector customers.
“The direction is right. The execution will be slow,” said Fernando Pereiro, senior director analyst at Gartner.
While the Commission has correctly identified areas where the EU is most dependent on foreign providers, delivering on its ambitions is another challenge, he said. Scaling alternatives to US suppliers “takes time, capital, and coordination at a level that is difficult to sustain in Europe.”
Dario Maisto, senior analyst at Forrester, played down the prospect of a major short-term shift towards European cloud providers as a result of the CADA proposals, even after recent interest in local European vendors for mission-critical workloads and highly sensitive data.
“I do not expect an immediate impact on the cloud infrastructure market,” Maisto said. “Full-blown migrations are costly and take several years. They are not going to happen in the near future.”
Instead, Pereiro expects the gradual emergence of “sovereign enclaves” or controlled environments for sensitive workloads, particularly in government and regulated sectors. “Outside of those areas, the market will remain global, but increasingly shaped by European rules,” he said.
Nevertheless, the three US hyperscalers that account for around 70% of the European cloud market – Amazon Web Services (AWS), Google, and Microsoft — will likely see a more competitive environment.
“The real shift is symbolic and structural: hyperscalers move from being the default choice to one option among others, and their competitiveness will increasingly depend on how well they align with European control requirements, not just on technology or price,” said Pereiro.
What is CADA and what could it mean for Europe’s cloud market?
CADA is part of a range of policy and legislative proposals — known as the Tech Sovereignty Package — published by the Commission, alongside Chips Act 2.0, the Open Source Strategy, and Strategic Roadmap for Digitalization and AI in Energy.
CADA includes measures to boost European tech sovereignty. Among other things, it aims to triple data center capacity in the next five to seven years by easing restrictions on new infrastructure projects across the EU, as well as efforts to support research and development of cloud and AI technologies.
It also includes a sovereignty framework that, if enacted, would require EU public bodies to assess sovereignty risks and procure cloud services that meet four assurance levels.
The various levels portray “a political vision with many open questions,” said Maisto. In more detail:
Level 1 requirements are achievable by hyperscalers, Maisto said, with requirements focused mostly on data residency.
Level 2 is “more controversial,” he said, as it includes requirements around third-country access to data and disruption of services.
Level 3 leaves room for US providers to win procurement contracts — particularly where they enter a joint venture with a European cloud provider such as S3NS, a Thales subsidiary that has partnered with Google.
Level 4 applies to only a small proportion (1%) of the most sensitive workloads.
The first two levels could be open to US hyperscalers, said Maisto, with 70% of existing EU public sector workloads falling under Level 1 and 20% at Level 2, according to Commission’s own impact assessment. Just 9% of the workloads would require Level 3.
The most stringent Level 4 would require cloud providers that “have full transparency and control over their software supply chain and no interference from a third country,” the Commission said.
For public sector organizations, the CADA rules could create more clarity around procurement, said Pereiro. “Today, the concept of ‘sovereign cloud’ is often vague and inconsistently applied in providers’ marketing and messaging,” he said. “This package standardizes what sovereignty must look like in practice, effectively ending the era of ‘sovereign washing.’”
The proposals give public sector organizations a “stronger set of requirements with which to assess risk, especially around jurisdiction and access to data,” he said.
“For enterprises, it’s less about regulation and more about leverage,” said Pereiro. “They gain clearer benchmarks and more viable alternatives, particularly through open source and emerging European providers.”
European cloud industry sees ‘a step in the right direction’
The Cloud Infrastructure Services Providers in Europe (CISPE) — a nonprofit trade group — welcomed the “strong definitions” of Levels 3 and 4, and said that, if implemented well, the proposed rules could “help to challenge the commercial dominance of established foreign cloud and AI vendors.”
However CISPE also called the current Level 1 and 2 criteria “confusing and non-sensical,” and said they should not be designated as “sovereign” since US hyperscalers can meet the requirements. “This will continue to confuse the market, both public and private customers, and encourage more sovereignty washing attempts,” CISPE said in a blog post Thursday.
CISPE also said the proposals fail to require public authorities to check whether a European service exists before opting for a foreign supplier. “We see a significant risk that assessments become a ‘rubber-stamp’ exercise that allow IT departments to continue to buy non-sovereign services out of convenience,” the organization said.
French firm OVHcloud — one of the leading European cloud computing and web hosting companies — welcomed the proposals, though it said any rules must be carefully scoped to ensure they are effective.
“This text is a step in the right direction and represents an opportunity to strengthen European strategic autonomy — something unthinkable just a few years ago,” an OVHcloud spokesperson said. “It provides a useful framework, but one that must not leave too much room for exceptions and workarounds.
“Europe must and can move much faster, with very clear rules and a genuine European preference. Beyond this text, the Commission has demonstrated with its sovereign procurement call that it is possible to act right now to reduce critical dependencies. The time for waiting is over. We must accelerate. We must clarify. We must own it.
“Europe has the players and the expertise,” the spokesperson said. “It is time to turn political ambition into European industrial capability.”
The overall tech sovereignty package “marks the overdue shift from diagnosis to treatment,” said a spokesperson at Ionos, a German cloud and hosting company. Ionos pointed to the EC’s claims that more than 80% of digital products, services and infrastructures in the EU originate from non-European providers, while 264 billion euros flow from EU organizations into predominantly US-based IT products.
“This is a strategic failure that must now be corrected,” the spokesperson said. While the company applauded the Commission’s focus on “secure and sovereign cloud and AI infrastructure for highly critical use cases,” it argued the CADA proposals fall short. “The central weakness of the package: the approach remains predominantly supply-side. The decisive lever — the demand side – is missing. Public procurement is the most powerful instrument for digital sovereignty. The public sector as anchor customer is critical for scaling sovereign cloud and AI solutions.
“Europe will remain dependent on Nvidia and AMD for GPU computing, the spokesperson said. “What matters is not whether to cooperate, but on what terms: data under European law, operations by European providers, no extraterritorial access. …If EU funding earmarked for ‘sovereign cloud’ ends up with the European subsidiaries of US hyperscalers, the package will have failed its objective.”
The real impact on hyperscalers
The proposed rules could require hyperscalers to change tactics to cater to European customers, or to at least ramp up existing sovereign cloud strategies. “For vendors, this is essentially a shift in what ‘competitive’ means,” said Pereiro. “For the last decade, scale and hyperscaler alignment were enough. That’s no longer the case.”
Cloud providers will need to demonstrate real control over data, infrastructure, and operations, he said, and not just label solutions as “sovereign.”
“The bar has been raised, and some existing offerings simply won’t clear it,” he said.
While the CADA rules are designed to favor European providers in some cases, the proposals stop short of barring US providers from public sector contracts. “It doesn’t shut them out,” said Pereiro, “but it changes competitive conditions substantially.”
The proposed procurement requirements make sovereignty a “gating factor” for sensitive workloads, said Pereiro, and “create real friction for providers whose operating models depend on centralized control or non-EU jurisdiction.”
US tech firms tout support
US hyperscalers publicly welcomed the proposals, and indicated plans to work with policy makers and ensure the importance of customer choice in cloud service procurement.
“We look forward to reviewing the proposed rules and continuing to work alongside our partners to ensure European organizations have the power of choice and sovereign control,” a Google spokesperson said.
An AWS spokesperson said the company has invested ”tens of billions of euros” in European cloud infrastructure, which it claims has “already advanced the continent’s competitiveness, helped organizations innovate and grow, and supported the development and resilience of both public and private services that Europeans now rely on every day.
“European organizations deserve access to the best technology available from trusted providers, chosen on the basis of security, performance, verifiable controls, and value,” the AWS spokesperson said. “We look forward to working with policymakers to ensure the Cloud and AI Development Act promotes technology choice and rewards long-term investment in Europe’s digital future.”
A Microsoft spokesperson said the company shares the EU’s “ambition to strengthen technological sovereignty and global competitiveness in AI, grounded in openness, partnership and fair competition.
“Achieving this will depend on access to world-class infrastructure and technologies at scale,” the Microsoft spokesperson said. “That means enabling European companies and public administrations to make procurement choices based on a broad, risk-based assessment in an open and competitive market.
“Microsoft offers secure and sovereign cloud solutions that put customers in control, and we stand ready to help build a strong, resilient and globally connected AI ecosystem in Europe.”
While the proposals present potential hurdles for US hyperscalers, those that adapt to the new regulatory direction — and concerns of European organizations — will benefit, said Pereiro. “If your offering aligns with sovereignty requirements, your company will be likely to see more opportunities, not fewer,” he said.
Login
