From prototype to 510(k): a practitioner’s guide to AI SaMD submission.

i. Starting position

This guide assumes a specific set of conditions — close enough to reality for most AI SaMD startups that the guidance is actionable.

What you have: a working prototype of an AI/ML algorithm, trained and validated on anonymized EHR data; a locked intended use and indications for use; enough capital to fund 12–18 months of regulatory and quality work; and a founding team with domain knowledge but likely without deep regulatory or quality experience in-house.

What you probably don’t have yet: a Quality Management System, a regulatory submission strategy validated by FDA, software development processes that meet IEC 62304, cybersecurity documentation that meets FDA’s current expectations, a clinical evidence package, a Predetermined Change Control Plan (PCCP), or any formal engagement with FDA.

This guide covers the sequence of work that gets you from the first column to the second — in the right order, with the right team, at the right depth for your stage.

ii. Phase 1 — Hire your regulatory and quality foundation

The first operational decision isn’t technical. It’s personnel.

Step 1: Engage a QA/RA consultant

Before hiring anyone full-time, engage a senior consultant who has direct experience with AI SaMD submissions. This person will shape every subsequent decision — team composition, QMS scope, regulatory strategy, submission structure. The quality of this hire compounds across the entire project.

What to look for: the PACE framework applies here with one addition — for AI SaMD specifically, the consultant needs demonstrated familiarity with FDA’s AI/ML guidance documents, the PCCP framework, and the intersection of software lifecycle (IEC 62304) with machine learning development practices. Ask directly.

Step 2: Use the consultant to make key hiring decisions

Your consultant should help you identify who you actually need versus who can stay fractional. For a typical AI SaMD startup at this stage:

Full-time (or near-full-time):

• Software engineers with medical device experience. Engineers who understand design controls, IEC 62304 documentation levels, and the discipline of working within a controlled software development lifecycle. Engineers from consumer tech or unregulated SaaS need significant ramp-up. One experienced medical device software engineer saves months of rework.
• ML/data science engineers. You likely already have these from the prototype phase. What changes now is the documentation rigor — training data governance, algorithm versioning, performance validation protocols. The work doesn’t change; the traceability does.

Full-time or senior fractional:

• Infrastructure/DevOps engineers with security standards experience. Cloud deployment for regulated SaMD requires someone who understands ISO 27001 controls, HIPAA technical safeguards, SOC 2 trust criteria, and FDA’s cybersecurity expectations. This isn’t a junior DevOps hire — it’s someone who can architect a secure-by-design deployment and document it for both FDA and hospital security intake.

Fractional (for now):

• Clinical affairs. You’ll need clinical input for evidence strategy and study design. At this stage, a fractional clinical affairs consultant is usually sufficient.
• QA/RA. Your lead consultant fills this role. Full-time QA hire comes later, typically when you’re approaching submission.
• Finance, legal, HR. Standard startup fractional roles.

What not to hire yet — and why this matters more than you think

iii. Phase 2 — Build the lean QMS

The QMS is the infrastructure within which all regulated development work happens. For an AI SaMD 510(k), the QMS needs to satisfy ISO 13485:2016 (now harmonized with FDA’s QMSR as of February 2026) and incorporate the specific controls that FDA’s AI/ML, software, and cybersecurity guidance documents expect.

Scope it to the submission. A common mistake is building a QMS for a company you don’t have yet. At this stage, you need the procedures that support design, development, and submission — not the full lifecycle of a commercial manufacturing operation.

Core SOPs for an AI SaMD 510(k)

