Why Private VPC Architecture Matters for Clinical Research AI

Introduction

The FDA's October 2024 final guidance on electronic systems in clinical investigations addresses a question that clinical IT and regulatory teams have been working through for years: who remains responsible for compliant electronic systems when those systems are hosted by third parties? The guidance is direct. Regulated entities, including sponsors and CROs, retain responsibility for ensuring that electronic systems deployed in their investigations comply with applicable FDA requirements, regardless of whether those systems are owned or hosted externally ^[1].

That position carries architectural consequences. Many commercial AI platforms run on shared multi-tenant infrastructure, where compute resources, data stores, and in many deployments inference pipelines, are pooled across customers. For general business applications this is a reasonable trade-off. For systems processing protected health information (PHI), unpublished trial results, and the patient safety data underlying regulatory submissions, the control requirements differ in kind, not just degree.

Private Virtual Private Cloud (VPC) architecture is one control pattern that organizations use to satisfy those requirements for high-risk clinical AI workloads. It is not a regulatory mandate by name; FDA, HIPAA, EU GMP Annex 11, and ICH E6(R3) are control- and outcome-based frameworks. What they require are validated systems, documented access controls, tamper-evident audit trails, and data confidentiality. A private VPC, properly configured, can be an appropriate technical means of meeting those requirements for AI processing PHI or GxP records. This article examines exactly what that means, what each layer of control actually does, and what procurement teams should request to verify it.

What the Regulatory Frameworks Require

Clinical AI infrastructure decisions sit inside multiple overlapping regulatory regimes, each with its own controls.

FDA 21 CFR Part 11 and the October 2024 Electronic Systems Guidance

FDA 21 CFR Part 11 establishes requirements for electronic records and signatures in FDA-regulated activities. The regulation is technology-agnostic. Under 21 CFR 11.10, systems that create, modify, maintain, or transmit electronic records subject to FDA oversight must be validated to ensure accuracy and reliability; produce accurate and complete copies of records; protect records against unauthorized alteration, destruction, or loss; limit access to authorized individuals; and provide secure, computer-generated, time-stamped audit trails of user actions and data changes ^[2].

The FDA's October 2, 2024 final guidance, "Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers," is not AI-specific ^[1]. It covers electronic systems, records, and signatures across clinical investigations and addresses how Part 11 obligations apply when regulated entities use IT service providers. It specifies that sponsors should verify IT service providers can demonstrate: documented validation processes; the ability to generate accurate and complete record copies for regulatory inspection; secure and time-stamped audit trails; and access controls with documented SOPs for granting and revoking access ^[3].

A March 2026 Clinical Leader analysis of GxP IT infrastructure noted that the guidance confirms GxP validation obligations cannot be delegated to a cloud service provider ^[4]. A vendor holding SOC 2 Type II or ISO 27001 certifications has passed an information security assurance audit. Neither certification substitutes for computer system validation (CSV) under Part 11. A sponsor integrating an AI tool into a GxP workflow still needs a System Validation Report, a Traceability Matrix, and documented change control procedures specific to that system and its intended use.

Non-compliance with Part 11 data-integrity requirements can result in FDA Form 483 observations, warning letters, or product approval delays ^[5].

ICH E6(R3) and Trial Master File Documentation

For clinical-investigation records, including the Trial Master File (TMF), the governing GCP framework is ICH E6(R3), finalized by ICH in January 2025 and adopted across ICH member regions ^[6]. ICH E6(R3) specifies requirements for the management of electronically stored records, including the integrity, security, and traceability of electronic records within the TMF ^[7]. It requires that trial-related records be legible, readily available for inspection throughout the retention period, and version-controlled so that the document history is recoverable.

In the UK specifically, compliance with the ICH E6 GCP Principles (as amended from time to time), and not the entirety of the guideline, became a legal requirement on 28 April 2026 under Regulation 28 of the amended UK Clinical Trials Regulations ^[22]. This distinction matters for UK sponsors: the binding obligation is to the principles, interpreted alongside MHRA annotations and UK national law, rather than every procedural element of the full guideline.

EU GMP Annex 11 is the European framework for computerized systems in GMP manufacturing and quality activities. It overlaps with Part 11 in scope but is not a direct substitute for the clinical-trial documentation requirements of ICH E6(R3) or the EU Clinical Trials Regulation ^[8]. For tools generating TMF-relevant documents, including regulatory writing tools and eTMF-integrated AI systems, the governing clinical framework is ICH E6(R3) alongside the EU Clinical Trials Regulation 536/2014. EU CTR Article 58 requires that TMF content be archived for at least 25 years after the end of the trial, in a way that keeps it readily available and accessible to competent authorities ^[23]. The requirement that all alterations to TMF content be traceable flows from Article 58 of the Regulation read alongside ICH E6(R3) and established GCP audit-trail expectations for electronic records ^[6],[7],[23].

