Dovetail
Choose support for your regulatory work

Choose a regulatory AI assistant for your device team

Your regulatory lead needs help getting work done, but a convincing answer in a demo does not show what the team can safely use. Choose an artificial-intelligence, or AI, regulatory assistant by the task you need it to perform, the evidence you can inspect and the decisions your people will retain.

For medical-device teams, that means separating research about regulations from work on your own controlled records. This guide helps you shortlist tools and run a bounded evaluation. It concerns AI used to support regulatory work, not the regulatory pathway for an AI-enabled medical device.

Dovetail publishes this guide and provides QMS Plus, which includes its browser-based agent, and Coworker. The product examples below use public descriptions, not hands-on comparative testing or an independent ranking.

What work do you need the assistant to do?

Write down one task before comparing feature lists. Finding relevant public guidance, preparing a submission draft and proposing changes to your quality management system, or QMS, involve different sources, permissions and review work. A tool that suits one task may not cover the others.

Use these starting points. Decide where you want to work as well as what you want the assistant to do. An agent inside your browser-based QMS and an assistant in a team chat can support related tasks through different interfaces.

Your immediate taskWhat to ask the provider to demonstrateWhat your reviewer should inspect
Research a regulatory questionRetrieve the relevant sources and explain their applicabilityOriginal passages, dates, jurisdiction and the limits of the conclusion
Prepare a document or submission draftUse the supplied evidence and identify missing inputsTraceability to inputs, assumptions and unresolved sections
Work with an agent inside your browser-based QMSOpen the relevant device context and prepare a document draft or gap review in the applicationWhich records the agent used, the proposed output and how your team reviews it
Move work through your QMSFind the intended records and propose a controlled changeAccess, document revisions, the proposed difference and the approval boundary

These are practical buying criteria, not regulatory classifications. Keep the proposed scope narrow enough that someone in your team can assess the result.

If your actual problem is deciding what evidence the device needs, name the person who will make that decision. Faster drafting will not resolve an unanswered clinical or regulatory question.

Which products belong on your shortlist?

Use published capabilities to decide what to investigate, then ask each provider to show the relevant task. Category labels alone do not establish comparable functionality, and a feature missing from a public page is not proof that a product lacks it.

The public descriptions illustrate different starting points.

Agent Astro describes regulatory research, predicate comparisons, structured outputs and eSTAR drafting. Its page also describes organizational knowledge and confirmation before deeper research runs. Those are reasons to investigate a research-and-submission workflow, not evidence of its performance on your device.

Rhizome presents its medical-device offering around cited regulatory precedent and research. Its vendor-authored comparison describes connections into other assistants through Model Context Protocol, or MCP. That connection can bring research into another application, but it does not by itself establish controlled editing of your QMS records.

RegDesk describes using product information to populate submission forms, checklists and other documents. If repeated applications across markets consume your team's time, ask it to demonstrate the relevant template and how a reviewer checks the populated content.

Dovetail QMS Plus combines a verified eQMS with a browser-based regulatory agent. Its published agent capabilities include FDA predicate search, device classification across jurisdictions, document drafting and review, gap analysis against standards and submission-format checking. You can work in the browser; Slack or Microsoft Teams is not a prerequisite. Ask for a demonstration using your device context and a document your reviewer can assess. These are published capabilities, not proof that a particular regulatory conclusion is correct.

Dovetail Coworker describes work in Slack and Microsoft Teams connected to your QMS, with sources, progress and proposed changes visible in the conversation. If that is the workflow you need, evaluate the exact connection, access and approval behavior available for your team.

QMS Plus is the platform to assess when you want the agent alongside your QMS in the browser. Coworker is the channel-based option to assess when the conversation belongs in Slack or Microsoft Teams. Do not treat a chat integration as a requirement for using the browser-based agent, or assume that the two interfaces have identical actions and approval behavior.

These examples are not interchangeable recommendations. None of the public descriptions establishes which product will perform best on your task. Ask for evidence rather than carrying a marketing claim into your buying decision.

How should you run a useful evaluation?

Give each shortlisted provider the same bounded task and assess the result against criteria you set beforehand. Include a realistic uncertainty, such as an outdated source or a missing input, so you can see whether the assistant exposes the gap instead of completing the story around it.

Here is an illustrative exercise. The records and scenario are invented, not a customer case or a product test.

Your team has an approved intended-purpose statement, a draft requirements document and a proposed feature change. Ask the assistant to identify which records may need review and prepare questions for the regulatory lead. Do not ask it to declare the change acceptable or release revised documents.

For a browser-based evaluation, open the intended device workspace, ask for a draft or gap review, and inspect the records and output in the application. Check that changing the selected device or document does not silently carry the wrong context into the next task. Browser-based here means working with the agent in the web application, not permission to operate arbitrary third-party websites.

Supply only material you are authorized to share. Synthetic records can test the workflow before you consider using confidential information.

Evaluation itemWhat you provideWhat you want to see
Browser workspaceOne selected device and a bounded drafting or gap-review taskThe agent uses the intended context, and the reviewer can inspect the output in the application
Document scopeTwo clearly identified revisionsThe assistant identifies which revision it used
Proposed changeOne bounded feature descriptionThe output distinguishes supplied facts from assumptions
Evidence gapOne deliberately missing inputThe assistant identifies the gap and asks a focused question
Proposed actionA request to prepare review workThe output separates a proposal from an executed change
Review recordA named reviewer and decisionThe team can recover the sources, proposal and review outcome

