Europe Cannot Govern AI by Cloud Region Alone: A Technical Architecture for AI Sovereignty

Specialized Hardware Requirements and High-Throughput Scalability

Does the Architecture Require NVIDIA H100/H200 Confidential Computing, AMD SEV-SNP, or Other Specific Hardware?

No. The architecture is not dependent on NVIDIA H100/H200 Confidential Computing, AMD SEV-SNP, or any single processor, accelerator, TEE vendor, or cloud platform.

The architectural requirement is narrower: there must be a protected authorization domain capable of protecting the security-critical state and controlling release of the capability required at the relevant execution boundary. The disclosure expressly permits a TEE, HSM, secure enclave, secure element, confidential-computing module, hardware-rooted control module, or functionally equivalent cryptographically isolated enforcement domain. It also expressly states that the protected domain need not execute the entire AI inference workload.

Accordingly, NVIDIA Confidential Computing and AMD SEV-SNP should be understood as possible implementation substrates, not architectural prerequisites.

For example, an NVIDIA H100-or-later GPU supporting Confidential Computing can provide GPU attestation and cryptographic evidence concerning GPU hardware and software integrity. NVIDIA's current attestation architecture supports local and remote GPU attestation and can collect evidence across multiple GPUs. AMD SEV-SNP provides a different implementation substrate: a confidential VM with hardware-rooted isolation and attestation that can protect an authorization controller from an untrusted hypervisor.

Neither technology, by itself, implements the proposed execution-finality architecture.

The distinction is important:

Confidential computing answers:
Is this workload or execution environment running in an expected protected state?

Execution-finality governance asks:
Given that protected state, does this particular computation or output possess the required authority to cross the next consequential boundary?

Attestation can therefore become an input predicate to execution-finality rather than being the final authorization decision itself.

A deployment could, for example, use:

CPU confidential VM / TEE
→ hold policy, trust anchors, ALF repository and authorization keys

GPU or accelerator
→ perform bulk inference

GPU/VM attestation
→ prove relevant execution-environment state

Protected authorization controller
→ validate ALF + attestation + policy

Capability release
→ permit computation

and later:

Runtime evidence + destination credentials + jurisdiction context + freshness/revocation state
→ Finality Controller
→ release or withhold the output-finality capability.

This is consistent with the disclosure's explicit separation of high-performance computation from authorization-critical operations.

Current confidential-computing systems also demonstrate that secret or resource release conditioned on successful attestation is technically practical. For example, NVIDIA's Confidential Containers architecture describes attestation of CPU/GPU TEE state followed by policy-controlled release of secrets or resources.

Deployment Without Confidential GPUs

A confidential GPU is therefore not mandatory.

One implementation could place the authorization controller in an AMD SEV-SNP confidential VM, HSM, or another protected CPU-side environment while conventional GPUs perform inference externally.

Before inference, the protected controller could:

1. receive the invocation identifier and protected policy context;
2. obtain the proposed model/checkpoint/orchestration identity;
3. derive or verify the candidate ALF;
4. verify relevant compute-plane attestation or service credentials where available;
5. evaluate expiry and revocation state;
6. create a fresh invocation identifier or nonce; and
7. release a bounded scheduler token, model-access credential, decryption key, API authorization, or equivalent computation-start capability.

The disclosure specifically contemplates these forms of computation-enabling capability.

A deployment using H100/H200-class Confidential Computing could strengthen the trust chain by adding hardware-backed GPU measurements. A deployment without such GPUs would need another trustworthy mechanism for establishing the properties of the external compute plane that matter to the applicable policy.

The security strength therefore depends on the implementation's trust boundary, but the architecture itself is hardware-agnostic.

How Does Runtime Signal Collection Scale to High-Throughput AI?

The architecture should not be implemented by continuously streaming every GPU operation, tensor value, token, activation, attention state, or internal model state into the protected domain.

That would create an unnecessary observability and performance burden and would undermine the architectural separation between high-throughput inference and bounded governance enforcement.

The disclosure instead defines the runtime behavioral governance descriptor from governance-relevant instrumentation points such as policy evaluation, tool invocation, retrieval operations, safety processing, workflow branching, configuration state, output classification and timestamps.

This means the scalable unit is not:

every GPU instruction → TEE

or:

every generated token → HSM

but rather:

security-relevant state transition → bounded governance event.

For example, a high-throughput inference system could internally process thousands of token-generation operations while emitting only bounded events such as:

MODEL = ALF_27

PURPOSE = P3

TOOL_CALL = T7

RETRIEVAL_CLASS = R2

POLICY_NODE = PASS

SAFETY_STATE = S4

OUTPUT_CLASS = O2

DESTINATION_CLASS = EU_AUTHORIZED