HIPAA and the Business Associate Agreement Chain

Under HIPAA, any cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is itself a business associate, even if it processes only encrypted data and lacks the encryption key ^[9]. This determination, issued in HHS Office for Civil Rights guidance on cloud computing, is unambiguous. Every AI vendor in the clinical data processing chain, including any subcontractors of the primary vendor, must be covered by a valid, HIPAA-compliant BAA ^[9].

The BAA obligation flows downstream. Under 45 CFR 164.308(b)(2) and 164.308(b)(3), a business associate must execute BAAs with subcontractors that create, receive, maintain, or transmit PHI on its behalf ^[10]. In practice, some AI hosting providers maintain a BAA with an upstream cloud provider (AWS, Azure, or GCP) but do not clearly document whether that chain covers every service used in a specific deployment. Procurement teams should request the full subprocessor list and verify BAA status for each entity.

BAA language should also, as a negotiated contractual control, explicitly prohibit the AI vendor from using customer PHI to train or retrain models without explicit authorization. HIPAA does not use AI-training-specific language, but appropriate BAA language can add this restriction directly. Technical verification of how the vendor separates training pipelines from inference pipelines provides more assurance than a contractual clause alone.

EU AI Act

The EU AI Act entered into force on August 1, 2024, with obligations applying on a phased timeline ^[11]. AI-based software intended for medical purposes can qualify as a high-risk system under Chapter III, subject to requirements including risk mitigation, high-quality training data documentation, technical documentation, and human oversight mechanisms. On 7 May 2026, the Council of the EU and the European Parliament reached a provisional political agreement under the Digital Omnibus on AI, extending key compliance deadlines: standalone high-risk AI systems listed in Annex III would now be subject to full high-risk obligations from 2 December 2027, and high-risk AI embedded in regulated products from 2 August 2028 ^[25]. Formal adoption of those amendments was still pending as of publication, with formal approval expected before 2 August 2026. Organizations should monitor the Official Journal of the European Union and seek legal counsel on applicability to their specific AI systems as final text becomes available.

What Multi-Tenant Architecture Means for Clinical AI Data

Regulatory frameworks set outcome requirements. They do not mandate named architectures. The procurement question for any AI vendor is whether the deployment model provides adequate controls for the specific data types and intended use in scope. Understanding what "multi-tenant" means in an AI context, and where its specific risks arise, informs that question.

Multi-tenant SaaS platforms run multiple customers' workloads on shared infrastructure. At the network and application layers, customers appear isolated. Underneath, compute nodes, memory, and in many AI platforms' inference frameworks, caches may be shared. For traditional SaaS, multi-tenancy is a well-understood risk that can be managed through logical isolation and access controls. For AI systems, it introduces an additional class of risk with no direct analog.

Wu et al. presented the PROMPTPEEK attack at NDSS 2025, the first peer-reviewed investigation of security risks specific to multi-tenant LLM serving ^[12]. They demonstrated that KV-cache sharing, a standard optimization in frameworks such as SGLang and vLLM where key-value caches are reused across requests with identical prompt prefixes, creates a timing side channel through which an adversary can reconstruct prompts from other users. The attack applies to specific serving architectures, not all multi-tenant deployments; vendors using different caching implementations or cache isolation controls are not necessarily affected. The finding matters for clinical procurement not because every multi-tenant AI is exploitable in this way, but because it illustrates that AI-specific infrastructure risks exist that standard SaaS security questionnaires were not designed to detect.

Model memorization presents a different category of concern. AI systems can retain fragments of sensitive inputs encountered during training or fine-tuning, and those fragments may surface in future outputs for different users. The 2025 industry survey underlying the Kiteworks report found that 83% of pharmaceutical organizations lacked automated technical controls preventing sensitive data, including unpublished trial results and patient records, from entering commercial AI tools ^[13]. IBM's 2025 Cost of a Data Breach Report found that 97% of AI-related breaches occurred at organizations lacking proper AI access controls, and 63% had no formal AI governance policies in place ^[14].

The HSCC's April 2026 "Health Industry Third-Party AI Risk and Supply Chain Transparency Guide," a 109-page resource produced by over 480 healthcare and life sciences organizations, identified training data leakage, adversarial inference, and model drift as AI-specific risks that traditional vendor risk management frameworks were not designed to assess ^[15]. Its seven-phase AI vendor evaluation lifecycle reflects the sector's recognition that standard software procurement checklists miss these dimensions.

Understanding VPC Architecture: What It Does and Does Not Control

A private Virtual Private Cloud provides logical network isolation for the workloads deployed within it. It is not a single technology setting; it is a network boundary enforced by cloud provider infrastructure. What a VPC controls and what it does not control are both important to understand, because the gap between the two is where AI-specific risks live.

