An AI product that analyses medical data, supports clinical decisions, predicts risk, or controls a medical function may fall within India’s medical-device framework. Its intended purpose and potential effect on patients matter more than the technology label. For an applicant in West Bengal, the appropriate authority and route depend on the device’s risk class, manufacturing location, and proposed activity. Before market entry, developers must align their claims, evidence, quality controls, and application materials. A software release can also change that regulatory position after launch.
When Does AI Software Become a Medical Device?
The Drugs and Cosmetics Act, 1940, and the Medical Devices Rules, 2017, provide the principal Indian framework. Regulatory status turns on the product’s intended medical purpose, functions, and claims. An algorithm does not become a medical device merely because a hospital uses it or because its developer calls it artificial intelligence.
Software that schedules appointments, manages invoices or displays general wellness information may sit outside medical-device licensing if it makes no medical claim. In contrast, software that identifies a suspected disease on an image, interprets diagnostic information or recommends a patient-specific intervention may require assessment as a medical device. Software that controls medical hardware also needs scrutiny, whether the algorithm runs locally, on a mobile device or through a cloud service.
Developers should examine what the product actually does alongside its label, instructions, website, sales demonstrations and intended users. A disclaimer cannot reliably neutralise a specific diagnostic claim or a function that materially influences clinical decisions. Equally, a clinician’s involvement does not automatically remove a decision-support tool from the framework.
Describe the intended purpose before assigning a risk class. Identify the patient population, medical condition, inputs, output, intended user, and point in the clinical pathway. Then explain how a user should act on the output and what could happen if it proves wrong.
Classify Risk Before Selecting a Licensing Route
India uses Classes A, B, C and D, which progress from lower to higher risk. The Medical Devices Rules set classification principles, while official lists identify numerous device categories. A novel AI function may not match a listed description precisely; applicants should document their reasoning and seek appropriate regulatory clarification where uncertainty remains.
For software, the seriousness of the condition and the clinical significance of its output deserve particular attention. A tool that organises images for viewing differs from one that flags a possible emergency. Likewise, an output that supplies background information differs from one that drives a diagnosis or treatment decision. False reassurance, unnecessary treatment and delayed intervention can each affect the risk analysis.
Classification influences the competent authority, manufacturing application route and extent of regulatory scrutiny. It also shapes how the applicant justifies performance, clinical evidence and risk controls. However, no generic rule assigns every diagnostic algorithm, predictive model or connected device to one class. The actual intended use and applicable classification provisions govern the assessment.
Applicants should preserve a classification memorandum showing:
- The intended purpose and medical claims.
- The applicable rule and any relevant official device listing.
- The clinical significance of an incorrect output.
- The reasoning behind the proposed class and any unresolved questions.
Review that rationale when the product acquires new functions or claims. A later release that changes clinical decisions may invalidate assumptions made for an earlier version.
Identify the Competent Authority and Activity
The Central Drugs Standard Control Organisation, or CDSCO, performs central regulatory functions under the Medical Devices Rules. The Central Licensing Authority handles matters including import licensing and domestic manufacture of Class C and D devices. State Licensing Authorities generally handle domestic manufacture of Class A and B devices, subject to applicable exemptions and the specific route. The central authority also has functions concerning new or investigational devices.
A West Bengal address does not create a separate substantive AI-device rule. It does matter when an applicant manufactures a device at a site under the competent State Licensing Authority’s jurisdiction. Conversely, an importer based in West Bengal generally follows the central import route. A developer, legal manufacturer, Indian authorised agent, distributor and hospital customer may hold different responsibilities; their physical addresses do not make those roles interchangeable.
The rules also provide a licensing exemption for certain Class A devices that are neither sterile nor measuring devices. Applicants must assess its exact scope rather than assume all Class A software qualifies or that an exemption eliminates every applicable obligation.
Manufacture, Import and Special Permissions
Domestic manufacture for sale requires the route appropriate to the device class and manufacturing arrangement. The legal manufacturer should establish which entity assumes responsibility for design, production, release, labelling and continuing compliance. A loan-licence arrangement requires assessment when another licensed facility undertakes manufacture on the applicant’s behalf.
Importing a finished device follows a distinct central route, commonly through an authorised Indian agent acting for the overseas manufacturer. Foreign authorisation may contribute to an application, but it does not itself grant permission to market the device in India.
Units intended solely for testing, evaluation, demonstration, training or clinical investigation require assessment under the corresponding provisions; applicants must not treat such permissions as commercial licences. A device without an appropriate predicate, or another product that meets the applicable new-device criteria, may need additional permission before ordinary manufacture or import. Confirm the sequence and current forms for the actual product rather than copying a form list from another device category.
Prepare the Applicant, Sites and Quality System
Identify the legal manufacturer early. A software developer may write the model while another entity controls its intended purpose, release and market placement. Contracts should allocate development, testing, hosting, maintenance and complaint responsibilities clearly, but private contracts cannot displace statutory duties.
Map every site and critical supplier. Software production may involve code repositories, remote teams, cloud infrastructure, data processors, external testing and an assembly site for connected hardware. Even without a conventional factory floor, the manufacturer needs controlled development, verification, release and recordkeeping processes. The application should consistently describe the entity, site, product variants and activities.
An appropriate quality-management system connects product requirements to documented evidence. It should control design inputs, development decisions, software versions, testing, supplier work, releases and changes. It also needs mechanisms for complaints, corrective and preventive action, internal review and management oversight. Applicants should apply the quality requirements relevant to their device and route; holding a private certificate alone does not establish regulatory approval.
A practical system answers three questions for every release: what changed, what evidence supports the change, and who authorised deployment? Configuration records should identify the model, software, training-data version where relevant, interface and compatible hardware. Without that traceability, a manufacturer may struggle to investigate a complaint or identify affected users.
Build a Device-Specific Technical File
Technical documentation should explain the product well enough to support its proposed use, classification and safety claims. The precise contents depend on the device and application route, but generic descriptions of an algorithm rarely suffice.
Organise the evidence around:
- Device identity, variants, intended purpose and intended users.
- Patient population, clinical setting, indications and limitations.
- Architecture, interfaces, hardware dependencies and software versions.
- Design requirements, risk analysis, verification and validation.
- Performance and clinical evidence appropriate to the claims.
- Labelling, instructions, maintenance and post-market controls.
The description should show how data enter the system, how the model produces an output and how a clinician or other authorised user receives it. Record dependencies such as scanners, operating systems, network access and third-party software. Where interoperability affects safety, test the relevant interfaces rather than assume that technically compatible systems behave identically in clinical use.
A medical device license consultant in West Bengal may assist when an applicant must reconcile uncertain classification, outsourced software development and an import or manufacturing route. Specialist input can help expose inconsistent documents, but the legal manufacturer must substantiate its own intended use, evidence and controls.
Address AI-Specific Safety and Performance Risks
An AI model can perform differently when a hospital changes its equipment, patient population, image protocol or data quality. Consequently, a single overall accuracy figure cannot establish that the product works safely for every intended setting.
Document where development and validation data came from, whether their use was lawful, and how teams checked their quality. Explain annotation methods and disagreements where human-labelled data establish the reference result. Separate development from independent evaluation so that performance estimates do not simply reflect repeated testing on familiar cases.
Assess clinically meaningful measures, including false positives and false negatives. Subgroup analysis may reveal poorer performance for patient groups, conditions or acquisition settings that an average conceals. Where data do not adequately represent an intended group, narrow the claim, obtain further evidence or establish a suitable control. The assessment should match the actual clinical consequences of errors.
AI risk controls should address:
- Inputs outside the validated range and unreliable data.
- Human review, automation bias and output interpretation.
- Model drift and real-world performance signals.
- System downtime, failed integrations and fallback procedures.
- Cybersecurity, access control, logging and recovery.
- Version identification, rollback and controlled deployment.
A locked model keeps its approved behaviour stable between controlled releases. An adaptive model that changes after deployment presents additional questions about validation and change control. Developers should not assume that continuous retraining falls within an earlier authorisation. Define how they detect performance deterioration, investigate its cause and decide whether a proposed model change needs regulatory assessment.
Explainability should serve the intended user. A clinician may need to know an output’s scope, confidence and limitations rather than receive a misleading impression of certainty from a visual highlight. The interface should make human-review requirements and failure messages clear.
Match Clinical Evidence to the Claim
Technical verification asks whether software meets its specifications. Analytical validation examines how accurately it processes defined inputs. Clinical performance asks whether the output supports its stated medical purpose in the intended population and setting. These questions need different evidence.
The required evidence depends on risk class, novelty, intended use, patient risk and the extent to which users rely on the output. A retrospective dataset or published paper may support part of the case, but applicants must assess its relevance to the marketed version and Indian use conditions. Foreign clearance likewise cannot replace an Indian regulatory determination.
Where the applicable rules call for a clinical investigation or performance evaluation, establish the required permission, protocol and oversight before starting. Do not assume every AI device needs an identical prospective study. Conversely, do not infer that a small technical test establishes clinical benefit. Document the chosen evidence strategy and its limitations.
Keep Claims and Labelling Consistent
The application, software screens, instructions, website and demonstrations should describe the same intended purpose. State who may use the device, what inputs it accepts, how users should interpret outputs and which limitations require further clinical assessment.
Provide relevant identification, manufacturer or importer details, version information, system requirements, warnings and operating instructions according to the applicable labelling provisions. For a connected product, explain installation, connectivity dependencies and update arrangements where they affect safe use.
Marketing teams should review new diagnostic, predictive or treatment claims before publication. A statement that expands the patient population or shifts an output from assistance to autonomous decision-making can alter the regulatory assessment even if engineers make no code change.
Manage the Device After Market Entry
A licence does not end the manufacturer’s responsibilities. Track distribution and software deployment so the organisation can identify affected versions and users. Investigate complaints, evaluate reportable incidents under the applicable vigilance rules, and undertake field safety action or recall when necessary.
Cybersecurity maintenance and clinical performance monitoring both matter for connected AI devices. A vulnerability may expose data or alter outputs; model drift may reduce accuracy despite unchanged code. Review signals from complaints, monitoring and clinical users together rather than treating them as unrelated issues.
Apply change control before releasing a new model, architecture, intended use or major performance claim. Assess whether the change remains within existing permission or requires an application or amendment. Keep supporting tests, risk decisions and release approvals. Confirm current licence maintenance requirements for the specific authorisation.
For a West Bengal operation, keep local site and personnel records aligned with the application. Where development, hosting, manufacture and distribution occur in different jurisdictions, document who controls each activity. Other facility, business, labour, tax and data obligations may apply separately; a medical-device licence does not replace them.
Resolve Common Gaps Before Filing
Recurring problems arise when teams treat a clinical algorithm as ordinary software, select a risk class without written reasoning or describe different intended uses across documents. Confusion over which entity acts as legal manufacturer can also leave supplier and release responsibilities unclear.
Generic software test reports may omit clinical failure modes. Accuracy percentages can conceal subgroup bias, while cloud contracts may leave incident access and recovery unresolved. An applicant may also overlook how frequent releases affect the approved product description. Each gap can trigger regulatory questions or create a problem after launch.
Before submission, confirm:
- The product’s regulatory status, intended use and proposed class.
- The competent authority and correct manufacture or import route.
- The legal manufacturer, sites and outsourced responsibilities.
- Quality-system controls and a version-specific technical file.
- Clinical, subgroup, cybersecurity and usability evidence.
- Consistent labels, screens and promotional claims.
- Complaint, monitoring and future-change arrangements.
Resolve discrepancies while the team can still revise its product or evidence plan. Filing a technically complete application cannot compensate for an internally inconsistent device description.
Conclusion
An AI-enabled product’s intended purpose determines whether medical-device regulation may apply; risk classification then shapes its authority, licensing route, and evidence needs. Manufacturers and importers must align technical performance, clinical support, quality controls and product claims before market entry, then manage software changes and safety signals afterwards. Before filing, compare the proposed device, every marketed version, responsible entities and supporting documents against the current Indian rules and the requirements of the competent authority.
FAQs
Does every healthcare AI tool need a medical-device licence?
No. Regulatory status depends on the tool’s intended medical purpose, functions and claims, not its use of AI or its healthcare customers alone. Administrative and general wellness tools may fall outside medical-device licensing. A tool that diagnoses, predicts clinical risk or materially directs care requires closer assessment.
Who regulates devices manufactured in West Bengal?
The competent authority depends on the activity and risk class. The applicable State Licensing Authority generally handles domestic manufacture of Class A and B devices, subject to the rules and exemptions. The Central Licensing Authority handles Class C and D manufacture and import matters. Applicants should verify their specific route.
How does intended use affect an AI device’s class?
Intended use establishes what medical decision the output supports and what could happen if it proves wrong. The clinical condition, significance of the information and applicable classification rules then inform the proposed class. A developer should document its rationale instead of assigning a class solely from the underlying algorithm.
Can cloud-based software qualify as a medical device?
Yes. Cloud delivery does not determine regulatory status. Software supplied through a server, mobile application or local installation may qualify if its intended purpose meets the relevant medical-device criteria. Developers must also assess connectivity, cybersecurity, version control and responsibility for the service components that affect safe performance.
Can one licence cover several models or versions?
Coverage depends on the authorised device description, variants, intended purpose and applicable regulatory provisions. Minor maintenance and a new diagnostic function do not present the same change. Manufacturers should identify every marketed version, assess differences and seek regulatory clarification or an amendment where a change exceeds existing coverage.
Do imported AI medical devices need Indian authorisation?
An importer should assess the Indian import-licensing route for the finished device and any additional requirements that apply to a new device. An authorised Indian agent may act for the overseas manufacturer as the rules permit. Foreign clearance can support evidence, but it does not automatically authorise Indian marketing.
What clinical evidence can support an AI-enabled device?
Evidence should address the claimed clinical purpose in a relevant population and setting. It may include appropriate performance studies, clinical data and an evaluation of foreseeable errors. The required package depends on novelty, class, risk and existing evidence; a retrospective dataset alone may not answer every clinical question.
Does every software update need fresh regulatory approval?
Not necessarily. The manufacturer should assess each update against the authorised intended use, performance, risk profile and applicable change requirements. Security maintenance may differ from retraining a diagnostic model or expanding its patient population. Document the assessment and obtain any required regulatory action before deploying a significant change.
How should manufacturers address bias and model drift?
They should assess whether development and validation data represent intended users, examine performance across relevant groups and settings, and investigate material differences. After launch, they should monitor complaints and performance signals. When drift appears, controlled investigation, corrective action, and any necessary regulatory assessment should precede a changed release.
Can foreign approval replace an Indian licence?
No. A foreign authorisation may provide useful technical or clinical material, but Indian market entry follows the applicable Indian medical-device rules. The applicant must determine the correct class, authority and route, then submit evidence relevant to the product and its proposed Indian intended use.
