How Compliance-Bound Engineering Teams Lock an AI App Builder Inside Their Own Cloud Perimeter

AI app builders can speed up regulated product development, but they cannot host patient data without the right legal agreement. When a builder will not sign a Business Associate Agreement, the practical answer is to separate code generation from production. The builder produces the code. A private cloud perimeter holds the application, its data, and the controls needed to run it safely.

Why AI app builders cannot sign a BAA — and what that actually means for compliance teams

HIPAA requires a signed Business Associate Agreement, or BAA, with every vendor that creates, receives, maintains, or transmits protected health information on a covered entity’s behalf. SOC 2 and ISO 27001 attest to a vendor’s controls, while a BAA makes the vendor responsible for its part in handling regulated data.

Base44 holds SOC 2 Type II and ISO 27001 certifications, and Lovable holds comparable credentials. Yet the standard terms of both services ban PHI. Base44’s terms allow an exception only with prior written agreement and the appropriate contract in place. Lovable’s terms and Data Processing Agreement prohibit uploading PHI, and its terms say standard services are not designed to provide regulatory-grade safeguards for sensitive data.

HHS states that a cloud provider remains a business associate even when it stores only encrypted electronic PHI and does not hold the encryption key. This is the distinction behind “HIPAA-ready” and “HIPAA-compliant with a BAA.” The barrier is not necessarily technical incapacity or carelessness, but a service whose legal commitments do not cover the proposed use.

Why the BAA gap forces an architectural decision, not just a vendor swap

An AI-built application is not a single box. Patient data can pass through its database, hosting layer, authentication service, logs, monitoring tools, and AI model providers. Each vendor handling that data on the covered entity’s behalf needs the appropriate BAA. Moving to another builder does not solve that chain-of-custody problem if the replacement uses the same kind of non-BAA-covered hosting.

That dependency chain is also what makes builders convenient. They connect services so that an engineering team can get an application running quickly. But placing PHI in that application turns those connections into a compliance project. The structural response is to separate the place where code is generated from the place where regulated data is processed.

With this split, the builder creates source code without receiving PHI, and the team deploys that code on infrastructure it controls and that has separate BAA coverage. Lovable explicitly supports code ownership, export, and unrestricted self-hosting. Compliance then depends on the finished application’s runtime, its data flows, and the agreements covering them.

What "inside your own cloud perimeter" actually means as an infrastructure pattern

The practical target is a single-tenant virtual private cloud, or VPC, inside the team’s own cloud account. It gives the customer a boundary it can show for data residency, encryption key control, and network isolation. Isolation exists on a spectrum. Shared cloud with compliance controls offers less isolation and can leave AI inference coverage unresolved, while air-gapped or on-premises deployment brings months of setup and substantial operating work. A private VPC sits between those extremes.

In this setup, GPU instances, vector databases, and application services run in private subnets without an internet gateway. Cloud service traffic stays private through VPC endpoints. AWS Bedrock provides a concrete example of covered inference through this arrangement. PrivateLink keeps inference traffic within the private network path, fine-tuning data remains encrypted within the AWS network, and the AWS BAA covers the workload. The cloud provider’s agreement covers the model service, so it needs no separate AI-vendor BAA.

Self-hosted open-weight models such as Llama or Mistral use a different route to the same boundary. The model runs as software inside the customer’s HIPAA-eligible cloud environment, so there is no separate inference vendor to contract with. Geography adds another constraint for personal data. EU-hosted tools can still send inference calls to US-based providers, so an EU-region VPC that the customer controls is the safest path described here for processing that must meet cross-border transfer restrictions.

Which AI agent and orchestration platforms already support this deployment model

Available tooling falls into distinct contractual and deployment groups. As of October 30, 2026, Voiceflow and Lindy offer signed BAAs on Enterprise plans, while Keragon offers them on all paid plans. All three hold SOC 2 Type II credentials. AWS Bedrock AgentCore falls under the AWS BAA and has SOC 2 and ISO certifications.

n8n offers no BAA for its cloud service, so teams that use PHI must take on the work of self-hosting on infrastructure covered by the customer’s BAA. It also holds SOC 2 Type II credentials, which do not change that hosting distinction. Zapier explicitly says it does not support PHI, Make publishes no BAA, and Relevance AI publishes no HIPAA terms. Those offerings do not establish a basis for routing PHI through them.

As of October 2026, Magical claims compliance without a published BAA, while Botpress offers a BAA only on Enterprise plans. Teams should ask for a signed agreement before they send any PHI. Even then, coverage depends on the plan, region, model provider, and feature. Google Cloud leaves out pre-release features, which shows why teams need to check those details one by one.

Braintrust demonstrates a hybrid approach to the perimeter. Its vendor-hosted control plane provides the UI, metadata, and authentication, while its data plane holds traces, datasets, prompts, and evaluation results inside the customer’s AWS, GCP, or Azure VPC. Official Terraform modules support that deployment. This divides platform management from sensitive evaluation data rather than requiring every part of the product to run privately.