1. Design controls — the backbone of the submission. For AI/ML, this includes algorithm development as a design activity, with inputs, outputs, reviews, verification, and validation mapped to the ML lifecycle (data collection, training, validation, testing, deployment). FDA expects to see how design controls governed the AI development process.
2. Risk management (ISO 14971) — with AI-specific risk categories: algorithmic bias (demographic, clinical, dataset), data drift and distribution shift, model degradation over time, failure modes specific to ML (adversarial inputs, out-of-distribution behavior, edge-case performance), and transparency/explainability considerations.
3. Software development lifecycle (IEC 62304) — adapted for ML. IEC 62304 was written for deterministic software; ML is probabilistic. The standard still applies, but ML-specific activities (training, hyperparameter tuning, architecture selection, dataset management) must map onto 62304’s framework. The “level of concern” concept has been replaced with “documentation level” — ensure your procedures reflect current terminology.
4. Document control — every version of the training data, every model iteration, every performance benchmark needs to be traceable.
5. Supplier controls — particularly for training data sources, cloud infrastructure providers, and any third-party ML components. Each is a “supplier” in QMS terms.
6. CAPA — lean at this stage. You won’t have post-market complaint volume, but you need the procedure in place.
7. Cybersecurity controls — integrated from day one, not bolted on later. FDA’s pre-market cybersecurity guidance expects a secure product development framework embedded in your development process.
8. Management responsibility — standard ISO 13485 requirement. Lean for a startup but required.
9. Training — procedures and records for QMS training and device-specific topics.

Incorporate FDA guidance directly into templates. Don’t write generic templates and retrofit AI guidance later. Build the guidance expectations in from day one: design control templates should include fields for training data provenance, algorithm architecture decisions, performance metric selection rationale, and bias assessment. Risk management templates should include AI-specific hazard categories. V&V protocols should include ML-specific testing approaches. Cybersecurity templates should align with FDA’s pre-market guidance structure.

eQMS selection. Right-size the tool. You need document control, design control workflow, CAPA tracking, and audit trail. You don’t need manufacturing execution or enterprise reporting. Platforms at $300–$800/month handle this well for a startup at this stage.

iv. Phase 3 — Regulatory strategy and FDA Pre-Sub

With the QMS in place and the team assembled, you’re ready for formal regulatory strategy work.

Predicate device identification

For AI SaMD specifically, the substantial equivalence (SE) argument is nuanced. Your algorithm may be novel, but the clinical function it performs often has existing predicates. The strategy is to argue SE against the clinical function and intended use, not against the underlying technology.

Example: an AI algorithm that detects diabetic retinopathy from fundus images is technologically novel, but the clinical function (detection of diabetic retinopathy from retinal imaging) has established predicates. The SE argument focuses on “same intended use, same clinical function, different technological characteristics that don’t raise new questions of safety and effectiveness” — which then requires you to show that the AI approach performs at least as well as the predicate’s approach.

Identify 2–3 candidate predicates. For each, map: intended use, indications for use, technological characteristics, performance data in the clearance summary.

First Pre-Sub (Q-Sub) meeting

The Pre-Sub is your most important FDA touchpoint before submission. For AI SaMD, use it to get written FDA feedback on:

1. Classification and predicate strategy. Does FDA agree with your proposed classification and predicate?
2. Clinical evidence expectations. The highest-value question for AI SaMD. FDA’s expectations vary significantly — retrospective analytical performance data may suffice for some devices; others require prospective clinical data. Getting this answer before designing your studies saves months.
3. AI/ML-specific questions. Training data requirements, performance metrics, PCCP applicability, and transparency/explainability expectations.
4. Cybersecurity scope. What level of documentation FDA expects given your device’s architecture and connectivity.
5. Software documentation level. Confirmation of the appropriate documentation level under current guidance.

How to structure the Pre-Sub package: include a device description, proposed intended use, proposed predicate(s) with SE rationale, proposed clinical evidence approach, proposed performance testing plan, and specific questions formatted as “does FDA agree with this approach” rather than open-ended “what should we do.” FDA responds better to specific proposals they can react to.

What to do with FDA’s feedback: the Pre-Sub response is written and becomes part of your submission record. If FDA agrees, cite the response in your 510(k). If they disagree, you now know before investing in the wrong strategy. Either outcome is valuable.

v. Phase 4 — AI/ML-specific development and documentation

This phase overlaps with ongoing engineering work, but the regulatory documentation requirements are specific.

Training data governance

FDA expects you to demonstrate that your training data is representative of the intended patient population, adequately sourced with clear provenance, properly curated (annotation methodology, inter-rater reliability, disagreement resolution), and free of systematic bias that would cause differential performance across clinically relevant subgroups. Document all of this proactively.

