AI Infrastructure Patterns for Regulated Healthcare Systems

Introduction

Selecting an AI model is the easy part. Deploying it in a regulated healthcare environment without accumulating compliance debt is not.

Most engineering teams working in pharma and clinical research understand, in principle, that their AI systems must satisfy 21 CFR Part 11, align with HIPAA, and eventually stand up to an FDA or EMA inspection. What they underestimate is how early and how deeply infrastructure choices shape whether any of that is achievable. A model that performs well in a proof-of-concept collapses under regulatory scrutiny when the underlying architecture cannot produce complete audit trails, enforce data isolation, or survive a computer system validation (CSV) exercise. The decision points are often invisible until the audit notice arrives.

This article examines the structural patterns that separate deployable clinical AI from compliance liabilities, drawing on current regulatory guidance, accepted validation frameworks, and the architectural choices that determine whether an AI platform can operate across regulated GxP environments.

Why Infrastructure Decisions Come Before Model Decisions

In regulated clinical research, the infrastructure layer carries the evidentiary burden. Regulators are unlikely to evaluate the model in isolation; the audit extends to the system around it, including how data flows into it, what gets logged when it generates an output, how access is controlled, how changes to the model are governed, and whether any of this was validated before the system touched clinical data.

FDA's January 2025 draft guidance on AI in drug development (FDA-2024-D-4689) ^[1] introduced a seven-step credibility assessment framework for AI models used to produce "information or data intended to support regulatory decision-making" about a drug or biological product's safety, effectiveness, or quality. The guidance has a defined scope: it covers AI used in nonclinical studies, clinical trials, pharmacovigilance, and manufacturing contexts where AI outputs directly inform those determinations. FDA explicitly excludes AI used for operational efficiencies, including drafting or writing regulatory submissions, when those uses do not affect patient safety, drug quality, or the reliability of study results. For in-scope uses, the credibility framework requires sponsors to define a clear context of use, assess model risk, and document a validation plan before using AI outputs to inform a submission. That documentation requirement cannot be satisfied retroactively, and it demands infrastructure that captures model provenance, version history, training data metadata, and output lineage from the first production run.

Separately, the EMA's Reflection Paper on AI in the medicinal product lifecycle (EMA/CHMP/CVMP/83833/2023), finalized in September 2024 ^[2], is explicit that AI systems used in clinical development must satisfy the same GxP standards that govern any other regulated technology. The EMA emphasizes that a human sponsor remains fully responsible for any content or regulatory decision influenced by an AI tool, regardless of which platform generated it. That accountability requires traceable infrastructure, not just a capable model.

In January 2026, FDA and EMA jointly published ten Guiding Principles for Good AI Practice in Drug Development ^[3], the first coordinated regulatory position between the two agencies on AI. These principles are non-binding, but among the ten, data governance, lifecycle management, and clear context of use appear as clearly articulated expectations, signaling that infrastructure design has moved to the front of both agencies' thinking on responsible AI deployment.

The Regulatory Foundation Every Architecture Must Satisfy

Before describing specific infrastructure patterns, it is worth mapping the compliance obligations that any clinical AI platform will encounter, and drawing a distinction that the article returns to throughout: some frameworks are binding regulations (FDA CFR, HIPAA, EU GDPR, EU AI Act), others are finalized guidance documents (non-binding FDA and EMA guidance, ICH guidelines), and others are voluntary industry frameworks (NIST AI RMF, ISO 42001, GAMP 5) or proposed rules not yet in force. Infrastructure decisions should be grounded first in binding obligations, then in guidance documents, then in voluntary standards that have become de facto procurement expectations.

The table below summarizes which regulatory instrument applies to which category of clinical AI use:

21 CFR Part 11 and the Audit Trail Requirement

FDA's 21 CFR Part 11 ^[4] governs electronic records and electronic signatures in regulated environments. Part 11 defines electronic records broadly as any combination of text, graphics, data, audio, or other representation created, modified, or transmitted in digital form. For AI systems in GxP contexts, industry guidance (including EMA's reflection paper ^[2] and the ISPE GAMP AI Guide ^[12]) interprets this to encompass AI-specific artifacts that contribute to regulated decisions: training dataset versions, model parameter snapshots, inference logs, prompt histories for generative systems, and output revisions. This is an interpretive extension of Part 11's broad definition, not an enumerated requirement, but it reflects the evidentiary approach that GxP guidance documents, including EMA's reflection paper and the ISPE GAMP AI Guide, expect when AI systems contribute to regulated workflows.

