Why a Local AI Foundry, and What GxP Changes

Part 1 of 6. The series index, with links to every part as it is published, is Part 0: Introduction and Series Map. This series is for the people who must stand up shared AI capability in a regulated life-sciences organization: heads of architecture, CTOs, and VPs of engineering, together with their partners in Quality, Validation, and Security. It assumes you know what a language model and a vector index are. Basic terms are defined in the glossary at the end of the series. Regulatory status is stated as of September 2026 and will change. This is a technical guide, not legal advice.

The problem this series solves

Most life-sciences software organizations start AI the same way. One product team calls a hosted model. Another picks a different model. A third builds its own retrieval pipeline. Each team makes a sensible local choice. The organization ends up with a problem that nobody chose.

The symptoms are predictable.

• Documents are copied into several indexes, and the copies drift away from the approved versions in the document management system.
• Access rules are enforced by some integrations and not by others, so the same user gets different answers to the question "may I see this?"
• Prompts live in code, in spreadsheets, and in chat histories, and nobody can say which prompt produced last month's output.
• There is no shared evaluation baseline, so "the model got better" and "the model got worse" are opinions, not measurements.
• Each integration keeps its own logs, in its own format, with its own retention period, or with none.

In a GxP setting these are not engineering annoyances. They are inspection findings waiting to happen. An inspector who sees an AI-drafted deviation summary will ask a chain of questions. Which version of the procedure did the system read? Who was allowed to see it? Which model and which prompt produced the text? What has changed since the system was validated? Who reviewed the output before it entered the record? An ad hoc estate cannot answer those questions consistently, and an inconsistent answer is worse than no answer.

The evidence says the ad hoc route rarely pays, even outside regulated work. A 2025 MIT study of enterprise generative AI, based on a survey of 153 leaders, 52 executive interviews, and analysis of more than 300 public deployments, found that about 95 percent of pilots produced no measurable profit-and-loss impact [16]. The study blames a learning gap and weak integration into real workflows, not model quality. The winners were narrow, back-office systems that fit an existing process, and organizations that partnered with specialists succeeded at roughly twice the rate of those that built alone [16]. A 2024 RAND report notes that by some estimates more than 80 percent of AI projects fail, twice the rate of other IT projects. From 65 interviews with data scientists and engineers it identifies five root causes: a misunderstood problem, inadequate data, chasing the technology instead of the outcome, underinvestment in deployment infrastructure, and problems beyond what current AI can do [17]. Most of those causes are organizational, and a platform is an organizational answer.

A Local AI Foundry is that answer. It is one shared, self-hosted platform that provides models, retrieval, policy enforcement, evaluation, audit, and operations to every product, while keeping each product's data, permissions, prompts, and quality thresholds isolated. Product teams consume a small, stable API. The platform team owns the controls that inspectors will ask about.

The split of responsibilities is the heart of the idea.

The word "foundry" is deliberate. A foundry does not decide what is cast. It guarantees that whatever is cast meets a standard.

What "local" means here

"Local" has a precise meaning in this series.

• Self-hosted. Models, indexes, prompts, and logs run on infrastructure the organization controls.
• Air-gap capable. The platform must work with no outbound connectivity. Model weights, containers, and dependencies are brought inside once and updated through change control.
• Sovereign. No prompt, document chunk, or output leaves the boundary unless a documented decision allows it.

Why go this far? There are four reasons, and only one of them is about data leaving the building.

Validated state. A GxP computerised system is validated for its intended use and then kept in that state [2][10]. A hosted model that changes under you, through a silent version update, breaks that state without any change request on your side. A locally pinned model version changes only when you decide, through change control, with evidence.

Auditability. Part 11 and Annex 11 expect audit trails, access control, and record retention under your control [8][10]. That is far easier to prove when the logs, the prompts, and the retrieved text are stored in systems you administer.

Supplier accountability. The draft Annex 22 states that accountability for AI output stays with the regulated company, and Annex 11 expects oversight of suppliers and service providers [10]. You can only exercise that oversight over components you can inspect and pin.

Cost predictability. Usage-billed inference is a variable cost tied to how people use the system. Owned or leased hardware at steady utilization is a known cost. Part 6 returns to the numbers.

Hybrid designs are possible, and the regulators do not forbid cloud. FDA's assurance guidance explicitly covers cloud models such as software as a service, platform as a service, and infrastructure as a service when they are used for production or quality-system work, and it scales assurance to intended use and risk [3]. The point is not that cloud is banned. The point is that a non-regulated workload, a development environment, or a synthetic-data experiment may run on rented capacity, while anything that touches GxP data or GxP decisions runs inside the boundary by default. Every exception is a recorded decision, not a convenience.

