Demos
Healthcare AI deployment is constrained by where clinical data is allowed to move. A model that performs well in evaluation may still be unusable if its deployment requires external APIs, outbound network access, or infrastructure that conflicts with an organization’s security and data residency policies.
Healthcare AI does not run everywhere
Software that handles clinical data inherits every constraint that applies to the data itself. A model that reads patient notes falls under the same rules as the notes.
HIPAA sets safeguards for protected health information and permits cloud hosting under a business associate agreement (HHS Office for Civil Rights, Guidance on HIPAA & Cloud Computing, 2016). GDPR restricts transfers of personal data outside the European Economic Area (Chapter V, Articles 44–49). Each organization adds its own security policies, data residency requirements and procurement rules on top of these. An infrastructure team may prohibit outbound connections from systems that touch PHI. A compliance office may require that data never leaves a specific jurisdiction. A government contract may forbid any external network dependency at all.
An AI tool that requires internet access, external APIs or a specific cloud provider cannot be deployed where these policies exclude them.
Six deployment options run the same workflows
Generative AI Lab installs through AWS Marketplace or Azure Marketplace, on customer-managed Amazon EKS or Azure AKS clusters, on dedicated on-premises servers, or as an air-gapped installation with no external network connection. All six options run the same annotation, de-identification, evaluation, human review and model training workflows.
Healthcare organizations operate across a wide range of infrastructure environments, each suited to a different set of requirements.
Some run in managed cloud, deploying through a marketplace where the vendor handles provisioning and billing. Others run in their own cloud account inside a private network, using managed Kubernetes so data stays within a VPC they control. Some require full on-premise installation on dedicated servers, keeping every component inside their own data center. And some operate air-gapped, with no internet connection at all.
A research hospital with an established cloud security program may choose a marketplace deployment. A government health agency may be required to run air-gapped. A pharmaceutical company may keep some workflows on-premises and others in a private cloud.
Why air-gapped environments still exist
An air-gapped system has no connection to external networks. Organizations use one when policy prohibits any external exposure of the data it holds.
An AI platform that pulls container images, validates licenses or downloads models over the internet cannot run in these environments. Generative AI Lab’s air-gapped package includes all images, dependencies and licensing. Administrators transfer it into the isolated environment through a controlled process, and the platform runs with no outbound connection.
Offline operation is a meaningful engineering requirement, not a checkbox. It shapes how licensing works, how updates are delivered, and how the software is packaged. Building for air-gapped operation from the start is different from bolting it on later.
Whether deployment happens through a cloud marketplace, a customer-managed Kubernetes cluster, or an air-gapped installation package, the objective is the same: give infrastructure teams a supported installation path instead of asking them to assemble one themselves.
Each of the six options has a documented installation path.
AI should adapt to infrastructure, not the other way around
The organizations that adopt healthcare AI most successfully tend to share a trait: they do not redesign their security and governance to fit a tool. They select tools that fit the security and governance they already have.
That principle points to a clear design goal. Teams should be able to choose their models, their annotation workflows, and their review processes based on clinical and operational needs. They should not have those choices dictated by a deployment architecture the vendor happened to assume.
Generative AI Lab provides the same user experience whether it is deployed through AWS Marketplace, Azure Marketplace, a customer-managed Kubernetes cluster, an on-premise server, or a fully air-gapped environment. Clinical teams keep the same workflows while infrastructure teams choose the deployment model that satisfies organizational requirements. Neither decision constrains the other. Restricted networks that require proxy routing, custom certificate authorities, or enhanced audit logging should be supported as standard deployment scenarios rather than treated as exceptional cases.
The goal is not to convince organizations to change how they operate. It is to meet them where they already are.
Frequently asked questions
Q: Can the platform run completely offline?
Yes. The air-gapped installation package includes all required images, dependencies and artifacts for transfer into an isolated environment.
Q: What deployment options are available?
Generative AI Lab supports deployment through AWS Marketplace, Azure Marketplace, customer-managed Amazon EKS and Azure AKS clusters, dedicated on-premise servers, and fully air-gapped environments. Proxy deployments, custom certificate authorities, and offline licensing are also supported for restricted enterprise environments.
Q: Does on-premise deployment reduce functionality compared to cloud?
No. On-premise and air-gapped deployments provide the same annotation, evaluation, and model training workflows as cloud deployments. The difference is where the software runs, not what it can do.
Q: How does licensing work in an air-gapped environment?
Air-gapped deployments use offline licensing that does not require a connection to an external license server. Floating and air-gapped licenses cannot be mixed within the same instance, so the licensing model is chosen to match the deployment.
Q: Can an organization move between deployment models later?
Yes. Because the same platform runs across all deployment types, organizations can start in one environment and migrate to another as their infrastructure or compliance requirements change.