What a VPC directly controls: network-layer routing and access. Resources inside a private VPC are not reachable from the public internet by default. Network traffic between components routes through private pathways. This eliminates a large category of external attack vectors, supports access-limitation controls at the network layer in line with 21 CFR 11.10(d), and substantially reduces the perimeter available to external adversaries.

What a VPC does not automatically control: compute tenancy, model weights, inference isolation, and vendor operational access. A private VPC deployed on shared physical hardware still uses shared compute unless dedicated tenancy is explicitly configured. The model itself, its weights and serving infrastructure, is not isolated by network controls alone. A vendor can deploy model inference on shared GPU infrastructure within a VPC boundary. Vendor engineers may retain privileged operational access to the environment for maintenance purposes depending on the deployment contract. None of these are automatically resolved by a VPC configuration; each requires a separate, verifiable control.

This distinction matters for clinical AI evaluation. A vendor stating "we deploy on VPC" without specifying the tenancy model, inference isolation approach, and vendor access policy is describing a network-layer boundary, not a complete isolation architecture. The questions that follow from "VPC yes/no" are: dedicated or shared tenancy? Separate inference endpoints per customer? Customer-managed encryption keys, and does the vendor access plaintext data during inference or through application logs? What privileged access do vendor engineers retain, and under what conditions?

Customer-managed encryption keys protect data at rest from unauthorized access to storage. They do not, on their own, prevent a vendor from accessing plaintext during active inference, through application logs, or via runtime memory, depending on the architecture. Confidential computing (trusted execution environments) can extend protection to data-in-use by performing computation in a hardware-based, attested environment where even the host operating system and cloud provider cannot read the data in memory; this is a separate, additional control from key management alone ^[16].

Private endpoints route connections between the VPC and dependent services (storage, databases, AI APIs) without traversing the public internet. AWS PrivateLink, for example, enables a VPC to communicate with services as if they were within the same private network, with no internet gateway required ^[17]. This is a meaningful network control, distinct from compute isolation.

The practical conclusion for procurement: VPC, private endpoints, dedicated tenancy, customer-managed keys, confidential computing, model-training prohibition, audit trail configuration, and CSV documentation are distinct controls. Evaluating a vendor means asking which of these exist, how they are implemented, and what evidence supports each claim.

Intended Use and Its Effect on Which Controls Apply

Not all clinical AI workloads carry the same regulatory weight, and the controls required scale with the intended use. This distinction affects both procurement scoping and validation depth.

An AI tool used for early-stage drafting assistance, where a qualified human reviews, edits, and independently verifies every output before it enters any regulated system, sits in a different risk tier than a tool whose outputs are directly saved as source records or eTMF documents. For draft-support use cases, the primary risk controls are around access, confidentiality, and the contractual prohibition on model training with proprietary data. The output itself is not a GxP record until a human converts it into one through a controlled process.

For tools whose outputs become, or directly inform, GxP records, such as AI-generated protocol language incorporated into a signed protocol, ICF content entered into an IRB-approved document, or CSR sections included in a regulatory submission, the full CSV framework applies. The system must be validated for its specific intended use, the audit trail must capture the complete provenance of the AI-generated content, and every model update must go through change control.

ICH E6(R3) Appendix C, which covers essential records for clinical trials, requires that electronic systems supporting those records maintain integrity, security, and traceability across the full retention period ^[7]. For AI tools integrated into eTMF workflows, this means the model version that generated a specific document, the inputs provided, and all subsequent human edits must be recoverable for any document in the TMF.

The Clinical Trial Data Threat Landscape

Healthcare remained the most expensive sector for data breach remediation for the fourteenth consecutive year in 2025. IBM's 2025 Cost of a Data Breach Report found the average cost of a healthcare breach was $7.42 million per incident, with an average containment time of 279 days, more than five weeks longer than the global average ^[14]. In 2024, an average of 792,226 individuals' records were affected by a healthcare data breach every day, driven substantially by the Change Healthcare ransomware attack, which affected an estimated 192.7 million individuals ^[18].

Clinical trial data occupies a specific position in this threat environment. It combines participant PHI with commercially sensitive IP representing years of R&D expenditure. Multiple parties, including sponsors, CROs, academic sites, and technology vendors, touch the data, and it flows across IT systems at each node ^[19]. Ransomware attacks on businesses within the healthcare sector, including pharmaceutical manufacturers and clinical technology vendors, increased 25% from 2024 to 2025 ^[20].

The HSCC's April 2026 guidance noted that many healthcare organizations operate with incomplete vendor inventories, and that AI-specific cybersecurity risks, including training data leakage and adversarial inference, are frequently undisclosed by vendors and not surfaced by standard procurement processes ^[15]. Third-party vendor involvement in healthcare breaches has grown significantly, making the due diligence depth applied to AI tool procurement a directly consequential security decision.

