9 Questions Sponsors Must Ask Before Buying AI Regulatory Software

The FDA and EMA issued their joint guiding principles for AI in drug development in January 2026 ^[1]. For sponsors evaluating AI regulatory software, the publication added a second layer of questions to procurement conversations that had previously focused on speed and output quality: validation, model governance, audit trail architecture, data custody, hallucination controls. For vendors without clear answers, the 10-principle framework was uncomfortable reading. For sponsors who had already purchased a platform on the basis of a demo, it raised questions worth revisiting.

Buying AI regulatory software is not the same as buying an EDC system or an eTMF. Those platforms manage and store information generated by humans. AI regulatory tools generate information themselves, producing protocol drafts, informed consent forms, investigator brochures, DSURs, and clinical study reports that may eventually reach a regulatory agency. That distinction creates a compliance exposure that extends beyond the software itself, back to the sponsor who relied on it. Under ICH E6(R3), finalized at Step 4 in January 2025 and adopted by the FDA in September 2025 ^[2], ultimate responsibility for trial conduct remains with the sponsor even when activities are delegated to vendors or third-party platforms.

The nine questions below are not a checklist for a procurement manager. They are the questions a qualified person, a regulatory affairs director, or a clinical quality lead should be asking before a contract is signed.

Why Sponsor Accountability Makes Vendor Choice a Quality Decision

The framing matters before getting to the questions. Sponsors routinely delegate documentation-intensive activities to CROs, medical writing agencies, and software platforms. ICH E6(R3) addresses the accountability structure in its sponsor responsibilities section: while sponsors may transfer or delegate duties, that transfer does not remove the sponsor's overall responsibility for trial quality and integrity ^[2]. Every system classified as critical in a vendor management plan must have documented oversight. E6(R3)'s existing requirements on data governance, audit trails, computerized system validation, and service-provider oversight collectively create a framework within which AI-supported documentation workflows would reasonably fall, even though E6(R3) does not regulate AI regulatory writing tools by name ^[3].

A framing note applies throughout this article: there is a meaningful difference between a binding regulatory requirement, a non-binding FDA or EMA guidance recommendation, an industry good-practice standard, and a vendor-selection criterion. The questions below draw on all four. Where a specific claim derives from draft guidance or non-binding principles rather than a regulation or finalized guidance, that distinction is noted.

This has direct implications for AI regulatory software. If a KScribe-generated protocol section contains an error that reaches an IND, the sponsor owns that error, not the vendor. If an AI-drafted ICF omits a required risk disclosure because the underlying model misunderstood a therapeutic area, the sponsor carries the regulatory consequence. That accountability structure is why vendor qualification for AI platforms is not a formality. It is a mechanism for managing documented, foreseeable risk.

The EMA notice on validation and qualification of computerised systems used in clinical trials put the position plainly: sponsors must be able to provide GCP inspectors with access to qualification and validation documentation for all systems used in trial conduct, regardless of who performed those activities ^[4]. Relying on a vendor's qualification documentation is permitted, but only when the sponsor has assessed it as adequate.

Question 1: What Does the Validation Package Look Like, and Does It Cover AI-Specific Risks?

Traditional computer system validation (CSV), governed by FDA 21 CFR Part 11 ^[5] and structured through the GAMP 5 framework ^[6], addresses how a system performs what it is designed to do. For deterministic software, validation is relatively tractable: define inputs, specify expected outputs, test systematically. For AI-based systems, the challenge is categorically different. LLMs do not produce identical outputs from identical inputs. Their behavior can shift with model updates, prompt changes, or new training data.

GAMP 5 (Second Edition, 2022) provides a software categorization framework used to calibrate validation effort to risk. Custom or highly configurable AI applications may be assessed against Category 5 criteria under that framework, depending on their degree of customization, where documentation requirements are highest and user-side validation effort is most intensive ^[6]. The ISPE GAMP AI Guide (July 2025), which covers AI system categorization, lifecycle validation, and change-control expectations in its core chapters on AI system development and qualification, is the appropriate reference for determining how a given AI platform should be categorized and validated ^[12]. Sponsors should ask vendors to identify which GAMP category their platform falls into and to provide the corresponding validation documentation, including the validation master plan, AI-specific risk assessment methodology, and their approach to testing non-deterministic outputs.

