A GxP assessment for an AI pilot has to settle two things before anyone argues about sample sizes: whether the system falls under GxP at all, and, if it does, how much assurance each of its functions needs. The first is a documented impact classification (direct, indirect or no impact), reached through a structured decision tree plus a narrative written for that specific system. The second is a Computer Software Assurance (CSA) record that states the intended use, the result of the risk-based analysis, the assurance activities performed, the issues found and a conclusion on acceptability. A one-week sampling protocol is defensible only as evidence inside that record, never as a substitute for it.
Does this AI pilot fall under GxP at all?
Check regulatory scope before planning any validation. Many parts of a life-sciences pipeline sit outside the regulated portion even when the company assumes everything is constrained, and the assumption itself is a real barrier to adoption.
The tool for settling scope is the GxP assessment form, a controlled document that evaluates whether a system has a direct or indirect impact on product quality, patient safety or data integrity, and therefore needs formal validation. It exists to prevent two opposite failures: validating systems that do not need it, and leaving unvalidated systems that do. FDA does not prescribe a form by that name, but its data integrity and CSA guidance both expect a system’s GxP relevance to be determined before validation scope is decided, and GAMP 5 formalises the step as the Impact Assessment that precedes software category assignment.
Direct, indirect and no impact: how GxP and non-GxP systems differ
| Impact class | What puts a system there | Typical examples | Closest FDA CSA category |
|---|---|---|---|
| Direct | Controls, monitors or generates data used in product quality decisions or regulatory submissions | LIMS, electronic batch record, MES, QMS for quality events | Software used directly in production or the quality system: automating production, inspection, testing or quality records |
| Indirect | Supports a direct-impact system without itself touching product or GxP records | Building management monitoring (not controlling) temperature, IT monitoring of GxP servers, backup infrastructure | Supporting software: development and test tools, general record-keeping outside the quality record |
| No impact | No connection to product quality, patient safety or data integrity | HR systems, office productivity tools | Out of scope: general business software such as email or accounting, and infrastructure such as networking, authentication or backup and restore |
The two classification schemes do not line up perfectly. The FDA CSA guidance treats backup and networking infrastructure as outside validation requirements, while EU GMP Annex 11 requires IT infrastructure to be qualified and backup to be validated, a contradiction R.D. McDowall pointed out in the 2023 draft guidance, in Spectroscopy. A site inspected under EU GMP should not lean on the FDA exclusion; the stricter reading is the safer one wherever both regimes apply.
The decision tree questions
A structured decision tree walks the assessor through the system’s relationship to product, data and regulatory obligations:
- Does the system create, modify, store or transmit data used in batch release, quality decisions or regulatory submissions?
- Does it directly control a critical process parameter or quality attribute?
- Does it generate electronic records that serve as the primary GMP record?
- Does it interface with a direct-impact system in a way that could affect that system’s data integrity?
- Is it used in GLP, GCP or GDP activities that affect product safety or regulatory data?
- Would its failure create a patient safety or product quality risk that goes undetected before release?
For an AI pilot, we would treat the third question, asked honestly, as the one that decides the class. A summarisation model that drafts text a qualified person reviews and corrects is in a very different place from one whose output is filed unreviewed as the record of what happened.
The tree gives completeness; it does not give credibility on its own. Inspectors pick two or three systems and compare their rationales, and a LIMS and an HR system with identical reasoning tells them the assessment was filled in without analysis. That is why the defensible form combines yes/no questions with a required narrative explaining the rationale for this particular system. A no-impact outcome still needs a controlled, signed document, which can be as brief as two or three paragraphs on the system’s function, why it has no GxP connection and who approved the call. The broader picture of what GxP compliance requires of AI software in pharma sits upstream of this form: the form is where that understanding becomes a signed decision for one system.
Function-level risk sets the depth of computer system assurance
Once a system is in scope, FDA describes computer software assurance as a risk-based approach for establishing and maintaining confidence that software is fit for its intended use, following a least-burdensome principle in which validation effort is no more than the risk requires. The unit of that risk is the function, not the system: a single eQMS can hold a high-risk automated lot disposition alongside low-risk document routing, and CSA calibrates each one separately.
FDA treats a function as high process risk when its failure may cause a quality problem that foreseeably compromises safety, for example maintaining process parameters essential to device safety, or determining product acceptability with limited or no human review. Everything else is “not high process risk”, and a manufacturer that grades a function as moderate or low falls under that branch. Human review changes the answer: in FDA’s own example, an ERP restocking feature that could deliver the wrong materials is rated intermediate risk because a qualified person checks materials before use. Other controls in the quality system can likewise reduce the assurance effort a function needs.
The guidance does not prescribe a risk tool, but the assessment has to consider intended use, severity of harm, likelihood of failure and detectability through existing controls, applied as one documented methodology across the portfolio. ICH Q9(R1) gives the underlying definition: risk is the combination of the probability of harm and its severity.
Where CSA’s authority stops
The dates matter for anyone citing the guidance. Sakara Digital records the final CSA guidance as published on 24 September 2025, and Scilife reports a revised final version on 3 February 2026 that superseded it and aligned it with the QMSR amendments to 21 CFR Part 820. Its formal scope is software used in medical device production and quality management systems, with its principles being adopted more widely in pharmaceutical and biotech settings. McDowall’s caution still holds: CSA supplements FDA’s General Principles of Software Validation rather than replacing it, and Scilife likewise describes CSA as a way of performing validation, not a substitute for it. A pharmaceutical team should read CSA as a method for proportionate evidence, not as permission to drop documentation.
Writing the GxP assessment rationale for a one-week sampling protocol
To make a one-week sample count as a system impact assessment rather than skipped validation, write the risk rationale first and attach the sample to it as evidence. The rationale names the intended use, records the risk determination per function and justifies the assurance approach selected for each function. Regulators across regimes expect exactly this justification: Annex 11 requires manufacturers to justify their protocols and acceptance criteria based on their risk assessment, and PIC/S asks regulated users to defend their standards and records against their own documented risk assessments.
The framing that makes a lighter touch legitimate comes from ICH Q9(R1): the level of effort, formality and documentation should be commensurate with the level of risk. The same guideline lists justifying reduced in-process control testing under conditions of proven control as a use of quality risk management. Read the same way, a short sample is a reduced-testing decision that needs its conditions stated, and the record has to show what those conditions are.
Is one week long enough?
One week has to be justified functionally against what the pilot will meet in use. FDA’s General Principles of Software Validation say user-site testing should run across the full range of operating conditions and for long enough to encounter a wide spectrum of conditions and events, in order to expose latent faults that normal activity hides. The same guidance warns that testing alone is limited in its ability to surface latent defects, and that confidence comes from a mix of methods.
In practice, we would list the conditions the pilot must see (document types, volume peaks, shift or rota patterns, any periodic process such as month-end reporting) and show which ones fell inside the sample window. Where a known condition does not occur within a week, either extend the window or add targeted cases for it, and say so in the rationale. Statistical tools can support the significance argument where the volumes allow it.
What the CSA record holds, by risk tier
| Record element | Not high process risk (unscripted testing) | High process risk (scripted protocol) |
|---|---|---|
| Intended use | Required | Required |
| Result of risk-based analysis | Required | Required |
| Testing description | Summary of the failure modes tested | Detailed protocol and detailed test report |
| Pass/fail results | Outcomes recorded in the testing summary, not as per-case pass/fail | For each test case |
| Issues found | Required | Required |
| Conclusion on acceptability, with issue resolution | Required | Required |
| Who tested and when | Required | Required |
| Signature of signatory authority per SOP | Review and approval when appropriate | Required |
For unscripted sessions, the record should also capture the scope and objective, the software version and environment, a summary of what was tested and observed, and any defects, though it need not be a formal protocol; logs, screenshots, recordings and narrative summaries all count. FDA prefers system logs, audit trails and other software-generated data over paper and screenshots as the least-burdensome evidence. Low risk lightens the documentation but never removes it, and a verbal assertion that testing happened is not evidence.
What an auditor will want to see if they ask why the pilot was approved on a one-week sample
Inspectors working under CSA ask “why” questions more often, and they check whether the organisation can explain its assurance decisions. The minimum package that answers them:
- The impact classification and the function-level risk assessment it led to.
- The rationale for sample size and duration, tied to the operating conditions covered.
- The pre-determined acceptance or pass/fail criteria.
- The results obtained, including deviations and how each was resolved.
- Change control and periodic review records showing assurance continues after the pilot.
- Signatures from the author, technical reviewer and QA approver, with dates, on the impact assessment.
Your compliance review must sign off on the specific rationale used.
When the sample should not carry the decision
If any function feeding the pilot is high process risk, or the sample results are ambiguous, escalate before approval. For high-risk functions FDA suggests considering scripted testing or a hybrid of scripted and unscripted testing. In its high-risk example the manufacturer adds a detailed scripted protocol with repeatability testing across scenarios. FDA also notes that unscripted testing can still suit some high-risk functions, so the escalation is towards more rigour and evidence, not automatically towards scripts.
After the pilot: monitoring and reassessment triggers
Approval starts the lifecycle; it does not close it. A change that alters how the system is used, what data it processes or how it interacts with other GxP systems should trigger a reassessment of the original classification. Annex 11 adds periodic evaluation to confirm systems remain in a valid state, and FDA’s software validation guidance treats any change, even a small one, as requiring the validation status to be re-established. For an AI pilot, we would write the triggers out explicitly: a retrained or replaced model, a new department or document type, and any move of the output towards becoming the primary record. The model-side work that follows, scoping validation depth from risk tiering to evidence packs, covers how deep model validation should go before go-live.
Scoring departments for a phased pilot rollout
A pre-pilot documentation audit can score each department separately against one predefined rubric, so a department below a documented threshold goes to remediation while those above it join the pilot; there is no need for a single go/no-go across the organisation. TechnoLynx’s AI Readiness Scorecard scores an AI programme against a named published rubric, with an evidence trail and a remediation backlog.
Phasing has regulatory precedent. PIC/S notes that large enterprise systems may be tested in pilot mode first, followed by a controlled roll-out to the user environment. And documentation consistency is a fair thing to score, because MHRA notes that risks to data rise with complex, inconsistent processes with open-ended, subjective outcomes. For a summarisation model, inconsistent source records are a direct input risk: the model cannot be more consistent than what it is summarising.
What score threshold should disqualify a department from the initial pilot?
The cut-off for documentation readiness is a judgement that has to be argued and documented. ICH Q9(R1) gives the mechanism: risk ranking and filtering combines several factors into a single relative score, with filters in the form of weighting factors or cut-offs fitted to management or policy objectives. We would set the cut-off from evidence in the sample, by checking where summarisation errors begin to rise as documentation consistency falls, rather than picking a round number.
| Tier | Condition (set by your rubric) | What happens |
|---|---|---|
| Pilot-ready | At or above the threshold, no hard-gate failures | Joins the first phase under the CSA record above |
| Remediation needed | Below the threshold but fixable | Remediation plan with priorities, interim risk-reducing measures, rescored before inclusion |
| Disqualified | Fails a hard gate, for example shared logins on GxP data or audit trails not enabled | Excluded from this pilot until the control gap is closed |
WHO’s data integrity guideline supports the middle tier directly: where remediation is identified, its prioritisation and any accepted residual risk should be documented, and short-term measures should keep data governance acceptable in the interim. WHO’s data integrity risk assessments also evaluate personnel, training and quality systems alongside the computerised systems.
Three limits belong in the write-up. The rubric scores documentation consistency only; it does not certify clinical safety or summarisation accuracy. A small or unrepresentative sample within a department can misclassify it, so record the sample size per department next to the score. Thresholds set once go stale as documentation practice or the NLP tooling changes, so add them to the reassessment triggers. This is a data and process decision; it has nothing to do with hardware or serving infrastructure.
Who can help us score departments and document the assessment?
TechnoLynx does the engineering side of this for life-sciences teams through its AI Readiness Scorecard: scoring department readiness against a named rubric, with an evidence trail and a remediation backlog, starting by agreeing the rubric and threshold with the pilot owner and QA. Building it in-house makes sense when your quality unit already runs CSA and someone on the team understands how the model fails. A specialist pays off when the AI system’s failure modes are the open question. When choosing a partner, ask whether they will write function-level evidence your QA can sign, not just a model report.
Some things stay outside that engagement. TechnoLynx does not give regulatory sign-off or decide GxP classification for you; the regulated user keeps ultimate responsibility for that. A team validating a conventional, non-AI system under an established CSV or CSA procedure probably does not need us at all.
FAQ
Does CSA apply to pharmaceutical companies?
FDA’s CSA guidance formally covers medical device production and quality system software, but its principles are being adopted across pharma and biotech. McDowall argued of the 2023 draft that only a little of it could be transferred to pharmaceutical GxP.
