Healthcare, finance and the public sector: Why AI data needs different infrastructure

AI models can improve productivity in healthcare, finance and public administration. But requirements for confidentiality, regulatory compliance and operational resilience vary widely across these sectors. A shared infrastructure, whether a public cloud, an on-premises datacentre or a training platform, can expose each sector to legal, technical and organisational risks. This article sets out sector-specific requirements, examines isolation, sovereignty and performance constraints, and describes hybrid architectures suited to them.

Introduction: An AI surge meeting legal and technical boundaries

In 2023, the global artificial intelligence market exceeded €200 billion, with rapid adoption across healthcare (assisted diagnostics, patient monitoring), finance (fraud detection, portfolio management), and the public sector (public data analysis, citizen services). Organisations are seeking to pool their training platforms to reduce infrastructure costs: theoretically, a single GPU cluster, object storage system, or MLOps solution could serve multiple use cases.

However, each sector operates under distinct regulatory frameworks (RGPD/GDPR and HDS for healthcare, PCI-DSS and GLBA in the United States, NIS2 for public services) and possesses data sovereignty, availability, and traceability requirements that are mutually incompatible. The temptation of a 'single-tenant AI platform' quickly clashes with contradictions: how can one guarantee the confidentiality of a medical record while simultaneously processing ultra-sensitive stock market feeds?

This observation is leading CIOs, CISOs, and AI leads to rethink the architecture of their learning environments. Rather than aiming for total uniformity, it is necessary to identify which assets, policies, and deployments must remain isolated, and then design secure bridges between them.

1. Regulatory Overview: Differentiated Requirements by Sector

These frameworks impose different controls:

• Encryption: healthcare requires end-to-end encryption with separate key management (HDS requirement). Finance often mandates FIPS 140‑2 for cryptographic modules. The public sector may be subject to state-approved encryption requirements (ANSSI).
• Traceability: finance must produce access logs compliant with PCI‑DSS, whereas healthcare focuses on the record of processing activities (GDPR Art. 30). The public sector must guarantee log retention for 10 years for critical services (NIS2).
• Resilience: healthcare systems cannot tolerate more than 5 minutes of downtime in emergencies, while the financial sector aims for < 1 minute latency for high-frequency transactions. The public sector mandates specific continuity plans (PCP) for state services.

These incompatible requirements make total infrastructure pooling impossible without robust isolation mechanisms.

2. Technical risks of a single shared environment: when interoperability becomes vulnerability

• Cross‑tenant data leakage
• In a multi‑tenant environment, misconfigured access controls could allow a model trained on patient records to be exposed to finance teams via the same object storage. The slightest IAM (Identity and Access Management) flaw then becomes a vector for a GDPR Art. 9 violation.

• Model contamination
• Biases present in healthcare datasets can propagate to financial models if training pipelines share the same metadata registry. This 'model poisoning' compromises the reliability of fraud detection algorithms, leading to regulatory consequences (PCI-DSS 12.2).

• Conflicting compliance constraints
• Implementing homomorphic encryption compatible with HDS requirements may be incompatible with the performance levels required for high-frequency trading in the financial sector, creating a trade-off between security and latency.

• Data sovereignty failure
• A public cloud provider based outside the EU could host healthcare data (subject to GDPR) while simultaneously storing financial streams subject to the US Gramm-Leach-Bliley Act. Unauthorised cross-border transfers expose the organisation to sanctions of up to 4% of annual global turnover.

These risks demonstrate that the principle of least privilege and physical or logical isolation are indispensable for each business domain.

3. Isolation Architectures: Proven Technical Options

3.1 Physical Isolation (bare-metal, dedicated zones)

• Sovereign datacenters: dedicated healthcare servers hosted in an HDS-certified sovereign cloud, with separate networks (VLAN/VRF) for finance and public sectors.
• Advantages: guaranteed total separation of traffic flows, compliance with data residency requirements.
• Disadvantages: high infrastructure costs, potential under-utilisation of GPU resources.

3.2 Logical isolation (virtualisation, containers, software-defined networking)

3.3 Hybrid approaches

• Sovereign Data Mesh: each domain owns its domain data product with local governance, while AI models can be trained via federated learning where parameters are aggregated without exchanging raw data.
• Edge‑AI for healthcare: processing medical images directly on the device (e.g., MRI scanner) so that data never leaves the hospital perimeter, while financial inference models remain in the public cloud.

