How we use our infrastructure to meet healthcare standards with AI

Contents

In a healthcare setting, the challenge of putting AI into production is not the model: it is compliance. The rules that apply, both the technical interoperability standards and the law, impose concrete requirements on access control, confidentiality, traceability, data location and governance. A demo on a laptop ignores all of that; a real platform has to satisfy it, and has to be able to prove it to an auditor.

This article is not a tour of technologies. It is the opposite: we take the requirements the rules impose and, for each one, we show how our infrastructure is used to meet it. The infrastructure is real, two RKE2 clusters (Kubernetes v1.35) with Cilium as the network, GitOps with Flux, Keycloak as the identity server, inference on our own GPUs and, in pre-production, scheduling with Volcano, and every component is here because it solves a regulatory requirement, not because it looks good on a diagram. Like all infrastructure, moreover, it is measured by efficiency and cost, which is what makes compliance sustainable instead of an expense nobody can bear.

It is worth starting with an idea many people are unaware of: standards for this already exist in the sector, and nothing has to be invented. There are clinical interoperability standards (HL7, FHIR, DICOM and the IHE profiles that combine them), there is a Kubernetes-native standard for packaging and running medical imaging AI (MONAI Deploy and its MONAI Application Package), and there is an emerging standard for what a cluster must look like to run AI with guarantees (the CNCF Kubernetes AI Conformance). Let us first lay out that map of standards, and then walk the requirements one by one.

The map of standards in the sector

Three families of standards intersect in a healthcare AI platform, and understanding what each one covers avoids reinventing wheels.

Clinical interoperability: HL7, FHIR, DICOM and IHE. The base formats are well known, HL7 v2 for legacy messaging, FHIR for modern clinical data over REST, DICOM/DICOMweb for imaging. What many people overlook is that there is a body, IHE (Integrating the Healthcare Enterprise), which does not invent formats but defines profiles: concrete combinations of those standards to solve a use case in an interoperable way. Profiles such as XDS/XCA (document exchange), PIX/PDQ (patient identification and query) and, crucial for security, ATNA (Audit Trail and Node Authentication), which specifies the four pillars of a secure node: node authentication, user authentication, audit logging and encryption of communications. And it rests on a sibling profile, Consistent Time (CT), which synchronises the clocks of all nodes: without reliable time, an audit log is worthless as evidence, because what happened can be neither ordered nor correlated. ATNA has also been modernised with RESTful ATNA and the BALP (Basic Audit Log Patterns) profile, which express auditing as FHIR AuditEvent resources. IHE is, in practice, the standard that says how FHIR and DICOM are combined securely and auditably; it is the natural reference for designing compliance controls.

Medical AI on Kubernetes: MONAI Deploy and the MAP. For the specific problem of packaging, distributing and running medical imaging AI applications there is a de facto standard: MONAI Deploy, part of the MONAI project (an open source deep learning framework for healthcare imaging, from the PyTorch ecosystem), and its MONAI Application Package (MAP). A MAP is a container image that complies with a specification defined by the MONAI Deploy working group, experts from more than a dozen medical imaging institutions, and, according to that specification, a MAP must support deployment on Kubernetes and integrate with DICOM and FHIR for data exchange. That is, there is a standard format for “a medical AI app” that runs natively on Kubernetes, which is exactly our substrate. This matters for compliance because a MAP encapsulates the model, its dependencies and its input/output contract in a versioned, reproducible form. Around the MAP, MONAI Deploy also supplies the orchestration pieces a clinical environment needs: an Informatics Gateway that receives DICOM studies and triggers inference, and a Workflow Manager that chains the steps of a pipeline on Kubernetes. It is not just a packaging format: it is a standard way to take a medical imaging app from the registry to the PACS without bespoke integration at every hospital.