Three tests separate "local" from "locally installed".

1. The outbound test. Block all outbound network traffic from the platform. Does every feature still work? A tool that calls a hosted endpoint for embeddings, moderation, licence checks, or telemetry fails this test.
2. The update test. Can you install a new model, container, or dependency from media you brought inside, through your own change control, without the vendor's server being reachable?
3. The dependency test. Do you hold a bill of materials for every model, container, and library in the platform, so that a vulnerability notice can be traced to what you actually run?

Part 6 applies these tests to real tools.

What "regulated" changes

Regulated does not mean adding a compliance checklist at the end. It changes the design. The table maps the frameworks that matter for pharma and medical-device organizations to what each demands of the platform. The paragraphs after the table explain the ones that most affect the architecture.

GAMP 5 and the GAMP AI Guide. GAMP 5 is not law. It is the industry's standard method for validating computerised systems in GxP, and inspectors know it well. The Second Edition, published in 2022, added an appendix on AI and machine learning. In July 2025 ISPE published a stand-alone AI Guide to be used alongside it [1][2]. The AI Guide covers the AI lifecycle from concept to retirement, includes appendices on supplier management and quality by design, incorporates ISPE's records and data integrity guidance, and explicitly considers ISO/IEC 42001 [1]. Its emphasis is the same as the Second Edition's: patient safety, product quality, data integrity, and critical thinking instead of box-ticking. For an architect, the practical message is simple. AI-enabled systems are validated systems, and the validation lifecycle must cover the models and the data, not only the code.

FDA Computer Software Assurance. In September 2025 FDA finalized its CSA guidance for software used in device production and quality systems, replacing Section 6 of its 2002 software validation guidance [3][4]. The approach is risk-based and least-burdensome. You identify the intended use of each software feature, assess its risk to patient safety and product quality, and choose assurance activities in proportion: scripted testing where the risk is high, unscripted or exploratory testing where it is lower, continuous monitoring as ongoing evidence, and supplier evidence where it exists [3]. It applies to on-premises and cloud software alike, and it does not apply to software that is itself a medical device [3]. Its formal scope is devices, but the approach has become the shared vocabulary for pharma quality teams too, because GAMP 5 already leans the same way. Part 4 builds the validation approach on it.

The FDA draft credibility framework. FDA's January 2025 draft guidance, still a draft as of September 2026, proposes a seven-step framework for establishing the credibility of an AI model for a specific context of use [5]. The steps are: define the question of interest; define the context of use; assess model risk as a function of model influence and decision consequence; develop a plan to establish credibility; execute the plan; document the results and any deviations; and determine whether the model is adequate for the context of use [5]. The draft is about AI used to support regulatory decisions for drugs and biologics, not about every business tool. But its two central ideas, context of use and risk as influence multiplied by consequence, are the cleanest way to reason about any AI feature in a regulated product. This series uses them throughout.

The FDA and EMA joint principles. In January 2026 the two agencies published ten non-binding principles of good AI practice in drug development, building on EMA's 2024 reflection paper [6][15]. They cover human-centric values, adherence to standards, a risk-based approach, a clear context of use, data governance, multidisciplinary expertise, lifecycle management, transparency, human oversight, and international cooperation [6]. None of this is new to a GAMP practitioner. What matters is that the two largest regulators now say the same things in one document.

Records and data integrity. 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails that record the date and time of operator entries and actions that create, modify, or delete electronic records, retained for at least as long as the records themselves [8]. FDA's data integrity guidance sets out ALCOA+: records must be attributable, legible, contemporaneous, original, and accurate, and also complete, consistent, enduring, and available [9]. In the EU, Annex 11 sets similar expectations for computerised systems, and PIC/S PI 041 gives inspectors a shared view of data integrity in GMP and GDP environments [10][24]. For an AI platform this raises a question that most teams have not asked. When an AI output influences a GxP decision, is the output itself a record? The safe answer is yes. Part 2 designs for it.

