Computer Software Assurance has been the word on every pharma quality forum for the past year, and for good reason. FDA finalized its guidance, Computer Software Assurance for Production and Quality System Software, on September 24, 2025 — published in the Federal Register as document 2025-18468 — and it formally supersedes Section 6 of the 2002 General Principles of Software Validation guidance. That's a twenty-three-year-old validation model getting retired in favor of something built for how software actually gets built and deployed today. FDA issued an updated version of the guidance on February 3, 2026, which tells you the agency is still actively refining its position rather than treating this as settled.
The timing is not incidental. CSA lands right as pharma manufacturing, quality, and clinical operations are absorbing AI and machine learning into the same systems the guidance is meant to cover — batch record review tools, deviation triage, environmental monitoring analytics, even GMP document classification. The question I get most often from quality leaders right now isn't "what is CSA." It's "does CSA actually work for AI, or were we handed a risk-based validation framework built for software that doesn't learn, retrain, or drift?"
In my view, that second question is the one worth answering carefully, because getting it wrong in either direction has real consequences. Treat AI like static software and you validate once, then miss the model drift that shows up eighteen months later. Treat AI like it needs a whole new regulatory category and you'll spend budget building a parallel compliance system nobody at FDA is asking for. The honest answer sits in between, and it starts with understanding what CSA actually changed.
What the Final CSA Guidance Actually Says
CSA replaces the old "test everything with equal rigor" approach to computer software assurance with a risk-based one. Software with low impact on product quality or patient safety can be assured through unscripted or exploratory testing — testers using the system as a subject-matter expert would, documenting what they find, without a pre-written script dictating every click. Software with higher risk still gets scripted, documented testing. FDA's own language in the guidance frames this as "least burdensome" — a term with real regulatory weight, since it echoes the least-burdensome-approach language Congress wrote into the FD&C Act for device reviews.
The guidance was issued by CDRH and CBER, and its text is written around the Quality System Regulation — 21 CFR Part 820 — for medical devices, not around 21 CFR Parts 210/211 for drug manufacturing. That distinction matters and gets glossed over constantly in pharma trade press. CSA is not binding guidance for a drug manufacturer running batch record software under 21 CFR 211.68. What it is, and what CDER's documented involvement in drafting it signals, is the clearest statement yet of how FDA thinks about software risk generally. Quality leaders at drug and biologics companies who adopt CSA principles are applying a device-guidance framework by analogy, under the broader risk-based validation philosophy ICH Q9 and Q10 already endorse. That's a legitimate and increasingly common choice. It is not the same as being told to do it.
One more structural fact worth knowing: FDA's Quality Management System Regulation, which harmonizes 21 CFR Part 820 with ISO 13485:2016, took effect February 2, 2026. CSA and QMSR landed within months of each other. Reading them separately misses how deliberately FDA is rebuilding its device quality architecture around international standards and risk tiering at the same time.
Why AI Doesn't Fit the Old CSV Playbook
Traditional computer system validation assumes a fixed, deterministic artifact. You write test scripts against defined requirements, execute them, and the software either matches expected output or it doesn't. That model works when the software's behavior on a given input is the same today as it will be next year.
Machine learning models break that assumption at the root. A model trained on historical deviation data doesn't have a single fixed behavior — it has a behavior distribution that depends on the training set, and that distribution can shift when the underlying process changes, when new failure modes appear, or when the model is retrained on fresh data. Validate an AI system once, the way you'd validate a fixed-logic spreadsheet macro, and you've validated a snapshot. You haven't validated the thing that's actually running in production six months later.
This is where CSA's risk-based logic is genuinely useful, not just convenient. Instead of asking "did we test this once, thoroughly, before go-live," the CSA mindset asks "what's the ongoing assurance activity proportional to this system's risk to product quality and patient safety." For AI, that reframes validation from an event into a lifecycle activity: performance monitoring, drift detection, periodic re-verification, and documented decisions about when a model's outputs have moved far enough from its validated baseline to require re-validation. GAMP 5 Second Edition, published in 2022, already built the scaffolding for this in Appendix D11, which addresses AI and machine learning specifically within the broader computerized system validation framework.
GAMP 5 Appendix D11 and the ISPE AI Guide
GAMP 5 Second Edition's Appendix D11 is the closest thing pharma has to an industry-consensus AI validation framework, and ISPE followed it in July 2025 with a dedicated GAMP Guide on Artificial Intelligence that expands the appendix into a fuller operational treatment — covering model lifecycle management, data quality controls, explainability expectations, and ongoing performance monitoring specific to AI/ML systems in GxP environments. Neither document is FDA guidance. Both function as the reference an inspector is increasingly likely to expect a sponsor's quality team to be conversant in, the same way GAMP 5 itself became the de facto CSV standard long before FDA cited it directly.
The practical value of Appendix D11 is that it gives you category logic for AI the same way GAMP 5's original software categories (1 through 5) gave you category logic for conventional software. A rules-based, non-learning algorithm behaves close to a GAMP Category 4/5 configured or custom application — validate it, document the logic, move on. A model that retrains on a schedule or continuously learns from new data needs a different assurance model entirely: one built around monitored performance thresholds, not a one-time pass/fail test script. Conflating the two categories is the single most common mistake I see in pharma AI governance work — treating a static classifier the same as an adaptive model, or worse, treating both the same as a spreadsheet macro.
A Risk-Based Way to Tier AI Systems Under CSA
The table below is the tiering logic I walk clients through when mapping AI/ML systems into a CSA-style assurance program. It's not an FDA-published table — no such table exists yet in binding guidance — but it applies CSA's risk categories and GAMP 5 Appendix D11's AI-specific logic together in a way that holds up under audit scrutiny.
| AI System Type | Example in GxP Use | CSA Risk Posture | Assurance Activity |
|---|---|---|---|
| Static rules engine (non-learning) | Deviation categorization by fixed logic tree | Low-to-moderate, direct impact | Scripted testing at deployment; periodic confirmation logic hasn't been altered |
| Fixed/frozen ML model (trained once, deployed as-is) | Predictive maintenance scoring on a locked model version | Moderate, indirect impact | Scripted validation at deployment plus documented performance monitoring against a defined baseline |
| Periodically retrained model | Batch record anomaly detection retrained quarterly | Moderate-to-high, direct impact | Re-verification at each retraining cycle; drift thresholds defined in advance with escalation criteria |
| Continuously learning/adaptive model | Real-time process analytics with online learning | High, direct impact | Continuous monitoring, locked audit trail of model versions, formal change control tied to performance drift, not calendar time |
The pattern across every row is the same: assurance effort scales with the system's proximity to product quality and patient safety decisions, and with how much the system's behavior can change without a human deliberately changing it. That second variable — behavioral drift without human action — is the one conventional CSV never had to account for, and it's the one an AI-specific assurance program has to be built around from day one.
The EU Side: Annex 11 and the Draft Annex 22
Europe is moving on a parallel track. In July 2025, the European Medicines Agency published draft revisions to EU GMP Annex 11 (Computerised Systems) alongside a new draft Annex 22 addressing Artificial Intelligence specifically. As of this writing, both remain drafts — not final, applicable GMP guidance — which means a company building its AI assurance program around the current draft text is making a forward-looking bet, not complying with an enforceable requirement. That's a reasonable bet to make, given how directly Annex 22 addresses questions CSA and GAMP 5 only imply, but it should be labeled internally as "anticipatory" rather than "required," so the distinction doesn't get lost by the time an auditor asks where a control came from.
What I'd watch for as these drafts move toward finalization is whether EMA's final language on AI model lifecycle governance converges with or diverges from FDA's CSA risk-tiering logic. A pharma company operating in both markets doesn't get to pick one framework. It needs a single internal AI assurance program that satisfies both, and the smart move is building that convergence now rather than retrofitting it once both frameworks are final and, inevitably, not identical.
Building a Defensible AI-CSA Program: Five Moves
Classify before you validate. Every AI/ML system touching a GxP process needs a documented risk classification before assurance activities are designed, not after. That classification should name the model type (static, fixed-trained, periodically retrained, continuously learning), its GxP impact, and the rationale for its assurance tier — in writing, reviewed, and version-controlled.
Write the drift threshold down before you need it. The single most common gap I find in pharma AI programs is a monitoring dashboard with no documented threshold for what triggers re-validation. Watching a metric isn't governance. A pre-defined, approved threshold that triggers a specific corrective action is.
Separate "assurance activity" from "assurance record." CSA's whole value proposition is letting the assurance activity match the risk — unscripted testing where it's appropriate, full scripted validation where it isn't. But the record of what was done, why, and by whom still has to meet the same documentation rigor either way. Lighter-touch testing does not mean lighter-touch documentation.
Treat retraining as a change-controlled event, not a maintenance task. If a model retrains on a schedule, that retraining needs to run through the same change control process a configuration change would. The output is different code behavior even if no one touched a line of code.
Map your framework choices explicitly. Note where you're following binding requirement (21 CFR 211 for drugs, harmonized 21 CFR 820/ISO 13485 for devices), where you're applying non-binding guidance by analogy (CSA), where you're following industry consensus (GAMP 5 Appendix D11, the ISPE AI Guide), and where you're anticipating a draft standard (EU Annex 22). An inspector who asks "why did you do it this way" deserves an answer that names the source, not a shrug toward "best practice."
None of this is a one-time project. It's a governance structure, and structures need an owner, a review cadence, and a place in the quality system where AI-specific risk decisions actually get made rather than absorbed into a generic IT validation SOP that was written before anyone in the building was training a model. Our AI risk assessment work with pharma and healthcare clients starts exactly there — classifying what's actually running before arguing about how much testing it deserves.
What Auditors Are Actually Asking Right Now
Inspectors are not yet asking pharma quality teams to cite Appendix D11 by section number. What they are asking, increasingly, is some version of: "how do you know this system behaves the same way today as it did when you validated it?" For static software, that's an easy question. For a learning model, it's the whole ballgame, and a quality team that can't answer it in plain terms — not "we monitor it," but "here is the threshold, here is who reviews it, here is what happens when it's crossed" — is going to have a hard conversation. Building that answer before the inspector asks the question is the entire point of an AI-CSA program, and it's the piece of GxP-compliant AI governance that most companies are still building reactively rather than proactively.
FAQ
Is FDA's CSA guidance legally binding for drug manufacturers under 21 CFR 211? No. The final guidance issued September 24, 2025 is written around the Quality System Regulation (21 CFR Part 820) for medical devices, not 21 CFR Parts 210/211 for drugs. Drug and biologics manufacturers can adopt CSA's risk-based principles as a documented, defensible practice under the broader risk-based validation philosophy in ICH Q9 and Q10, but it is not a binding requirement for them the way it functions for device makers.
Does GAMP 5 cover AI and machine learning validation? Yes, in part. GAMP 5 Second Edition, published in 2022, addresses AI/ML in Appendix D11. ISPE expanded that treatment with a dedicated GAMP Guide on Artificial Intelligence in July 2025, which most quality teams now treat as the working reference for AI-specific validation logic even though it is industry consensus guidance, not FDA guidance.
What's the biggest mistake pharma companies make applying CSA to AI systems? Validating a learning model once and treating that validation as permanent. CSA's risk-based logic is meant to make assurance activity proportional and ongoing, not lighter and one-time. A model that retrains or adapts needs a documented drift threshold and a monitoring program, not just a deployment test.
Is the EU's Annex 22 on AI already in effect? No. EMA published draft revisions to Annex 11 and a new draft Annex 22 on Artificial Intelligence in July 2025, and both remain in draft form. Companies building controls against the current draft text should label those controls as anticipatory rather than compliant with a finalized requirement.
How does ISO 42001 relate to FDA's CSA guidance? They address different layers of the same problem. CSA is a software assurance methodology for validating GxP production and quality system software. ISO 42001:2023 is a management system standard for governing AI across an organization — risk assessment, oversight roles, and continual improvement of the AI program itself. A pharma company can use CSA to validate an individual AI-enabled system while using an ISO 42001-aligned management system to govern the AI program that system sits inside.
Last updated: 2026-08-20
Jared Clark
AI Governance Consultant, Regulated AI Consulting
Jared Clark is the founder of Regulated AI Consulting, advising organizations on AI governance frameworks, ISO 42001 compliance, and responsible AI deployment in regulated industries.