These architectures make it possible to reconcile economic efficiency (reuse of shared GPUs) and sector-specific compliance through clearly defined boundaries.

4. AI data lifecycle management: sector-adapted governance

• Ingestion
• Healthcare: use of FHIR (Fast Healthcare Interoperability Resources) with TLS‑1.3 encryption and strong authentication via OAuth2 + OpenID Connect.
• Finance: secured FIX or SWIFT feeds, digital signature validation.
• Public: Open APIs compliant with the OpenAPI standard but protected by time-limited access tokens.

• Storage
• Healthcare: HDS-certified object storage with mandatory immutability (WORM) and versioning.
• Finance: Databases encrypted at rest, with separate audit logs in accordance with PCI-DSS 10.5.1.
• Public: Sovereign data lake compliant with the NIS2 directive, featuring a distinct sensitive data zone.

• Training
• Use of domain-dedicated GPU clusters or reserved spot instances for non-critical workloads (e.g., academic research in the public sector).
• Application of the data minimisation principle: loading only the columns necessary for training to reduce the attack surface.

• Deployment
• Healthcare: Models packaged in signed containers (Docker Content Trust) and deployed within HDS-certified environments.
• Finance: Use of model serving with weight encryption (e.g., Homomorphic Encryption for Model Inference) for high-value services.

• Archiving & Decommissioning
• Compliance with retention requirements: 10 years for financial logs, 15 years for patient records in France. Use of cold storage (Glacier, Azure Archive) with automated purging upon expiration of legal obligations.

5. Illustrative use case: hybrid AI platform serving a public hospital and a regional bank

Context

A French hospital group wishes to deploy an AI-assisted diagnostic model (early detection of lung cancer from CT scans). Simultaneously, the same local authority owns a banking subsidiary that wants to implement a real-time fraud detection system. Both entities share the same sovereign cloud provider (e.g., Orange Cloud for Business), but their requirements differ radically.

Proposed architecture

Read the diagram notation

graph TD
  subgraph Zone Santé (HDS)
    A1[Ingestion FHIR] --> B1[Stockage objet HDS chiffré]
    B1 --> C1[Cluster GPU dédié – VM isolée]
    C1 --> D1[Modèle entraîné + registre MLflow sécurisé]
    D1 --> E1[Déploiement conteneur signé -> Service d’imagerie interne]
  end

  subgraph Zone Finance (PCI-DSS)
    A2[Ingestion FIX] --> B2[Data Lake chiffré, clés FIPS140-2]
    B2 --> C2[Cluster GPU partagé – Namespace Kubernetes dédié]
    C2 --> D2[Modèle entraîné + registre MLflow séparé]
    D2 --> E2["API d’inférence haute fréquence (latence <5 ms)"]
  end

  subgraph Federated Learning Layer
    F1[Paramètres agrégés] --> G1[Orchestrateur FedAvg sécurisé]
    G1 --> H1["Modèles globaux anonymisés (exemple : détection d’anomalies génériques)"]
  end

  C1 -- Envoi des gradients → F1
  C2 -- Envoi des gradients → F1
  H1 -- Distribution modèles → C1 & C2

Key strengths

• Physical storage isolation (HDS vs PCI encryption).
• Distinct Kubernetes namespaces, with NetworkPolicies preventing any inter-zone traffic.
• Federated Learning enables the sharing of knowledge (e.g., anomaly detection) without exchanging raw data, thereby adhering to the principle of minimisation.

Expected results (hypothetical, based on published case studies)

This scenario demonstrates that targeted isolation enables economies of scale while adhering to the specific regulatory requirements of each sector.

6. Points of vigilance: common pitfalls and mitigation measures

Security & Compliance

Governance

• Establish a cross-functional AI Architecture Committee including the CIO, CISO, DPO and business representatives from the three sectors.
• Formalise retention policies and purging processes within the cloud service catalogue.
• Implement Key Performance Indicators (KPIs): % of isolated workloads, number of leakage incidents, mean time to compliance following regulatory changes.

7. Strategic decision: how to choose the most suitable architecture

| Regulatory complexity | Comb