Annex 22, the draft that matters most. In July 2025 the European Commission opened consultation on a revised Chapter 4, a revised Annex 11, and a new Annex 22 on AI in GMP, prepared with the EMA and PIC/S inspectors' working group [10]. The consultation closed on 7 October 2025 with about 1,300 comments. As of September 2026 all three texts remain drafts, EMA's work plan targets a final text for late 2026, and no effective date has been announced [10]. The draft's scope is AI in critical GMP applications, meaning those with a direct impact on patient safety, product quality, or data integrity. Its central statement is that dynamic models, models that can return different outputs for identical inputs, generative AI, and LLMs should not be used in those critical applications [10]. For the static models it does permit, it expects a defined intended use, validation data that represents real operating conditions, explainability, confidence thresholds where applicable, human oversight, change control, and ongoing performance monitoring [10]. It allows generative AI in non-critical uses, such as summarising a deviation report or searching procedures, when a qualified person reviews the output and keeps documented responsibility. And it is explicit that accountability stays with the regulated company, not with the supplier. EMA held a workshop on 30 June and 1 July 2026 to consider whether adaptive and generative models could be addressed under risk-based safeguards, but the published text has not changed [10]. A prudent platform treats the draft as design guidance now. If the final text relaxes the rule, nothing is lost. If it does not, the platform is already aligned.

The EU AI Act, as amended. The AI Act entered into force in August 2024. In July 2026 the Digital Omnibus on AI amended it and changed the timetable [11][12]. Article 50 transparency duties, such as telling people they are interacting with AI and marking generated content in a machine-readable way, have applied since 2 August 2026, with a grace period to 2 December 2026 for systems already on the market [12]. The high-risk obligations now apply from 2 December 2027 for stand-alone systems listed in Annex III, and from 2 August 2028 for AI embedded in products covered by EU product law under Annex I, such as medical devices [12]. Systems placed on the market before those dates are grandfathered unless they undergo a significant design change, and the threshold for "significant" is not yet defined [12]. For a quality-system or document assistant, the two plausible high-risk hooks are worker management under Annex III, for example if the system allocates tasks or monitors performance, and being a safety component of a medical device under Annex I [11]. Most quality-system assistants will not be high-risk. But the classification must be documented, and the Article 4 AI-literacy duties and the Article 50 transparency duties apply regardless. Part 5 works through the classification.

Privacy. India's Digital Personal Data Protection Act, 2023, became operational through the DPDP Rules notified in November 2025, with obligations phased in through 2027 [13]. The organization that decides the purpose and means of processing is a data fiduciary, and that includes training or deploying AI on personal data. Breach reporting is two-stage: notify the Data Protection Board without delay, then file a detailed report within 72 hours, and notify affected individuals with no materiality threshold [13]. Penalties reach ₹250 crore for failures of reasonable security safeguards [13]. Organizations operating in Europe work through the GDPR, including its rules on automated decisions and impact assessments. Part 5 covers privacy inside the platform.

Management standards. ISO/IEC 42001:2023 defines an AI management system that can be certified and that integrates with ISO/IEC 27001 [19]. NIST's AI Risk Management Framework gives a shared vocabulary of four functions, govern, map, measure, and manage, and its 2024 generative AI profile adds risks specific to generative systems, including confabulation and information integrity [20][22]. Neither is a GxP requirement. Both are useful scaffolding for the governance in Part 5.

Two things stand out across all of this.

First, the frameworks agree with each other. They all ask for a defined intended use, risk-based assurance, human accountability, documented evidence, and control over change. A platform built for one of them is most of the way to the others.

Second, the hardest constraint is still a draft. That is a reason to design for it now, not a reason to wait. The cost of building human review and evidence into the platform is small. The cost of retrofitting it after an inspection is not.

The consequence that shapes everything else

Put the frameworks together and one rule follows. Every AI use must be classified before it is built, on two axes.

1. GxP impact. Does the output touch product quality, patient safety, or a regulated record? Critical, or non-critical?
2. Decision influence. Does the output inform a human decision, or does it make the decision? This is the logic of the FDA credibility framework, where model risk rises with the model's influence and with the consequence of a wrong decision [5]. It is also the logic of ICH Q9(R1), which ties the formality of risk management to the importance of the decision and warns about subjectivity in risk assessments [14].

Together the two axes make four quadrants.

The platform defaults to the top-left quadrant: decision support, non-critical use, with a named person who reviews and signs. Anything else is an exception with its own validation case. The bottom-right quadrant is off the table for generative models until the regulators say otherwise.

