Beacon Biosignals: Medical AI Hardware and the Regulatory Requirements Stack

Beacon Biosignals makes an EEG monitoring platform that combines custom hardware electrodes, clinical signal acquisition electronics, and an AI software layer trained to detect seizures, quantify brain injury, and assess depth of anesthesia. That description sounds clean. The regulatory reality is not.

To ship a product like Beacon’s, you are simultaneously complying with IEC 62304 (medical device software lifecycle), IEC 60601 (electrical safety and performance for medical electrical equipment), and FDA’s Software as a Medical Device guidance — while also managing post-market AI performance surveillance requirements that barely existed five years ago. Each framework has its own vocabulary, its own documentation artifacts, and its own logic for how requirements should be structured and traced. The teams that figure out how to unify these frameworks survive. The teams that treat them as separate workstreams do not.

This is an analysis of the engineering and organizational challenge Beacon Biosignals represents — not a company profile built on insider access, but an examination of the systems engineering problem their product category forces into existence.

What Beacon Biosignals Actually Builds

Beacon’s core product, Dreem, started as a consumer-grade sleep EEG headband before the company pivoted hard into clinical-grade neurological monitoring. Their current platform targets ICU and perioperative settings where continuous EEG interpretation has historically required a trained epileptologist available around the clock — a constraint that eliminates the modality from most community hospitals.

The product architecture is a three-layer stack:

Hardware layer: A dry-electrode EEG acquisition device that must meet IEC 60601-1 electrical safety requirements, including isolation from mains power, biocompatibility of skin-contact surfaces, and EMI performance in environments saturated with other clinical equipment.

Signal processing and software layer: Real-time firmware and embedded software that acquires, filters, and conditions EEG signals. This software falls squarely under IEC 62304 class C — the highest risk category — because a failure mode in signal processing could cause a clinician to miss a seizure.

AI inference layer: Machine learning models that interpret processed EEG, generate quantitative indices, and surface clinical alerts. This is where FDA SaMD guidance and the agency’s AI/ML-based SaMD action plan become directly relevant.

The integration of all three creates a compliance surface that no single standard was designed to address. You are applying three overlapping frameworks to a product that is simultaneously an electrical device, a software system, and an AI clinical decision support tool.

The IEC 62304 Problem at the AI Boundary

IEC 62304 defines a software development lifecycle for medical devices with three software safety classes (A, B, and C), each requiring progressively more rigorous documentation, testing, and change control. For a seizure detection system, class C is non-negotiable — software failure could directly cause serious injury or death.

Class C requirements under 62304 include full software unit testing, integration testing, and system testing with documented test cases traceable to software requirements. Every requirement must trace to a test. Every test must trace to a requirement. The architecture must be documented at the unit level. Changes require impact analysis that traces through the entire requirement-to-test chain.

This is manageable when your software is deterministic. It becomes structurally complicated when the “software unit” making clinical decisions is a neural network.

Neural networks do not have requirements in the traditional sense. You cannot write a software requirement that says “the LSTM shall output a seizure probability greater than 0.85 when presented with ictal EEG morphology” and then unit-test the model against that specification in the way you would test a threshold function. The model learns its behavior from training data. Its “specification” is effectively its performance on a held-out validation set.

The practical implication is that medtech AI teams must create a parallel requirements structure that bridges the traditional software engineering world of IEC 62304 and the statistical performance world of machine learning validation:

  • Clinical performance requirements (sensitivity, specificity, positive predictive value on defined patient populations) that are specified before training and validated after
  • Input data requirements (signal quality thresholds, electrode impedance limits, artifact rejection criteria) that constrain what the model receives
  • Output interface requirements (alert latency, display format, alert suppression logic) that constrain how model outputs reach clinicians
  • Operational design domain requirements that define the population and conditions under which AI outputs are valid

The 62304 requirement-to-test traceability is preserved by treating the AI model as a black box with specified inputs, outputs, and performance characteristics — and writing requirements around those boundaries rather than inside the model. This is not a theoretical workaround; it is the practical structure that FDA’s AI/ML SaMD guidance expects.

IEC 60601 and the Hardware Requirements Stack

IEC 60601-1 covers general safety and essential performance requirements for medical electrical equipment. For Beacon’s EEG hardware, the relevant substandards include 60601-1-2 (electromagnetic compatibility), 60601-1-6 (usability engineering — applying IEC 62366), and 60601-2-26 (particular requirements for EEG equipment).

The hardware requirements stack under 60601 operates on a risk management foundation defined by ISO 14971. Every potential harm — electrical shock, misdiagnosis from signal artifact, skin irritation from electrodes — must be identified, estimated for probability and severity, and controlled through design or mitigation. The control measures become hardware requirements.

This is where the systems engineering problem gets expensive. A risk control measure identified in your ISO 14971 risk file must become a requirement that is implemented, tested, and verified. If the risk control is “electrode impedance monitoring shall alert the user when contact quality falls below acceptable thresholds,” that requirement now needs to exist in your hardware requirements document, link to a design feature, link to a test protocol, and link back to the risk item it controls.

Multiply this across hundreds of identified hazards across hardware, software, and AI interfaces, and the traceability burden becomes the dominant engineering overhead for a company of Beacon’s size. A 100-person medtech startup can easily generate 2,000-plus traced requirements before a design freeze.

FDA SaMD Guidance and the Clinical Claim Problem

FDA’s Software as a Medical Device framework classifies SaMD by two dimensions: the significance of information provided to healthcare decisions, and the state of the healthcare situation the software addresses. Beacon’s seizure detection product — providing diagnostic information in critical or serious clinical situations — lands in the highest SaMD risk tier.