Practically, a qualifying vendor should be able to demonstrate user acceptance testing (UAT) protocols that cover hallucination scenarios, citation generation accuracy, template compliance, and cross-document consistency across document types. Where a vendor cannot produce this documentation, the sponsor will need to generate it independently, which is permitted under EMA guidance ^[4] but substantially increases the sponsor's own compliance burden.

The FDA's Computer Software Assurance (CSA) guidance, most recently issued on February 3, 2026 (superseding a September 24, 2025 version), formalizes a risk-based, critical-thinking approach to software assurance for production and quality management system software ^[7]. Although the CSA guidance was issued by CDRH and CBER and addresses device manufacturing contexts specifically, its core principle, that assurance effort should be proportional to intended use and risk rather than exhaustive scripted testing, reflects a broader FDA validation philosophy applicable across regulated software categories. For AI regulatory writing tools, that philosophy still implies substantial assurance effort, particularly around outputs that could directly influence regulatory submissions.

Question 2: How Does the System Handle Hallucinations, and What Controls Exist?

Research evaluating LLM performance in regulatory and clinical contexts identifies hallucination as a consistent risk. A peer-reviewed study in npj Digital Medicine found that LLMs require careful validation in regulatory science contexts because error modes, including hallucinations, may not be self-evident to reviewers, even on structured extraction tasks ^[8]. That study focused on medical device regulatory documents; by analogy, similar validation concerns apply wherever LLMs are used to generate or analyze regulated content.

The FDA's own experience with Elsa, its internal AI review assistant, underscores the risk. Applied Clinical Trials reported that Elsa experienced accuracy problems including false citations and data hallucinations during early deployment, preventing its use in formal regulatory assessments ^[9].

Sponsors should ask vendors three specific questions about hallucination risk. First, what retrieval or grounding mechanism does the system use to anchor generated content to a defined source corpus? A vendor relying on a general-purpose foundation model without domain-specific grounding has a materially higher hallucination rate than one using retrieval-augmented generation (RAG) over validated regulatory and clinical document libraries. Second, what human review step is built into the workflow before output is accepted into the sponsor's document system? FDA's January 2025 draft guidance on AI supporting regulatory decision-making addresses human involvement through a credibility assessment framework that covers context of use, model risk, and human-AI team evaluation where applicable ^[10]. Third, does the system produce any confidence scoring or uncertainty flagging that signals to the reviewer which outputs warrant closer scrutiny?

An AI regulatory writing platform that presents outputs without provenance indicators, without grounding references, and without structured human review workflows is poorly suited to regulated use, regardless of how well the demo documents read.

Question 3: Is There a Complete, Submission-Ready Audit Trail for Every AI-Generated Output?

21 CFR Part 11 requires audit trails that record what changed, when it changed, and who made the change, with sufficient detail to reconstruct the history of an electronic record ^[5]. Part 11 Subpart B (Section 11.10) specifies that systems subject to the regulation must include validation, audit trails, operational controls, and access management as core technical controls ^[5]. For AI-generated regulatory documents, the audit trail requirement logically extends beyond user edits to the generation event itself: which model version produced the output, which prompt or input data was used, and when. Part 11 does not address AI model versioning by name, but the requirement to create accurate and complete records of all system activity that creates, modifies, or deletes electronic records ^[5] provides the basis for this interpretation.

ICH E6(R3) addresses data governance and audit requirements in its data oversight provisions, requiring that the review of trial data, including audit trails, be a planned activity, with procedures documented and the scope proportional to risk ^[2]. These provisions support the view that a clinical AI platform generating regulatory content should record the model version, generation timestamp, input parameters, and subsequent review actions. A platform that cannot demonstrate this level of traceability may not satisfy data governance expectations under E6(R3) and Part 11 as applied to AI-generated records.

Sponsors should request a demonstration of the audit trail specifically for an AI generation event, not just for a user edit.

The record should capture: (a) the identity of the user who initiated the generation; (b) the model version and prompt configuration in use at that moment; (c) the timestamp; (d) the identity of the reviewer who accepted or modified the output; and (e) any version history of subsequent edits. A vendor whose audit trail begins only after the AI output lands in a text editor may not satisfy the traceability expectations associated with Part 11 and E6(R3) data governance requirements as they are reasonably applied to AI-generated records.

For submissions to the FDA or EMA, the ability to reconstruct the provenance of a document section from an AI tool is a reasonable inspection expectation. It is the kind of documentation GCP inspectors would likely ask for when the platform appears in the computerized systems inventory for a trial.