Those values can be normalized into a deterministic per-invocation descriptor rather than preserving the entire inference trace. The disclosure expressly provides for deterministic serialization, canonical ordering, normalized representations and cryptographic hashing of the resulting descriptor.

The High-Throughput Data Path

A practical implementation can therefore separate the data plane from the governance plane:

High-throughput data plane

GPU inference
→ batching
→ KV-cache operations
→ token generation
→ model parallelism
→ ordinary high-bandwidth execution

while in parallel:

Bounded governance plane

Invocation ID
→ ALF/version reference
→ policy-state transitions
→ tool/retrieval events
→ safety-state changes
→ output classification
→ destination/jurisdiction evidence
→ canonical descriptor
→ cryptographic commitment
→ Finality Controller.

The protected domain therefore does not have to absorb the model's complete computational bandwidth.

This distinction becomes particularly important for multi-GPU systems. NVIDIA itself recognizes that confidential multi-GPU data paths can create performance considerations; its PPCIE mode is specifically designed to alter the security/data-path trade-off for NVLink/NVSwitch environments. The execution-finality architecture avoids making its fundamental security property dependent on continuously routing the entire AI data plane through such a governance controller.

Per-Invocation State Rather Than Per-Token Attestation

Hardware attestation also does not need to be repeated for every generated token.

A deployment can establish an attested execution environment, bind that environment to a bounded validity epoch, and associate individual invocations with that trusted state. Per-invocation enforcement can then use lightweight freshness, nonce, ALF, policy and descriptor checks while requiring renewed platform attestation when the applicable trust epoch expires or material platform state changes.

Conceptually:

Platform attestation

→ establish trusted execution epoch

→ many individually identified inference invocations

→ bounded runtime governance events per invocation

→ per-invocation descriptor/finality decision

→ re-attest upon security-relevant state change or expiry.

This distinction between platform attestation frequency and execution-finality decision frequency is important for scalability.

NVIDIA's current tooling, for example, can collect evidence from all GPUs in a system and supports local and remote verification; the technology does not imply that a fresh remote hardware attestation must occur for every token or every inference operation.

Batching Does Not Require Loss of Per-Invocation Authority

AI serving systems commonly batch multiple requests onto the same accelerator. Execution-finality need not prohibit batching.

The batch can remain a performance optimization of the compute plane while each invocation maintains its own logically separate governance state:

Batch

Invocation A → Descriptor A → Jurisdiction A → Finality A
Invocation B → Descriptor B → Jurisdiction B → Finality B
Invocation C → Descriptor C → Jurisdiction C → Finality C

The GPU may calculate A, B and C together, but authority to externalize their results does not have to be shared.

If Invocation A satisfies its predicates while B has a revoked credential and C targets an unauthorized jurisdiction, the architecture can permit A while withholding finality from B and C.

This follows the disclosure's core requirement that finality predicates be evaluated for the particular inference/output rather than merely trusting the region in which the shared compute instance resides.

Cryptographic Work Can Also Be Amortized

Not every trust object must be reconstructed from zero for every invocation.

Longer-lived infrastructure certificates, trust chains, approved ALF repositories and authority keys may be validated and cached according to bounded validity policies, while security-sensitive per-invocation state remains fresh.

The fast path can therefore concentrate on operations such as:

cached trust anchor + fresh invocation nonce + ALF reference + bounded runtime descriptor + destination binding + freshness/revocation state → finality decision.

Where policy permits, revocation information and authority state can likewise use bounded freshness windows rather than requiring an external network round trip for every generated output.

The architecture nevertheless preserves the fail-closed option where a high-risk operation requires current revocation information. The disclosure expressly treats stale, unknown, revoked or unavailable status beyond an allowed freshness window as a condition capable of preventing finality.

Engineering Limitation

The architecture doesnot  not claim zero overhead.

Runtime instrumentation, descriptor construction, cryptographic verification, attestation, revocation checking and finality evaluation all have costs. The exact latency and throughput impact will depend on the deployment architecture, number of predicates, credential infrastructure, batching strategy, frequency of attestation, network dependence and placement of the Finality Controller.

The technical proposition is narrower:

Execution-finality does not require placing the full AI computation inside the trusted enforcement domain or continuously inspecting the model's complete internal computation. High-throughput inference can remain on GPUs or accelerators, while a comparatively narrow governance plane captures bounded security-relevant state transitions and controls the capabilities required at computation-start and output-finality boundaries.

NVIDIA H100/H200 Confidential Computing, AMD SEV-SNP and comparable technologies can strengthen particular implementations, but they are implementation substrates rather than requirements of the architecture. The scalability objective comes from keeping the high-bandwidth computational data plane separate from the bounded authorization and finality plane.