These are suggested acceptance criteria for your pilot, not a statement that any named product passes them. Record what happened, including failed cases and the work your reviewer needed to correct.

What makes a citation useful?

A citation helps only when your reviewer can open the source and check that it supports the specific statement. Test the passage, version and applicability, not just whether a link works. A relevant document title can still sit beside an unsupported conclusion.

For a public-source question, ask the assistant to identify the jurisdiction and distinguish legal text from guidance and its own interpretation. A US source does not establish an EU requirement merely because both concern the same device type.

For an internal question, ask for the record identifier, revision and relevant section. Then check whether the output reflects that record accurately. A source-grounded answer still needs someone to assess whether the source applies to the decision.

The same principle matters when your team reviews a clinical evidence gap. Our technical-documentation deficiencies guide distinguishes evidence that is hard to locate from evidence that does not support the conclusion. An assistant should help make that distinction visible, not hide it behind fluent wording.

What should you establish before connecting company records?

Ask for the access and data-handling arrangements for the exact service you are evaluating. Do not assume that a familiar chat application, a source citation or a private workspace answers questions about retention, training, subprocessors or who can retrieve a record.

Review the applicable contract and security documentation with your responsible team. Establish what information the connection can read, what actions it can perform, how access changes take effect and what records remain when you stop using the service.

For an agent embedded in your QMS, include the browser workspace in that access review. Establish which device and document context it receives, where generated drafts are saved and who can approve changes. Do not assume that a draft generated inside the platform is an approved controlled record.

Then test the boundary. Use accounts and synthetic documents with deliberately different permissions. Check whether a user can retrieve material outside the agreed scope and whether a proposed write waits for the intended review.

Keep the distinction between finding information and changing an approved record explicit. A successful search does not demonstrate an approval workflow.

How do you compare the real cost?

Compare the cost of producing a result your team can accept, including review and correction. A short answer that needs substantial checking may remove less work than a slower output with clear sources and a usable handover. Measure that on your own task rather than assuming it from a subscription price.

For each pilot, record preparation time, review time, corrections, unresolved questions and the accepted output. Keep the task and reviewer expectations comparable. Do not turn a small evaluation into a general accuracy or savings claim.

Ask what happens when the work leaves the tool. Can you retain the relevant output, sources and review record in the systems your team uses? Who maintains the connection and checks changes to templates or source coverage?

If choosing and operating the QMS itself is the larger decision, our medical-device startup eQMS guide addresses that separate task. An assistant evaluation should not quietly become a software migration.

When is an assistant the wrong next purchase?

An assistant may be a poor next step when nobody can define the task, supply suitable inputs or review the result. Establish that ownership first. If the missing capacity is senior regulatory judgment or programme coordination, assess the people and service scope you need before buying more software.

A useful pilot can reveal that only part of the task should be assisted. You might accept help assembling sources while keeping interpretation and document decisions with your lead. That is a workable boundary, not a failed purchase.

For the separate decision about external delivery capacity, our Envoy and regulatory consultant comparison explains how to compare responsibilities and work packages.

Sources and further reading

  • Dovetail QMS Plus describes the included agent, its browser interface and regulatory research, drafting, review and gap-analysis capabilities.

  • Dovetail Coworker describes the channel-based, QMS-connected workflow to assess during onboarding.

  • Agent Astro describes its regulatory research, structured outputs and submission-related capabilities.

  • Rhizome's medical-device selection page explains its research positioning. It is a vendor-authored comparison, not independent comparative evidence.

  • RegDesk's AI regulatory affairs page describes its submission and form-population workflows. Test the relevant task rather than adopting its general performance claims.

Questions to ask before you choose

Use these questions to define the task, the evidence and the review your team needs.

No. This guide concerns tools supporting a regulatory team's work. An AI-enabled medical device raises a different question about the product's intended purpose and applicable regulatory pathway. Make that distinction explicit when searching for tools or briefing a provider.

Yes. Check whether the cited passage supports the statement and applies to your device, jurisdiction and question. A working link does not establish that the conclusion is right.

No. QMS Plus includes a browser-based regulatory agent, so Slack or Microsoft Teams is not required to use that interface. Coworker serves the channel-based workflow. Choose where your team needs to work, then test the available context, actions, permissions and review behavior in that interface.

You can start with synthetic or appropriately cleared material to test retrieval, revision handling and proposed actions. That will not establish performance on every real task, but it can expose workflow problems before you broaden access.

Keep the task, inputs and revisions, returned output, supporting sources, corrections and review decision. Record what the pilot did not test as carefully as what it demonstrated.

Bring one workflow to the conversation

QMS Plus includes a browser-based regulatory agent alongside a verified eQMS. Bring a drafting, research or gap-review task, the records it needs and the person who will review the result. Evaluate the agent in the platform and establish fit before extending the scope.

About the author

Dr Spencer Todd is the CEO and co-founder of Dovetail, a regulatory partner for medical device companies. Before founding Dovetail, he spent years at the FDA and as a medical device consultant.