Sovereign compute at scale: architecting for the Belgian AI Factory Antenna
By Pierre Hockers
With the inauguration of the Belgian AI Factory Antenna (BE-AIFA) in mid-2026, the European High-Performance Computing (EuroHPC) landscape has established a localized access framework for high-capacity workflows. For chief technology officers, research coordinators, and data architecture leaders, this specialized antenna serves as a direct pipeline to massive computational reserves.
Navigating this emerging infrastructure, however, requires a precise understanding of its technical architecture, processing queues, resource access rules, and the systemic trade-offs between remote data silos and sovereign compute power.
For technology leaders, this opens a pathway to de-risk heavy R&D exploration without the capital expenditure of purchasing large-scale GPU clusters. By routing through BE-AIFA, engineering teams can stress-test deep models in sovereign European environments that guarantee regulatory alignment from day one.
What Is an AI Factory (and What Is It Not)?
EuroHPC AI Factories are designed to provide tailored supercomputing capacity and expert support to European industry, scientific institutes, and public entities. Their objective is to accelerate the development of large-scale AI models, drive the adoption of regional AI technologies, and build localized technological sovereignty.
1. Eligibility: Specific to SME, Startup, and Public Segments
While promoted as an engine for "European industry," direct access is strictly bounded by company profile and scale:
- The Eligible Base: Startups, Small and Medium Enterprises (SMEs), research institutes, and public administrations. Large corporate entities are excluded from obtaining direct, subsidized compute allocations for proprietary commercial projects.
- The Bridge: Large enterprises cannot directly benefit from these systems. The exception is a grey area: large companies could purchase or license a finished, proprietary software product (IP) developed by an eligible SME that utilized the AI Factory.
2. Technical Focus: Computational Training, Not Live Inference Hosting
A misconception is viewing EuroHPC clusters as a sovereign alternative to commercial cloud application hosting (such as AWS, GCP, or Azure).
The Reality: These facilities are engineered strictly for high-throughput model training (massive backpropagation passes, pre-training, and heavy parameter optimization). They are not designed to serve low-latency, high-availability, high-volume production inference pipelines for live, customer-facing applications.
While minor exploratory inference environments exist (such as JUPITER’s Jarvis cloud preview or LUMI's lightweight inference tester), physical supercomputing nodes are non-interactive batch-processing architectures. Your engineering team trains the model inside the AI Factory, exports the weights, and then hosts them on your dedicated production infrastructure for live client interaction. This setup delivers massive training throughput, but application teams must plan for separate inference hosting from the outset.
Mapping the Architecture: BE-AIFA as the Access Layer
A foundational distinction must be drawn between the centralized EuroHPC AI Factories and the regional Antennas. Practically structured:
The Regional Antenna = The AI Factory − The Physical Compute
BE-AIFA acts strictly as the ingestion, routing, and expert advisory layer. It does not house the underlying physical compute clusters on-site; rather, it serves as regional support. Its mandate is to model customer AI journeys, provide compliance and trustworthy AI counseling, and facilitate access configurations to EuroHPC clusters.
This structural separation allows teams to rely on a local technical interface for onboarding and compliance. Senior engineers avoid the friction of navigating EuroHPC administrative frameworks directly, keeping their focus entirely on core model craft.
Performance Tracks and Response SLAs
To accommodate varying model exploration lifecycles, the Antenna operates three access pipelines designed with distinct processing SLAs:
| Access Pipeline | Processing SLA |
|---|---|
| Playground | 2 Working Days |
| Fast Lane | 4 Working Days |
| Large Scale | 10 Days (SLA) |
The Compute Engines: LUMI 2, JUPITER, and Beyond
While LUMI 2 and JUPITER are highlighted as the two largest and most important compute engines, there are many others. You can access the entire EuroHPC network via the general system (even outside the AI antennas).
For BE-AIFA specifically, the architecture often routes Belgian requests to these two heavyweights:
Architectural Impact: High-capacity workflows gain direct access to energy-efficient hardware clusters, enabling predictable execution schedules for intensive training runs.
1. LUMI 2 (Finland)
LUMI 2 is the more mature, active, and responsive environment for immediate work. It is structured around three core pillars:
- The Supercomputer Cluster: Massively parallel processor groups tailored for deep foundation model training.
- AI Factories Service Center: Low-overhead software environments, optimization architectures, and model catalog hosting.
- Quantum Exploration Centers: Direct hybrid co-processing, allowing developers to couple quantum exploration systems with classical neural network graphs.
The LUMI service catalog also includes dedicated "Trustworthy AI" advisory support and a lightweight AI inference service tailored for open, lower-volume usage.
2. JUPITER (Germany / Hungary / Belgium)
While LUMI 2 represents immediate runtime readiness, JUPITER represents the upcoming frontier for heavy co-simulation and AI workloads. It divides its architecture into two distinct systems:
- JUPITER Training Nodes: A cluster configured for training models from scratch, optimized for highly distributed parameter updates, massive batch sizes, and high-speed memory links.
- JARVIS Inference Cloud: A low-latency, resilient cloud system dedicated to hosting and serving completed models in production environments.
Core Bottlenecks and Strategic Trade-Offs
While the availability of massive compute clusters (>100,000 advanced compute processors across EuroHPC Giga Factories) addresses the European compute shortage, implementing workflows on this scale introduces deep technical and regulatory hurdles.
1. The Compute-to-Data Ingestion Mismatch
In high-performance training, data volume is massive, but the physical compute nodes are geographically remote. Moving multi-terabyte datasets to Finland or Germany introduces substantial latency and ingress constraints.
The initiative offers Data Labs—curated regional repositories that group high-quality datasets. They act as a supplementary service to handle the underlying data transfer bottleneck. Computer vision, for instance, is one example where these localized datasets provide immediate value.
Engineering Implication: Ingestion pipelines, dataset synchronization, and cross-border latency must be accounted for early in the design phase rather than treated as post-training details.
2. The Data Security Gray Area
During initial workshops, data security emerged as a key friction point. Currently, the EuroHPC infrastructure lacks the robust, enterprise-grade security guarantees required for processing highly sensitive telemetry, clinical healthcare environments, or classified public safety datasets. Security and process isolation mechanisms on shared supercomputing nodes are evolving slowly.
Security Protocol: Teams operating in sensitive domains should maintain raw datasets on-premises or within controlled environments, transmitting only stripped, synthetic, or fully anonymized inputs for remote supercomputer training.
3. The Commercial SME Qualification Loophole
Under the EuroHPC access policy, the framework is heavily optimized for ethical, sovereign, open research and development. This structure introduces strict boundaries:
- The Restriction: Private organizations are prohibited from using EuroHPC infrastructure to train models for direct, customized commercial use on behalf of large enterprises.
- The Path Forward: R&D-driven consultancies, startups, and SMEs can utilize these factories to develop, test, and iterate on their own proprietary products. These products can then be packaged, licensed, and sold to larger companies as commercial software assets.
Strategic Approach: Product architectures must be modular by design. SMEs building solutions for enterprise clients can train proprietary models within EuroHPC facilities, package the resulting weights into commercial software modules, and license the product downstream without violating access rules.
Engaging the Antenna: Technical Expertise Domains
Beyond raw processing power, BE-AIFA offers hands-on guidance on several execution fronts. Crucially, organizations can leverage these services even if they do not require EuroHPC compute resources:
- Model Selection and Fine-Tuning Strategy: High-level code review, model parameter optimization, and design choices.
- MLOps and Pipelines: Practical pipelines, automated testing, containerization, and configuration tracking across distributed node sets.
- Compliance and the EU AI Act: Deep technical advisory on audit requirements, transparency reports, and risk assessments under emerging EU guidelines.
- Resource Contribution Policy: Access is non-monetary (unless choosing pay-for-use options), but it requires users to "give back" to the community via formal reporting, participating in events, and public project credits.
Operational Value: Technical teams can access compliance reviews and architectural sanity checks early in the project lifecycle—well before submitting resource requests or writing production training code.