Question 4: How Does the Platform Maintain Consistency Across Document Sets?

One of the persistent failure modes in regulatory documentation is cross-document inconsistency: an eligibility criterion stated in the protocol that does not match the screening criteria in the ICF; a dosing schedule in the investigator brochure that differs from the one in the DSUR; a safety signal described differently in the IB versus the CSR. These inconsistencies create inspection findings, generate queries during regulatory review, and in the worst cases, create data integrity questions that delay approval.

A 2025 preprint on human-AI collaboration in regulatory writing, co-authored by researchers from Weave Platform and Takeda Pharmaceuticals, identified consistency as one of seven core quality dimensions for AI-generated regulatory content, alongside accuracy, completeness, clarity, and appropriate emphasis ^[11]. The authors found that AI-generated documents evaluated against a 0-3 regulatory compliance scale showed variable performance on consistency specifically, because LLMs do not inherently carry state across document generation sessions. Readers should note that this is a preprint with vendor involvement and has not been independently peer-reviewed.

For a sponsor generating a protocol, ICF, and IB using an AI platform, the relevant question is whether the system maintains a shared data model that propagates agreed parameters across all documents in a development program. A platform where each document is generated independently, without reference to a shared protocol backbone, will reproduce cross-document inconsistencies at scale, which may be worse than the inconsistencies it was supposed to solve.

Kitsa's KScribe is designed around this problem: regulatory documents are generated from a structured clinical intelligence layer that holds a single version of the trial's operational parameters, so that a protocol amendment propagates consistently through dependent documents rather than requiring manual reconciliation across each one. Sponsors evaluating any AI regulatory writing tool should ask the vendor to demonstrate how a change to a key eligibility criterion propagates, or fails to propagate, across a complete document set.

Question 5: Where Is Your Data Hosted, Who Owns It, and What Are Your Security Certifications?

Clinical trial data includes information that is simultaneously protected health information under HIPAA, commercially sensitive under confidentiality agreements, and GCP-regulated under ICH E6(R3). Uploading unpublished trial data, patient narratives, or draft regulatory submissions to a third-party AI platform creates data governance obligations that many sponsors have not yet formalized.

The joint FDA-EMA AI guiding principles published in January 2026 identify data governance, document management, and cybersecurity as a unified principle area, noting that drug developers should maintain traceable records on data sources used to train AI models and the steps taken to process data ^[1]. This has a direct implication for vendors who train on customer data: sponsors should ask explicitly whether submitted documents are used to fine-tune or update the AI model, and what data isolation controls prevent one customer's confidential information from influencing outputs generated for another.

As a baseline of good practice, sponsors should expect vendors to hold a HIPAA Business Associate Agreement (BAA), SOC2 Type II certification, and a clear statement of data residency. ISO 27001 certification provides additional assurance around information security management. None of these are explicitly mandated by Part 11 or ICH E6(R3) as a named certification requirement, but they represent an industry-standard expectation for vendors handling sensitive clinical trial data in regulated environments. For submissions to the EMA or EU competent authorities, data residency within the EEA or contractual safeguards under GDPR Standard Contractual Clauses should be addressed in the vendor agreement.

The architecture itself matters. A platform hosted in a shared public cloud with multi-tenant model serving presents different risks than one deployed within a customer's own Virtual Private Cloud environment. The latter allows sponsors to satisfy ICH E6(R3)'s requirement to maintain systems inventories and ensure audit access ^[2] without relying on a vendor's willingness to cooperate in the event of a dispute or insolvency.

Question 6: What Human-in-the-Loop Workflows Does the Platform Enforce?

FDA's January 2025 draft guidance on AI supporting regulatory decision-making addresses human involvement in AI workflows in the context of a "human-AI team" approach, where human judgment is involved in evaluating AI outputs that contribute to regulatory submissions ^[10]. The FDA-EMA joint principles reiterate human-centric design as the first of ten guiding expectations ^[1]. These are non-binding documents at this stage, but they reflect consistent agency thinking and the direction in which expectations are developing. Treating human review as a genuine structural step in the workflow, rather than a nominal one, is the appropriate industry response to that trajectory.

