Inferensys

Glossary

Good Machine Learning Practice (GMLP)

A set of best practices and standards for developing, validating, and monitoring AI/ML-enabled medical devices to ensure their safety and effectiveness throughout the total product lifecycle.
Modern WeWork hardware lab area with product team collaborating around AI device prototypes, 3D printer in background, dramatic industrial lighting with product sketches on glass walls.
AI/ML QUALITY SYSTEM FRAMEWORK

What is Good Machine Learning Practice (GMLP)?

A consensus framework for the safe and effective lifecycle management of artificial intelligence in medical devices.

Good Machine Learning Practice (GMLP) is a set of best practices and standards developed by the U.S. Food and Drug Administration (FDA), Health Canada, and the UK’s MHRA for developing, validating, and monitoring AI/ML-enabled medical devices to ensure their safety and effectiveness throughout the total product lifecycle. It aligns with established quality system regulations but addresses unique risks like data drift and model opacity.

The ten guiding principles of GMLP emphasize multi-disciplinary expertise, secure software engineering and cybersecurity, representative clinical study data, and a focus on the human-AI team. A core tenet is the use of a Predetermined Change Control Plan (PCCP) , which allows manufacturers to prospectively specify planned modifications to a locked model without requiring a new regulatory submission, enabling continuous learning within a controlled safety envelope.

REGULATORY FRAMEWORK

The 10 Guiding Principles of GMLP

A consensus framework co-developed by the FDA, Health Canada, and the UK MHRA to guide the development of safe and effective AI/ML-enabled medical devices through the total product lifecycle.

01

Multi-Disciplinary Expertise

Leverage a deep, cross-functional understanding of clinical workflows, model engineering, and regulatory requirements throughout the design process. Operational silos are a primary source of safety risk.

  • Integrate clinicians, data scientists, and regulatory specialists from day one.
  • Ensure the team understands the intended use environment and potential misuse scenarios.
  • Document the roles and responsibilities of each discipline in the development plan.
02

Good Software & Security Engineering

Implement rigorous software lifecycle controls, risk management, and cybersecurity practices. AI/ML components are software first and must adhere to foundational IEC 62304 principles.

  • Apply defense-in-depth security strategies to protect the model pipeline.
  • Conduct adversarial testing to assess vulnerability to data poisoning and evasion attacks.
  • Maintain a comprehensive software bill of materials (SBOM) for all dependencies.
03

Clinical Study & Representative Data

Ensure training, tuning, and test datasets are statistically representative of the intended patient population. Selection bias is a critical failure mode that leads to health inequity.

  • Define explicit inclusion/exclusion criteria based on demographic and phenotypic factors.
  • Audit datasets for hidden stratification across subpopulations.
  • Document the provenance, acquisition protocols, and annotation processes for all data sources.
04

Training Data Independence

Maintain strict separation between training and tuning datasets to prevent overfitting and inflated performance estimates. Data leakage is a primary cause of real-world model degradation.

  • Physically or logically separate data partitions at the patient level, not the sample level.
  • Use a held-out lockbox dataset that is never touched during iterative development.
  • Pre-register the data split methodology before any model training begins.
05

Best Practices for Reference Standard

Construct a reliable, clinically accepted ground truth based on expert consensus or established biomarkers. A model is only as valid as the labels it learns from.

  • Use adjudicated expert panels to resolve ambiguous or conflicting labels.
  • Quantify and report inter-rater variability to establish the noise ceiling.
  • Justify the clinical validity of the reference standard relative to the target condition.
06

Model Design Tailored to Available Data

Select model architectures and regularization techniques appropriate for the size and complexity of the available data. Over-parameterization relative to data volume invites spurious correlations.

  • Prefer intrinsically interpretable models when performance is equivalent to black-box alternatives.
  • Apply inductive biases that align with known physiological or physical constraints.
  • Document the rationale for architectural choices in the context of data limitations.
07

Human-AI Team Performance

Evaluate the performance of the clinician-model interaction, not just the standalone model. The relevant metric is the combined decision-making accuracy of the human-AI dyad.

  • Design user interfaces that mitigate automation bias and alert fatigue.
  • Conduct think-aloud usability studies to observe how clinicians interpret model outputs.
  • Measure the impact of the model on clinical decision speed and confidence calibration.
08

Testing on Clinically Relevant Subgroups

