An AI/ML SaMD validation study is only as credible as the evidence trail around it. The reviewer has to be able to reconstruct the study: which data went in, which model version was tested, who changed what and when. That depends on computer system assurance for the systems involved, sequestered test data, attributable audit trails, tested backups and independent review. Treat that trail as an engineering output in its own right. It should be scaled to risk, time-stamped, attributable to an individual and reconstructable from retained data and metadata.
TechnoLynx builds this evidence as engineering work for teams in AI engineering for life sciences and healthcare: lineage capture, versioned artefacts, audit logging and the infrastructure records behind them. We do not provide regulatory sign-off or certification. The first step in a TechnoLynx engagement is to list the artefact classes this particular study has to produce.
Researchers who audited public FDA summary reports for AI/ML-enabled devices found traceability evidence in only 8.3% of them (43 of 519). The authors say this measures how transparent the public reports are, not whether the devices comply. Even so, it shows how rarely provenance and audit evidence is presented in a form outsiders can check.
How do we prove the reader study set never overlapped with training or analytical validation data?
You show that test data were kept apart from development with documented sequestration controls and records. That record should show the test data were never used in training, tuning or validation of the model. FDA’s draft guidance on AI-enabled device software functions says reviewers need to know whether test data are independent of the training data (for example, drawn from entirely different clinical sites) and kept away from the model developers and the development stage. The submission should explain how development data were split into training, tuning and tuning-evaluation subsets. It should also describe the controls that keep test data out of development and justify why the validation counts as robust external validation.
The EU’s draft GMP Annex 22 on artificial intelligence sets out the mechanics. Test data should either be captured only after training and validation are complete, or split from the full pool before training starts. If the split comes first, nobody involved in development may ever have had access to the test data, which sits behind access control with an audit trail logging every access and change, and no copies may exist outside that repository. People who have had access to test data should be kept out of training and validation of the same model. Where an organisation cannot manage that, they may work on it only alongside a colleague who has not had access (the four-eyes principle). FDA’s AI/ML discussion paper asks for the same discipline in its own words: an auditing and sequestration strategy that documents test dataset independence and controls access to training and test data as new data is added.
Provenance tooling helps trace this. Provenance systems can give a unique identifier to every data value that passes through a transformation, so the path from raw file to learned model stays linked. They also distinguish prospective provenance (the planned workflow) from retrospective provenance (the data actually consumed and produced, plus an execution log). For a medical imaging study, base the overlap check on a stable pseudonymous patient key, image content hashes and acquisition dates. Run it across every subset, including any a data vendor supplied.
There are two caveats. The check is only as good as the identifiers behind it: de-identification that re-keys patients differently in different exports can hide a genuine overlap. Provenance also has to cover every processing stage, not only the final split. Run the verification as a gate before the technical file is finalised. If it finds overlap, remove or re-source the affected cases before submission rather than disclosing the overlap afterwards and arguing it did not matter.
Which artefacts from the validation study must be kept for the submission, and for how long?
Keep everything a reviewer would need to rerun the validation exactly: the locked validation dataset with its version and provenance, the exact model checkpoint and configuration, the lineage records, the access and change logs, and the protocol, statistical analysis plan and results. TechnoLynx can add this lineage and version capture to an existing training and validation pipeline, check that the captured artefacts rebuild the reported run, and set up access-controlled storage that meets the retention requirement.
FDA’s draft AI guidance asks for a version history that shows any differences between the tested model and the released model. The reason is to show the model was not adjusted after the fact in light of the test data. It also suggests recording the device version or state used for each patient during the study, ideally captured automatically in an eCRF or EDC system.
Validation evidence checklist for an AI SaMD study
| Artefact class | What to retain | Why a reviewer needs it |
|---|---|---|
| Validation dataset | Raw and processed data, version hash, site and acquisition-period metadata | FDA asks for data sources, sites and collection period, with sites named consistently |
| Model artefacts | Checkpoint, training configuration, hyperparameters, pipeline code version | Tested versus released model differences must be explained |
| Software environment | All versions of application software, operating systems and tools that processed the data | They should remain available as long as the associated records are retained |
| Audit trail | Who, what (old and new value), when (with time zone where applicable) and why for each change | Draft Annex 11 asks for this content; FDA, MHRA and EMA texts set similar expectations |
| Access records | User list, roles, the date each was granted and every change to rights | FDA expects a record of authorised personnel and their privileges |
| Protocol and analysis | Study protocol, statistical analysis plan, protocol deviations | FDA asks for all protocols and SAPs, and for protocol changes and deviations to be explained |
| Backup and recovery logs | Backup, restore-test and recovery records | They let a reviewer assess the scope of any data loss |
Where the evidence is digital, FDA’s computer software assurance guidance recommends using system logs, audit trails and other data the software generates as objective evidence, rather than screenshots or paper copies of results the system already holds. That record should state the intended use, the result of the risk analysis, the testing done, any issues found and a conclusion on acceptability. For a more complete treatment of how these pieces become one reviewable dossier, see our guide to building an audit-ready model documentation and approval package.
Retention periods differ between regulators and record types, so confirm the period with regulatory affairs rather than assuming one. Two examples show the range. FDA’s data integrity guidance for bioavailability and bioequivalence studies asks for study data to be archived for at least five years, starting within two weeks of study completion. EMA’s clinical-trial guideline ties availability to the full legally mandated duration and to local legal requirements. Under FDA’s clinical-trial guidance, audit trails must be kept at least as long as the records they relate to.
Format expectations differ between regulators too. FDA has said it will not object to archiving required records as PDF, XML or similar standard formats, provided their content and meaning are preserved. The EU’s draft Annex 11 says flat, locked files are not acceptable for a complete electronic copy of system data, which must be searchable and sortable. If a study may be used in both jurisdictions, make archive copies searchable and sortable, as the draft Annex 11 asks. When data move to an archive, check their integrity (for example with a checksum) before deleting the source.
Does the server and access-control environment hosting the AI workload need computer system assurance?
Yes, where it stores quality-system records, as FDA’s CSA guidance example shows. Treat the infrastructure as part of the computerised system, not as neutral plumbing. FDA’s drug CGMP data integrity guidance defines computer systems to include hardware, networks, cloud infrastructure, personnel and the associated documentation. FDA’s CSA guidance gives an example: an IaaS storage service is infrastructure, but once it stores quality records it counts as used directly in the quality system. Assurance effort should then focus on record integrity and the applicable 21 CFR Part 11 controls. ISPE’s GAMP 5 Second Edition added an appendix on risk-based management of infrastructure, whether on site or supplied as IaaS, PaaS or SaaS.
The US position on Part 11 needs to be read carefully, because two FDA texts treat validation differently. The Part 11 scope and application guidance says FDA will exercise enforcement discretion on Part 11’s own validation requirement. That same guidance says predicate-rule validation requirements still apply, and recommends basing the validation decision on a justified, documented risk assessment. The CSA guidance then states that this discretion expressly does not apply to validation of production and quality-system software under ISO 13485. Read together, the practical result is a written, risk-based justification of what was validated and why, not an assumption that discretion removes the obligation.
Is CSA a replacement for CSV?
No: CSA is a risk-based way of meeting existing validation requirements, not a replacement for them. FDA describes computer software assurance as a risk-based way to establish confidence in software used for production or the quality management system, and to generate the objective evidence that existing validation requirements call for. The current version is the final guidance issued in February 2026, which supersedes the version issued on 24 September 2025. Like all FDA guidance, it sets out the agency’s current thinking rather than new requirements, and it points readers to GAMP 5. It explicitly covers AI/ML tools and cloud computing used in production or the quality system.
Two consequences follow for an AI study environment. First, CSA’s scope is production and quality-system software. For clinical-investigation records, FDA’s guidance on electronic systems in clinical investigations recommends risk-based validation from design to decommissioning. Second, risk-based assurance focuses effort according to risk rather than removing it. For record-holding systems, FDA recommends focusing assurance on features relevant to record integrity and Part 11. The CSA guidance’s own example includes unscripted attempts to “break” the system, for instance by trying to delete the audit trail. The written risk assessment is what an inspector reads, and lighter testing of a low-risk function is defensible only when the reasoning is recorded.
Software upgrades and security patches need to be evaluated and validated across the system’s lifecycle according to risk, and every change documented. An environment validated once and then patched without change control does not stay validated, whichever method was used at the start.
What uptime and disaster-recovery commitments should the study have in writing?
Regulators ask for written, tested backup and disaster-recovery arrangements. For uptime itself, a published SLA shows what a written commitment looks like. One academic platform’s SLA, for example, commits to 99.5% monthly availability, no more than 80 minutes of unplanned outage a month and seven days of rolling daily backups.
The PIC/S guidance on computerised systems in GxP environments sets out a detailed baseline. It calls for routine backups, at a risk-based frequency, to storage kept well apart from the primary location. All GxP data, including audit trails, should be backed up. There should be a test plan for backup and disaster-recovery procedures, a log of backup tests with dates and results, and a record of any error fixed. Other regulators set similar expectations. The draft Annex 11 asks for replication to a geographically separate failover site and a tested disaster-recovery plan. EMA asks for backups in separate physical locations and logical networks, with documented restore tests. FDA asks for periodically tested backup procedures and backup and recovery logs.
What happens to the evidence if the system goes down mid-study? FDA says the purpose of backup and recovery logs is to support an assessment of the nature and scope of any data loss after a system failure. Complete backup and recovery logs support that assessment after an outage. An outage without them leaves a gap nobody can bound. Plan for the outage itself as well. FDA lists alternative data entry methods for times when the system is unavailable among the things a sponsor should document. Annex 11 (2011) asks for documented, tested continuity arrangements for systems that support critical processes.
Is your current hardware acceptable, or do you need a validated clinical ML platform? A practical order for the decision: first set the uptime target and the maximum tolerable data-loss window, based on study length and submission timeline. Then ask whether the current hardware can be shown, with records, to meet them. If it can, write those commitments into the study plan. If it cannot, move before the study starts. Whichever platform you choose, check what the vendor actually qualified. MHRA warns that vendor-supplied validation data, taken in isolation from the system’s configuration and intended use, is not acceptable. In FDA’s CSA guidance example, the SaaS service agreement covers security, data integrity, privacy, availability, change management and business continuity. Migrating data to a new platform mid-study means the transcription process has to be validated. EMA’s clinical-trial guideline also expects the audit trail to stay joined to the data it describes during migration.
How should periodic audit-trail reviews be signed off, and what happens when one finds an anomaly?
A periodic audit-trail review needs a documented procedure, a reviewer not involved in the activity, a signed record and documented follow-up of any finding. The draft Annex 11 asks for a written procedure per system or type of system, saying who reviews, what they review and when. Any significant variation found must be investigated and recorded. The reviewer should not be directly involved in the activities under review. EMA’s clinical-trial guideline asks for risk-based, trial-specific audit-trail review procedures and documented data review. The aims include spotting missing data, signs of manipulation, unauthorised access and system malfunction.
One practitioner glossary describes what a usable review record contains: the reviewer, the period reviewed, the scope, the findings, any follow-up (investigations, deviations or CAPAs) and an explicit conclusion, all held as a controlled document. The same source says there is no single regulator-mandated review frequency, and that cadence scales with the criticality of the records. For software anomalies, FDA’s software validation guidance calls for root-cause analysis and documented corrective and preventive action where a trend appears. FDA’s guidance on electronic systems in clinical investigations lists CAPAs that address data-integrity errors among its inspection focus areas.
The AI module’s own audit trail deserves a direct question. The draft Annex 11 expects audit-trail functionality on any system where users create, modify or delete data or settings. If the model-serving component was brought into the SOP’s scope only after someone found a gap, make sure the scope change was formally documented and approved under document control. Even then, an inspector may read a late addition as evidence of an earlier traceability gap, so the remediation record needs to be as clean as the current state. When reviews are infrequent, look at the full history rather than the last three records alone. Three annual reviews say little about whether the procedure actually works.
Should an independent biostatistics core or CRO run the validation analysis?
If an ethics board or regulator needs to see that the developer did not grade its own homework, yes: an external academic biostatistics core or CRO is the most defensible option. FDA’s software validation guidance names “independence of review” as a basic quality-assurance principle, notes that self-validation is extremely difficult, and says independent evaluation is better especially for higher-risk applications. It also accepts that third-party verification is not always feasible, in which case qualified internal staff not involved in the design are the fallback. Whoever runs the analysis, the manufacturer keeps ultimate responsibility for the validation.
Choosing between the two is a judgement call. Independence alone does not guarantee quality, so vet the partner’s protocol and expertise either way. Get competitive quotes once the validation plan and the data-access model are fixed, because those two decisions drive the scope.
Data governance does not transfer with the work. EMA states that a sponsor can delegate tasks but keeps full responsibility for data integrity, security and confidentiality. EMA also expects signed written agreements before any work starts, with audit rights over the vendor written into them. MHRA asks contract givers to include data ownership, governance and accessibility in the agreement, and to review data governance as part of vendor assurance. The ACRO and TransCelerate data governance framework names the roles worth assigning explicitly, including a data custodian for the technical environment, a data reviewer whose duties include audit-trail review and a data archivist who tracks archived data until disposal.
For privacy, settle the mechanism before the external party starts: de-identified extracts, a secure analysis enclave or controlled on-site access. FDA’s draft AI guidance lists access controls, encryption and anonymisation or de-identification among the controls against data leakage.
The evidence has to exist before the study starts
Several of the controls above cannot be added after the fact. Test data that developers have already seen cannot be re-sequestered, and an access log that was never switched on cannot be rebuilt. In engineering terms, the evidentiary backbone belongs in the study protocol and the pipeline design, built alongside the model, not assembled at submission time. FDA expects manufacturers to monitor AI-enabled devices for performance changes and to manage those risks under the Quality System Regulation, including design changes and CAPA.
FAQ
What is the difference between 21 CFR Part 11 and Annex 11?
Part 11 is the FDA regulation covering electronic records created, modified, maintained, archived, retrieved or transmitted under the agency’s records requirements. Annex 11 is the EU GMP annex on validating computerised systems, published in EudraLex Volume 4. FDA guidance and the draft Annex 11 differ in detail, for example on acceptable archive formats.
Can an audit trail be deleted or switched off?
Users should not be able to edit audit-trail data, and the draft Annex 11 expects any deactivation or settings change to create its own audit-trail entry. FDA’s clinical-trial guidance says the people who create or modify records should not be able to modify the audit trails.
What is GAMP 5?
GAMP 5 is ISPE’s guide to computerised system practice, and its second edition added appendices on AI/ML and on infrastructure. It is an ISPE industry guide that FDA’s CSA guidance refers readers to.