At that tier, FDA’s pre-submission and 510(k) expectations are significant. The predicate device comparison (for 510(k)) or de novo submission must establish substantial equivalence or justify novel classification, which for AI-based neurodiagnostics typically requires a clinical study demonstrating that the device’s outputs match expert clinician interpretation within specified performance bounds.

The requirements engineering implication is that FDA’s clinical evaluation endpoints must be reflected in product requirements before clinical studies are designed. You cannot run a clinical trial to “see how the AI performs” and then reverse-engineer requirements from the results. FDA expects that your intended use, indications for use, and clinical performance requirements were specified before validation, not after.

This forces a discipline that good requirements engineering practitioners will recognize: requirements must be written at the clinical claim level first, then decomposed through the system to hardware, software, and AI model specifications. The clinical claim (“the device identifies electrographic seizures with sensitivity ≥ 85% in adult ICU patients”) is a stakeholder requirement. The AI model performance threshold is a derived software requirement. The signal quality floor is a derived hardware requirement. The chain must be explicit and bidirectional.

FDA’s AI/ML Action Plan: What It Means Operationally

FDA’s 2021 AI/ML-based SaMD action plan introduced the concept of predetermined change control plans (PCCPs) — a mechanism allowing manufacturers to describe, in advance, the types of changes they will make to AI/ML functions and the validation that will accompany those changes, without requiring a new premarket submission for every model update.

For a company like Beacon, whose AI models will improve as clinical data accumulates, the PCCP is operationally critical. But implementing it requires requirements infrastructure that most startups do not build early enough:

Change impact boundaries must be specified. The PCCP must define which requirements can be modified under the plan (typically AI performance thresholds and model weights within a fixed architecture) versus which require new premarket review (intended use, hardware interface, output format changes).

Performance monitoring requirements must exist. Post-market AI performance surveillance — comparing deployed model outputs against ground truth at defined intervals — must be specified as a requirement, not an afterthought.

Traceability must be maintainable. When a model update changes a performance threshold in the requirements, that change must propagate visibly through the traceability structure. If your requirements live in a Word document and your RTM lives in an Excel file, post-market model updates become a compliance liability.

How Medtech Startups Structure Requirements Engineering to Survive

The companies that successfully navigate this regulatory stack share a common structural approach, even when they implement it with different tools.

Clinical requirements are the root. The hierarchy starts with clinical claims and intended use, not with engineering features. Every hardware specification, software requirement, and AI performance threshold traces upward to a clinical rationale and downward to a verification test.

Risk management is continuous, not a phase. ISO 14971 risk analysis is not completed and then set aside. It is a living model that generates requirements throughout development. New risks identified during testing generate new requirements. Requirements changes trigger risk re-evaluation.

Software and hardware requirements are managed in a unified system. The failure mode of separating hardware and software requirements into different tools — a hardware team using Excel and a software team using Jira — is that cross-domain traceability breaks. A hardware signal conditioning requirement that changes in response to an AI model accuracy problem should visibly affect the software and hardware requirement dependency chain. Flat document systems hide these connections.

Verification is planned at requirement creation. Every requirement is written with its verification method (inspection, analysis, test, or demonstration) specified at the time of writing. This prevents the common late-stage discovery that a requirement has no feasible test.

Design history file artifacts are outputs of the process, not separate documents. The design history file (DHF) required for 510(k) submission is not assembled after design; it is the accumulated output of a requirements and verification process run correctly.

The Modern Tools Question

The requirements volume and traceability complexity of a product like Beacon’s exceeds what document-based tools handle gracefully. The legacy medtech approach — IBM DOORS for requirements management, separate risk management tools, spreadsheet RTMs — creates a maintenance burden that grows quadratically as requirement count increases. Changing a clinical claim requires manually hunting every downstream requirement, risk control, and test case.

Graph-based requirements management platforms handle this differently. When requirements are nodes in a connected model rather than rows in a document, the impact of a change is computed automatically. Adding a new risk control generates a visible gap in the traceability graph. A clinical claim change highlights every dependent downstream requirement.

Tools like IBM DOORS Next, Jama Connect, and Innoslate all offer traceability features that go beyond flat documents. Newer AI-native platforms such as Flow Engineering, which builds graph-based traceability for hardware and systems engineering contexts, represent a category designed around this connectivity model from the ground up rather than adding graph features onto a document foundation.

The practical consideration for a medtech startup is not which tool has the most features — it is which tool makes it possible for a 15-person engineering team to maintain accurate traceability across 2,000 requirements without dedicating two people full-time to RTM maintenance. The answer is almost always a tool that models requirements as a connected structure, not a tool that stores them as documents.

Honest Assessment

Beacon Biosignals is building a product category that the regulatory system was not designed for — a combined hardware, software, and AI system where the clinical decision-making function is emergent from a trained model rather than encoded in deterministic logic. The frameworks exist. The guidance is getting more specific. But the gap between what the standards assume and what AI-based medical devices actually are is still being actively negotiated between industry and FDA.

The companies that will succeed in this space are not the ones with the best AI. They are the ones that build requirements and traceability infrastructure early enough that their regulatory documentation reflects the actual product — not a simplified version of it that was written to pass a review. That discipline is not glamorous, and it is not where venture capital attention goes. But it is where 510(k) submissions succeed or fail.

For hardware-embedded AI in clinical settings, the requirements stack is not a compliance burden layered on top of engineering. It is the engineering.