A Part 11-compliant AI audit trail must capture who triggered the AI action, what inputs were provided, which model version was used, what output was generated, and what happened to that output afterward. The "single source of truth" design approach, where raw inputs, processed outputs, and AI-generated changes are retained in a unified repository with full processing history, supports the attributable, legible, contemporaneous, original, and accurate (ALCOA) data integrity standard that FDA's guidance on data integrity and GCP audits consistently reference ^[4],[6].

ICH E6(R3) and Technology Infrastructure

ICH E6(R3), finalized in January 2025 and adopted by the FDA in September 2025 ^[6], introduced explicitly technology-neutral language designed to accommodate electronic data collection, risk-based oversight mechanisms (including AI-assisted monitoring where it is used), and decentralized trial operations. The guideline formalizes the expectation that critical-to-quality (CtQ) data elements are identified at the design stage and that the technology systems handling them are validated accordingly. For systems that incorporate AI components, this means validation scope cannot be limited to the front-end application. It must extend to the underlying infrastructure, including the data pipeline, inference engine, access control layer, and storage system. ICH E6(R3) does not prescribe a specific AI technology standard; it sets quality and validation expectations for any computerized system used in regulated trial conduct.

HIPAA and the Business Associate Framework

Under HIPAA, an AI platform that processes protected health information (PHI) on behalf of a covered entity operates as a business associate and must execute a Business Associate Agreement (BAA) ^[7]. Not every clinical AI tool automatically touches PHI; the obligation depends on what the platform processes and whether it does so on behalf of a covered entity. Where PHI is involved, the HIPAA Security Rule requires administrative, physical, and technical safeguards, which extend to any AI inference pipeline that handles PHI even if the model's final output does not reference it directly. HHS published a Notice of Proposed Rulemaking (NPRM) on January 6, 2025 (Federal Register Docket 2024-30983) ^[8], proposing significant updates to the Security Rule that include mandatory vulnerability scanning at least every six months and penetration testing at least once annually. As of June 2026, this remains a proposed rule under regulatory review and has not yet been finalized; the existing Security Rule continues to govern compliance.

Core Infrastructure Patterns for Regulated AI Deployment

Pattern 1: Private Deployment and Tenant Isolation

The most consequential architectural decision for regulated clinical AI is whether the platform operates in a shared or isolated environment. Multi-tenant SaaS deployments, where multiple sponsors or sites share the same application instance and underlying database, introduce cross-tenant data risks that are difficult to fully control through software-level isolation alone. A 2024-disclosed PostgreSQL vulnerability (CVE-2024-10976) ^[9] demonstrated that row-level security policies could be bypassed when query plans are reused across role changes within a session, meaning one tenant's query could return rows belonging to another under certain conditions. This illustrates that database-level isolation through row-level security alone, without additional middleware enforcement and session-management controls, carries material risk.

Single-tenant or private cloud architectures, by contrast, provide dedicated infrastructure per organization. Each sponsor gets a separate application instance, isolated database, and in many cases a separate Virtual Private Cloud (VPC). No PHI or trial data shares infrastructure with another customer. This significantly reduces cross-tenant data exposure risks and simplifies the compliance boundary, because the data processor can demonstrate clearer ownership and control of the environment in which PHI is handled. It does not eliminate all misconfiguration or supply-chain risks, but it removes the class of shared-infrastructure vulnerabilities that multi-tenant designs carry by default.

For clinical AI platforms specifically, the private VPC pattern supports 21 CFR Part 11's treatment of closed versus open systems. Under Part 11, a closed system is one controlled by persons responsible for the content of the electronic records on it ^[4],[5]. A regulated company hosting within a private VPC, where access is controlled exclusively by that firm, may satisfy that closed-system definition, while a fully externally managed multi-tenant service may require additional open-system safeguards such as encryption and digital signature controls. The regulated company remains accountable for meeting Part 11 requirements regardless of cloud provider.

Pattern 2: Validation-First Design

