Platomics announces new collaborations Read the Press Releases

From Regulatory Data to Regulatory Intelligence: What AI Can and Cannot Do for IVDR Technical Documentation
Rethinking IVDR Technical Documentation – Part 4 of 4
Introduction
IVDR technical documentation is more than a collection of files. In this four-part series, we have examined how digitalization can make regulatory information more actionable, maintainable and suitable for responsible automation. The final article considers where semantic analysis and artificial intelligence can add value, and where regulatory judgement must remain decisive.
Ask a generative AI tool to draft a device description from an instruction for use and a product specification.
Within seconds, it may produce fluent, professional-looking regulatory text. It may identify the analyte, specimen type, intended user and measuring principle. It may even organize the information under the headings of Annex II.
But several questions remain:
- Did it use the currently approved documents?
- Did it distinguish a verified device characteristic from a marketing statement?
- Does every generated claim have an identifiable source?
- Did it preserve important limitations?
- Did it fill an information gap with a plausible-sounding assumption?
- Can the manufacturer reproduce and review how the result was produced?
The central question is not whether AI can write regulatory text. It is whether that text can be trusted, traced and controlled.
Not Every Automation Is AI
Regulatory automation can involve several different capabilities.
- Deterministic rules apply predefined logic. For example, identifying a device as intended for self-testing can trigger additional questions concerning lay users, usability and labeling.
- Semantic analysis examines the meaning of text. It can recognize that “EDTA plasma” and “plasma collected using EDTA anticoagulant” may refer to the same specimen type.
- Generative AI creates new text, summaries, recommendations or other content based on the information it receives.
These capabilities are related, but they are not interchangeable. Rules are often preferable when the relevant regulatory condition can be defined explicitly. AI becomes particularly useful when information is unstructured, terminology varies, and meaning must be extracted from narrative documents.
Content generation should normally come last. Before software drafts a new section, it should know what approved information already exists and which sources support it.
First, Understand What Already Exists
Not starting from scratch
Manufacturers rarely begin technical documentation with an empty page. Relevant information can often be found in existing documentation generated throughout the product lifecycle. This includes documents prepared during product development, such as product specifications and development data, as well as supplier documentation and legacy technical files.
Additional information may be available in performance reports, risk management files, and manufacturing records, while post-market surveillance documentation and previous regulatory submissions can provide further insights into the product’s performance and regulatory history.
Do a Systematic Review
AI-assisted analysis can support the systematic review of these documents by identifying relevant information and translating it into candidate regulatory variables. For example, AI tools can extract information about the device and its components, the types of specimens it is intended to analyse, and the users for whom it is designed.
They can also identify technical characteristics, such as measuring ranges and storage conditions, alongside performance claims, warnings, and limitations. In addition, these tools can capture information on applicable standards, suppliers, and manufacturing processes, helping to structure relevant data for further regulatory assessment.
This can significantly reduce manual searching and data entry. But extraction is not the same as approval.
Documenting Case by Case
A document may be obsolete. A statement may apply only to one variant. A supplier specification may describe the component generally rather than its use within the finished IVD. Two similar terms may have different regulatory meanings.
To ensure traceability and support subsequent regulatory review, all extracted information should remain linked to its original source, including its precise location within the document and the applicable document version. It should also be clearly associated with the relevant device or variant, where applicable, and its review status should be documented.
AI-assisted extraction should therefore be treated as a means of identifying and structuring information for human review, rather than as a mechanism for establishing new regulatory facts.
From Completeness to Consistency
A conventional completeness check can determine whether a section or field has been populated.
Semantic analysis can go further by comparing meaning across documents.
Consider an intended purpose that lists serum and EDTA plasma as supported specimen types. The current IFU also lists both. However, the analytical performance report available in the technical documentation refers only to serum. A system could identify the difference and raise a question:
Does the available performance documentation support both claimed specimen types?
That does not prove that evidence is missing. Plasma data might exist in another report, the performance report may have been superseded, or the intended purpose may recently have changed. The value lies in identifying the relationship that requires review. Similar automated checks can also help identify inconsistencies and potential gaps across the documentation.
For example, they may detect cases where a component manufacturer has changed but an outdated supplier certificate is still referenced, or where a performance claim appears in the IFU without corresponding supporting evidence in the referenced documentation. They can also highlight situations in which a device is described as quantitative but no measuring range is documented, or where different documents describe different intended user populations, such as professional laboratory users in one document and self-testing users in another.
Other checks may identify mismatched software versions across the device description, validation records, and labeling, or flag cases where a warning associated with a documented risk-control measure is no longer present in the current IFU.
Traditional comparison usually searches for identical words. Semantic comparison can identify potentially inconsistent concepts even when the wording differs.
Plausibility Is Not Compliance
The next step is plausibility checking. A completeness check asks:
Is information present?
A consistency check asks:
Is the information represented consistently?
A plausibility check asks:
Does the information make sense when considered together?
This is a powerful use case for AI, but also one that requires careful limits. AI may identify that the intended purpose, device configuration, evidence and labeling do not appear to align. It may propose explanations or questions for the reviewer. It should not automatically conclude that the technical documentation is noncompliant.
The apparent discrepancy may have a valid explanation. The system may not have access to all relevant information. It may misunderstand technical language or fail to recognize an indirect reference.
The appropriate output is therefore not simply noncompliant. It is more likely:
Potential inconsistency identified. The intended purpose includes EDTA plasma, but the reviewed analytical performance report refers only to serum. Confirm whether additional evidence exists or whether the documents require alignment.
This changes the role of AI from automated decision-maker to structured reviewer.
Content Creation Should Be Based on Controlled Information
Generative AI can help manufacturers create regulatory content, particularly where the required output is based on information that has already been approved.
These capabilities can support a range of recurring activities throughout the preparation and maintenance of technical documentation. For example, AI-assisted tools can help draft device descriptions and intended-purpose statements, prepare summaries of approved changes, and populate recurring sections of technical documentation.
They can also convert structured information into tables, suggest relevant cross-references, and summarize supplier documentation. Where human input is required, the tools can assist by drafting questions for subject-matter experts or preparing initial versions of review comments, which can then be assessed and refined by the appropriate reviewers.
The Governing Principle: Derive, do not invent.
Generated text should be based on identifiable source information and explicit regulatory context. Where information is missing, the system should raise a question or mark the gap rather than silently complete the sentence.
It is also useful to distinguish three types of AI-supported content:
- Extracted content: Information reproduced directly from an identified source.
- Transformed content: Existing information summarized, reformatted or adapted for a different regulatory context.
- Proposed content: A new interpretation, rationale or recommendation requiring expert assessment.
These categories should not be treated as equivalent. A transformed summary requires different review from an inferred regulatory conclusion. The more interpretation the system introduces, the stronger the need for review, justification and approval.
Fluent Errors Are Particularly Difficult to Detect
Generative AI can produce incorrect information in a confident and coherent form.
The US National Institute of Standards and Technology uses the term “confabulation” for generated content that is confidently presented but erroneous or false. Its guidance notes that such outputs may also contain fabricated logic or citations that appear to support the answer.
This risk is particularly relevant in domains requiring substantial context and specialist expertise. (NIST AI 600-1, Section 2.2.)
In regulatory work, a fluent error may be more dangerous than an obvious one. Professional wording can create an impression of authority and reduce the likelihood that the reviewer challenges the content.
Relevant controls may include:
- limiting the system to approved sources
- requiring source references for factual statements
- preventing unsupported citations from being presented as verified
- testing the tool with representative regulatory cases
- defining which outputs always require expert review
- recording relevant model and system versions
- monitoring performance after system updates
- preserving the distinction between source content and generated suggestions
Grounding an AI tool in controlled documents can reduce some risks, but it does not eliminate the possibility of incorrect extraction, interpretation or generation.
Governance Must Match the Use Case
Not every AI use requires the same level of control.
Using AI to reformat an approved table presents a different risk from using it to assess whether performance evidence supports an intended-purpose claim.
A proportionate approach could distinguish between activities such as:
- Lower-consequence support:
- formatting
- proofreading
- summarizing approved content
- translating internal working text
- generating search terms
- Intermediate support
- extracting regulatory variables
- comparing documents
- identifying inconsistencies
- drafting technical documentation sections
- proposing change summaries
- Higher-consequence support
- recommending GSPR applicability
- assessing evidence sufficiency
- proposing benefit-risk conclusions
- determining the regulatory significance of a change
- recommending notified body involvement
- concluding that technical documentation is compliant
As the potential regulatory consequences of an automated process increase, the level of control applied to that process should increase accordingly. This includes clearly defining its intended use and restricting it to authorized data sources, while ensuring appropriate controls over confidentiality and access.
Automated functions should also be subject to defined testing and acceptance criteria, with appropriate human review and approval before their outputs are relied upon. Traceability should be maintained throughout the process, and staff should have the competence required to understand, operate, and critically assess the system.
Mechanisms for error reporting and ongoing monitoring should be established to identify problems, assess their impact, and ensure that the system continues to perform as intended over time.
The EU Artificial Intelligence Act should not be used to assume that every internal regulatory support tool is automatically a high-risk AI system. Applicability depends on the characteristics of the system, its use and the organization’s role.
However, Article 4 requires providers and deployers within scope to take measures supporting the AI literacy of staff and other persons operating or using AI systems on their behalf.
(Regulation (EU) 2024/1689, Articles 1 to 4.)
In the medicines regulatory environment, European guidance on large language models similarly emphasizes safe data input, critical review of outputs, defined governance, training and risk monitoring. That guidance does not determine IVDR compliance, but it illustrates the broader direction of responsible AI use in regulated life sciences.
(EMA and HMA, Guiding Principles on the Use of Large Language Models in Regulatory Science and for Medicines Regulatory Activities, 2024.)
AI Does Not Transfer Regulatory Responsibility
This article concerns AI used to support regulatory work. AI that forms part of an IVD’s medical functionality raises separate product-regulatory questions and is outside this article’s scope.
For technical documentation, the manufacturer’s responsibilities remain unchanged.
Article 10(4) requires the manufacturer to draw up and keep technical documentation up to date. Article 10(9) requires a quality management system governing the structures, responsibilities, procedures, processes and resources necessary to achieve IVDR compliance.
Using AI does not transfer those responsibilities to the software provider or the model.
(Regulation (EU) 2017/746, Article 10(4) and Article 10(9).)
Regulatory professionals must ultimately assess the appropriateness and reliability of the information used in the compliance process. This includes determining whether a source is appropriate, verifying that extracted statements are accurate, and evaluating whether any generated rationale is scientifically and regulatorily defensible.
They must also determine whether the available evidence is sufficient to support the relevant conclusions, whether the remaining risks are acceptable, and whether the final technical documentation provides an accurate representation of the device. In this context, automation can support the regulatory process, but accountability for the resulting assessment and documentation remains with the responsible experts.
The most useful AI output may therefore be neither a finished document nor a compliance decision.
It may be a well-supported question that directs the expert to an issue that would otherwise have been missed.
From Digital Files to Regulatory Intelligence
Across this series, we have followed four stages of regulatory digitalization.
First, information must become more than text inside Word, Excel and PDF files. It must become identifiable and actionable.
Second, relationships must be visible so that manufacturers can understand the potential consequences of a device or component change.
Third, IVDR requirements must be translated into device-specific questions, applicability logic and information needs.
Only then can AI meaningfully support semantic comparison, plausibility checks and controlled content derivation.
The realistic future of IVDR automation is not fully autonomous compliance, but a combination of structured regulatory information, explicit regulatory rules, semantic analysis, and controlled generation, supported throughout by accountable expert judgement.
In this model, automation can handle the identification, organisation, comparison, and transformation of regulatory information, while human experts remain responsible for interpreting requirements, evaluating evidence, and making regulatory decisions. The objective is therefore not to replace regulatory expertise, but to create a system in which technology and expert judgement work together in a traceable and controlled way.
The purpose of AI should not be to hide regulatory complexity behind fluent text. It should make information, assumptions, inconsistencies and decisions more visible.
The most valuable regulatory AI will not be the system that writes the most text. It will be the system that helps experts see what the text is based on, what may be missing and where judgement is still required.
This article provides general regulatory information and does not replace an assessment of the legal, regulatory, data-protection or artificial-intelligence requirements applicable to a specific system, device, manufacturer or use case.
References
- Regulation (EU) 2017/746 on in vitro diagnostic medical devices – consolidated version dated 10 January 2025
Relevant provisions: Article 10(4), Article 10(9), Annex II and Annex III.
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence – consolidated version dated 27 July 2026
Relevant provisions: Articles 1 to 4. The applicability and obligations of the Artificial Intelligence Act depend on the characteristics of the AI system, its use and the role of the organisation.
- NIST AI 600-1 – Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
National Institute of Standards and Technology, July 2024. Relevant sections: Section 2.2, Confabulation; and Section 3, Suggested Actions to Manage Generative AI Risks.
- Harnessing AI in medicines regulation: use of large language models
European Medicines Agency and Heads of Medicines Agencies, September 2024. The associated guiding principles address safe data input, critical review of outputs, governance, staff training and risk monitoring. Their scope is medicines regulatory activity rather than IVDR technical documentation.
- Artificial intelligence in the European medicines regulatory network
European Medicines Agency. This page documents ongoing work involving AI-supported knowledge mining, process automation, data analysis and regulatory decision support. Its scope is medicines regulation and is cited as broader life-sciences context.
See how IVDR documentation can work from one source of truth
Join the founding partner program and help shape PlatoX® for IVD manufacturers. We’ll show you how it could fit your current documentation workflow—with no obligation.
*We have compiled the above information to the best of our knowledge, yet our blog entries do not constitute expert advice and cannot substitute your own examination of the legal situation applicable to you and your institution.



