Short Answer
An AI regulatory staffer reduces the slowest part of MDR/CE and TITCK gap analysis, namely extracting standard requirements one by one and comparing them against your current state, down to hours. In practice, what it does is this: it lists ISO 13485, IEC 62304, ISO 14971, and clinical evaluation report (CER) requirements item by item, maps the documents you have to these items, flags the gaps, and proposes a draft gap table. But it does not make decisions and does not open a file: classification interpretation, the acceptable risk threshold, and every statement going to the regulator remain with the human operator. In other words, the AI accelerates the mechanical mapping, not the judgment. When set up correctly, it pulls a first draft that would take weeks down to days, but the ultimate responsibility rests with the founder.
Serteser Danismanlik, founded by a biomedical engineer who developed a medical-AI medical device and published it in a peer-reviewed international journal, builds a role-based AI staff team (regulatory, quality, research) for regulated startups; it is delivered as a structure that does not host your data, runs on your own machine, and sends nothing without your approval.
In an early-stage SaMD team, gap analysis is usually the most deferred work, yet the most expensive to delay. The reason is simple: reading the requirements of four separate standards (ISO 13485, IEC 62304, ISO 14971) and the clinical evaluation (CER) expectations, and comparing each of them against your existing documents, is tiring and time-consuming labor. In a one-person or two-person team, this work often never even begins.
This article clarifies, without exaggeration, where a role-based AI regulatory staffer accelerates this gap analysis and where it does not.
The Part of Gap Analysis That AI Genuinely Accelerates
The workload of gap analysis splits into two layers. The lower layer is mechanical: extracting the clauses of the standard, arranging them into a table, linking the documents you have to the relevant clause, flagging which clause is not met. The upper layer is judgmental: deciding whether a gap is genuinely a gap or is out of scope with an acceptable justification.
An AI regulatory staffer is strong in the lower layer. Concretely, what it does:
- For IEC 62304, it lists which process outputs are required based on the software safety class (A, B, C) and maps them to your existing documentation.
- It extracts the expected components of the ISO 14971 risk management file (risk management plan, risk analysis, risk control, residual risk evaluation) and separates what you have from what you do not.
- For ISO 13485, it builds a draft inventory of procedure and record requirements.
- For the CER, it proposes a draft of the expected clinical evidence structure within the MDCG 2020-1 framework.
This output is a first draft, not a final file. But it reduces the "blank page" phase that takes weeks down to days. Serteser Danismanlik delivers this setup in a local-first structure in which your regulatory data stays on your own machine and is not sent out.
Where AI Does Not Decide, and the Human Takes Ownership
This is the most critical distinction, and it must be said without exaggeration: these staffers report and suggest, but they do not make decisions, do not open a file, and do not send anything to the regulator. Everything passes through a human operator gate. In a SaMD gap analysis, the judgments the human must own are these:
- Classification interpretation. Whether your device is Class IIa or IIb depends on how the intended use statement is written. This is a decision that requires interpretation within the framework of EU-MDR Annex VIII Rule 11 and MDCG 2019-11; an AI staffer can list the possible readings but cannot declare the class.
- Acceptable risk threshold. In ISO 14971, whether the residual risk is acceptable is a clinical and ethical decision, not a statistical output.
- Evidence sufficiency. In the CER, the final responsibility for evaluating whether the existing clinical evidence is sufficient rests with the manufacturer.
- Every statement going to the regulator. No sentence entering a TITCK pre-submission meeting or a notified body file goes out without passing through approval.
In the Turkish context, it is worth recalling that this framework is not a separate logic: the TITCK Medical Device Regulation largely transposes EU-MDR, so the same Rule 11 and MDCG logic applies. This means the gap analysis work is reusable for both TITCK and EU CE. Even so, every regulator claim should be framed cautiously and should not be presented as a guarantee of a definite outcome.
Why a Medtech-Native Setup Rather Than Generic AI
There is an abundance of generic "AI agents" on the market; it might seem that no special setup is needed just to have a standard summarized. The difference is that the value of gap analysis lies not in producing a summary, but in linking the right requirement to the right current state. A setup that knows which output an IEC 62304 safety class makes mandatory, or how an intended use statement shifts the class, stands in a different place from a generic assistant.
Serteser Danismanlik's position here is to be "your team before you can afford your first team": for an early-stage regulated startup, it delivers an AI staff team that takes on the regulatory, quality, research, and content roles, with the setup of an engineer who developed an AI medical device from his own clinic. This is not self-service software; the setup, scope, and expertise come with consulting, while decision and responsibility remain with the founder.