GAMP 5 (Good Automated Manufacturing Practice), published by the International Society for Pharmaceutical Engineering (ISPE) and widely referenced by FDA and EMA in their regulatory training and guidance ^[11], provides the industry standard framework for risk-based computerized system validation across GxP environments including GCP, GMP, and GLP. ISPE published the Second Edition of GAMP 5 in July 2022, and in July 2025 followed it with a standalone GAMP AI Guide covering validation and lifecycle management specifically for AI systems in GxP environments ^[12]. For clinical trial sponsors and CROs, GAMP 5 combined with the GAMP AI Guide is widely applied as the industry standard framework for software systems managing clinical data, regulatory documents, and trial operations, though it is industry practice rather than a regulatory mandate.

It is worth distinguishing a parallel validation framework: FDA finalized its Computer Software Assurance (CSA) guidance in September 2025 (Docket FDA-2022-D-0795, updated February 2026) ^[13], providing a risk-based approach to assurance for computers and automated data processing systems used in medical device production and quality management systems under 21 CFR Part 820. CSA applies to device manufacturers' production environments; it does not directly govern clinical trial software under GCP, though its risk-proportionate philosophy, where validation effort scales to the criticality of the system function, is consistent with GAMP 5 principles and widely applied across regulated computing contexts. For clinical AI tools generating regulatory document content or influencing patient eligibility decisions, the validation scope is correspondingly broad and should include installation qualification, operational qualification, and performance qualification documentation, with separate protocols for the AI model layer and the infrastructure layer.

AI systems that adapt post-deployment, such as models fine-tuned on new data or RAG pipelines pulling from evolving document corpora, require a change control process that treats each substantive model update as a regulated change event. In the medical device space, FDA finalized guidance on Predetermined Change Control Plans (PCCPs) for AI-enabled device software functions in August 2025 ^[14]. While PCCP applies to the device pathway, it illustrates a regulatory expectation of proactive lifecycle governance that sponsors and platform vendors in clinical operations should apply by analogy: document planned changes before they occur, assess their impact on validated system behavior, and maintain traceable version history across the model lifecycle.

Pattern 3: Certification Stacking for Enterprise Trust

No single certification satisfies the full compliance surface of a regulated clinical AI platform. Enterprise buyers in pharma and clinical research expect a layered certification portfolio, and while no regulation mandates a specific combination, procurement teams at large sponsors and CROs routinely require documented evidence of these controls before approving vendor onboarding.

The most commonly expected certifications in clinical research procurements are: SOC 2 Type II (covering security, availability, processing integrity, confidentiality, and privacy controls over a 12-month observation period); HIPAA compliance with BAA availability for any platform handling PHI; and ISO 27001:2022 certification of the information security management system. SOC 2 and ISO 27001 overlap by roughly 60 to 70 percent in their control requirements (a commercial market estimate ^[15], not a regulatory standard), but ISO 27001 carries more weight in European procurement contexts, particularly because EMA's drug development framework expects AI systems to satisfy EU legislative requirements including GDPR and applicable information security standards ^[2].

For platforms handling clinical trial data governed by 21 CFR Part 11, additional attestation through AWS GovCloud or AWS VPC configuration documentation, demonstrating that the cloud infrastructure meets the closed-system criteria, adds regulatory defensibility. eClinical Solutions, for example, added ISO 27001:2022 and ISO 27701:2019 certifications alongside its existing SOC 2 Type II compliance specifically to address the growing complexity of privacy law and clinical technology data management requirements ^[16].

ISO 42001, the AI management system standard published in 2023, is emerging as a differentiator for platforms that need to demonstrate responsible AI governance to regulators. The NIST AI RMF 1.0, launched in 2023 and expanded through 2024 and 2025 companion playbooks ^[17], maps closely to ISO 42001 and provides a voluntary but authoritative framework for governing AI risk across the identify, measure, manage, and govern functions. NIST released a Generative AI Profile (NIST-AI-600-1) in July 2024 ^[18], specifically addressing twelve risk categories for generative AI including hallucinations, data privacy, and confabulation, and released a concept note in April 2026 for an AI RMF Profile tailored to critical infrastructure, a category that clinical research infrastructure may increasingly fall under.

A 2025 Censinet survey of hospital organizations found that only 12 percent reported having a formal AI governance framework in place ^[19], a figure that suggests the majority of healthcare institutions running AI tools have not yet built the institutional controls that FDA and EMA guidance increasingly treats as expected for responsible deployment. That gap has practical consequences: it makes onboarding more difficult for vendors who need to demonstrate a governance posture, and creates due diligence exposure for sponsors selecting platform partners.

Pattern 4: Data Residency and Cross-Border Controls