Algorithm development documentation (GMLP principles)

FDA’s Good Machine Learning Practice (GMLP) principles provide a framework for responsible AI/ML development. While not a graded checklist, they represent the expectations reviewers carry into evaluation: multi-disciplinary expertise was applied, data quality and relevance were ensured, training and test datasets were independent, reference datasets were based on best available methods, model design was tailored to clinical context, focus on human-AI team performance where applicable, and testing demonstrated clinically meaningful performance.

Your design history file should reflect adherence to these principles as a natural consequence of how the work was done within your design controls.

Verification and validation for ML models

• Data partitioning: clear separation of training, validation, and test sets. FDA expects the test set to be truly held out — never used during any development or tuning phase.
• Performance metrics: selected to be clinically meaningful for your use case. Sensitivity, specificity, AUC are common; the right metrics depend on clinical context. Justify your choice.
• Subgroup analysis: performance broken down by clinically relevant subgroups (age, sex, race/ethnicity, disease severity, comorbidities, imaging equipment if applicable). FDA increasingly expects this.
• Robustness testing: performance under degraded or edge-case conditions — noisy inputs, out-of-distribution inputs, variations in data acquisition.

The Predetermined Change Control Plan (PCCP)

The PCCP is FDA’s framework for allowing AI/ML devices to be modified post-clearance without requiring a new 510(k) for each change. It consists of two components:

• SaMD Pre-Specifications (SPS): what aspects of the device you anticipate changing (retraining on new data, expanding to new modalities, adjusting decision thresholds).
• Algorithm Change Protocol (ACP): the methodology for developing, validating, and implementing those changes (performance benchmarks, validation dataset requirements, change review process).

A PCCP is not required for every AI SaMD 510(k), but it’s increasingly recommended and can be a significant commercial advantage — it allows post-clearance algorithm improvements without new submissions. Discuss applicability in your Pre-Sub.

Transparency and explainability

FDA increasingly emphasizes that users should understand what the device does and doesn’t do, how it arrives at outputs, and what its limitations are. This manifests in labeling, user-facing confidence/uncertainty indicators, and design choices that prioritize interpretability where clinically important. FDA does not require all AI to be fully “explainable” — the expectation is proportional to clinical risk.

vi. Phase 5 — Cybersecurity

FDA’s cybersecurity requirements for SaMD are substantial and non-negotiable. Section 524B of the FD&C Act made cybersecurity documentation a statutory requirement for premarket submissions.

Pre-market cybersecurity documentation

1. Threat modeling. Systematic analysis of attack vectors, threat actors, and consequences. STRIDE, Attack Trees, or FMEA-based approaches are all acceptable. Scope includes device software, cloud infrastructure, data in transit/at rest, authentication, and connected systems.
2. Security architecture. Access controls, authentication, encryption (at rest and in transit), secure boot/update mechanisms, network segmentation, logging and monitoring, data integrity controls.
3. Software Bill of Materials (SBOM). Complete inventory of all software components including third-party libraries, open-source packages, and ML frameworks with versions. FDA expects machine-readable format (SPDX or CycloneDX).
4. Vulnerability assessment. Known vulnerabilities in SBOM components, mitigation strategy for each, monitoring process for new vulnerabilities.
5. Security testing results. Penetration testing, static analysis, dynamic analysis, fuzz testing — evidence that you’ve tested your security architecture.

Post-market cybersecurity plan

Your submission also needs: coordinated vulnerability disclosure policy, software patching and update cadence, monitoring for new SBOM component vulnerabilities, incident response procedures, and communication plan for notifying users of security issues. This describes a real operational capability you need to have, not just a submission artifact.

vii. Phase 6 — Clinical evidence strategy

Clinical evidence for AI SaMD is where many startups either over-invest (running unnecessary prospective studies) or under-invest (submitting weak performance data that triggers FDA questions). Getting the scope right is the highest-leverage outcome of your Pre-Sub meeting.

Types of clinical evidence FDA expects