The practical question for sponsors is whether the AI regulatory software enforces this accountability structurally, through configured workflows, or leaves it to the discretion of individual users. A platform that generates a protocol draft and places it directly in an editable document without a mandatory qualified medical writer review step provides no compliance assurance. The audit trail may record that a user opened the document, but it cannot guarantee that a suitably qualified person reviewed the AI-generated content before it was accepted.

Effective human-in-the-loop architecture for regulated AI includes: (a) defined review roles with minimum qualification criteria; (b) structured review checkpoints that must be completed before document status advances; (c) an electronic signature step tied to a specific review declaration; and (d) the ability to revert to prior AI-generated versions and document the reason for any rejection. Sponsors should ask vendors to walk through the workflow for a protocol section that the reviewer rejects. If the system has no structured rejection workflow, it has not been designed for regulated use.

ICH E6(R3)'s emphasis on data governance as a shared domain between sponsor and investigator ^[2] extends naturally to sponsor-vendor relationships in AI regulatory writing. The sponsor's quality agreement with the vendor should specify which review steps are mandatory, how review completion is recorded, and how the sponsor exercises oversight over the AI component itself, not just the final document.

Question 7: What Is the Vendor's Change Control and Model Versioning Process?

Traditional software change control is well-understood in pharma: changes are documented, tested, and released under a formal change management process. For AI regulatory writing platforms, change control has a more complex dimension: the AI model itself can change, and changes to a model may alter outputs in ways that are not immediately visible to end users.

Under GAMP 5 principles, changes that may affect system behavior trigger re-validation activities proportional to the scope of the change ^[6]. The ISPE GAMP AI Guide extends this to AI model updates in its AI lifecycle and change-management sections, noting that changes to a model can alter system behavior in ways not immediately visible through traditional change-detection methods ^[12]. A vendor that pushes model updates automatically, without sponsor notification and without re-testing documentation, would raise a GCP-compatible change-control concern. Sponsors should ask: how are model version changes communicated to customers? Is there a formal change notification and re-qualification process? Can the sponsor pin a specific model version for an ongoing trial to ensure that the document set for a given study is generated under consistent conditions?

This last point is particularly relevant for long-duration Phase III programs. A CSR that is drafted 24 months after the protocol was generated may use a different model version if the vendor has updated its platform in the interim. The resulting documents may be internally consistent, or they may not be, and without documented model versioning, neither the sponsor nor an inspector can determine which version of the model produced which output.

The FDA's draft guidance on AI credibility assessment for regulatory decision-making (FDA-2024-D-4689, January 2025) emphasizes a risk-based credibility framework that includes model performance documentation and context of use specifications ^[10]. A vendor whose model versioning documentation cannot support this level of credibility assessment for a sponsor's IND or NDA submission presents a qualification gap that the sponsor will need to close.

Question 8: How Does the Platform Align with the FDA-EMA Joint AI Guiding Principles?

The January 2026 FDA-EMA joint principles are non-binding, but they represent the first coordinated international framework of this kind and state explicitly that they are intended to "lay the foundation for developing good practice" and to inform future regulatory guidance and policy in both jurisdictions ^[1]. The agencies frame the principles as a basis for future guidance development, standards work, and international harmonization, not as an immediate inspection checklist. Sponsors buying AI regulatory software today should nonetheless expect these principles to influence how agency expectations evolve in the next regulatory cycle, and should ask vendors where they stand against them now.

The ten principles are: human-centric by design; risk-based approach; adherence to standards; clear context of use; multidisciplinary expertise; data governance and documentation; model design and development practices; risk-based performance assessment; life cycle management; and clear, essential information ^[1].

For a regulatory writing platform, the principles with most immediate operational relevance are risk-based performance assessment (Principle 8), life cycle management (Principle 9), and clear, essential information (Principle 10). Principle 8 asks whether the validation methodology evaluates the complete system, including human-AI interactions, using data and metrics appropriate for the context of use. Principle 9 asks whether a quality management system governs the AI lifecycle, including scheduled monitoring and re-evaluation for issues such as data drift. Principle 10 asks whether users and sponsors can access clear, accessible information about the system's purpose, performance, limitations, and data sources. A vendor that cannot answer these questions concretely has not engaged with the framework the FDA and EMA have built around responsible AI in drug development.

Sponsors should ask vendors specifically: have you mapped your product documentation against these ten principles? If so, can you provide that mapping? If not, why not? The answer will reveal more about a vendor's regulatory sophistication than any product demonstration.

Question 9: What Does Implementation Look Like, and What Happens When the Vendor Is Audited?

