TL;DR: FDA clearance answers whether your clinical AI is safe to sell. IRB approval answers whether your hospital can use it on their patients. These are two separate gates. Most clinical AI teams build only for the first one. They then watch deployment stall for months while retrofitting IRB documentation. The fix is a pipeline that produces both FDA and IRB packages from one source.

Key Takeaways: - FDA clearance and IRB review operate on different definitions of "human subject" and answer different questions - De-identified data does not exempt FDA-regulated AI from IRB oversight - IRBs need five documentation layers that most vendors never produce. These layers include local validation, data governance, change management, consent strategy, and site-specific risk-benefit analysis. - A modular IRB submission template paired with a versioned model registry compresses deployment timelines. It does this by reusing documentation across sites.

This is the new bottleneck in clinical AI. The FDA has authorized more than 1,240 AI-enabled medical devices. The majority were cleared in just the last three years.

But that headline number hides a harder truth. FDA authorization is a market access milestone, not a deployment milestone. The hospital's IRB still has to sign off before your model touches a single patient record.

The AI compliance world treats these as one gate. They are not. FDA clearance answers a product safety question. It asks: is this device safe and effective for its intended use?

IRB review answers a local research ethics question. It asks: should this institution expose its patients to this technology under these conditions?

Two different bodies. Two different rulebooks. Two different timelines.

The 21st Century Cures Act excludes some clinical decision support tools from device oversight. Yet hospitals still apply IRB scrutiny before allowing patient data access.

CTOs who treat FDA clearance as the finish line discover the real race starts after approval.

The two regulatory systems don't just differ in scope. They use different definitions of what counts as a "human subject."

The FDA evaluates device safety and efficacy through premarket pathways. These include 510(k) for equivalence to a predicate device. They also include De Novo for novel low-risk devices, and PMA for high-risk implants. These pathways share one trait. They produce a general market authorization. Your device can be sold across the US to any provider who buys it.

IRBs operate under the Common Rule. This is a different framework with a different mandate. They evaluate research ethics, risk to local participants, and whether the institution's context supports the activity. Multiple analyses show many FDA-cleared AI devices lack clinical performance data. The data isn't good enough to convince an institutional reviewer. That gap is what IRBs are designed to catch.

Here is the split that breaks most clinical AI teams. The Common Rule's definition of human subjects research excludes studies using only de-identified data. However, FDA regulations make no such distinction.

FDA treats the data itself as a human subject, similar to biological specimens. Model training on patient data triggers IRB obligations even when every field is de-identified.

For top AI companies for healthcare in India expanding into US markets, this is where deployments stall. The FDA filing is universal. The IRB filing is per-site, per-protocol, per-population.

Vendors who built one FDA package now need dozens of customized packages. Each hospital interprets "research" differently.

Most research teams assume HIPAA de-identification exempts them from IRB review. The NIH IRB office explicitly warns this assumption is wrong for FDA-regulated AI research.

If your AI analyzes human data to predict disease, IRB review is required. This rule applies even when every data point is de-identified. The rule covers model training, not just deployment.

Retrospective training on historical patient data triggers obligations before any clinical use begins.

That governance gap mirrors what we covered in RAG Is Dead for Healthcare AI. The model never sees a patient. The data it was built on is still regulated.

Most AI devices enter the market through the 510(k) pathway. This is a route with capped indications for use. IRBs read this as evidence the device isn't validated for their specific patient population. A model cleared for sepsis prediction in adult ICU patients at large academic centers looks very different. An IRB serving a rural community hospital with a different demographic sees it very differently.

This is where the pattern in Why 73% of Hospital AI Pilots Die in Year One starts. The pilot dies not because the model failed. It dies because the deployment infrastructure never accounted for local validation requirements. Teams that skip the IRB layer during planning pay for it during rollout.

