Red Hat and Rafay: architecture for sovereign AI cloud as a service
Red Hat and Rafay have published a reference architecture for turning distributed GPU infrastructure into a governed, multi-tenant sovereign AI service. For Belgian and French enterprises, its value lies less in the technology catalogue than in the complete operating chain, from ordering to usage metering.
1. What the architecture describes
The blueprint targets telecommunications providers, sovereign cloud operators, and neoclouds. It combines Red Hat's multi-tenant cloud and AI platform with Rafay's commercial self-service capabilities. Red Hat describes it as a validated architecture: it names components, assigns capabilities to each layer, and traces a tenant request from offer selection to a metered GPU environment.
The defining feature is the separation of commercial, control, and execution planes. Catalogue, quotas, identity, isolation, policy, observability, and consumption are explicit service components alongside Kubernetes, models, and accelerators.
2. What this changes for a Belgian or French company
An SME or mid-market company can access governed GPU capacity without building the whole platform, but should verify the operating location, effective operator, privileged access, reversibility, and portability of models and data. A large enterprise or public administration can require separate environments by entity, project, or sensitivity level, with quotas and usage evidence.
For CIO and procurement teams, the practical consequence is that a tender should ask more than where data resides. It should cover operator identity, the administration chain, keys, logs, consumption metering, software dependencies, updates, and the exit process.
3. Underside analysis: sovereignty becomes an operating model
Underside's analysis is that a credible sovereign AI cloud is judged by enforceable controls. For an agent or RAG system, compute isolation must connect to corpus permissions, secrets, MCP tools, network egress, and decision logs. Location alone protects neither against an overpowered administrator account nor a poorly bounded business connector.
In Odoo Enterprise, this architecture can support distinct development, evaluation, and production environments, while agents receive only the necessary rights over CRM, purchasing, or accounting. Local, European cloud, or hybrid placement still needs to be decided workload by workload according to sensitivity, latency, cost, and continuity.
4. Questions to require before contracting
Enterprises should request a responsibility matrix covering hardware, clusters, models, data, and applications; proof of tenant isolation; capacity and cost metrics; documented export of models, configurations, and logs; and recovery and revocation tests. GPU billing must also be attributable to a project, business owner, and outcome.
Operational recommendation: test the service with a bounded RAG or agentic workload, then verify isolation, permissions, logs, measured cost, recovery, and export before extending it to critical data or processes.
Assess a sovereign AI architecture