Computer Software Assurance for AI: A Practical Guide

Computer Software Assurance has been the quiet story in regulated manufacturing for the last few years, and this year it stopped being quiet. The Quality Management System Regulation took effect February 2, 2026, folding ISO 13485:2016 into 21 CFR Part 820. Manufacturers who spent 2023 and 2024 rewriting their validation programs around FDA's risk-based CSA approach are now living with those programs under an active regulation. At the same time, the software those programs are meant to assure looks less and less like the deterministic, if-this-then-that code CSA was designed around. Production floors are running AI-assisted defect detection. Quality systems are running AI-drafted CAPA analysis and automated batch record review. Neither of those fits cleanly into a testing framework built for software that behaves the same way every time you run it.

I get some version of this question every few weeks from quality and regulatory teams: does CSA even apply to AI-enabled software, and if it does, what does "assurance" mean for a system whose outputs can change after you've already validated it? This article is my attempt at a straight answer.

What Computer Software Assurance Actually Is

CSA is not a new regulation. It is FDA's name for a risk-based interpretation of an old one: 21 CFR 820.70(i), which requires that when a manufacturer uses software as part of production or the quality system, that software must be validated for its intended use. FDA's draft guidance, "Computer Software Assurance for Production and Quality System Software," issued September 13, 2022, reframed how manufacturers should meet that requirement. Instead of scripted test protocols that document every click and every expected result for every feature regardless of risk, CSA asks manufacturers to spend their assurance effort where the risk actually sits and to use unscripted testing, ad hoc exploration, and even vendor documentation review for low-risk functions.

GAMP 5 Second Edition, published by ISPE in 2022, leans heavily on critical thinking as an alternative to exhaustive scripted validation, and I read FDA's CSA guidance as adopting that same premise: assurance activities should be proportional to the risk a software failure would pose to product quality or patient safety, not proportional to how many features the software happens to have.

That premise holds up fine for a batch record system that behaves identically every time. It gets harder the moment the software you're assuring is a model.

Why AI Breaks the CSA Assumptions

Traditional CSV and CSA both assume a software function has a knowable, fixed behavior you can test once and rely on. Feed it input X, it produces output Y, forever, until someone changes the code and you re-validate. An AI or machine learning model does not make that promise. The same input can produce a different output after retraining, after a data drift, or in some architectures, after enough new examples accumulate in production. The validated state is not a fixed point. It's a moving one.

This is where a lot of quality teams get stuck, and I think the stuck point is usually the same one: they try to bolt CSA's existing risk categories (limited, non-limited) onto AI without asking what "risk" even means for a system that can drift on its own. A model used to flag potential visual defects on a packaging line is not equivalent to a model used to auto-approve batch disposition, even if both are "AI." The intended use, and what happens downstream if the model is wrong, still has to drive the assurance strategy. AI doesn't replace that judgment. It just makes the judgment harder to skip.

Here's a comparison that might help frame where each approach actually applies:

What Assurance Needs to Cover for AI-Enabled Systems

If you're extending a CSA program to cover an AI or ML component, there are a handful of things a scripted test plan was never built to catch.

Retraining and versioning. Every retraining event is functionally a software change, even when nobody touched a line of code. A CSA program that only triggers re-validation on code deployments will miss the change that actually moved the model's behavior. The change control procedure needs a trigger for model version changes, not just code releases.

Performance drift after deployment. A model validated against last year's data distribution can degrade quietly against this year's inputs without ever throwing an error. Assurance for AI has to include a monitoring plan, not just a pre-release test plan. That's a shift from a point-in-time activity to a continuous one, and it's the single biggest structural change AI forces onto a CSA program.

Explainability evidence, where the intended use demands it. For a low-risk AI function, unscripted exploratory testing of outputs may be entirely adequate under CSA's own logic. For a high-risk function, an auditor is going to ask not just "did it produce the right answer in testing" but "can you explain why it produced this answer in this specific case." That's evidence a traditional test script doesn't generate.

Human-in-the-loop verification. Where an AI output feeds a quality decision, the record needs to show that a qualified person reviewed and could override the output, not just that the model ran. This is as much a procedural control as a software one.

None of this means CSA's core proportionality principle is wrong for AI. It means the risk assessment that decides what's "high" versus "low" risk has to account for drift and retraining as first-class hazards, alongside the traditional hazard of a coding defect.

Where ISO 42001 Fills the Gap FDA's Guidance Doesn't

FDA's CSA guidance was written for software generally. It was not written with AI's lifecycle in mind, and it doesn't try to be. ISO/IEC 42001:2023 is the standard that was, and for organizations layering AI governance on top of an existing quality system, it's the more natural home for the AI-specific controls that CSA leaves out.

ISO 42001:2023 clause 6.1.2 requires a documented AI risk assessment process, and clause 6.1.3 requires risk treatment tied to that assessment. Clause 8.1 covers operational planning and control across the AI system's lifecycle, which is the natural place to define what "validated" means for a model that can retrain. Clause 9.1, on monitoring, measurement, analysis and evaluation, is where the continuous performance-drift monitoring I described above actually gets formalized as a management system requirement rather than a best practice someone remembers to do.

