How Neurosurgical AI Reaches Clinical Regulation

Gate 01 · Intended use

Start with the clinical function, not the AI label

FDA authorization attaches to a defined device, intended use, user, patient population, input, output, and workflow. “AI-enabled” does not describe the clinical authority of a product. A segmentation tool, an operating-room monitor, a navigation platform, and a prognostic classifier can all contain algorithms while creating different risks and evidence requirements.

The exact submission number is therefore the first useful join key. Product-family names can span different software versions, functions, predicates, and postmarket events. The Atlas does not transfer evidence from one version to another without a source establishing that relationship.

Reading ruleIdentify the exact regulated function before interpreting the model, benchmark, or marketing category.

Gate 02 · Pathway

The regulatory route is not an evidence grade

Within this deliberately selected ten-case teaching set, seven records use the Traditional 510(k) pathway and three use De Novo. Those proportions describe the editorial selection, not the market.

Gate 03 · AI disclosure

FDA-list inclusion and disclosed architecture are separate facts

The FDA AI-enabled device list is a discovery source. The decision summary is used to determine whether reviewed materials explicitly describe AI/ML, a named classifier or algorithm, or no identifiable learning architecture. Absence of public disclosure is recorded as uncertainty, not converted into an LLM, foundation-model, or generative-AI claim.

xvision Spine is the useful boundary case: it appears in the FDA list, while the reviewed public summary does not establish a learning architecture. That uncertainty is more informative than an invented classification.

Gate 04 · Validation

Ask what was tested, against what reference, and in whom

The ten selected public cases contain three nonclinical, five retrospective-clinical, and two prospective-clinical evidence patterns. None establishes improved patient outcomes. These categories are not a ranking of product quality; they describe the strongest design visible in the reviewed source for the function being discussed.

Mazor X illustrates the distinction: expert acceptance of an AI-generated plan is not observed implant-placement accuracy. SpineAR SNAP illustrates version-specific segmentation evidence inside a broader navigation workflow.

Gate 05 · Human role

Required review is part of the intended system

Several reviewed products require a clinician to review, modify, approve, or interpret an output. That instruction defines responsibility and use boundaries, but it does not automatically prove that review catches clinically important errors. A credible human–AI claim needs evidence about residual error after review, correction time, workload, override, and automation bias.

This distinction becomes more important for patient-facing or generative systems. The separate FDA GenAI consultation draft proposes patient understanding, substantive clinician review, and trajectory-level testing as measurable safeguards; it remains an editorial response and has not been submitted to FDA.

Gate 06 · Change control

A PCCP authorizes bounded change, not unrestricted learning

Three of the ten public cases document an authorized PCCP in the reviewed lineage. The Atlas distinguishes authorization in the indexed submission from a plan inherited from an earlier submission. Scope, controls, validation criteria, and source lineage must remain visible.

SafeOp 3 and Brainomix 360 Hyperdensity show PCCPs authorized in the indexed submission. Acorn 3D shows why an inherited plan should not be rewritten as a new authorization.

Gate 07 · Postmarket

Authorization is the start of a monitored lifecycle

Postmarket evidence can alter how an authorization should be interpreted. A recall must be attributed to the affected product, component, software version, and submission lineage. A product-family or earlier-version event is not automatically evidence that the reviewed submission failed.

SafeOp 3 retains a component-specific recall beside its authorization record. SpineAR SNAP and Mazor X keep earlier-version or product-family events separate from claims about the indexed submission.

Operational map

Seven questions for reading a neurosurgical AI authorization

1. FunctionWhat clinical task, user, input, output, population, and exclusion define the device?
2. PathwayIs the decision based on substantial equivalence or a new De Novo device type?
3. AI disclosureWhat architecture is actually identified in the reviewed FDA material?
4. EvidenceWhat design, comparator, ground truth, representation, and metric support the function?
5. Human roleWhat must the clinician review, modify, approve, or independently confirm?
6. Change controlWhich future modifications are authorized, under what controls, and in which submission?
7. PostmarketWhat later studies, recalls, corrections, or version changes modify the interpretation?

Evidence boundary

What this map can—and cannot—tell us

This guide synthesizes ten intentionally selected public cases from a private registry of 30 source-checked submissions. It is designed to expose regulatory patterns and counterexamples. It is not a complete list of FDA-authorized neurosurgical AI, a prevalence estimate, a purchasing guide, legal advice, clinical advice, or evidence of comparative superiority.

Case-level statements remain governed by the linked FDA sources and the Regulatory Atlas Methodology. A synthesis does not advance the underlying source-check dates. Material changes are recorded separately in the Update Ledger.