The FDA has already shown what happens without this. In April 2026 it issued a warning letter to a manufacturer after an inspection found that the firm had used an AI agent to draft specifications and records without adequate review [7]. The firm told investigators that it had not performed process validation because the agent never told it that validation was required. The letter states that a firm using AI as an aid in document creation must review the generated documents for accuracy and compliance, and it cites 21 CFR 211.22(c), the rule that makes the quality unit responsible for procedures and specifications, and 211.100 on written production controls [7]. The remedy FDA expected was simple: an authorized person must review and clear any output from an AI agent [7]. The UK MHRA made a similar point in June 2026 about AI-assisted responses to inspection findings: they must be accurate, technically reviewed, and approved by an accountable person [23].

That letter is the design brief for a regulated AI platform. The system may draft. A person decides. The record shows who.

Classification also decides validation depth and review tier. Under CSA, a non-critical decision-support feature can be assured with unscripted testing and monitoring, while a critical feature needs scripted evidence per context of use [3]. Under the FDA credibility framework, the credibility plan grows with model influence and decision consequence [5]. Part 4 turns this into a concrete procedure.

Six design principles

These principles run through every later part. Each one comes with what it means in practice, and what it prevents.

1. Sovereign by default. Data, models, and logs stay inside the boundary. In practice: an approved list of what may cross the boundary, and nothing else. It prevents accidental disclosure, and it makes the supplier oversight that Annex 11 and Annex 22 expect possible [10].
2. Default-deny, enforced before retrieval. The platform knows who is asking and which documents they may see, and it filters before any text reaches a model. Product-level isolation is not enough. Two users of the same product may have different rights to the same document. In practice: the caller's identity and entitlements travel with the request, and the retriever filters on them before ranking, never after generation. It prevents the leakage paths that OWASP lists as sensitive information disclosure and as vector and embedding weaknesses [21].
3. Evidence first. Every answer cites the source document, version, and section it used. If the evidence is thin, the system says so instead of guessing. In practice: citations carry document identity, version, effective date, and section, and the system abstains below an evidence threshold. It supplies the kind of evidence the FDA credibility framework asks for [5].
4. Human accountability by design. Outputs are decision support. A qualified person reviews anything that feeds a GxP record or decision, and the review is itself a record. In practice: a review tier per quadrant, and a captured record of who reviewed what, when. It is the rule in the April 2026 warning letter and in the draft Annex 22 [7][10].
5. Risk-based validation and change control. Intended use is defined per feature. Changes to a model, prompt, retrieval setting, or embedding model are controlled changes with evidence, not configuration edits. In practice: an evaluation suite that runs on every change, and a registry that records exactly what is deployed. It aligns with CSA and GAMP, and it protects grandfathering under the AI Act by making "significant change" a documented decision rather than an accident [2][3][12].
6. Records, not logs. Audit trails meet the expectations of 21 CFR Part 11 and Annex 11: secure, time-stamped, attributable, unalterable, and retained for the life of the record [8][10]. In practice: audit events are written to a store with the same controls as other GxP records, and their retention follows the record they relate to.

Models and suppliers, briefly

The model is the least stable part of the platform. New versions appear every few months, licences change, and vendors retire models. So the platform must not depend on any one model, and the design must make a model swap a controlled, evidenced change rather than a rebuild. Part 2 introduces the model router that makes this possible. Four points matter at the start.

Open-weight and vendor-supported models can both run locally. Open-weight models are downloaded and self-hosted. Vendor-supported models are packaged and supported under a commercial licence, but they still run on your hardware. The difference is support, indemnity, packaging, and cost. It is not sovereignty. Either path passes the outbound test if it is deployed correctly, and either fails it if the tooling around it phones home.

Licences differ, and they change. As of September 2026, several strong model families use permissive licences. Qwen3 open-weight releases and IBM Granite 4 releases are Apache 2.0, DeepSeek releases use MIT, and some Mistral models are Apache 2.0 while others are not [18]. The Llama 4 Community License is free below 700 million monthly active users but carries naming and attribution rules for derived models [18]. Some vendors use custom terms that are more restrictive than Apache 2.0. Check the licence on the model card for the exact version you deploy, and record it in the model registry described in Part 5. The same applies to embedding and reranking models, which are often forgotten. They have licences and versions too, and a change to the embedding model invalidates every vector built with the old one.

You cannot fully verify training data, so qualify the supplier instead. Model cards vary widely in what they disclose about training data and knowledge cutoffs. There is no practical way to audit a training corpus from the outside. Two levers help. The EU AI Act requires providers of general-purpose AI models to maintain technical documentation, including a summary of the content used for training [11]. And the GAMP AI Guide includes a supplier management appendix, while the draft Annex 22 is explicit that accountability stays with the regulated company, not with the supplier [1][10]. The practical response is a supplier qualification file for each model. It should hold the licence and the version identifier, the documented training-data summary, published evaluation and bias evidence, known limitations, the security posture of the serving container, the vendor's versioning and change-notification commitments, support and indemnity terms if any, and your own evaluation results. FDA's assurance guidance allows supplier evidence to reduce your own testing, but only if you hold that evidence and can show it [3].