A Procurement Evidence Map

The FDA's October 2024 guidance specifies what documentation regulated entities should evaluate from IT service providers ^[3]. The following table maps each requirement to the control it addresses, the evidence artifact that supports it, and the regulatory anchor.

SOC 2 Type II and ISO 27001 appear in this table under security assurance, not regulatory compliance. They confirm that the vendor operates a documented security program and has been audited against recognized controls. When reviewing a SOC 2 Type II report, verify that the scope covers the specific product and deployment model being purchased; some vendors hold certifications for their managed cloud but not for customer-deployed or BYOC configurations. Neither certification constitutes GxP CSV documentation, which must be evaluated separately.

Not all controls apply to all use cases. The required depth of validation, audit trail configuration, and data isolation depends on the intended use of the AI tool and the regulatory jurisdictions involved. A tool used only for internal drafting assistance, with no outputs entering a regulated system directly, carries different requirements than one generating TMF-registered documents or regulatory submission content. The intended use should be defined before applying this checklist, as it determines which rows are mandatory versus advisory for a given deployment.

Vendor Questions Worth Asking Directly

Beyond documentation requests, the following questions surface architecture details that procurement questionnaires often miss:

Vendors who cannot answer these questions specifically, or who route all questions to their terms of service, are a meaningful procurement risk signal for GxP-regulated workloads.

How Kitsa Fits This Framework

Kitsa's platform is deployed on AWS VPC infrastructure. Kitsa holds SOC 2 Type II and ISO/IEC 27001 certifications and maintains HIPAA compliance documentation and executed BAAs. The certifications are publicly listed at kitsa.ai/certifications ^[24]; executed BAAs, validation documentation, and detailed architecture evidence are available to enterprise customers through the qualification process under NDA. (HIPAA does not have a government-issued certification body in the way ISO 27001 does; compliance is demonstrated through documented adherence to the Privacy and Security Rules, executed BAAs with covered entities, and readiness for HHS OCR review.)

For KScribe, Kitsa's AI-powered regulatory document generation tool, the architecture choices have direct implications for the workflows described above. Protocol text, investigator brochure content, and CSR language contain unpublished trial data; processing that data within an isolated VPC environment with private endpoints reduces the exposure surface at the network layer. The audit trail for each KScribe document is designed to capture the model version, generation timestamp, user identity, and all subsequent edits with before-and-after values, supporting Part 11 and ICH E6(R3) expectations for traceable, recoverable electronic records, depending on scope and intended use.

Organizations integrating KScribe into GxP workflows should note that vendor-supplied validation documentation supports, but does not replace, the sponsor's own CSV obligations. Sponsors must produce their own User Requirements Specification and Traceability Matrix for the specific workflow, work with Kitsa's enterprise team to obtain the system validation documentation needed to support their CSV activities, confirm BAA coverage across the deployment chain, and verify that the audit trail configuration meets their specific intended-use requirements before treating KScribe outputs as GxP records.

Key Takeaways

• •FDA, HIPAA, ICH E6(R3), and EU GMP Annex 11 are control- and outcome-based frameworks. They require validated systems, documented access controls, tamper-evident audit trails, and data confidentiality; they do not mandate any named cloud architecture. Private VPC is one appropriate control pattern for high-risk PHI and GxP AI workloads.
• •A VPC provides logical network isolation. It does not automatically provide compute isolation, inference isolation, single-tenant model weights, or zero vendor access. Each of those requires a separate, verifiable control.
• •Customer-managed encryption keys protect data at rest. They do not prevent a vendor from accessing plaintext during active inference, via application logs, or through runtime memory, depending on deployment architecture. Confidential computing addresses data-in-use protection separately.
• •GxP validation obligations cannot be delegated to a cloud provider. SOC 2 Type II and ISO 27001 are security assurance certifications; Computer System Validation documentation, including a System Validation Report and Traceability Matrix, must be evaluated separately.
• •Multi-tenant AI introduces risks, including KV-cache prompt leakage and model memorization, that standard SaaS security questionnaires were not designed to detect. NDSS 2025 peer-reviewed research demonstrated prompt reconstruction via timing side channels in specific KV-cache sharing implementations ^[12].
• •Healthcare remained the costliest sector for data breaches in 2025 at an average of $7.42 million per incident, with a containment time of 279 days, per IBM's 2025 Cost of a Data Breach Report ^[14].
• •Procurement evidence for clinical AI should include a validation package, audit trail export, BAA with subprocessor list, model training prohibition with technical verification, tenancy model documentation, and vendor access policy, in addition to security certifications.

Frequently Asked Questions

References

Related Articles