AI-ready clusters: CNCF Kubernetes AI Conformance. In November 2025 the CNCF launched the Certified Kubernetes AI Conformance Program, which standardises how AI workloads run on Kubernetes through a set of requirements, the KARs (Kubernetes AI Requirements), covering GPU integration, volume management and job-level networking, aligned with Kubernetes v1.35. And what is most relevant for healthcare: the programme announced that during 2026 it will be extended with a Sovereign AI track, focused on hardened sandboxing and data privacy. It is the industry-level formalisation that a cluster running serious AI must meet minimum guarantees, and that data sovereignty is now a first-class category, not a preference.

With this map on the table, let us walk the requirements.

Requirement: interoperability on standards (EHDS, MDR, IHE)

The EHDS requires health data to be exchanged in standard formats, and its profiling is built on FHIR R4; the IHE profiles define how that exchange is done interoperably; the MDR requires data traceability when the software is a medical device. The requirement: the platform cannot speak a dialect of its own.

How we meet it: we put an interoperability layer as the boundary between the clinical domain and the inference domain. A FHIR server (R4, because it is the normative version and the one the EHDS profiles; R5 has marginal adoption and the sector is waiting for R6, in ballot since January 2026) exposes the clinical resources; a DICOMweb node serves imaging through QIDO-RS, WADO-RS and STOW-RS; and a gateway transforms incoming HL7 v2 into FHIR. On that base we apply the relevant IHE profiles: patient identification with PIX/PDQ so identities are not crossed between sources, and document exchange with XDS/XCA where appropriate. The AI model never touches the clinical database directly: it consumes FHIR and DICOMweb through this layer, which is where data is normalised, profiled and access-controlled. When we deploy an imaging AI application, the aim is to package it as a MAP, so that its contract with DICOM/FHIR is the sector standard and not a bespoke integration.

Requirement: AI results return to the clinical workflow in standard form (DICOM, FHIR, MDR)

Clinical AI does not end when it produces an output: that output has to return to the system in a format the clinician and the record understand, and traceably (MDR). Returning a PDF or a proprietary JSON breaks interoperability and leaves the result outside the clinical record, where nobody audits or reuses it.

How we meet it: results from imaging models are re-injected as standard DICOM objects, DICOM SR (Structured Report) for findings and measurements, DICOM SEG for segmentations, or Secondary Capture for visual representations, through STOW-RS, so that the PACS and the viewer treat them like any other series in the study. Results unrelated to imaging are expressed as FHIR resources (Observation, DiagnosticReport) linked to the patient and the originating study. This way the AI result is a first-class citizen of the clinical record, referenceable, versioned and auditable, not a loose artefact on a disk. Packaging the application as a MAP helps here too: the output contract towards DICOM/FHIR is part of the package specification itself, not a different piece of glue script at every deployment.

Requirement: minimal, authorised access (GDPR, ENS, EHDS, IHE ATNA)

The GDPR imposes minimisation (art. 5) and reinforced protection of health data as a special category (art. 9); the ENS (Esquema Nacional de Seguridad, the Spanish National Security Framework) requires identification and access control; the EHDS, control over who accesses data and for what; and IHE ATNA requires node authentication and user authentication as pillars of a secure node. Translated into infrastructure: every access to clinical data authenticated, authorised to the minimum and bound to a purpose; and every participating node identified.

How we meet it: a single identity server, Keycloak, governs all authorisation with OAuth 2.1 and OpenID Connect, profiled by SMART on FHIR:

  • Resource- and purpose-oriented scopes. SMART distinguishes patient/, user/ and system/, and its version 2 separates permissions by operation (create, read, update, delete, search). An AI agent receives the minimum, for example system/ImagingStudy.rs (read and search studies only). It is GDPR minimisation implemented in the token, and the user authentication that ATNA demands.
  • Service identity without shared secrets. Unattended workloads use private_key_jwt (an assertion signed with a private key).
  • Audience binding. The token carries the URL of the destination server in aud and that server validates it, preventing lateral reuse of credentials; it relies on FHIR-specific Keycloak extensions.
  • Node authentication (ATNA) with mTLS. Between nodes handling clinical data we require mutual TLS, so that it is not only the user or the service that is authenticated, but the machine or service itself taking part in the exchange.