IRB review is a documentation exercise. Vendors who lose here usually have the right model but the wrong paperwork. Here are the five layers every IRB submission needs. - Layer 1: Local validation protocol. IRBs want a site-specific study plan, not your FDA pivotal trial summary. Detail how you'll evaluate performance on their patient population. Use their EHR data, under their clinical workflow. - Layer 2: Data governance addendum. Describe data flows, access controls, retention policies, and how you'll handle re-identification risk. A HIPAA Business Associate Agreement is not enough. The IRB wants to see the actual controls. - Layer 3: Algorithm change management. IRBs are increasingly requiring a written plan for how model updates will be governed post-deployment. They also need to cover retraining and drift monitoring. Our piece on Your AI Model Is Drifting and You Don't Know covers why drift detection matters. IRBs want the governance layer, not just the metric. - Layer 4: Consent and patient notification. Determine whether the AI counts as standard-of-care enhancement (minimal consent) or research activity (full informed consent). Choose between the two options. The line is blurry for adaptive algorithms. Each IRB draws it differently. - Layer 5: Local risk-benefit analysis. Show how the AI addresses a documented clinical gap at this specific institution. Don't show the general market your FDA submission targeted. Use the hospital's own quality metrics, their own mortality data, their own readmission rates.

For vendors working with top AI companies for healthcare in India, layer 5 is where international expansion hits a wall. Each site needs its own risk-benefit story. The original FDA submission rarely supports it.

The pipeline has five components. Build them once, reuse them across sites. - Step 1: Modular IRB submission template. Separate universal content (FDA clearance, architecture overview, training data summary) from site-specific content (local validation, governance, risk-benefit). Teams with experience across many regulated environments treat this template as living infrastructure, not a one-time document. - Step 2: Versioned model registry. Every algorithm change documented with timestamped training data, performance metrics, and intended use. IRBs will ask for this history during renewal reviews. If you can't produce it quickly, your model is out of compliance. - Step 3: Pre-submission consultation. Many institutions offer informal pre-review that surfaces objections before formal submission. Use it. A 30-minute call with the IRB chair can save months of back-and-forth. - Step 4: HIPAA-compliant data handling layer. Log every data access event. This satisfies both the IRB's data governance layer and your AI compliance audit trail requirements. Vendors who skip this step end up rebuilding it per site. - Step 5: Drift monitoring plan. Define thresholds for performance degradation, escalation paths, and a model rollback protocol. This is the single document most AI vendors lack. It also feeds directly into Layer 3 of your IRB submission.

Teams that operationalize this pipeline compress deployment timelines by removing redundant documentation work. The difference comes down to how early you build these systems. A pre-built pipeline with reusable components lets each new site inherit the universal layers. Each new site only produces what's truly local.

A short deployment window is a competitive moat. It is still rare. What shifts when both gates clear isn't just timelines, though. The economics of clinical AI change in ways most vendors never model.

Clearing both gates changes the economics of clinical AI deployment.

Hospitals stop rejecting your deployment packages. Teams that built IRB-ready pipelines from day one consistently report faster multi-site expansion. They also report fewer renegotiation cycles. The friction moves from regulatory to operational. This is a much easier problem to solve.

Retention improves when hospitals see governance handled properly. They become long-term partners, not one-time contracts. Deployments that last in production share a common trait. They were built with post-market governance infrastructure, not bolted on after FDA clearance.

The competitive moat shifts. FDA clearance is increasingly common, with over 1,240 AI-enabled devices and counting. The differentiator is the ability to move through local review quickly at any hospital.

That is still rare. It is worth more than any clearance letter. For top AI companies for healthcare in India eyeing US hospital systems, this is the entry strategy that works.

Build the pipeline once. The next site inherits it.

Does FDA clearance eliminate the need for IRB review for clinical AI?

No. FDA clearance and IRB approval address different questions. They look at product safety versus research ethics. Hospitals require IRB review before allowing patient data access, even for FDA-cleared devices. The two processes are governed by separate regulatory frameworks. They must be completed independently.

Can de-identified patient data bypass IRB requirements for clinical AI?

Not under FDA regulations. The Common Rule excludes research using only de-identified data from human subjects research. However, FDA regulations make no such distinction. If your AI analyzes human data to predict disease risk, IRB review is required regardless of identifiability. This includes during model training.

How long does IRB review typically take for clinical AI deployment?

IRB review timelines vary by institution, risk level, and the quality of the submission package. Pre-submission consultations and well-prepared documentation packages can shorten review timelines.

Do hospital IRBs evaluate AI/ML devices differently than traditional medical devices?

Yes. IRBs increasingly require additional documentation for AI. This includes algorithm change management plans, drift monitoring protocols, local validation data, and re-identification risk assessments. Traditional device documentation focused on hardware or software feature is generally not enough.