Proactively assess model performance on demographic, clinical, and edge-case subgroups defined during the risk assessment. Aggregate metrics can mask catastrophic subgroup failure.

  • Report per-subgroup sensitivity and specificity with confidence intervals.
  • Define a priori the minimum acceptable performance threshold for each subgroup.
  • Test on intersectional subgroups to detect compounding biases.
09

Clear and Transparent User Information

Provide users with a Model Card or similar document that clearly communicates the device's intended use, limitations, and performance characteristics in plain language.

  • Disclose the demographic composition of the training data.
  • Explain the output format, confidence calibration, and known failure modes.
  • Provide actionable guidance on how to interpret and act upon model outputs safely.
10

Monitoring Performance on Deployed Models

Implement a Predetermined Change Control Plan (PCCP) and continuous monitoring infrastructure to detect data drift, concept drift, and performance degradation in production.

  • Monitor input data distributions for covariate shift relative to the training baseline.
  • Establish statistical process control limits that trigger automated alerts and human review.
  • Log all model predictions and associated metadata for post-market surveillance audits.
REGULATORY FRAMEWORK

GMLP and the FDA's Total Product Lifecycle Approach

Good Machine Learning Practice (GMLP) is a set of consensus standards co-developed by the FDA, Health Canada, and the UK's MHRA to guide the safe development and monitoring of AI/ML-enabled medical devices across their entire lifespan.

Good Machine Learning Practice (GMLP) is a regulatory framework of 10 guiding principles that govern the design, development, and maintenance of AI/ML-enabled medical devices. It mandates a Total Product Lifecycle (TPLC) approach, requiring manufacturers to manage risks from data collection and model training through to post-market performance monitoring and iterative improvement.

The framework emphasizes that multidisciplinary expertise must be integrated throughout the lifecycle, and that clinical study participants and datasets are representative of the intended patient population. A core tenet is that a Predetermined Change Control Plan (PCCP) allows manufacturers to prospectively specify planned modifications, enabling safe device evolution without necessitating a new regulatory submission for each update.

REGULATORY AI/ML BEST PRACTICES

Frequently Asked Questions

Clarifying the core principles of Good Machine Learning Practice (GMLP) for the development and regulatory submission of AI-enabled medical devices.

Good Machine Learning Practice (GMLP) is a consensus framework of 10 guiding principles developed by the U.S. Food and Drug Administration (FDA), Health Canada, and the UK's Medicines and Healthcare products Regulatory Agency (MHRA) to ensure the safety and effectiveness of AI/ML-enabled medical devices. These principles are not legally binding regulations but represent a harmonized set of engineering best practices that guide the total product lifecycle. GMLP addresses unique challenges of machine learning, such as data drift, model overfitting, and the management of iterative updates. The framework emphasizes that multi-disciplinary expertise must be integrated throughout the design process, good software engineering and security practices are foundational, and clinical study participants and datasets must be representative of the intended patient population to mitigate algorithmic bias. Ultimately, GMLP provides a common language for developers and regulators to discuss the rigorous validation of adaptive, non-deterministic systems.

REGULATORY PARADIGM COMPARISON

GMLP vs. Traditional Software Validation

Key distinctions between Good Machine Learning Practice (GMLP) for AI/ML-enabled medical devices and traditional software validation approaches under IEC 62304 and FDA guidance.

FeatureGMLPTraditional Software ValidationHybrid Approach

Primary Regulatory Framework

FDA AI/ML Action Plan, IMDRF guidance, consensus standards

IEC 62304, FDA 21 CFR Part 820.30 Design Controls

IEC 62304 with GMLP overlay for ML components

Model Retraining After Deployment

Data Quality Management Focus

Representativeness, label accuracy, distribution shift monitoring

Functional requirements traceability

Both data quality and functional traceability

Validation Methodology

Prospective clinical studies, silent trials, stress testing on edge cases

Verification against static requirements, unit testing, integration testing

Static verification plus clinical performance monitoring

Handling Non-Deterministic Outputs

Change Management Philosophy

Predetermined Change Control Plan (PCCP) with pre-authorized modifications

Full re-validation and new 510(k)/PMA submission for significant changes

PCCP for ML updates; traditional re-validation for non-ML changes

Post-Market Monitoring Requirement

Continuous performance monitoring, drift detection, real-world evidence collection

Complaint handling, CAPA, periodic review

Continuous monitoring plus traditional CAPA processes

Explainability Documentation

SHAP values, attention maps, model cards, intended use population analysis

Design specification documents, traceability matrices

Both interpretability artifacts and design specifications

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.