DICOMweb is protected with the same token and the same Keycloak. The result is a single identity plane for FHIR, DICOMweb and the MCP servers: one place to demonstrate who can access what.

The same principle of least privilege is applied one level below, to the Kubernetes plane itself, which the ENS also reaches. Operators do not connect with a universal cluster-admin: administrator access to the cluster API is federated against Keycloak over OIDC, with roles scoped by namespace, so that technical access too is authenticated, limited and audited. And workloads use service accounts with no permissions by default, granted only the strict minimum. Whoever administers the platform is subject to the same identity regime as whoever consumes clinical data through it.

Requirement: confidentiality, isolation and leak prevention (GDPR art. 32, ENS, ATNA encryption)

The GDPR (art. 32) requires confidentiality, integrity, availability and resilience, with measures such as data separation and encryption; the ENS details segregation and communications protection controls; ATNA requires encryption of communications between nodes. In a multi-customer platform this translates into two things: that one centre’s data is not visible to another, and that a compromised component cannot get data out.

How we meet it for tenant isolation: each tenant lives in its own namespace, with scoped RBAC, ResourceQuota and LimitRange, a dedicated database per operator (CloudNativePG), not a shared database behind an application filter, and its own object storage space. Identity is segregated by realm in Keycloak. Everything is defined in Git and reconciled by Flux (GitOps): separation is declarative and auditable through change history. Faced with “prove to me that centre A cannot see centre B’s data”, the answer is a commit.

How we meet it for network confidentiality and exfiltration prevention: the network is managed by Cilium (eBPF) with a default-deny model. A pod has no connectivity beyond what a policy grants it explicitly, flow by flow, which turns exfiltration into something blocked in the kernel. For example, the traceability component can only talk to its analytical database, its PostgreSQL, the object storage, the cache and DNS:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: trazabilidad-egress-minimo
  namespace: trazabilidad
spec:
  endpointSelector:
    matchLabels:
      app: trazabilidad-web
  egressDeny:
    - toEntities: [world]      # nothing leaves the cluster by default
  egress:
    - toEndpoints:
        - matchLabels:
            app: postgres
    - toEndpoints:
        - matchLabels:
            app: analitica
    - toEndpoints:               # DNS, without this the pod does not resolve
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports: [{ port: "53", protocol: UDP }]

Two nuances separate a correct policy from a broken or leaky one: you have to explicitly allow DNS (otherwise the pod does not work) and filter by endpoint identity, not by CIDR, because in an identity-based network filtering by IP ranges does not behave the way intuition suggests. On top of this we add flow observability with Hubble and runtime security with Tetragon (eBPF), which watches process execution, file access and connections inside the container, making it possible to detect and block anomalous behaviour in workloads handling sensitive data. For the encryption in transit required by art. 32 and ATNA, cert-manager manages TLS at the ingresses and Cilium can transparently encrypt traffic between nodes.

To this are added two baseline controls that art. 32 and the ENS take for granted. First, the Pod Security Standards in restricted profile, containers without privileges, not running as root and with a read-only filesystem where possible, which reduce the surface of a compromised container. Second, disciplined management of secrets and keys: the private_key_jwt private keys, the certificates and the database credentials do not live in plain manifests in Git, but are managed and rotated, with cert-manager issuing and renewing certificates automatically. A secret leaked into a repository is a potential data breach, and is treated as such from the design stage.

Requirement: data life cycle, minimisation, retention and pseudonymisation (GDPR, EHDS)

The GDPR does not only limit who accesses data: it limits how much data is processed (minimisation, art. 5) and how long it is kept (storage limitation), and it promotes pseudonymisation as a protection measure (art. 32). The requirement: do not accumulate identifiable clinical data longer than necessary, and de-identify where the use case allows.