Treat the model like any other qualified component. A validated system does not change its database engine without a change request. It should not change its language model without one either. That means the registry records the model, its version, its licence, its evaluation results, and the products that use it, and a swap goes through the same gate as any other controlled change.

What comes next

All parts are linked from the series index in Part 0. Part 2 gives the reference architecture: the control plane, the eight execution layers, and the request path that carries identity and authorization into retrieval before any text reaches a model. Part 3 treats documents as governed data. Part 4 answers the question every quality head asks first: how do you validate a system that is not deterministic? Part 5 covers security, privacy, and governance. Part 6 covers hosting, cost, operations, the team, and a production readiness checklist.

Sources for Part 1

Links marked (confirm) were not re-checked for this draft and must be verified before publication.

1. ISPE. ISPE GAMP Guide: Artificial Intelligence. July 2025. Final. https://ispe.org/publications/guidance-documents/gamp-guide-artificial-intelligence
2. ISPE. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. 2022. Final. https://ispe.org/topics/gamp
3. FDA. Computer Software Assurance for Production and Quality System Software. Guidance for Industry and FDA Staff. September 2025. Final. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-system-software
4. Federal Register. Notice of availability of the CSA guidance. 24 September 2025. https://www.federalregister.gov/documents/2025/09/24/2025-18468/computer-software-assurance-for-production-and-quality-system-software-guidance-for-industry-and
5. FDA. Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products. Draft guidance, January 2025. Draft, not for implementation, as of September 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological
6. FDA and EMA. Guiding principles of good AI practice in drug development. January 2026. Non-binding. https://www.fda.gov/media/189581/download
7. FDA. Warning Letter, reference 722591, dated 2 April 2026, citing 21 CFR 211.22(c) and 211.100. FDA warning letters database. https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/compliance-actions-and-activities/warning-letters (direct letter link: confirm)
8. 21 CFR Part 11, Electronic Records; Electronic Signatures, section 11.10(e). eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
9. FDA. Data Integrity and Compliance With Drug CGMP: Questions and Answers. Guidance, December 2018. Final. (confirm)
10. European Commission. Stakeholder consultation on EudraLex Volume 4: revised Chapter 4, revised Annex 11, and new Annex 22, Artificial Intelligence. Consultation 7 July to 7 October 2025. Draft, not adopted, as of September 2026. (consultation page: confirm)
11. Regulation (EU) 2024/1689, the Artificial Intelligence Act. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
12. Regulation (EU) 2026/1744, the Digital Omnibus on AI. Published 24 July 2026, in force 27 July 2026. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2026/1744/oj
13. Ministry of Electronics and Information Technology, India. Digital Personal Data Protection Act, 2023, and Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025, Gazette of 14 November 2025. (Gazette link: confirm)
14. ICH. Q9(R1) Quality Risk Management. Step 4, January 2023. https://database.ich.org/sites/default/files/ICH_Q9(R1)_Guideline_Step4_2022_1219.pdf
15. EMA. Reflection paper on the use of Artificial Intelligence in the medicinal product lifecycle, EMA/CHMP/CVMP/83833/2023. Adopted September 2024. https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline
16. MIT NANDA. The GenAI Divide: State of AI in Business 2025. July 2025. (report link: confirm)
17. RAND Corporation. Ryseff, De Bruhl, Newberry. The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed. 2024. RRA2680-1. https://www.rand.org/pubs/research_reports/RRA2680-1.html (confirm)
18. Model licences: Meta Llama 4 Community License; Qwen3 model cards; IBM Granite 4 model cards; DeepSeek model cards; Mistral model cards. Licence terms are stated on each model card and vary by version. (links: confirm at publication for the exact versions deployed)
19. ISO. ISO/IEC 42001:2023, Artificial intelligence management system. December 2023. https://www.iso.org/standard/42001
20. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. January 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (confirm)
21. OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
22. NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf (confirm)
23. MHRA Inspectorate. Blog post on the use of AI in responses to GxP inspection findings. 29 June 2026. (confirm)
24. PIC/S. PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. In force 1 July 2021. https://picscheme.org (document link: confirm)