Clinical trials increasingly span multiple jurisdictions, and the AI infrastructure that supports them must handle data obligations that differ materially between the United States and the European Union. GDPR imposes several obligations relevant to clinical AI platforms handling EU participant data: Chapter V (Articles 44-46) governs international data transfers, requiring that personal data processed outside the EU remain subject to adequate protections; Article 5(1)(e) limits data retention to what is necessary for the specified purpose; and Article 17 establishes the right to erasure. These are distinct provisions within the same regulation ^[10]. Together they create infrastructure requirements: transfer and processing-boundary controls at the inference layer, configurable retention enforcement, and erasure workflows, all going beyond what HIPAA, SOC 2, or ISO 27001 address on their own.

The practical design requirement is that transfer and processing-boundary controls extend to the inference layer, not just the storage layer.

An AI model hosted in an EU data center that calls an external API for language model inference may be routing PHI or pseudonymized trial data through infrastructure outside the defined compliance boundary. Private deployment models that host all inference within the sponsor's or platform's controlled VPC close this gap by ensuring no data leaves the defined security perimeter during processing.

Pattern 5: AI-Specific Audit Trail Architecture

Standard application audit trails designed for human user actions are not sufficient for AI-generated content in regulated settings.

When an AI system produces a clinical document, analyzes a dataset, or generates a recommendation, the audit trail must capture not only who reviewed or approved the output, but also the model version, input context, inference parameters, and any human edits made between generation and submission.

EMA's reflection paper ^[2] emphasizes that AI introduces a new category of electronic records, including generation logs, training dataset versions, model parameter snapshots, and performance monitoring data, all of which must be managed as GxP records. The ISPE GAMP AI Guide ^[12] provides specific guidance on how these records should be structured, retained, and made available for regulatory inspection.

From a technical architecture standpoint, clinical AI platforms need write-once or tamper-evident logging for all inference events, separate from the application's general activity log. If a model drafts a clinical summary report, the audit record should be sufficient to reconstruct what version of the model generated the initial draft, what inputs it received, and how the output changed between generation and final submission. This aligns with Part 11's predicate-record logic: every electronic record that contributes to a regulated submission must be attributable, legible, and retrievable on demand ^[4],[5]. Storage and retrieval systems for these records must satisfy the retention requirements set by applicable regulatory requirements in each jurisdiction. Notably, ICH E6(R3) removed its previous universal retention timeframe; Section 2.12.12 of the finalized guideline instead requires records to be held "in accordance with applicable regulatory requirements," which vary by region ^[6]. The EU, for example, mandates at least 25 years retention for clinical trial master file content after the end of the trial under Regulation (EU) No 536/2014, Article 58 ^[22],[24]. Sponsors should consult jurisdiction-specific requirements rather than assuming a single global standard.

Regulatory and Documentation Considerations

The documentation burden for compliant AI infrastructure is substantial and underestimated by most teams adopting AI for the first time in a regulated context. Beyond validation protocols and audit trail configurations, platforms must maintain model cards or equivalent documentation describing training data, performance metrics, known limitations, and the specific contexts of use for which the model has been validated.

FDA's seven-step credibility framework ^[1] requires sponsors to specify the AI model's role, the population and context to which its outputs apply, the risk level of that context, and the evidence gathered during validation to establish credibility. That evidence package must be updated when the model changes. This is a materially different documentation model than traditional software validation, where a validated system remains validated until a change event triggers re-qualification. AI systems may drift in performance even without explicit model updates, due to changes in input data distributions or retrieval corpora, and platforms that cannot detect and document such drift will struggle to demonstrate continued qualification.

The European Commission's draft EU GMP Annex 22 on AI, published for stakeholder consultation in July 2025 alongside revised Annex 11 ^[21], applies to computerized systems in the manufacturing of medicinal products where AI models are used in critical applications with direct impact on patient safety, product quality, or data integrity. Following public consultation, the draft received approximately 1,300 comments and was undergoing revision as of early 2026; according to February 2026 EMA meeting notes, the final text was expected by the end of 2026 ^[23]. Annex 22 explicitly excludes generative AI and LLMs from its current scope, applying instead to static deterministic models. While it covers manufacturing directly rather than clinical operations, it signals the direction of regulatory thinking: AI-enabled systems in the GMP context are to be treated as controlled assets with the same evidentiary expectations as any GMP-critical software.

AI and Automation in Practice

