How to Prompt an FDA Regulatory AI: What Works and What Wastes a Turn
Most weak answers come from the prompt. Usually four small details are missing. Adding them takes one extra sentence.
Short answer
A good prompt has four parts: the device and who uses it, a known anchor such as a product code or confirmed predicate, the exact decision you need, and how deep an answer you want. Most weak prompts are missing one part: a clear device, or a clear decision.
You do not need to know FDA terms. A plain description of your device, plus a direct question, works as well as expert phrasing. The one part you cannot skip is a clear, specific device description.
The examples here use Complizen AI. The four parts apply to any FDA regulatory assistant.
Where to start
This guide covers three kinds of work. Read the one that matches what you are doing now, or read all three.
Business questions
Pathway, timeline, cost, and competitive position, asked in plain language. No FDA terminology needed.
Route 2Detailed regulatory work
Predicate scoping, standards sweeps, and document cross-checks. Covers how to direct the assistant and how to verify what it returns.
Route 3Prompt fundamentals
The four parts of a working prompt, then the checklist at the end. Useful before either route above.
The four parts of a working prompt
Every strong prompt in this guide uses some mix of the same four parts. Give all four in your first message, and you skip most follow-up questions and wasted turns.
Find 510(k)-cleared predicate candidates for a reusable fingertip pulse oximeter used by adults in hospitals. Use product code DQA, cleared from 2022 onward, and explain why each candidate is a good match — with citations, not just a shortlist.
Repeating yourself is a sign of a missing profile.
Stop retyping the same device details. Save a device profile. After that, the phrase "for my device" brings in the full description, intended use, and key specs automatically. Uploaded documents work the same way. Say "our uploaded risk analysis" instead of pasting it in each time.
Weak and strong prompts, by task
The examples below use real, cleared devices, so you can run and check each one. Product code DQA covers oximeters, under 21 CFR 870.2700. Product code DXN covers non-invasive blood pressure systems, under 21 CFR 870.1130.
Looking up a clearance record
Tell me about K211632.
Pull the full FDA record for K211632 and summarise the device description, the indications for use, and any predicate devices it cites.
Classification
What class is my device?
My device is a reusable adult blood pressure cuff used non-invasively in outpatient clinics, connected to a standard sphygmomanometer. What FDA product code and device class would this likely fall under? What regulation number governs it?
Predicate research
Find me predicates.
Find 510(k)-cleared predicate candidates for a reusable fingertip pulse oximeter used by adults in hospitals. Use product code DQA, cleared from 2022 onward, and explain why each candidate is a good match.
Comparing devices
Compare these three devices.
Compare K211632, K212555, and K220351 side by side. Look at intended use, patient population, sensor type and key performance specs, and flag any meaningful differences from my device.
Pulling one attribute across many devices
What are these devices made of?
For K211632, K212555, and K220351, pull the stated accuracy spec and the intended patient population for each device. Put the results in a table.
Risk and adverse event history
What are the risks?
Look at adverse event and recall history for product code DQA. What device and patient problems come up most often? What design or labelling changes usually fix them?
Testing and standards
What tests do I need?
My device is classified under product code DQA, with predicates K211632 and K212555. Which bench, biocompatibility, and electrical safety standards would typically apply? Which ones do reviewers check most closely?
Guidance and regulation lookups
What does FDA say about software?
What does current FDA guidance say about the documentation level required for a moderate-risk Software as a Medical Device component in a 510(k)?
A full strategy run
Help me with my FDA strategy.
I want a full regulatory strategy for my device, described as [description and intended use]. Classify it, identify predicates, compare specifications, assess risk, and identify required testing, then produce a strategy report. Go straight to the full analysis.
A full strategy run is multi-step work. First, the assistant restates your request and proposes a plan. It also asks you to choose: a quick preliminary answer, or the full analysis. Say which you want up front, and you skip that step.
Route 1: prompting as a business leader
Describe the device clearly, then state the business decision you need to make. You do not need to know pathways, classes or FDA terms. Asking in plain business language does not give you a weaker answer.
A complete example
We are developing a wearable patch that tracks heart rhythm and sends alerts to a phone app. It is for adults at home, not in hospitals. What is the likely FDA path to market? Roughly how long does that usually take? What are the main risks that could delay us?
The same question, asked two ways
Both columns lead to the same underlying analysis. Use whichever phrasing is natural.
| Goal | Regulatory phrasing | Plain-language phrasing |
|---|---|---|
| Classification | What product code and device class applies to this device? | Does this need FDA clearance before we can sell it, and how risky does FDA consider it? |
| Pathway | Is this a 510(k), De Novo or PMA candidate? | What is the path to market and roughly how long does it take? |
| Predicates | Identify substantially equivalent predicate 510(k)s. | Which already-approved competitor devices are most like ours? |
| Risk | Summarise MAUDE and recall trends for this product code. | What safety problems have similar products had, and what should we avoid? |
| Testing | Which recognised consensus standards apply? | What testing do we need to budget for before we can submit? |
| Strategy | Produce a full 510(k) regulatory strategy report. | Give me a board-ready plan for getting this cleared, with risks and timeline. |
Prompts by business goal
Time to market
- In plain English, what is the fastest legitimate path to get this device on the US market, and what drives the timeline?
- If we launched a simpler version first, would that get us to market faster? What would we give up?
Cost and resourcing
- What are the major cost drivers in getting this device cleared, so I can budget for it?
- Do we need to hire a regulatory affairs person now, or can we start with the essentials? What are the essentials?
Competitive position
- Which competitor devices already cleared by FDA are most similar to ours?
- If a competitor cleared a device like ours, what does that tell us about how hard our own clearance will be?
Board and investor communication
- Draft a one-page, plain-language summary of our FDA strategy for a non-technical board.
- Explain what 510(k) and predicate device mean in one sentence each, the way I would explain them to my sales team.
Say up front whether you want a quick take or a full analysis, and describe the device in as much detail as you can. It is fine to ask how confident the assistant is before you act on an answer. Treat timeline and cost figures as ranges, not fixed promises.
Route 2: prompting as an in-house regulatory team
You already know regulatory affairs. This section is about directing the assistant well and checking its answers, the part most experienced RA and QA staff have had the least practice with.
Where it adds value, and where judgment stays with you
The assistant is fast and thorough at broad tasks:
- Scan large numbers of candidate predicates.
- Add up adverse event and recall trends for a product code.
- Check for standards that may apply.
- Write a first draft of a narrative.
- Cross-reference your internal documents against a standard or a strategy.
Some decisions always stay with the expert: the substantial equivalence argument, final predicate selection, acceptance criteria, risk acceptability, and anything you submit to FDA. Treat the assistant's output as a researched draft. It still needs your review and sign-off.
Verify everything before you rely on it
The assistant's output can sound confident and correct even when a detail is made up or does not match the real record. Expert review catches this. Here is a simple habit that catches it every time:
- 1Treat every detail as unverified until you see it in a source the assistant cites. This includes clearance numbers, product codes, regulation numbers, standard designations, standard editions, acceptance limits, and guidance dates.
- 2When a detail has no source, ask the assistant for one. If there is no source, treat the claim as something to check, not as a fact.
- 3Check every clearance number and product code the assistant cites against the real FDA record. You can ask it to pull the full record, so checking takes just one more prompt.
- 4If an answer mixes facts about your specific device with general regulatory background, ask the assistant to label each part separately.
- 5For anything tied to compliance, do not accept words like "requires," "confirmed" or "official" without asking what source backs that claim.
Use your own documents
For an established team, the assistant is most useful cross-referencing your own documents, not redoing analysis you can already do yourself. Upload device master records, risk files, prior submissions, predicate rationales, and test reports. Then tell it exactly what you want, for example:
Compare our uploaded verification test reports against the consensus standards usually expected for this product code. List anything missing or out of date.
Cross-check our risk analysis file against our bench test reports. Flag any hazard that no test covers.
Compare our draft indications for use against the cleared predicate's indications. Highlight any wording that broadens our claim.
Read our prior 510(k). Tell me which sections we can reuse for this new variant, and which need to change.
When the assistant answers from your files, it names the exact document it used. That means every statement traces back to a real record. If a task needs detailed evidence, ask the assistant to read the key documents in full, not just sample them.
Keep the request narrow
For expert use, the goal is simple: narrow what the assistant searches, and make it show its reasoning.
- Limit the search. "Class II only, clearances after 2020, limited to these three product codes." A narrow filter is easier to check later.
- Ask for reasoning and sources. "Show the reasoning for each predicate match and cite the record used." Then you can review the logic, not just the conclusion.
- Correct mid-task. "That predicate has a different intended use. Remove it and re-run limited to reusable sensors." You do not have to get it right the first time.
- Pin the anchors. Give the assistant your confirmed product code and predicates. Then testing and risk questions build on facts you have already settled.
- Name the output structure. Say the format you want: a reviewer-style deficiency list, a side-by-side equivalence table, or a traceability matrix. Naming it is usually enough to get it.
Find Class II predicates under product code DQA, cleared after 2020, and show the reasoning behind each match, with the record cited. Use our confirmed predicates K211632 and K212555 as the baseline, and return it as a side-by-side equivalence table.
Correct mid-task That predicate has a different intended use. Remove it and re-run limited to reusable sensors.
Working as a team across sessions
A shared device profile keeps the description, intended use, and key specs the same for everyone on the team. A project decision record holds the chosen product code, the selected predicates and the reason for each, plus the pathway decision. Anyone who joins the project later can see both the decisions and the reasoning behind them.
At the end of a session, you can update this record for the next person. Before it saves anything, the assistant shows you the update and waits for your approval.
Expert prompt library
| Task | Precision prompt |
|---|---|
| Predicate scoping | Find Class II predicates under product code DQA cleared after 2020 whose intended use matches reusable hospital sensors. Show the record used for each and exclude single-use devices. |
| Equivalence stress-test | Here is our substantial equivalence rationale. Push back on it the way an FDA reviewer would, and list the differences most likely to cause a deficiency. |
| Standards sweep | List the consensus standards typically expected for product code DQA, flag which are FDA-recognised, and mark which editions I must confirm before relying on them. |
| Document gap analysis | Compare our uploaded test reports against those standards. Tell me what is missing, and name the source file for each finding. |
| Risk file cross-check | Cross-reference our uploaded risk analysis against adverse event and recall trends for product code DQA. Flag any hazard we may not have weighed heavily enough. |
| Narrative drafting | Draft the device description section from our device profile and uploaded specification, using submission-ready language. Then list every fact you could not source from our files. |
Exploring options before committing
The assistant can also help you explore options, not just look things up and analyse them. It can generate several possible answers, compare them, and test a position before you commit to it. This mode gives you a set of choices to weigh, not one final answer. Treat every option as a starting point for your own judgment, and check any fact inside it the same way you would check any other answer.
| Purpose | Prompt |
|---|---|
| Claims exploration | Draft three versions of our indications for use, conservative through broad, and explain what each would require us to support. |
| Pathway scenarios | Outline the situations where this device would need a 510(k) instead of a De Novo pathway. Explain what determines which one applies. |
| Reviewer simulation | Act like an FDA reviewer. List the deficiencies you would most likely raise against this device description. |
| Risk brainstorming | Generate a list of possible hazards and use-error scenarios for this device, for use in our risk analysis. |
| Pre-Sub questions | Propose specific questions we should ask FDA in a Pre-Submission, to reduce uncertainty about our testing plan. |
Three habits make this kind of prompt work well. Ask for a set of options. Ask for the trade-off that comes with each option. And keep the two steps apart: generate options in one prompt, then evaluate them in a separate prompt.
Prompting for documents
Drafting splits into two kinds of output. The assistant produces quick working files, such as summaries, comparisons, and notes, right away. For formal submission content, such as eSTAR sections, device descriptions, indications for use statements, and 510(k) or De Novo sections, it starts from a template. You can pick an existing template or upload your own.
Name the exact document type, and the first draft comes back closer to what you need. Five habits help:
- Name the type and the audience. A submission-ready device description and an internal summary of the same device are different documents.
- Point to your source material. Base the draft on your saved profile and uploaded files. Ask the assistant to list any fact it could not find a source for.
- Specify structure and length. Give it an outline or a word count, and the draft comes back in the shape you asked for.
- Set the tone. Formal submission language, plain internal note, or executive summary.
- Revise in passes. Ask for specific changes rather than expecting a finished draft first time.
Draft a submission-ready device description from our device profile and uploaded spec sheet, as a 150-word paragraph, in formal submission language.
Revise in passes Tighten the second paragraph, and cite the predicate comparison.
For instructions for use, labelling, narrative sections, and deficiency responses, the assistant can also rewrite existing text in Simplified Technical English. This keeps the technical meaning, but makes the text clearer for non-native readers and easier to translate.
| Document | Prompt |
|---|---|
| Device description | Draft a submission-ready device description from my device profile and uploaded specification, and list any fact you could not source from those materials. |
| Indications for use | Draft an indications for use statement consistent with the intended use in my profile, in formal submission language. |
| Pre-Sub package | Draft a Pre-Submission meeting request covering our device, our proposed testing, and three specific questions for FDA. |
| Deficiency response | Draft a response to this Additional Information request. Address each item in order, and cite the supporting document for each. |
| Instructions for use | Review our uploaded instructions for use. Rewrite it in Simplified Technical English for clarity and easier translation. Keep the technical meaning, and flag anything unclear. |
Checklist before sending a prompt
- State what the device is, who uses it, and how it is used, including setting, patient population, and invasiveness.
- State the specific output required: classification, predicates, comparison, risk, testing, strategy or a named document.
- Say whether you want a quick answer or a deeper, evidence-backed analysis.
- Point to saved or uploaded material instead of retyping it.
- For documents, name the exact type.
- Refine your request in follow-ups. Do not expect a finished result on the first try.
Common mistakes
- Describing the device vaguely, as "a medical sensor" rather than by what it does and who uses it.
- Assuming the device is already known, with no saved profile, memory or uploaded documents.
- Treating a first draft as final instead of asking for revisions.
- Not specifying audience or format, then receiving the wrong tone.
- Skipping the quick-versus-full choice, then being surprised that a full strategy run takes longer.
- Accepting a confident-sounding answer without checking its clearance number, product code or standard edition against a source.
- Using the assistant to redo analysis your team can already do, instead of using it on your own documents for cross-referencing and gap analysis.
- Relying on a standard designation without confirming the FDA-recognised edition and any transition dates.
Limits to know about
Four things to know:
Database lag.
FDA databases update on their own schedule. A very recent clearance may not show up yet, so check time-sensitive lookups directly with FDA.
Standard editions.
The assistant can point you to standards that likely apply, but you must confirm the exact edition and any transition dates yourself, using the FDA recognised consensus standards database.
Timeline ranges.
Timeline figures are ranges. They do not account for review queues or how ready your submission is.
Reviewer discretion.
Nobody can predict how a specific reviewer will act. The assistant can describe what is typical. It cannot predict your outcome.
The assistant drafts and analyses. It is not your quality system of record, and it does not submit anything on your behalf. High-stakes decisions still belong with a qualified regulatory affairs or quality professional.
Frequently asked questions
Do I need to know FDA terms to ask a useful question?
No. A plain description of your device, plus a direct question, gets you the same depth of analysis as expert phrasing would. What matters most is a specific, clear device description, not the exact regulatory words you use.
What makes a regulatory prompt different from a general AI prompt?
Two things. First, a good regulatory answer depends on device details that a general prompt often leaves out, such as patient population, use setting, and how invasive the device is. Second, regulatory answers contain facts you can check, such as clearance numbers, product codes, and standard editions. Check these against a source. Do not accept them just because the answer sounds confident.
How do I check whether the assistant's answer is accurate?
Ask for the source behind any detail. You can cross-check clearance numbers, product codes, and regulation numbers against the real FDA record. The assistant can pull that record for you in one more prompt. If a detail comes with no source, treat it as something to verify, not as an established fact.
Can the assistant work from my company's own documents?
Yes, once you upload them. The assistant can search specifications, test reports, risk files, prior submissions, and standard operating procedures. It names the exact file behind each answer. This is usually more useful to an experienced team than general research, because it works with documents only your team has.
Can the assistant decide my device's classification or pathway?
No. It can suggest the likely product code and class, based on precedent and the classification regulations. It can also explain why. But the final decision, the substantial equivalence argument, and anything you submit to FDA stay with a qualified regulatory professional.
Why does the assistant sometimes ask a question instead of answering?
Sometimes a detail is unclear, or you need to make a choice, such as picking between several possible product codes. A full device description up front makes this happen less often. Before any multi-step task, the assistant also restates your request and proposes a plan. You can skip that step by saying up front whether you want a quick answer or a full analysis.