How we meet it: the interoperability layer is also the control point for the data life cycle. Pseudonymisation is applied there when the AI workflow does not need direct identity, for example evaluation or tuning over cohorts, keeping the re-identification table separate from the rest of the system and behind its own access policies. One principle we apply strictly: traces and logs contain no clinical data. They record resource identifiers, model, cost, latency and tenant, not the content of the record or the image, so that the observability layer does not become a second store of sensitive data that has to be protected and audited twice over. And retention policies are applied per data type, traces, caches, intermediate copies, with automatic expiry, so that the storage period is a declared, verifiable property, not an oversight accumulating risk on disks nobody reviews.

Requirement: data location and sovereignty (GDPR, EHDS, CNCF Sovereign AI)

Processing special-category health data by sending it to a third party’s inference API, outside the controller’s control, is hard to justify under the GDPR and contrary to the spirit of the EHDS. And it is not only a legal requirement: the Sovereign AI track of the CNCF AI Conformance raises it to a first-class technical category for 2026. The implicit requirement is that clinical data must not leave the perimeter.

How we meet it: inference is served locally, on our own GPUs, with a high-performance serving engine (vLLM). Imaging AI applications are packaged, ideally, as MAPs, which run natively in the cluster without taking data outside. In front of them we put a model gateway through which all inference traffic passes: it is the point where it is decided what runs inside and where, so that clinical data does not leave by default and any exception is explicit and logged. Whether this is viable, and not a luxury, depends on efficiency: to serve in-house at a reasonable cost you have to squeeze the hardware, and that is where scheduling comes in. Sovereignty stops being a promise on a slide and becomes a property of how the inference is built.

There is a nuance worth spelling out, because it marks the difference between “we say the data does not leave” and “the data cannot leave without a record”. The gateway reverses the burden: the default behaviour is local inference, and any egress towards an external service is an exception that has to be enabled explicitly, that is logged and that, in addition, collides with the default-deny network policies if the corresponding destination has not been opened. That is, sovereignty does not rest on a design decision alone, but on several mutually reinforcing controls, gateway, network policy and logging, so that a configuration slip does not translate into a silent leak. For special-category data, that difference between trust and guarantee is exactly what the GDPR asks for when it speaks of data protection by design and by default (art. 25).

Requirement: reliable execution of critical workloads and efficiency (ENS, CNCF AI Conformance)

Keeping inference in-house is only sustainable if the GPU is used well, and certain workloads (an overnight batch of image processing) must run reliably and to completion. The CNCF AI Conformance KARs also formalise GPU integration and job-level networking requirements that a serious AI cluster must meet. The default Kubernetes scheduler schedules pod by pod, which for distributed workloads produces half-started jobs that hold GPUs without making progress.

How we meet it: GPU allocation is governed by Volcano (a CNCF incubating project), today in pre-production, with the mechanisms that matter for reliability and efficiency:

  • Gang scheduling (PodGroup with minAvailable): a distributed job starts complete or does not start, avoiding GPUs blocked while waiting.
  • Per-tenant queues with quota and priority, which make real the fair sharing between tenants that multitenancy only declares.
  • Fair-share (DRF) to distribute proportionally and pre-emption so that an urgent workload can overtake a deferrable batch.
  • Topology awareness (NVLink/PCIe) to reduce fragmentation.

This raises the effective utilisation of the GPU fleet, which is what makes sovereign inference economically viable. And it is managed with metrics, not impressions: effective versus allocated utilisation, percentage of time idle, fragmentation, throughput per GPU (tokens per second) and GPU-hours consumed per tenant. These are the figures that let you decide whether more hardware is needed or whether there is spare capacity badly distributed, and the ones that turn a discussion about cost into a decision with data. On the state of the art: Kubernetes 1.34 took DRA (Dynamic Resource Allocation) to general availability, accelerator allocation by attributes instead of by count, and Kueue covers job quota management; both combine with a gang scheduler such as Volcano. Efficiency is not a FinOps extra: here it is the condition that makes meeting the sovereignty requirement sustainable.