The regulatory guidance described above does not prohibit AI in clinical research; it describes what responsible deployment looks like. Several practical infrastructure choices make compliance achievable without sacrificing operational efficiency.

Model version control, analogous to source code version control but extended to include training data snapshots and evaluation metrics, provides the foundation for a defensible change control process. Platforms that treat model versions as immutable, tagged artifacts and require a documented change event before any production model is replaced can demonstrate continuous qualification even as underlying capabilities improve.

Human-in-the-loop review workflows, where AI-generated outputs pass through a defined approval step before entering the clinical record, satisfy the EMA's position that sponsors retain full responsibility for AI-influenced decisions ^[2] while preserving the efficiency benefit of AI generation. The audit trail captures both the AI output and the reviewer's approval action, providing the complete lineage regulators require.

Retrieval-augmented generation (RAG) systems that ground model outputs in validated document corpora, rather than relying solely on pretrained model weights, present a more defensible profile for regulatory content generation because the information source is explicit, version-controlled, and auditable. That said, RAG pipelines introduce their own validation requirements: the retrieval index, document corpus, and similarity scoring mechanism are all components that can affect output quality and must be qualified accordingly.

How Kitsa Fits Into This Problem

Kitsa's platform was built with regulated clinical research as the design constraint, not a retrofit target. Kitsa states the platform holds SOC 2 Type II, HIPAA, and ISO/IEC 27001:2022 certifications ^[20]. KScribe, Kitsa's AI regulatory document generation system, is designed to produce Protocols, ICFs, IBs, DSURs, and CSRs within an architecture Kitsa describes as built for GxP audit lineage; sponsors evaluating the platform should request Kitsa's security documentation for current implementation details.

Key Takeaways

• Infrastructure architecture determines compliance feasibility before a single model decision is made. Audit trails, data isolation, and validation scope must be designed in from the start.
• FDA's January 2025 draft guidance (FDA-2024-D-4689) requires a seven-step credibility assessment framework for AI used in regulatory decision-making about safety, efficacy, or quality; it does not cover all clinical AI uses, but the infrastructure it demands, including model provenance tracking and output lineage, represents best practice for any GxP deployment.
• The FDA-EMA joint principles published January 14, 2026, signal that lifecycle management, data governance, and clear context of use are emerging expectations for AI used in drug development, and are intended to underpin future guidance and international harmonization across both agencies.
• ICH E6(R3), finalized January 2025 and FDA-adopted September 2025, requires that technology systems handling critical-to-quality data be validated, including computerized systems that incorporate AI where it is used in regulated trial conduct.
• Single-tenant or private VPC deployments significantly reduce cross-tenant data exposure risks that multi-tenant architectures cannot fully address through software-layer isolation alone; they do not eliminate all risk but remove a structurally different class of shared-infrastructure vulnerability.
• Compliant clinical AI audit trails must capture model version, input context, inference parameters, and human review actions, not only standard application access events.
• SOC 2 Type II, HIPAA BAA, and ISO 27001 are the most commonly expected certifications in enterprise clinical research procurements for AI platforms; ISO 42001 and NIST AI RMF alignment are becoming differentiators in regulated vendor evaluations. These are procurement expectations, not direct regulatory requirements.

FAQ

References

