Where you run clinical AI is usually treated as an infrastructure question — a matter for the people who manage servers, settled long after the clinical decisions are made. We think that gets the order backwards. Deciding to run inference where the patient is, rather than somewhere far away, is a decision about safety, privacy and trust first. The technical arrangements follow from it; they are not the reason for it.

Clinical AI should run where the patient is. When analysis happens on-site, sensitive data stays where it belongs, and clinicians keep control of a tool they can audit. That single sentence carries most of the argument, but it is worth taking the pieces apart, because each of them — safety, privacy, control — is a reason on its own, and together they point firmly toward the edge and the pod.

Edge and pod: AI where care happens

Our platform is organised so that the AI lives at the point of care. The edge tools — EndoEdge, PathoEdge and TomoEdge — sit where the clinical work is done, in the endoscopy suite, the pathology lab, the radiology reading room. The pods — EndoPod, PathoPod and TomoPod — provide the information system and the archive behind them. Both layers are deployable on-premises or in a hybrid arrangement, and the whole thing scales from a small clinic up to a large hospital.

This is not an accident of how the software happened to be packaged. It is the shape that follows from taking on-site seriously. EndoPod offers real-time endoscopy assistance alongside the endoscopic information system, which only makes sense if the assistance is right there during the procedure rather than waiting on a distant response. PathoPod brings whole-slide imaging from the slide scanners together with the laboratory information system for the anatomical-pathology lab, plus a web viewer for education and the tumour board. TomoPod is an AI-native RIS+PACS that produces semi-automated reports with the radiologist as verifier and approver. In each case the analysis happens where the images are made and read, because that is where it is useful and where it can be trusted.

Safety is a reason before privacy is

It is easy to assume the case for on-site AI is mostly about privacy. Privacy matters, and we will come to it, but in a clinic the first argument is safety.

A workflow that depends on a remote connection is a workflow with a single point of failure outside the clinic’s control. Connections drop, services slow down, remote systems have outages — and none of that should be able to interrupt care. Running inference on-site keeps the workflow resilient: the tool does its work where the work is, so a momentary problem with a link to the outside world does not become a clinical problem. Care does not depend on a remote connection, which means it does not fail when that connection does.

The exchange between the edge and anything central is asynchronous by design. Information moves between the edge and the wider system on its own schedule rather than as a live dependency that has to be satisfied before a clinician can proceed. That is what makes resilience real rather than aspirational: the clinical moment never has to wait on a round trip. The synchronisation happens around the work, not in the middle of it.

Privacy as a property of place

On-site is a safety decision as much as a privacy one — but the privacy case is strong, and it is strongest precisely because it is structural. When inference happens on-site, the most sensitive data in medicine — images, reports, the record itself — stays where it belongs, inside the institution that is responsible for it.

This turns privacy from a policy into a property of where the system runs. There is no implicit shipping of patient data to a distant service in order to get a result, because the result is computed locally. The standards the rest of medicine already relies on — DICOM and HL7, with HIPAA-aligned handling — describe how the data moves and is protected, and keeping the computation on-site means the institution decides where that data lives rather than discovering after the fact that it lived somewhere else. Data residency becomes the customer’s choice: on-premises, or hybrid with the boundary drawn where the institution’s own governance says it should be.

The clinician stays in control — and can audit the tool

The third reason is control, and it is the one that ties the platform’s architecture to its clinical philosophy. On-site AI keeps the people who are accountable for a decision firmly in the loop, because the tool is operating within their environment, on their terms, where they can see and audit what it does.

That control is most visible in how the assistance is offered. The reports are AI-assisted, but a human stays in the loop: TomoPod’s semi-automated reports leave the radiologist as verifier and approver, and across endoscopy, pathology and radiology the clinician confirms, edits, or overrides what the system surfaces. This is only coherent if the AI is genuinely under the clinician’s control, and running it on-site is part of what makes that true. A tool you can audit, in an environment you control, is a tool whose suggestions you can responsibly act on.

The web-based viewers extend that control without compromising the principle. A clinician can review whole-slide images or studies through a browser — at the tumour board, for education, or simply away from the scanner — while the underlying data and computation stay anchored on-site. Access to the view is not the same as exporting the data, and keeping the two separate is part of how on-site AI stays on-site even as more people need to look at the work.

A decision, then an architecture

Put the three reasons together and on-site AI stops looking like a deployment preference and starts looking like a commitment. It keeps care resilient, because the workflow does not hinge on a remote link. It keeps data where it belongs, because privacy follows from where the work runs. And it keeps the clinician in control of a tool they can audit, because the AI operates inside their environment rather than behind someone else’s API.

This is the principle behind everything we build: local-first, assistive, and auditable. The clinician decides; the tool supports. We put the AI at the edge and in the pod, deployable on-premises or hybrid, not because it is the easiest place to run it, but because it is the right place for the people whose judgement and accountability the whole system exists to support.