It is also worth reading these components in the light of the CNCF AI Conformance: its requirements (the KARs) verify that a cluster integrates GPUs correctly, manages the volumes AI workloads need and resolves job-level networking. They are not ornaments: they are precisely the capabilities that the inference serving, the model and data storage, and the distributed scheduling we have just described rest on. Aligning with that standard is, in practice, a way to guarantee that the platform runs AI with the same properties the industry has agreed as the minimum acceptable, and to be able to prove it, which in a regulated environment is worth as much as complying.

Requirement: activity logging and human oversight (AI Act, EHDS, IHE ATNA/BALP)

The AI Act, for high-risk systems, and clinical AI almost always is one, requires automatic logging of activity (art. 12) and meaningful human oversight (art. 14); the EHDS imposes traceability over the use of data; and IHE ATNA/BALP defines how that audit log must look, expressing it as FHIR AuditEvent resources. The requirement: being able to reconstruct every access and every decision, in a standard, queryable format.

How we meet it, on two planes. On the data access plane, audit events (who accessed which clinical resource, when, for what purpose) are emitted following the FHIR AuditEvent pattern of BALP, so that auditing is interoperable and not a proprietary log. On the AI decision plane, each inference is recorded as an auditable trace with Langfuse, prompt, response, model and version, cost, latency and tenant, stored in our own components locked behind network policies that prevent it from leaving. The trace satisfies the AI Act logging and the EHDS traceability, and at the same time serves as the basis for continuous evaluation and for human oversight, which is exercised at the gateway (review, limits, possibility of intervention). Instrumentation converges on the OpenTelemetry GenAI semantic conventions, correlatable with the rest of the observability.

An audit log is only worth anything as evidence if it is intact and ordered in time. That is why events are kept in append-only storage (with no possibility of later editing) with their retention defined, and node clocks are kept synchronised, the IHE Consistent Time profile put into practice with NTP, so that the sequence of “who did what and when” is reconstructible and defensible. Without integrity and reliable time, a log is a note, not evidence.

Requirement: availability, continuity and recovery (GDPR art. 32, ENS)

Art. 32 of the GDPR requires not only confidentiality and integrity, but availability and resilience, and the ability to restore access to the data after an incident; the ENS details service continuity measures. A clinical system that goes down and does not recover is a breach of the rules, not just an operational incident.

How we meet it: the platform runs across two sites (site01 and site02), which makes it possible to separate workloads and to have capacity available if a site goes down. The control plane of each cluster is highly available, with several control nodes and replicated etcd. The per-tenant databases are managed by an operator that automates replicas and backups to object storage, and the declarative state in Git allows rebuilding a complete environment from its repository. Recovery does not depend on a particular server or on the memory of whoever set it up, but on re-applying what is versioned. The combination of data copies and configuration reproducibility is, in the terms of art. 32, precisely the ability to restore the service within a reasonable time.

Requirement: reproducible and demonstrable operation (ENS, MDR/ISO 13485, AI Act)

The rules do not only ask that the system do the right thing: they ask that you be able to prove it and reproduce it. The ENS requires configuration management and change traceability; the MDR (via ISO 13485) requires change control and reproducibility; the AI Act, risk management and technical documentation.

How we meet it: the whole platform state, deployments, network policies, quotas, RBAC, identity configuration, is described in Git and applied by Flux over GitOps. Every change is a revision with an author, a date and a reviewer; every environment is reproducible from its repository. Model versions are recorded in the traces, and packaging the AI as a versioned MAP reinforces reproducibility: you know exactly which artefact was executed. A configuration audit thus becomes a query against the history, with the ability to reconstruct what was deployed on a given date.

The piece that ties it all together: ISO/IEC 42001

Everything above consists of technical controls that satisfy concrete requirements. But the rules also require a management system to order, evaluate and continuously improve them, with defined roles and responsibilities. That piece is ISO/IEC 42001, the certifiable standard for AI management systems: the one that turns “we have the controls” into “we have governed, demonstrable AI”. It is, precisely, the content of the AI Management Systems course we will publish shortly, designed to accompany the leap from technical implementation to certifiable governance.

A view of the sector as of June 2026

It is worth pinning down the snapshot of the moment, because several currents have converged right now and they condition any platform decision.