1. Analytical/bench performance (almost always required). Standalone testing of the algorithm against a curated, labeled test dataset. Demonstrates that the algorithm performs with adequate accuracy, sensitivity, specificity, and other relevant metrics. For most AI SaMD 510(k)s, this is the core of the clinical evidence package.
2. Clinical performance (sometimes required). Testing in a real or simulated clinical environment — the algorithm’s performance when used by the intended user in the intended workflow. May be retrospective or prospective. FDA’s expectation depends on clinical risk.
3. Clinical literature (supporting). Published evidence supporting the clinical validity of the underlying clinical function. Strengthens the clinical context but doesn’t replace device-specific performance data.

Study design considerations

• Retrospective vs. prospective. Retrospective studies using curated datasets are faster, cheaper, and often sufficient for lower-risk AI SaMD. Prospective studies may be required for higher-risk applications. Ask in your Pre-Sub.
• Dataset requirements. Diversity (demographic, clinical, geographic), representativeness, independence from training data, and adequate sample size with statistical justification.
• Ground truth / reference standard. How “truth” is established against which the algorithm is measured. For imaging AI, this often means expert adjudication by multiple specialists. Document inter-rater reliability.
• IRB considerations. Even retrospective studies using anonymized data may require IRB review. Prospective studies almost certainly do. Budget time for this — IRB timelines are one of the most common sources of schedule slip.

viii. Phase 7 — Submission preparation

With the QMS, regulatory strategy, AI documentation, cybersecurity package, and clinical evidence in place, you’re ready to assemble the 510(k).

The 510(k) package structure for AI SaMD

1. Administrative sections. Cover letter, FDA forms, indications for use statement, truthful and accurate statement, financial certification/disclosure.
2. Device description. What the device does, the AI/ML algorithm description (architecture, inputs, outputs, training methodology summary), deployment environment, and user interface description.
3. Substantial equivalence comparison. Side-by-side comparison with predicate(s) — intended use, indications, technological characteristics. For AI SaMD, the comparison focuses on clinical function rather than algorithmic implementation.
4. Software documentation. Per FDA’s guidance — software description, architecture diagram, requirements specification summary, risk analysis, documentation level justification, unresolved anomalies, revision history. For AI/ML: model description, training process summary, dataset description.
5. AI/ML-specific sections. Training data description, algorithm performance data (metrics, subgroup analysis, robustness testing), PCCP if applicable (SPS + ACP), GMLP adherence narrative.
6. Cybersecurity documentation. Threat model, security architecture, SBOM, vulnerability assessment, security testing results, post-market cybersecurity plan.
7. Clinical evidence. Performance testing results, clinical study report(s) if applicable, clinical literature review, statistical analysis.
8. Labeling. Draft labeling including instructions for use, intended use statement, warnings/precautions (including AI-specific limitations), performance summary, transparency/explainability disclosures.
9. Risk analysis summary. ISO 14971-based, including AI-specific risks, with residual risk assessment and benefit-risk determination.

Common deficiencies in AI SaMD 510(k)s and how to avoid them

• Insufficient training data description. FDA wants to understand the data, not just the algorithm. Describe provenance, representativeness, curation methodology, and known limitations.
• Missing subgroup analysis. Performance reported only in aggregate without breakdowns by clinically relevant subgroups.
• Inadequate cybersecurity documentation. Treating cybersecurity as an afterthought rather than an integrated section with the depth Section 524B requires.
• Weak substantial equivalence argument. Focusing on technological novelty rather than clinical equivalence.
• Missing or incomplete SBOM. Partial listings, missing version numbers, non-machine-readable formats.
• Labeling that doesn’t disclose AI limitations. FDA expects transparency about what the AI can and can’t do.

Pre-submission review: before filing, have your QA/RA consultant review the entire package against FDA’s refuse-to-accept checklist. A submission that’s refused before review costs months. Most RTA issues are avoidable with a careful final review.

ix. Phase 8 — Post-submission through clearance

Refuse-to-Accept screening: FDA screens within 15 days for completeness. If something’s missing, they refuse it and you refile.