What the perimeter deployment requires from the engineering team running it

Cluster and node upgrades, patching, and CVE remediation no longer belong to the app builder. Customer-managed encryption keys bring responsibility for key loss and misconfiguration, with potentially unrecoverable consequences. Teams also need to set up and maintain private subnets, endpoints, security groups, and the no-internet-gateway policy with care. Private GPU workloads add memory, utilization, and cost management to that work.

Access controls and audit trails must exist as platform properties before the first application is built. They cannot wait for a later compliance pass. The delivery pipeline must also fit the boundary, using self-hosted runners, keeping secrets out of external SaaS tools, and retaining audit records internally. For applications that use retrieval-augmented generation, continuous evaluation gates must check both the embedding model and the vector index. Both are versioned artifacts whose drift can change compliance-relevant outputs.

Auditors will ask for evidence that access controls are enforced, what encryption covers, how long logs are kept, and which patches have been applied. Producing that evidence requires internally retained records of how the system has been operated. At scale, a fully integrated self-hosted AI stack needs a dedicated ML infrastructure function, which is prohibitive for many startup-stage teams. That burden explains the appeal of moving from bare-metal self-hosting to a VPC-isolated cloud model.

How small engineering teams run this architecture without a dedicated DevOps function

A platform-as-a-service layer that deploys directly into the customer’s cloud account can handle the infrastructure work while preserving data residency, network isolation, and cloud-provider BAA coverage. The account remains exclusively the customer’s. That distinction lets a small team own the boundary without building a platform engineering function to maintain it.

The platform layer should absorb VPC provisioning, network configuration, cluster upgrades, and CVE patching. Provisioning isolated environments can then shrink from weeks to minutes, while upgrades shift from on-call tasks to automated work. Configuration-driven SOC 2 and HIPAA controls should eliminate the need for a multi-month engineering project. GPU deployment support removes the need for custom inference tooling. Autoscaling and cost optimization should also address idle compute without constant manual monitoring.

Automated tests, secret scanning, container scanning, approval gates, and artifact tracking reduce deployment failures and recovery time without a dedicated DevOps engineer. GitHub Actions supports self-hosted runners, making an internal execution environment a configuration choice. The pipeline around it still has to keep secrets and audit trails inside the chosen boundary. With this infrastructure layer in place, a two-to-three-person engineering team can operate a production-grade, HIPAA-compliant AI application in its own AWS, GCP, or Azure account.

The cloud provider choice and its effect on BAA coverage and AI inference options

The choice of cloud decides which AI services the provider’s BAA covers and which deployment options stay inside the account. The service scope is the deciding detail. AWS covers Bedrock and AgentCore under its BAA, with PrivateLink supporting private inference traffic. Teams can also run open-weight models on HIPAA-eligible EC2 or SageMaker instances. In that arrangement, there is no separate AI inference vendor whose BAA must be added to the chain.

Azure OpenAI Service offers BAA coverage within Azure’s native compliance framework. Microsoft Power Automate and Copilot Studio also provide BAAs by default, extending the available covered tooling to agent orchestration. Google Vertex AI Agent Builder falls under the Google Cloud BAA. Its pre-release features are left out, however, so teams must check that a feature is covered before sending PHI through it. A provider agreement is not permission to use every feature.

Llama, Mistral, or Qwen running on private GPU instances inside a HIPAA-eligible account is software the team operates. This removes the AI-vendor BAA dependency but retains the GPU operating burden. Some teams also route workloads by function, using AWS or Azure for general infrastructure and GCP for specific AI or data advantages. In that multi-cloud pattern, the primary provider anchors the compliance perimeter, but the added workloads still need their own applicable coverage and controls.

The architectural pattern summarized: what a regulated AI product built this way actually looks like

An auditor sees a boundary that can be examined. Data residency is demonstrable, the BAA chain covers the services handling PHI, and access controls are enforced by the platform. Audit logs exist as infrastructure records from the start. The review can follow data through the system without treating the builder’s security credentials as a substitute for production coverage.

Outside that data boundary, the AI builder generates code without receiving PHI. The exported source becomes an artifact deployed into the customer’s single-tenant VPC, where private subnets and endpoints define the runtime’s data paths. Inference uses a covered cloud-native service or an open-weight model on private GPUs. Orchestration follows the same contract rule through a BAA-backed platform or a self-hosted tool such as n8n. PHI stays in covered databases, while internal logs and a private evaluation data plane keep sensitive records of how the system runs within the perimeter.

A platform layer handles provisioning, patching, controls, and delivery automation inside that account. The team retains the assets that make future changes possible, including portable source code and ownership of the cloud environment. Switching an AI provider or orchestration tool need not require rebuilding the whole compliance boundary. The builder accelerates the application, while the private runtime and its operating layer keep infrastructure from becoming a liability.