The trigger was a formal letter from the national financial regulator. A mid-sized Benelux insurance group, around 2,000 employees and a substantial book of personal lines business, had been running AI-driven claims scoring on a US hyperscaler for three years. The letter gave them a deadline: demonstrate that policyholder data processed by those models remained under European legal jurisdiction, or face remediation conditions that would effectively suspend the scoring tools. Schrems II had invalidated the legal basis the organisation had relied on, and the regulator was no longer willing to accept standard contractual clauses as sufficient cover when the processing infrastructure sat in American-owned facilities subject to US surveillance law.

The technical and compliance challenge was more layered than a simple data-residency question. The claims scoring pipeline ingested raw claims notifications, enriched them with third-party reference data, ran inference against a gradient-boosted model retrained monthly, and wrote scored outputs back to the policy administration system. Every stage touched personal data. The hyperscaler contract specified EU-region endpoints, but the parent company’s US domicile meant that CLOUD Act requests could reach that data without the insurer’s knowledge or consent. Demonstrating EU-sovereign AI inference to auditors required not just moving compute to European soil but establishing a clean contractual chain: no parent entity outside European jurisdiction, no sub-processor with foreign-government exposure, and technical controls that prevented exfiltration even in theory.

The organisation also needed to preserve model performance and retrain cadence. The existing scoring model ran on GPU-accelerated infrastructure; moving to CPU-only compute would have degraded inference latency to a point where real-time claims triage became impractical. Any solution had to match the GPU profile of the existing environment, not approximate it.

Architecture: building a sovereign inference pipeline

DIVERSITY scoped the engagement in two parallel tracks: GPU inference infrastructure for the scoring workloads, and EU-only cloud compute for the surrounding data pipelines. The insurer’s AMS1 deployment at DIVERSITY’s Amsterdam datacenter gave them dense peering via AMS-IX, low-latency connectivity back to the policy administration system in the Netherlands, and a contractual anchor entirely within European legal jurisdiction. DIVERSITY is headquartered in Europe, operates no US parent entity, and answers exclusively to European law, which satisfied the first layer of the regulator’s concern immediately.

The inference workloads moved onto DIVERSITY’s GPU infrastructure, provisioned in AMS1. The retrain pipeline, which ran monthly against a rolling 18-month claims window, was rebuilt as a managed job on EU-only cloud compute with object storage for training artefacts and block storage for the working dataset. Data never left the AMS1 environment during processing. The enrichment stage, which had previously called a third-party reference data API hosted on a US CDN, was rerouted through a caching layer inside the DIVERSITY environment so that enriched records containing personal data were assembled and scored entirely within the sovereign boundary.

Network architecture received equal attention. The insurer’s on-premises policy administration system connected to AMS1 over a dedicated private link rather than the public internet, removing any possibility of personal data transiting infrastructure outside the contractual scope. DIVERSITY’s BGP multihoming configuration at AMS1 ensured that the path between the insurer’s datacentre and the inference endpoint was deterministic and documented, which mattered for the technical annex the auditors required.

What the regulator actually needed to see

Regulatory reviews of this kind are not satisfied by architecture diagrams alone. The insurer’s compliance team needed to produce a processing record under Article 30 of GDPR that accurately reflected the new environment, a data protection impact assessment updated to cover AI-assisted claims decisions, and a vendor assessment demonstrating that DIVERSITY met the technical and organisational requirements expected of a processor under Article 28. DIVERSITY’s ISO 27001 certification, Tier III datacenter classification, and contractual 99.9% uptime SLA were directly referenced in the vendor assessment. The absence of any non-European parent entity was the single most important factor in closing the Schrems II gap.

Schrems II is not a technical problem with a technical solution. It is a jurisdictional problem, and the only reliable answer is a cloud provider that has no legal exposure to non-European government demands. Everything else is risk management, not risk elimination.

The compliance team submitted the updated processing record and vendor assessment four months after the migration completed. The regulator’s review panel examined the technical annex, the contractual chain, and the DPIA. No remediation conditions were attached to the outcome. The scoring tools remained in production without interruption throughout the review period.

Outcomes: regulatory clearance and a 30% cost reduction

Six months after the initial letter from the regulator, the insurance group had passed its review cleanly and reduced its monthly cloud spend by roughly 30% compared with the previous hyperscaler contract. The cost reduction came from a combination of factors: GPU infrastructure priced for European mid-market customers rather than global enterprise contracts, elimination of egress fees that had accumulated as the scoring pipeline moved data between regions on the hyperscaler, and removal of several managed services the organisation had been paying for but not fully utilising.

Model performance held. Inference latency on the AMS1 GPU infrastructure matched the previous environment within acceptable tolerance, and the monthly retrain cycle continued without modification to the training code. The data science team reported that the migration had been largely transparent to their workflow once the pipeline configuration was updated to point at the new endpoints.

The broader benefit was operational confidence. The insurer’s data protection officer now had a defensible answer to any future regulatory inquiry about where policyholder data goes during AI processing: it stays in Amsterdam, on infrastructure governed by European law, with a contractual chain that contains no foreign-jurisdiction exposure. For a financial services organisation operating under increasing regulatory scrutiny of AI systems, that clarity has value well beyond the cost saving.

Relevant capabilities

  • GPU inference infrastructure at AMS1 Amsterdam, suited to production AI workloads requiring European jurisdiction
  • EU-only cloud compute with object and block storage, managed within a single sovereign boundary
  • ISO 27001 certification and Article 28 processor agreements supporting financial services compliance documentation
  • AMS-IX peering and private connectivity for deterministic, auditable data paths between customer premises and cloud infrastructure
  • No non-European parent entity, eliminating CLOUD Act and foreign-surveillance exposure at the contractual level