AI/ML Systems × Validation × Data Governance
Computer system validation was built to prove code does what its spec says. A model has no full spec — its behaviour is learned from data — so validation and data governance stop being neighbours and become one object.
What this page does not claim
An intersection covers what happens only where two axes overlap. It does not restate what either parent page says, and it is not a substitute for reading them.
WHAT ONLY EXISTS IN THE OVERLAP
- Classic CSV traces requirements to tests: the specification is written, the code is built, the tests confirm the match. A model is not fully specified by its requirements — half of what it will do is decided by the data it learned from. That missing half of the specification is supplied by data governance, which is why the two disciplines cannot be run as separate workstreams here.
- Part 11 and Annex 11 controls were scoped to electronic records and the systems that hold them. In a learned system the training and test datasets are part of the validated configuration, so the audit trail, access control, and record-integrity expectations extend onto the data itself — not as a courtesy, but because the dataset is now a controlled record whose provenance the validation claim rests on.
- Retraining is the change-control event CSV never had a template for. Its impact assessment is a data-lineage and performance comparison, not a redlined functional spec, and its approval evidence is verification against independent test data. The overlap owns the question of how a change to the data becomes a governed change to the validated system.
- Test-data independence is the single control that makes a model's verification mean anything, and it is a data-governance property, not a test-execution one. If the governance regime cannot prove the evaluation data never touched training, the passing test result proves nothing — the model may simply be reciting what it memorised.
The specification is partly data
Computer system validation earns its assurance from a chain most practitioners can draw from memory: user and functional requirements, a design that satisfies them, and tests that demonstrate the built system does what was specified. The chain works because a deterministic system's behaviour is fully determined by its code and configuration — specify those, test those, and you have bounded what the system can do. A machine-learning model refuses to sit in that chain. Its requirements can state the intended use, the performance the model must reach, and the boundaries it must not cross, but they cannot state how it will behave case by case, because that is learned from data rather than written into logic. The requirements describe the envelope; the data decides the contents.
This is where CSV and data governance fuse rather than cooperate. The part of the specification the requirements cannot express is carried by the dataset — its composition, its labelling, its representativeness, its provenance — and those are exactly the objects data governance exists to control. Validating the model therefore means validating claims about data as rigorously as claims about code: that the training set represents the intended context of use, that critical but rare cases are present rather than swamped, that labelling was controlled and consistent. GAMP 5 Second Edition frames this directly by treating the model and its data lineage as the validated object, not the software shell around it. A CSV programme that validates the platform and waves the data through has validated the empty container and left the payload — the thing that actually determines behaviour — ungoverned.
The audit trail now has to cover the dataset
Part 11 and Annex 11 built their expectations around records and the systems that create them: attributable actions, secure and computer-generated audit trails, controlled access, protection of the record from undisclosed alteration. In a conventional system those controls sit on transactional data and configuration. In a learned system the training, validation, and test datasets are configuration — change them and you change what the system is — so the same controls have to reach onto the data. Who assembled the training set, from what sources, under what version, with what transformations applied, is now audit-trail material, because the answer is part of the evidence that the validated state is real.
The consequence is a set of records CSV programmes rarely maintained before: an immutable account of which dataset version trained which model version, verified against which held-out set, with what result. This is not documentation for its own sake — it is the only thing that lets a site answer the inspection question a model invites, which is not merely 'is the system validated' but 'which model made this decision, learned from what data, and how do you know that data was fit'. Access control extends the same way. Write access to a production dataset is write access to the system's future behaviour, so it belongs under the same segregation-of-duties discipline as access to a released configuration. A governance regime that can name every actor who could alter the dataset is defending the validation; one that cannot has a hole where the specification used to be.
Retraining is a change with a data-lineage impact assessment
Change control is CSV's mechanism for keeping the validated state true after release, and it is configured around a proposal with a describable impact: a specification changes, its effect is assessed, the change is verified. Retraining fits the frame and breaks its shape at once. It is unmistakably a change — new parameters mean new behaviour — so it must pass through change control. But its impact assessment is unlike anything the change system was built to read: the evidence is a comparison of training-data lineage between the old and new model, and a comparison of performance on independent test data against pre-set acceptance criteria, not a marked-up functional specification. A change programme that cannot represent that shape either blocks retraining because the paperwork does not fit, letting the model decay, or nods it through as a like-for-like update and loses the ability to say which version did what.
The device world has a construct worth borrowing here with its scope stated honestly. FDA's guidance on Predetermined Change Control Plans for AI-enabled device software functions lets a manufacturer pre-authorise a bounded envelope of model change — defined modifications, made by a defined method, verified against defined criteria — so that changes inside the envelope do not each re-open a submission. That is a marketing-submission concept for medical devices, not a GMP CSV instrument, and it should never be cited as if it governed a pharmaceutical manufacturing deployment. What it offers a CSV programme is the philosophy: a data-governance regime can pre-define the envelope of acceptable retraining — the data sources, the transformation rules, the acceptance criteria — so that a routine retrain executes as a controlled, pre-assessed change rather than a fresh validation each time, while anything outside the envelope drops back into full change assessment.
Independence is a governance control, not a test detail
Every model verification rests on one assumption that CSV's traditional test design never had to police: that the data used to judge the model is genuinely separate from the data used to build it. Break that separation — let a few test records leak into training, or let the same subject appear on both sides — and the verification measures memorisation instead of capability. The model scores brilliantly on evaluation and fails in production, and the passing test report actively conceals the failure. No amount of test-execution rigour detects this, because the test ran correctly against contaminated data. The control lives upstream, in how the datasets were partitioned and kept apart, which makes it a data-governance responsibility that the validation depends on completely.
This inverts a familiar CSV instinct. In conventional validation the test evidence is the strong artefact and the data behind it is assumed sound; here the data partitioning is the load-bearing control and the test result is only as trustworthy as that partitioning was governed. So the validation package has to carry evidence a CSV programme rarely produced: how train, validation, and test sets were defined, how leakage was prevented, and how the independence was maintained through every retraining cycle. Annex 11's expectation that data be protected and its integrity assured, read onto this problem, is what forces the partitioning to be a documented, controlled boundary rather than a convenience of whoever assembled the files. A site that treats it as a modelling nicety will pass its own tests and be surprised only in production — or in front of an inspector who asks to see how the test set was kept clean.
Derived from the 4 standards SPEQ maps to this intersection, across 3 regulatory bodies: FDA, EMA, ISPE.
FREQUENTLY ASKED
Why can't a model be validated the way any other computerised system is?
Because the usual CSV chain — requirements, design, tests that confirm the design — assumes behaviour is fully determined by code and configuration, and a model's behaviour is not. Its requirements can set the intended use, the performance target, and the operating boundaries, but how it acts case by case is learned from data. The part of the specification that logic cannot express is carried by the dataset, so validation has to extend onto data governance: proving the training data is representative, controlled, and traceable, and that the evaluation data was genuinely independent. Validate the platform alone and you have qualified an empty container while the thing that decides behaviour stays ungoverned.
Do Part 11 and Annex 11 controls apply to training data?
Yes, because in a learned system the training, validation, and test datasets are part of the validated configuration — change them and you change what the system is. That pulls the record-integrity expectations onto the data itself: an audit trail of who assembled which dataset version from what sources with what transformations, access control over anyone who could alter it, and an immutable link recording which dataset trained which model version and how it was verified. These are the records that let a site answer the real inspection question, which is not only whether the system is validated but which model made a given decision, learned from what data, and how the site knows that data was fit for it.
Does the FDA Predetermined Change Control Plan concept apply to a GMP AI deployment?
Not as a governing framework — its stated scope is AI-enabled medical-device software functions and their marketing submissions, so citing it as if it authorised change to a pharmaceutical manufacturing model would be a scope error. What it lends a GMP CSV programme is its philosophy. A data-governance regime can pre-define an envelope of acceptable retraining — the permitted data sources, the transformation rules, and the acceptance criteria a retrained model must meet — so that a routine retrain executes as a controlled, pre-assessed change rather than a full revalidation each cycle. Anything outside that envelope drops back into full change assessment. The predicate rules and GAMP 5 remain the frame the deployment actually answers to.
What makes test-data independence a data-governance problem rather than a testing one?
Because the failure happens before any test runs. If evaluation records leak into training, or the same subject sits on both sides of the split, the verification measures what the model memorised rather than what it can do — and it does so silently, producing an excellent test report that conceals a production failure. Test-execution rigour cannot catch this, because the test ran correctly against contaminated data. The control lives in how the datasets were partitioned and kept apart across every retraining cycle, which is a governance responsibility. So the validation package must evidence the partitioning and the leakage prevention, not just the test outcome — the result is only as trustworthy as the independence behind it.