Everything in AI converges on Kubernetes. The CNCF itself described it in 2026 as “the great migration”: AI platforms, previously scattered across proprietary solutions, are consolidating on Kubernetes as a common substrate. The practical consequence is that capabilities once reserved for HPC systems, gang scheduling, topology awareness, integration with the network fabric, are now first-class citizens in Kubernetes.

Accelerator allocation is being standardised. With DRA at general availability (Kubernetes 1.34) the old model of “counting GPUs” gives way to allocation by device attributes, with dynamic partitioning. It is a fundamental change in how expensive hardware is shared out, and our clusters (v1.35) are already on the branch where this is real.

Conformance marks for AI are appearing. The CNCF Kubernetes AI Conformance (launched in November 2025, with the KARs) defines what makes a cluster “AI-ready”, and in 2026 it incorporates the Sovereign AI track: hardened sandboxing and data privacy as formal requirements. For healthcare this is enormous, because it turns data sovereignty, which we had been defending out of legal obligation, into a certifiable property of the platform.

Medical imaging AI has its packaging standard. MONAI Deploy and the MAP are maturing as the standard way to build, validate and run medical imaging applications, with Kubernetes as the target and DICOM/FHIR as the contract. Anyone deploying serious imaging AI in 2026 looks towards the MAP, not towards bespoke integrations.

Regulation enters its application window. The EHDS has been in force since March 2025 and its milestones are approaching: data access bodies towards 2027, cross-border primary use towards 2029, all profiled on FHIR R4. The AI Act saw its high-risk deadlines postponed by the Digital Omnibus (Annex III to December 2027, Annex I to August 2028), but its obligations, risk management, logging, human oversight, do not move. And the FHIR R4 to R6 transition is being planned skipping R5. The picture is of a sector where the technology (Kubernetes, eBPF, DRA, MAP) and the rules (EHDS, AI Act, IHE) are finally advancing at the same time.

GPU economics pushes in-house. The resource remains scarce and expensive, and that has two mutually reinforcing effects. On one hand, the pressure for efficiency, utilisation, fragmentation, density, is at its peak, which is why scheduling (Volcano) and attribute-based allocation (DRA) are at the centre of the debate. On the other, the maturing of open-weight models, which perform better and better on modest hardware, has made it viable to serve quality inference locally without depending on an external API. The combination, competent open models plus efficiency tools on Kubernetes, is exactly what turns data sovereignty, in healthcare, from a costly aspiration into a reasonable option. The 2026 trend is not only “AI in the cloud”; it is also a pragmatic return of compute to in-house infrastructure where the data and the cost demand it.

Where we stand in that picture: with the platform on Kubernetes, eBPF as the network and security substrate, GPU scheduling maturing in pre-production, sovereign inference by design, traceability in auditable format and the management framework (ISO 42001) as the next step. We are not chasing fashion; we are exactly on the line the sector has decided to advance along.

Summary: requirement by requirement

The thesis is simple: each rule or standard in the sector imposes a requirement, and each requirement is satisfied by a concrete piece of the infrastructure. The interoperability of the EHDS and the IHE profiles, with a FHIR R4 plus DICOMweb layer and, for imaging AI, MAP packaging. The minimal, authorised access of the GDPR and the ENS and the authentication of ATNA, with Keycloak, SMART on FHIR and mTLS. The confidentiality and leak prevention of art. 32, with multitenancy, Cilium in default-deny and Tetragon. Data sovereignty (GDPR/EHDS and CNCF Sovereign AI), with local inference made viable by Volcano’s efficiency. The logging and oversight of the AI Act and the auditing of ATNA/BALP, with traceability in FHIR AuditEvent format. The reproducible operation of the ENS and the MDR, with GitOps and versioned MAPs. And the governance that ties it all together, with ISO 42001.

It is not a PowerPoint: it is infrastructure that runs, that complies and that, being infrastructure, is measured by efficiency and cost. That, the cost control of a healthcare AI platform, is what the next article is about.

Sources