On this page
The 10 Good Machine Learning Practice (GMLP) guiding principles were jointly issued by FDA, Health Canada, and MHRA in October 2021. They are short, broadly worded, and easy to nod along to in a slide deck. The hard part is operationalizing them inside an actual QMS and engineering pipeline. This guide maps each principle to concrete controls.
Talk to an AI/ML expert · AI/ML Medical Device Security Service →
How to use this crosswalk
For each principle, we list (a) what the principle says in plain English, (b) the engineering controls that satisfy it, and (c) the documentation reviewers expect to see. Map this against your existing QMS to find the gaps.
1. Multi-disciplinary expertise applied throughout the lifecycle
What it means: Software, clinical, regulatory, human factors, cybersecurity, and data-science expertise are involved from concept through postmarket.
Engineering controls: Cross-functional design reviews at each gate; documented role assignments; clinical and human-factors representation on change-control board.
Documentation: DHF entries showing multi-disciplinary review, RACI for the AI program, training records.
2. Good software engineering and security practices
What it means: Secure SDLC applies to AI components, including training pipelines and data infrastructure.
Engineering controls: Version control for code, models, datasets, and configs; CI/CD with automated testing; secrets management; SAST/DAST; reproducible builds; signed model artifacts; supply-chain controls for third-party models and dependencies.
Documentation: Secure SDLC procedure, SBOM (including ML-BOM with model and dataset provenance), threat model, pen test report.
3. Clinical study participants and data sets are representative of the intended patient population
What it means: Training and validation data reflect the demographics, settings, and clinical realities the device will see.
Engineering controls: Documented data-sourcing strategy; representativeness analysis (age, sex, race/ethnicity, comorbidities, sites, devices) before training; gap-fill plan when subgroups are under-represented.
Documentation: Data management plan, dataset cards, representativeness report, subgroup-coverage matrix.
4. Training data sets are independent of test sets
What it means: No leakage between train, validation, and test sets - by patient, by site, by time.
Engineering controls: Patient-level (not record-level) splits; temporal hold-outs for time-sensitive models; site-level hold-outs for generalization claims; automated leakage checks in the training pipeline.
Documentation: Split methodology in the data management plan; leakage-check results in validation report.
5. Selected reference datasets are based upon best available methods
What it means: Ground truth labels are produced by a defensible, reproducible process.
Engineering controls: Multi-reader labeling with adjudication; documented label schema and edge cases; inter-rater agreement metrics; periodic label audits.
Documentation: Labeling SOP, reader credentials, agreement metrics, audit logs.
6. Model design is tailored to the available data and reflects the intended use of the device
What it means: The architecture and training approach fit the data volume, signal characteristics, and clinical question - not just whatever is fashionable.
Engineering controls: Documented architecture-selection rationale; complexity justified by data volume and noise; explicit handling of class imbalance, missing data, and uncertainty.
Documentation: Model design rationale section in the submission; experiment log showing alternatives considered.
7. Focus is placed on the performance of the human-AI team
What it means: The model is not evaluated in isolation - it is evaluated as part of the human workflow it supports.
Engineering controls: Human-factors evaluation; reader studies that compare unaided vs AI-assisted performance; automation-bias and over-reliance assessment.
Documentation: Human-factors report, reader-study results, IFU language addressing appropriate reliance and disagreement handling.
8. Testing demonstrates device performance during clinically relevant conditions
What it means: Performance is shown across the conditions the device will encounter, including subgroups and edge cases.
Engineering controls: Stratified evaluation across demographics, sites, scanner/sensor vendors, and clinical contexts; failure-mode characterization on edge cases; robustness testing.
Documentation: Validation report with subgroup tables and confidence intervals; edge-case test catalog.
9. Users are provided clear, essential information
What it means: Transparency to users about what the model does, how it performs, its inputs and limitations.
Engineering controls: Model-card-style summary in labeling; subgroup performance disclosed where clinically relevant; explicit statement of intended use, environment, and limitations.
Documentation: Transparency labeling, IFU performance section, user-facing release notes for new versions.
10. Deployed models are monitored for performance and re-training risks are managed
What it means: Ongoing performance, drift, and bias monitoring with documented thresholds and responses; retraining is controlled.
Engineering controls: Telemetry for input distribution, output distribution, and (where feasible) outcomes; drift detection; subgroup performance dashboards; alert thresholds tied to PCCP triggers; rollback capability.
Documentation: Postmarket monitoring plan, PCCP, drift-incident response procedure, periodic monitoring reports.
How GMLP maps into your submission
The 10 principles do not have a dedicated section in a 510(k) - they show up as evidence inside the standard sections: design controls, software documentation, risk management file, cybersecurity documentation, validation report, labeling, and PCCP. A practical move is to maintain a GMLP traceability matrix internally that points each principle to the documents and controls that satisfy it, so when a reviewer asks, the answer is one row in a table.
Where GMLP and cybersecurity actually collide
Four of the ten principles create security work that teams routinely miss because they read as data-science concerns.
Principle 2 is the obvious one, and the one most often underscoped. Applying a secure SDLC to the AI components means the training pipeline is in scope: the data lake, the labeling tooling, the experiment tracker, the model registry, and the credentials that move artifacts between them. A model registry with shared credentials and no audit trail is a supply-chain weakness in the device, even though it never ships with the device.
Principle 4 has an integrity dimension. Train/test independence protects performance claims, but the same controls protect against undetected data poisoning. If an attacker can write to the training set and to the test set, contaminated data will validate cleanly. Separate write paths and separate access controls for the two corpora, and record dataset hashes at split time.
Principle 7 shapes your harm analysis. Human-AI team performance means the clinician is a compensating control in your risk file. That cuts both ways: an attack that erodes trust calibration (subtle output manipulation that stays inside the plausible range) is more dangerous than an obvious failure, because the human-in-the-loop mitigation you claimed in the risk assessment stops working. Enumerate that as a threat explicitly.
Principle 10 is your postmarket security signal. Monitoring for performance drift and monitoring for exploitation share infrastructure. A sudden distribution shift in inputs is either a population change, a sensor fault, or an adversary probing the input space. If drift alerts route only to the data-science team, the security team never sees the first indication of an attack. Route them to one intake and triage both hypotheses.
Documentation set that satisfies both reviewers
A GMLP crosswalk is most useful when it produces a named artifact list rather than a set of intentions. For an AI-enabled device we expect to see:
| Artifact | Primary GMLP principles | Where it lands |
|---|---|---|
| Data management plan (sourcing, splits, representativeness) | 3, 4, 5 | Submission, DHF |
| Dataset cards and labeling SOP | 5 | DHF, referenced in submission |
| Model design rationale and experiment log | 6 | Submission |
| ML-BOM (models, runtimes, datasets by reference) | 2 | SBOM attachment |
| AI-aware threat model | 2, 7 | Threat model attachment |
| Adversarial and conventional test reports | 2, 8 | Testing attachment |
| Human factors and labeling for AI outputs | 7, 9 | Labeling attachment |
| Drift and security monitoring plan, with PCCP if applicable | 10 | Postmarket plan |
The pattern to avoid is a standalone "GMLP compliance memo" that asserts conformity without pointing to any of these. Reviewers read the artifacts, not the assertion.
Common gaps we find in a GMLP readiness review
- No model provenance. The device ships a fine-tuned third-party base model and nobody can name the base model version, its license, or its known weaknesses.
- Datasets referenced by path, not by hash. The path moved, the data changed, and the validation report can no longer be reproduced.
- Representativeness analyzed once. Done before the first training run and never repeated after the dataset grew by 40 percent.
- Retraining without a change-control gate. Engineering can push a new model to production faster than the QMS can evaluate whether the change was inside the cleared envelope.
- Security controls documented for the app but not the inference endpoint. Rate limiting, authentication, and input validation on the inference API are missing, making model extraction and probing cheap.
Where to go next
A GMLP crosswalk is only useful if it changes what your team does on Monday. The most common outcome we see is a beautifully mapped spreadsheet that nobody uses, because the mapping stops at "which principle covers this" and never reaches "who produces the evidence and where does it live." Close that gap first.
Assign each of the ten GMLP principles an evidence owner and an artifact location inside your existing quality system. Data management belongs to whoever controls the training and validation datasets. Model performance monitoring belongs to whoever owns postmarket surveillance. Security controls over the training pipeline belong to whoever owns your secure development lifecycle. If a principle has no owner, it has no evidence, and a reviewer will find it.
Then reconcile the two risk views. AI-enabled devices carry model risk and cybersecurity risk, and teams routinely maintain them in separate documents that contradict each other. Model drift is a performance concern under GMLP and a security concern when the drift is induced by manipulated inputs. Data poisoning is a security threat with a clinical harm. Merge them into one risk register keyed to clinical harm, using AAMI CR34971 for the AI-specific hazard vocabulary and ISO 14971 for the underlying method, so a single set of controls answers both reviewers.
Third, decide whether you need a Predetermined Change Control Plan. If any part of your model updates after clearance, whether that is periodic retraining, threshold tuning, or a locked model with planned refreshes, you need one, and it should be drafted alongside the GMLP evidence rather than bolted on at filing. A PCCP written in isolation from your change management procedures will not survive its first real update.
Fourth, treat the training and deployment pipeline as in-scope for cybersecurity. Model weights, feature stores, and inference endpoints are attack surface. If your threat model stops at the device boundary and never touches the pipeline that produces the model, it is incomplete for an AI-enabled device.
If you have limited time, do the owner assignment and the merged risk register. Those two produce the traceability that both the AI reviewer and the cybersecurity reviewer are looking for.
- FDA 2025 AI Guidance Decoded - what the lifecycle management expectations mean for your submission structure.
- PCCP Template & Worked Example - a filled example you can adapt rather than starting from a blank page.
- AAMI CR34971 Explained - the AI hazard vocabulary to use when merging model risk into your ISO 14971 register.
- AI/ML Medical Device Security Service - pipeline threat modeling, adversarial testing, and the evidence set that satisfies both review tracks.
- EU AI Act vs FDA AI/ML Cybersecurity - where the two regimes diverge on AI-enabled devices.
Frequently asked questions
Are the GMLP guiding principles mandatory for an FDA submission?
The ten guiding principles are not a regulation and the FDA does not require a document titled "GMLP compliance." Reviewers do expect the underlying evidence: dataset representativeness analysis, independence of training and test sets, human-AI team performance data, and postmarket monitoring of deployed model performance. The crosswalk matters because it shows that evidence already exists inside your quality system rather than being assembled for the submission.
Does a GMLP crosswalk replace a cybersecurity threat model?
No. They answer different questions. GMLP asks whether the model was developed and validated soundly; the threat model asks how an attacker could degrade or manipulate it. For an AI-enabled device the threat model must extend past the device boundary to cover training data stores, model weights, feature stores, and inference endpoints, because those are attack surface that classical device threat models usually omit.
Do we need a Predetermined Change Control Plan if our model is locked?
If the model never changes after clearance, no. If you plan periodic retraining, threshold tuning, or scheduled refreshes of a nominally locked model, yes. Draft the PCCP alongside the GMLP evidence rather than at filing time, because the plan has to reference the change-control procedures and performance limits your quality system actually enforces.
Which standard supplies the AI-specific hazard vocabulary?
AAMI CR34971 provides the AI and machine learning hazard vocabulary; ISO 14971 supplies the underlying risk management method. Use CR34971 terms inside a single ISO 14971 register keyed to clinical harm so model risk and cybersecurity risk are evaluated against the same severity scale instead of living in contradictory documents.
Who should own GMLP evidence inside the quality system?
Assign each principle to the function that already produces its artifact: data management to the owner of training and validation datasets, performance monitoring to postmarket surveillance, and pipeline security to the owner of the secure development lifecycle. A principle with no named owner reliably becomes the gap a reviewer finds.
Sources
- FDA / Health Canada / MHRA, Good Machine Learning Practice for Medical Device Development: Guiding Principles (October 2021)
- FDA, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft, January 2025)