Substantive review: if accepted, FDA assigns a reviewer. Standard 510(k) review target is 90 days, though AI SaMD submissions frequently take longer due to AI-specific section complexity.

Additional Information (AI) requests: FDA will almost certainly have questions. Common AI SaMD topics include: additional subgroup performance data, training data methodology clarification, additional robustness testing, PCCP clarification, cybersecurity architecture questions, and labeling revisions. Respond promptly, completely, and precisely — each request extends the review clock.

Interactive review: FDA allows interactive communication during review. If the reviewer offers a call to resolve questions, accept — these resolve issues in minutes that might otherwise take weeks of written exchange.

From clearance to market: on the day the clearance letter arrives, your device is legally marketable. Your establishment registration and device listing obligations begin, post-market obligations activate (MDR reporting, complaint handling, cybersecurity monitoring, any PCCP commitments), and what happens next depends on the choice you made at the beginning: sell, or commercialize. Either way, the clearance letter is the asset you built the company to produce.

x. The full timeline at a glance

Total estimated timeline: 12–18 months from consultant engagement to clearance. Estimates only — actual timelines vary significantly based on device complexity, clinical evidence requirements, and FDA review dynamics.

xi. Common questions

How much does an AI SaMD 510(k) cost in total?

Estimates only: for a focused AI SaMD startup with an experienced team and good consultant, expect $150K–$350K in total regulatory, quality, clinical, and submission costs between prototype and clearance. This does not include core engineering salaries. Capital-efficient sale-track companies can come in at the lower end; companies running prospective clinical studies push higher.

Do I need a PCCP?

Not required, but increasingly recommended — especially if your algorithm will be updated post-clearance (which most ML models will be). A PCCP allows pre-specified changes without new submissions. Discuss with FDA in your Pre-Sub.

Can I use retrospective data only, or do I need a prospective study?

Depends on FDA’s assessment of your device’s risk profile and clinical context. For many AI SaMD 510(k)s, retrospective analytical performance data on a well-curated, independent test set is sufficient. For higher-risk applications, FDA may expect prospective data. Ask in your Pre-Sub.

How do I handle algorithm updates after clearance if I don’t have a PCCP?

Each modification must be evaluated against FDA’s guidance on when a new 510(k) is required. Changes that could significantly affect safety or effectiveness require a new submission. Minor changes (performance improvements within the same intended use, retraining on similar data) may not. Your post-market change evaluation procedure governs this assessment.

What if my algorithm uses a foundation model or large language model?

FDA is still developing its regulatory approach to LLM-based medical devices. The general principles in this guide still apply, but LLM-specific considerations (hallucination risk, prompt sensitivity, training data opacity) introduce additional regulatory uncertainty. This is a high-priority Pre-Sub topic.

What’s the FDA user fee for a 510(k)?

For FY2026, the standard fee is approximately $24,335. A small business qualification (based on gross receipts and number of employees) reduces this to approximately $6,084. Most AI SaMD startups qualify. Verify current fees at FDA.gov before filing.

Should I pursue De Novo classification instead of 510(k)?

If no suitable predicate exists for your AI SaMD’s intended use, 510(k) isn’t available and De Novo is the appropriate pathway. De Novo is more expensive and typically longer, but it establishes your device as the predicate for future devices — which has strategic value.

How does international expansion interact with this process?

This guide is US-only, but the QMS, technical documentation, and clinical evidence you develop for a 510(k) can serve as the foundation for international submissions. ISO 13485 (now harmonized with FDA QMSR) is accepted globally. Clinical performance data requirements differ by jurisdiction, so plan your studies with international use in mind if expansion is on the roadmap.

Closing

The path from working prototype to FDA-cleared AI SaMD is long, expensive, and unforgiving of architectural mistakes. But it’s also well-mapped — FDA’s expectations, while complex, are documented and knowable. The founders who succeed are the ones who invest in understanding the journey before they start walking it, who hire people who’ve done it before, and who build the minimum infrastructure needed to get the work done right.

This guide is a map, not a GPS. Your specific device, your specific clinical context, your specific regulatory questions will require specific answers. Use this to understand the terrain. Then hire someone who’s walked it.