Procurement conversations focus on features and pricing. Quality and compliance conversations should focus on what happens at the edges: during implementation, when something goes wrong, and when an inspector arrives. These scenarios are not hypothetical. EMA guidance from 2020 states explicitly that sponsors must be able to provide GCP inspectors with access to qualification and validation documentation for all third-party computerised systems, and that the contract with the vendor must contain provisions for audit and inspection ^[4].

For implementation, sponsors should ask: what does the onboarding validation package look like? Is there a pre-configured IQ/OQ/PQ package, or does the sponsor build the validation from scratch? Who performs and signs off the UAT? What is the timeline between contract signature and a GCP-compliant go-live?

For incident response, the question is what happens when an AI-generated document contains an error that reaches a regulatory agency. Who is notified? What is the vendor's root cause analysis process? Is there a customer notification obligation? How are affected outputs identified and recalled from downstream use?

For audits, the practical question is whether the vendor has previously been through a GCP sponsor audit and, if so, can they provide the CAPA summary from the most recent findings. A vendor that has never been audited by a pharma sponsor is a materially different vendor than one who has been through that process multiple times and has documented improvements to show for it. Conference reporting on ICH E6(R3) implementation from SCOPE Europe in November 2025 noted that sponsor vendor management plans should include documented oversight findings and performance data ^[3]. That documentation should be available before a contract is signed, not after the first finding.

Regulatory and Documentation Considerations

The regulatory environment for AI regulatory software is evolving faster than most procurement cycles. The FDA's CSA guidance (most recent version February 2026) ^[7] formalized the shift toward risk-based software assurance. The FDA-EMA joint principles in January 2026 ^[1] established the first coordinated international framework for AI in drug development. ICH E6(R3)'s September 2025 adoption by FDA ^[2] elevated data governance, computerized system validation, and vendor oversight to explicit GCP expectations.

Against this backdrop, a sponsor who purchased AI regulatory software in 2023 under a lighter regulatory environment may need to revisit their qualification documentation against the current framework. That does not mean replacing the platform, but it does mean ensuring the qualification package addresses AI-specific risks, that the vendor management plan reflects E6(R3)'s requirements for critical system oversight, and that the audit trail architecture satisfies Part 11's traceability requirements for AI generation events.

The FDA's credibility assessment framework in draft guidance FDA-2024-D-4689 introduces a context-of-use specification requirement for AI models used to support regulatory decision-making ^[10]. Sponsors using AI to draft regulatory submissions should be prepared to document the context of use for the AI system, the scope of validation evidence supporting that context, and the human review process that sits between AI output and regulatory submission. As the draft guidance matures toward finalization, this type of documentation may be expected in sponsor inspection packages and, as the FDA-EMA joint principles signal, potentially as part of the submission dossier itself.

How Kitsa Fits Into This Problem

Kitsa states that KScribe is designed to address the compliance requirements described above. According to Kitsa's product documentation, the platform operates within SOC2, HIPAA, ISO 27001, and AWS VPC-compliant infrastructure, with audit trail architecture intended to satisfy 21 CFR Part 11 traceability requirements for AI generation events. Kitsa states that documents are generated from a structured clinical intelligence layer designed to maintain cross-document consistency, so that protocol parameters propagate to the ICF, IB, DSUR, and CSR rather than being generated independently. Kitsa also states that IQ/OQ/PQ validation support is available for sponsor qualification activities and that model versioning is managed under formal change control.

These are vendor claims. Sponsors evaluating KScribe should apply every question in this article directly to Kitsa's qualification documentation. That means requesting the validation master plan, the AI-specific risk assessment and UAT evidence, the audit trail demonstration for an AI generation event, the model versioning and change control procedures, and the information security certifications as primary documents, not accepting product descriptions as qualification evidence.

Key Takeaways

