Sovereignty Starts with the Hardware: Paul Speciale and Patricia Hillebrand on Building AI Infrastructure Europeans Can Actually Control
Q1 The partnership between Pyramid Computer and Scality sits at the intersection of two trends that are increasingly in tension: the urgency to deploy AI infrastructure quickly, and the growing organizational and regulatory pressure to maintain control over where data lives, how it is processed, and who can access it. For a CIO or infrastructure architect at a European enterprise or public sector organization who is evaluating this right now, what is the practical difference between deploying AI infrastructure on a hyperscale cloud and deploying a co-engineered stack like this one, not in marketing terms, but in terms of what they can actually control, audit, and guarantee about their data?
Patricia: Simply put, in the cloud, you control your workload only. With a local AI stack, you control the entire execution environment—from the hardware and network to the operating system and the AI application itself. Besides time to deploy and regulatory requirements or even regulatory pressure, there are two very important questions to consider: who can access my most valuable asset (= data), and can someone outside of my organization and control decide to pull the plug at any time. It’s true that a local deployment requires a solid hardware stack that’s ideally optimised for the software running on it.
Yes, that’s an investment and on top you need admins to deploy, run and maintain it.
At first glance intelligent pricing schemes from hyperscalers make operating a local AI stack look even more expensive than it actually is but because hidden costs like egress fees often dilute budgets and cause a lot of trouble. Sovereignty starts at the hardware level and when you own the stack your data stays within your firewall – that’s actually worth more than money can buy. Owning the IT stack gives you freedom, not isolation. It lets you keep critical workloads and sensitive data under your control while seamlessly integrating with the cloud provider of your choice. You can audit hardware, software, network traffic, access logs, and physical access according to your own policies.
When regulations change you’re not dependent on the hyperscaler’s implementation and compliance roadmap but implement the necessary changes according to your own roadmap.
Last but not least it’s not only about reducing dependencies from market dominating hyperscalers – it’s also about supporting all the local heroes around the corner: be it a local data centre operator offering colocation services, your local CSP or MSP.
Paul: Cloud gives you enormous power, but power and control are not the same thing. In a hyperscale environment, you are consuming infrastructure through a set of abstractions: compute instances, managed storage, networking, APIs and increasingly managed AI services. The result is immense capability. However, it also means that parts of the underlying infrastructure and software stack remain outside your direct control.
With a co-engineered stack, you can define that boundary much more precisely. You know which hardware is running the workload, where the storage is physically located, how the network is configured, which software components are involved and ultimately who has administrative access.
From a technical governance perspective, that gives you a much clearer chain of custody for the data. There is also a practical performance dimension. If your AI workload repeatedly moves large datasets between compute, storage and external services, you are not just introducing cost, but also network dependencies, latency as well as additional points of failure. Keeping compute and data together can remove a significant amount of that movement. I would like to add one important qualification to Patricia’s point: sovereignty isn’t something you establish with a single checkbox. You have to trace the complete dependency chain.
Where are the datasets? Where are the encryption keys? Who can access the management plane? Which telemetry leaves the environment? What happens if an external API or service changes? Those are architectural questions. So for me, the real benefit of this approach is that it gives the customer a clearly defined infrastructure boundary that they can inspect, operate and evolve themselves.
Q2 Patricia, you have spent over 25 years in the IT and service provider industry, and Pyramid Computer has been building compute infrastructure in Germany for over 40 years. That is a very different lineage from most of the companies currently selling AI infrastructure solutions, which are relatively young and primarily software-defined. What does 40 years of hardware manufacturing expertise actually contribute to the design of AI and object storage infrastructure that a software-first approach tends to miss, and where have you seen the most significant real-world performance or reliability differences emerge between purpose-built European hardware and commodity platforms assembled from global supply chains?
Patricia: Let me again begin with a highly simplified statement: Software is sexy, hardware isn’t. It’s much more fun to talk about fancy software features and all the customer pain points it can address and resolve rather than talking about mainboards, CPUs or HDD vs all-flash. But the reality is that software defines functionalities whereas hardware defines the performance, efficiency, reliability, and trustworthiness of these functionalities.
For example, an LLM will run on many different server platforms. But the GPU architecture determines inference speed. Memory capacity determines model size, storage bandwidth affects how quickly models load and network latency influences distributed training and inference. Same for software-defined object storage: The underlying hardware determines IOPS and throughput, energy consumption, density, rebuild times after disk failures and last but not least the overall cost per TB stored. In both scenarios the software is the same but the hardware stack is the decisive factor whether the user experience will be great or poor.
Q3 The joint solution targets broadcasting and media, healthcare imaging, autonomous systems development, and large-scale AI training environments: four verticals with genuinely different data characteristics, latency requirements, access patterns, and regulatory contexts. Rather than talking about all four, can each of you walk us through the vertical where you believe the combination of Pyramid’s compute and Scality’s object storage creates the most distinctive and defensible advantage, and explain specifically what the customer’s alternative would look like and why it is inferior for that particular workload?
Patricia: My favourite vertical from your list is healthcare. Not only because I’ve been working as a paramedic for over 15 years on a voluntary basis. It’s because I do believe that especially the healthcare sector deserves the following elements that are rarely delivered together:
- Application-optimised hardware Made in Europe
- A modern software-defined object storage with a native S3 API
- Local AI readiness
Think about a workload like AI-assisted radiology: customers usually choose GPU servers from hyperscalers or OEM commodity servers. As a result, patient images often leave the hospital network, compliance reviews become complex and inference costs grow over time. Instead, they could benefit from predictable local performance, simple and cost-effective S3 scalability, complete control over sensitive patient data, and optimized hardware for imaging workloads.
Another good example are electronic archives for health records and research results – the healthcare industry still relies on hyperscalers or traditional SAN/NAS environments.
Those storage environments have never been designed to archive a steadily growing amount of unstructured data with version control, a compelling search functionality, cost control, sufficient security layers for today’s cyberthreats and durability, just to name a few.
A great alternative is to have a modern object storage appliance on-prem providing the option to connect to AI and write archival data straight from S3 to tape or a glacier type storage class offered by a local and trusted cloud service provider. That’s the future-proof end-to-end solution stack Scality and Pyramid can bring to the table for the healthcare vertical, with simplicity-as-a-service in mind.
Paul: AI can move fast. Healthcare data often can’t. Take an AI-assisted imaging workflow. You might have the imaging system generating the original studies, an archive storing them, a PACS managing clinical access, and then a separate AI environment consuming the data. If those systems are architected independently, you can end up with several copies of the same study and multiple interfaces moving very large datasets around. That becomes particularly inefficient when AI workloads grow more sophisticated.
You may want one model for detection, another for segmentation, another for research, and potentially retrieval-augmented or multimodal applications around the same underlying dataset. Creating another copy of the data every time you introduce a new workload doesn’t scale particularly well. An S3-based object storage layer gives us a different architectural model. The data can remain in a highly scalable repository while different applications consume it through a consistent interface.
Markus Müller, Head of Data Center Management at our customer University Hospital Basel, pointed out: “We needed a solution to securely archive big data of all types yet make it universally accessible.”Compute can be positioned close to data, including GPU infrastructure for inference or training. The technical advantage is therefore not simply that we have storage plus servers. It is that we can create a common data plane for multiple workloads. You reduce unnecessary replication, simplify data access and make the archive itself useful to AI. For a healthcare organisation, that can overall translate into a much more sustainable architecture: retain the data once, protect it properly, and make it available to whichever authorised workload needs it without repeatedly redesigning the infrastructure around every new application.
Q4 Paul, Scality has been making a consistent argument across multiple partnerships and product launches that the old storage model is broken for AI workloads, and that tiered architectures built around predictable hot-warm-cold data lifecycle assumptions cannot handle the concurrent demands of training, inference, RAG, and agentic workflows. Patricia, Pyramid Computer builds purpose-built, high-density compute platforms. How does this partnership change what a customer can actually do at the edge specifically, and what AI or data-intensive workload use cases become possible at the edge with a co-engineered stack that were simply not practical before, either because of latency, cost, or the complexity of managing disaggregated systems?
Paul: The edge is moving from inference to intelligence. It’s where you decide what data matters. That distinction is of key importance. The old storage model is broken for AI workloads because it assumes predictable hot-warm-cold data patterns that don’t reflect how AI data is actually created and consumed. An edge AI system might generate huge amounts of raw video, sensor or telemetry data, but you don’t necessarily want to transmit all of it to a central environment. The useful architecture is to ingest the data locally, run inference close to where it is generated, identify the events or datasets that have value, and then decide what should be retained locally and what should be sent upstream. That requires three things to work together: sufficient local compute, storage that can absorb the data at the required rate, and software that can manage that data consistently.
That’s where the combination with Pyramid becomes interesting from a technical perspective. For example, an autonomous system could generate continuous sensor data while the local GPU infrastructure performs inference. The object storage layer can retain selected datasets, intermediate results or training material. Those datasets can then be transferred upstream when bandwidth is available or when they have sufficient value to justify the transfer.
The key point is that we’re not suggesting every workload should move to the edge. We’re giving the architect another option in deciding where compute and data should live. And that becomes increasingly important as AI models grow larger and datasets expand. If every edge device has to continuously stream raw data into a central cloud before anything useful can happen, the network becomes part of the application’s critical path. Processing locally removes that dependency and lets you make the data-movement decision based on the value of the data rather than the limitations of the architecture.
Patricia: Let me repeat that software defines what is possible whereas hardware determines how well it performs. That said, the era of one-size-fits-all infrastructure is over because great software shouldn’t have to adapt to generic hardware. It’s the other way round: the hardware should adapt to the software. A cornerstone of our partnership is a close and very transparent collaboration, not only on the engineering side. Together we can design infrastructure that isn’t just built from the fastest and best-in-class components. Jointly, we are selecting and testing the components that are balanced and optimised to work together for a particular use case. That’s important because an expensive GPU waiting for data from slow storage is a waste of money. Same for ultra-fast storage without enough GPU power.
We want to take the burden away from customers to search for specialized hardware among all the commodity offerings and often misleading marketing promises, and then install the software on their own without guarantee that the expected results are met. Instead, we strive for optimized and tested turnkey solutions combining Scality’s software functionalities with the optimal underlying hardware stack for the customer’s use case. Ideally as a plug & play appliance that brings enterprise grade performance and functionality to small and medium-sized businesses without the need to have an army of highly skilled IT experts and admins onsite. The same applies for large deployments in hybrid storage or AI environments where we can offer our jointly developed standard stack, or add more flexibility by building to order.
Q5 Data sovereignty is the explicit strategic rationale behind this partnership, and both companies are positioning it as a deliberate alternative to dependence on non-European hyperscale providers. But sovereignty is a spectrum, not a binary. A customer can have sovereign hardware and still use non-sovereign software, non-sovereign APIs, or non-sovereign AI models. For an organization that is genuinely serious about building a sovereign data architecture — not just checking a compliance box — what does the full stack actually need to look like, and where does the Pyramid-Scality partnership fit within that larger picture versus where customers still have sovereignty gaps to close on their own?
Patricia: First and foremost the tag ‘Made in Europe’ is not just marketing fluff for us but something we’re taking quite seriously. The Scality-Pyramid partnership is truly European as we are designing, building and testing our hardware platforms and appliances in Germany, and the code is written in France. However, I agree with you that sovereignty is a spectrum and goes beyond on-prem deployments. Having a truly sovereign IT stack means you can decide, verify, and enforce what happens to your data, infrastructure, software, and operations without being dependent on a single external provider or vendor, foreign jurisdiction, or opaque technology.
A sovereign IT stack comprises multiple different layers: on top of the hardware there’s firmware & BIOS, storage, an OS, virtualization, databases, backup and other applications, AI, identity and security as well as all the tasks that fall under governance and operations. The strongest sovereign architectures therefore combine trusted hardware, software-defined infrastructure, open interfaces such as S3, local AI capabilities, and hybrid cloud connectivity from European vendors that are under EU jurisdiction without any compromise. The latter is something the Scality-Pyramid partnership can provide. Yes, it doesn’t tick all the different layers above but quite a significant number.
Paul: The hard part of sovereignty is knowing what’s underneath the stack. You need to be able to identify every component between the physical infrastructure and the application and ask who controls it, where it is operated, what jurisdiction applies and what happens if that component or provider becomes unavailable. At the infrastructure layer, that means the servers, firmware, storage and networking. Then you move up through the operating system, virtualisation or container platform, storage software, orchestration, identity, monitoring, backup and last not least security. Above that you have the applications, AI frameworks, models, APIs and potentially external services. The interesting technical challenge is that modern AI stacks can introduce a very large number of dependencies.
A model may be locally deployed, for example, but the application around it could still depend on an external API, cloud-hosted telemetry, a proprietary management service or externally controlled model repository. As Andreas Knols, Head of Cloud at our customer Enthus, aptly puts it, “Scality ARTESCA is like a foundation. You never point at a building and say it has a beautiful foundation, but it’s the backbone that makes everything work.” So I agree completely that sovereign infrastructure does not automatically produce sovereign AI. What the Pyramid-Scality solution offers is control over a significant part of the physical and data infrastructure layer. The S3 interface is particularly important here because it provides customers with a well-established, open access model for their data, rather than tying it to a proprietary storage interface. From there, customers can make deliberate decisions about the remaining layers. They can choose where their AI models run, where identity is managed, where keys are held and which external services they are prepared to depend on. Technically, I think that’s the right way to approach sovereignty: not as a claim that everything must be disconnected from the outside world, but as the ability to identify and control your dependencies and to have an alternative when a particular dependency becomes unacceptable.
Q6 Both Pyramid Computer and Scality are European companies operating in a market that is largely shaped by the economics, technology standards, and go-to-market playbooks of American hyperscalers and Asian hardware manufacturers. That is a genuinely difficult competitive position. The customers you are targeting have existing relationships, existing contracts, and existing muscle memory built around AWS, Azure, Dell, and HPE. What is the honest version of the conversation you have with a customer who is evaluating this partnership seriously but is asking why they should accept the switching costs and integration risk of moving away from established vendors, and what does it actually take to win that conversation beyond the sovereignty narrative?
Patricia: What actually helps is a combination of customers who are looking for a trusted advisor helping to solve a problem on one hand, and the shift of hardware that has to become more specialised on the other hand. We strive for a true partnership rather than a traditional vendor-customer relationship and we do listen to what our customers have to say because the use cases are more important than anything else. Additional differentiators besides the sovereignty narrative are customization, speed, and the ease to do business with us.
For example, we don’t have any prerequisites like costly training sessions or certification requirements for companies who want to enter a channel or technology partnership with us.
Or, if the CPU of choice is not available or highly overpriced, we’re proactively reaching out to our customers, offering an alternative. Finally, good old fairplay is becoming important again because the current supply chain issues are causing a headache within the entire IT industry. But alongside those challenges and soaring prices for certain components, customers appreciate that we’re sticking to a fair pricing policy and still send order acknowledgements.
Paul: AI doesn’t necessarily demand new infrastructure. It just exposes the limits of the old. But in many cases, the customer doesn’t need to replace existing infrastructure at all.
The more interesting question is where the existing architecture starts to become inefficient for a new class of workloads. AI is a good example. Traditional infrastructure was often designed around relatively predictable application workloads, with storage and compute separated according to established enterprise patterns. AI changes the traffic profile. You can have very large datasets, high-throughput sequential access, GPU clusters that need to be continuously fed with data, multiple simultaneous consumers and data that needs to be retained for future training. That can expose bottlenecks that weren’t particularly visible in conventional workloads. So technically, we would start by looking at the workload rather than asking the customer to choose a vendor.
Where is the data? How much of it is moving? How often is it being copied? What is the storage throughput requirement? How much GPU utilisation are you actually achieving? What does the failure domain look like? What are the recovery requirements? And what does the infrastructure cost look like over three to five years?
Those measurements give us a much more objective conversation. There is also a significant integration advantage in having the hardware and storage software engineered and validated together. The customer isn’t responsible for determining whether a particular server configuration, drive topology, network design and software configuration will behave as expected under its workload. We can do that engineering work beforehand. So I don’t think the proposition is “replace your incumbent because we’re European.” It’s much more specific: identify the workloads where the existing architecture creates unnecessary data movement, complexity or cost, and build an infrastructure platform that is optimised for those workloads. If we can demonstrate better utilisation, predictable performance, simpler data management and a more controllable infrastructure boundary, then the switching decision becomes a technical and economic one rather than a geographical one.
……………………………………………………………
Patricia Hillebrand, Business Development Manager, Pyramid Computer.
Patricia Hillebrand doesn’t just work in tech; she lives and breathes it. With over 25 years of battle-tested experience in the IT and service provider industry, Patricia‘s mission is clear: rip down the barriers blocking businesses from embracing innovation.
Paul Speciale, CMO Scality
Over 20 years of experience in Technology Marketing & Product Management. Key member of team at four high-profile startup companies and two fortune 500 companies.
Sponsored by Scality