1. [1]U.S. Food and Drug Administration. "Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products; Draft Guidance for Industry." Docket FDA-2024-D-4689. January 7, 2025. https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug
2. [2]European Medicines Agency. "Reflection Paper on the Use of Artificial Intelligence (AI) in the Medicinal Product Lifecycle." EMA/CHMP/CVMP/83833/2023. September 9, 2024. https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline
3. [3]U.S. Food and Drug Administration and European Medicines Agency. "Guiding Principles of Good AI Practice in Drug Development." January 14, 2026. https://www.ema.europa.eu/en/news/ema-fda-set-common-principles-ai-medicine-development-0
4. [4]U.S. Food and Drug Administration. "21 CFR Part 11: Electronic Records; Electronic Signatures." Code of Federal Regulations Title 21, Part 11. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
5. [5]U.S. Food and Drug Administration. "Guidance for Industry: Part 11, Electronic Records; Electronic Signatures: Scope and Application." August 2003. https://www.fda.gov/media/75414/download
6. [6]ICH / U.S. Food and Drug Administration. "E6(R3) Good Clinical Practice Guidance for Industry." Finalized ICH January 6, 2025; FDA adoption September 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/e6r3-good-clinical-practice-gcp
7. [7]U.S. Department of Health and Human Services, Office for Civil Rights. "HIPAA Security Rule." 45 CFR Parts 160 and 164. https://www.hhs.gov/hipaa/for-professionals/security/index.html
8. [8]U.S. Department of Health and Human Services, Office for Civil Rights. "HIPAA Security Rule Notice of Proposed Rulemaking (NPRM): Strengthening Cybersecurity of Electronic Protected Health Information." Federal Register, January 6, 2025. Docket 2024-30983. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html
9. [9]National Vulnerability Database. "CVE-2024-10976: PostgreSQL Row Security Policy Re-Use Across Commands." NIST NVD. https://nvd.nist.gov/vuln/detail/CVE-2024-10976
10. [10]European Union. "General Data Protection Regulation (GDPR), Regulation (EU) 2016/679." Chapter V, Articles 44-46 (international transfers); Article 5(1)(e) (storage limitation); Article 17 (right to erasure). https://gdpr-info.eu/
11. [11]International Society for Pharmaceutical Engineering. "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition." ISPE, July 2022. https://ispe.org/publications/guidance-documents/gamp-5-guide
12. [12]International Society for Pharmaceutical Engineering. "New GAMP Guide Addresses Challenges Posed by AI-Enabled Computerized Systems." ISPE Pharmaceutical Engineering, July 2025. https://ispe.org/pharmaceutical-engineering/ispeak/new-gampr-guide-addresses-challenges-posed-ai-enabled
13. [13]U.S. Food and Drug Administration. "Computer Software Assurance for Production and Quality System Software." Guidance for Industry and FDA Staff. Docket FDA-2022-D-0795. Final September 24, 2025; updated February 3, 2026. Note: applies to medical device production/QMS software under 21 CFR Part 820, not directly to clinical trial software under GCP. https://www.federalregister.gov/documents/2025/09/24/2025-18468/computer-software-assurance-for-production-and-quality-system-software-guidance-for-industry-and
14. [14]U.S. Food and Drug Administration. "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions." Final Guidance. August 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence
15. [15]Comp AI. "SOC 2 for AI Companies: Complete Guide 2025." December 2025. Referenced for comparative framework overlap data; not a regulatory source. https://www.trycomp.ai/hub/soc-2-for-ai-companies
16. [16]eClinical Solutions. "eClinical Solutions Doubles Down on Data Security, Privacy with New ISO Certifications." Business Wire, November 14, 2023. https://www.businesswire.com/news/home/20231114225276/en/eClinical-Solutions-Doubles-Down-on-Data-Security-Privacy-with-New-ISO-Certifications
17. [17]NIST. "AI Risk Management Framework 1.0 and Companion Resources." National Institute of Standards and Technology, 2023-2026. https://www.nist.gov/itl/ai-risk-management-framework
18. [18]NIST. "NIST-AI-600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." July 26, 2024. https://airc.nist.gov/
19. [19]Censinet. "NIST AI RMF Adoption Still Nascent: Just 12% of Hospitals Have a Formal AI Governance Framework." December 2025. https://www.censinet.com/perspectives/nist-ai-rmf-adoption-hospitals-governance-framework
20. [20]Kitsa. "SOC 2, HIPAA and ISO 27001 Certifications." kitsa.ai/certifications. Lists SOC 2 Type II, HIPAA, and ISO/IEC 27001:2022 as current certifications. https://kitsa.ai/certifications
21. [21]European Commission / EMA GMDP Inspectors Working Group. "EU GMP Annex 22: Artificial Intelligence (Draft for Stakeholder Consultation)." July 2025. https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en
22. [22]European Parliament and Council. "Regulation (EU) No 536/2014 on Clinical Trials on Medicinal Products for Human Use." Article 58: Clinical Trial Master File Retention. April 16, 2014. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014R0536
23. [23]European Medicines Agency. "Summary Notes of the HMA-EMA Group Focused on AI with Industry Stakeholders Meeting, 4 February 2026." EMA/40804/2026. https://www.ema.europa.eu/en/documents/minutes/summary-notes-meeting-hma-ema-group-focused-ai-industry-stakeholders-february-2026_en.pdf
24. [24]European Medicines Agency. "Guideline on the Content, Management and Archiving of the Clinical Trial Master File (Paper and/or Electronic)." https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-content-management-and-archiving-clinical-trial-master-file-paper-andor-electronic_en.pdf