• Under ICH E6(R3) and 21 CFR Part 11, sponsors cannot delegate responsibility for AI-generated regulatory content to a software vendor. Vendor qualification is a compliance activity, not a procurement formality.
• AI regulatory writing tools introduce hallucination risk that traditional CSV frameworks were not designed to address. Sponsors must confirm that a vendor has AI-specific validation documentation covering non-deterministic outputs.
• A good-practice audit trail for AI-generated documents should capture the generation event itself, including model version, prompt configuration, and timestamp, in addition to subsequent user edits. While Part 11 does not explicitly name these fields, the requirement to record system activity that creates or modifies electronic records provides the basis for expecting them.
• Cross-document consistency is a structural capability, not a feature. Sponsors should test how a change to a key protocol parameter propagates across an entire document set before committing to a platform.
• Data governance questions, including HIPAA BAA status, SOC2 Type II certification, data residency, and model training data policies, should be resolved before any clinical trial data is uploaded to an AI regulatory writing platform. These are vendor-selection criteria reflecting good practice and sponsor risk management, not named regulatory mandates.
• The January 2026 FDA-EMA "Guiding Principles of Good AI Practice in Drug Development" are non-binding but represent the first coordinated international framework for AI in drug development. The agencies state they are intended to inform future guidance and regulatory policy. Sponsors should ask vendors how their platform maps to all ten principles now, before that policy matures.
• GCP sponsor audits of AI regulatory vendors are not standard practice yet, but E6(R3)'s vendor management plan requirements make them a foreseeable expectation. Sponsors should ask for prior audit documentation before contract signature.

FAQ

References

1. [1]U.S. Food and Drug Administration and European Medicines Agency. "Guiding Principles of Good AI Practice in Drug Development." January 2026. Note: these principles are non-prescriptive and non-binding at the time of publication, intended to lay the foundation for future guidance. https://www.fda.gov/media/189581/download
2. [2]International Council for Harmonisation. "ICH E6(R3) Guideline for Good Clinical Practice." Step 4 Final Guideline, adopted January 6, 2025. Adopted by FDA as final guidance September 2025, Docket FDA-2023-D-1955. https://database.ich.org/sites/default/files/ICH_E6(R3)_Step4_FinalGuideline_2025_0106.pdf
3. [3]Clinical Trial Vanguard. "New GCP Revision Redefines Vendor Oversight and Digital Accountability." Reporting from SCOPE Europe 2025. November 12, 2025. https://www.clinicaltrialvanguard.com/conference-coverage/new-gcp-revision-redefines-vendor-oversight-and-digital-accountability/
4. [4]European Medicines Agency. "Notice to Sponsors on Validation and Qualification of Computerised Systems Used in Clinical Trials." EMA/INS/GCP/454280/2010. April 7, 2020. https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/notice-sponsors-validation-qualification-computerised-systems-used-clinical-trials_en.pdf
5. [5]U.S. Food and Drug Administration. "21 CFR Part 11: Electronic Records; Electronic Signatures." Code of Federal Regulations. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
6. [6]International Society for Pharmaceutical Engineering (ISPE). "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems." Second Edition, 2022.
7. [7]U.S. Food and Drug Administration. "Computer Software Assurance for Production and Quality Management System Software." Guidance for Industry and FDA Staff, FDA-2022-D-0795. Issued February 3, 2026; supersedes version issued September 24, 2025. Issued by CDRH and CBER; scope covers production and quality management system software for medical devices. https://www.fda.gov/media/188844/download
8. [8]Li H, He X, Subbaswamy A, Vossler P, Gossmann A, Singh K, Feng J. "Scaling Medical Device Regulatory Science Using Large Language Models." npj Digital Medicine, vol. 9, no. 221. February 5, 2026. https://www.nature.com/articles/s41746-026-02353-7
9. [9]Applied Clinical Trials. "FDA's Elsa AI Tool Raises Accuracy and Oversight Concerns." Applied Clinical Trials Online. July 23, 2025. https://www.appliedclinicaltrialsonline.com/view/fda-elsa-ai-tool-raises-accuracy-and-oversight-concerns
10. [10]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, FDA-2024-D-4689. January 6, 2025. Not for implementation; contains non-binding recommendations. https://www.fda.gov/media/184830/download
11. [11]Eser U, Gozin Y, Stallons LJ, Caroline A, Preusse M, Rice B, Wright S, Robertson A (Weave Platform and Takeda Pharmaceuticals). "Human-AI Collaboration Increases Efficiency in Regulatory Writing." arXiv preprint, September 2025. Note: vendor-involved study; use with appropriate caveat. https://arxiv.org/pdf/2509.09738
12. [12]International Society for Pharmaceutical Engineering (ISPE). "ISPE GAMP Guide: Artificial Intelligence." ISPE GAMP Community of Practice, July 2025. 290 pp. https://ispe.org/publications/guidance-documents/gamp-guide-artificial-intelligence