In my view, the cleanest way to run this is not to build a separate AI validation program next to your existing quality system. It's to treat ISO 42001's AI risk and lifecycle clauses as the layer that tells your CSA program what to test and how often, and let 820.70(i) and your existing validation SOP handle the mechanics of documenting that testing. The two aren't competing frameworks. One tells you what AI-specific things to worry about; the other tells you how much documentation a given worry deserves.

For a manufacturer building this out for the first time, our AI governance design work usually starts exactly there — mapping which AI-enabled functions sit inside the quality system boundary before deciding how much assurance each one needs.

Building an AI-Aware CSA Program: The Sequence That Works

I've found the teams that get through this cleanly follow roughly the same order, and the teams that struggle usually skipped step one and went straight to writing test scripts.

1. Inventory every AI-enabled function inside the 820.70(i) boundary. Production and quality system software only. Not every AI tool in the building needs this treatment, just the ones touching product quality or the quality system itself.
2. Classify by intended use and failure consequence, not by how sophisticated the AI is. A simple model making a high-stakes decision needs more assurance than a complex model making a low-stakes one.
3. Define what "validated state" means for each function, including whether it's static (validate once, re-validate on change) or dynamic (validate initially, monitor continuously, re-validate on drift threshold or retraining).
4. Assign assurance activities proportional to that classification — scripted testing, unscripted testing, vendor documentation review, or ongoing statistical monitoring, per CSA's own risk logic.
5. Write the change control trigger for model changes explicitly into your SOP. Don't assume your existing "software change" trigger covers retraining. It usually doesn't, because whoever wrote it wasn't thinking about models when they wrote it.
6. Build the monitoring cadence into your management review, so drift isn't something a validation team discovers by accident eighteen months later.

That sequence takes longer than skipping to a test script, but it's the difference between a program that survives an audit and one that survives only until an inspector asks about your retraining records.

Common Pitfalls I See

The most frequent mistake is treating an AI model like a static software release and validating it once, the same way a spreadsheet macro gets validated once. That approach passes an initial audit and fails the second one, when the auditor asks how you know the model still performs the way it did when you validated it.

The second most frequent mistake runs the other direction: teams get spooked by AI's novelty and apply full scripted CSV-style testing to every AI touchpoint regardless of risk, defeating the entire point of CSA's risk-based approach and burning a validation budget on low-risk functions that never needed it.

The third is a documentation gap rather than a technical one: many quality systems still don't have a place to record a model version number the way they record a software version number. If your change control record can't answer "which version of the model made this decision," you have a traceability gap that has nothing to do with whether the model itself is any good.

FAQ

Does FDA's Computer Software Assurance guidance specifically mention artificial intelligence?

No. FDA's draft CSA guidance, issued September 13, 2022, addresses production and quality system software generally under 21 CFR 820.70(i) and does not contain AI-specific provisions. Manufacturers applying CSA to AI-enabled functions are extending its risk-based logic to a category of software the guidance wasn't written to anticipate, which is why pairing it with an AI-specific framework like ISO 42001 matters.

How is CSA different from Computer System Validation (CSV)?

CSV requires the same exhaustive, scripted testing regardless of how much risk a feature carries. CSA doesn't — it lets the risk assessment decide the testing method, so a low-risk feature might get nothing more than a vendor documentation review while a high-risk one still gets full scripted testing. The shift isn't less rigor; it's rigor aimed at where a failure would actually hurt product quality or patient safety.

What does "validated" mean for an AI model that can retrain itself?

For a static model, validated means the same thing it means for any software: tested against its intended use and unchanged since. For a model that retrains or updates on new data, validated has to include an ongoing monitoring commitment, since the behavior tested at release may not be the behavior running six months later. Your change control procedure needs a defined trigger, such as a performance-drift threshold or a scheduled retraining cadence, that forces re-assurance.

Does the new QMSR change how CSA applies?

No — QMSR harmonizes Part 820 with ISO 13485:2016, but it leaves the risk-based logic under 820.70(i) untouched. What changes is the stakes: those CSA programs are now running under an active harmonized regulation instead of a legacy Part 820 structure, so an AI extension that doesn't hold up gets tested by an actual inspector rather than a hypothetical one.

Where does ISO 42001 fit alongside CSA?

ISO 42001:2023 owns the AI-specific risk and lifecycle clauses (6.1.2, 6.1.3, 8.1, 9.1); CSA owns how much testing documentation a given function needs under 820.70(i). In practice, run the 42001 risk assessment first to see which AI functions need drift or retraining monitoring, then let your existing CSA validation SOP set the testing depth for each one.

If you're building out an AI-aware validation program and want a second set of eyes on where your current CSA approach has gaps, our GxP-compliant AI guidance walks through the validated-systems side of this in more depth, and the ISO 42001 definitive guide covers the AI management system clauses referenced above.

Last updated: 2026-09-07