Most medtech companies have more quality data than they can act on. Complaints pile up, Corrective and Preventive Actions (CAPAs) sit in backlogs, nonconformances (NCs) get resolved in isolation. Field data flows into the quality management system (QMS) on one side, and the engineering team makes product decisions on the other. The two rarely converge.
Quality engineers have known about this problem for years. Product development teams have known about it too. The gap between field surveillance and design iteration is one of the most commonly acknowledged structural issues in post-market quality operations. What has changed is that AI can now do something practical about it.
The actual problem: data without synthesis
Consider what a typical post-market quality team collects on a device product line. Customer complaints, CAPAs, nonconformances, service records, return data. All of it lives in the QMS. At the same time, engineering teams work in Jira, manage design files in product development environments, and run sprints according to their own prioritization logic. Good QMS processes define a pathway for field data to inform design decisions, but executing that pathway manually means someone has to read through every complaint, cross-reference open CAPAs, check the FDA's public adverse event and recall databases, and surface a synthesized picture for the engineering team before a product review meeting.
That process takes days. It often does not happen at all, and when it does, it happens on a quarterly or annual cadence that is too slow for the data to drive real decisions.
The result is that field data gets used primarily for its regulatory obligations, specifically complaint investigation, mandatory reporting, and post-market surveillance (PMS) documentation. Its potential as a design input, something that should directly weigh on what gets prioritized in the next development sprint, gets underused. This is the structural tension at the core of post-market surveillance in practice.
Three foundations for a connected loop
Before AI adds meaningful value, the organizational conditions have to exist. Will Sanders, a medical device quality engineer with a decade of hands-on experience across ISO 13485 and ISO 14971 risk management, describes three foundations for building a genuine closed loop between post-market operations and product development.
The first is communication culture. Teams working in complaint investigation and teams working in R&D need a shared language and a willingness to treat field data as a design input rather than a compliance burden. The quality side may be raising urgent signals, but those signals have to land in a context where product development treats them as design inputs rather than interruptions. This is an organizational norm, not a technical fix.
The second is formalized cross-functional processes. Open communication is not sufficient on its own. The pathway for field data to reach the design team needs to be defined in the QMS: how often it happens, who is responsible for the handoff, how routing decisions get made. When two departments have different priorities, a documented process gives both sides a reference point for resolving the conflict.
The third is the data pipeline itself. The most reliable way to ensure that field data reaches design is to connect the systems so that the transfer happens automatically. Relying on manual reporting means relying on someone to do it consistently under competing priorities. A technical connection between the quality management system, the engineering environment, and relevant external databases removes that dependency and closes the loop at the infrastructure level. This is also where AI has something concrete to offer.
What AI actually does here
Large language models are not well suited to decisions that require regulatory judgment or engineering expertise. But they are extremely well suited to one particular job that used to require days of manual work: reading through large volumes of structured data, identifying patterns, and surfacing a synthesis in minutes.
The approach Will Sanders demonstrated connects an AI agent to two data sources simultaneously. The first is the QMS itself, specifically complaints, CAPAs, nonconformances, and design development files. The second is OpenFDA, the FDA's public API that gives programmatic access to 510(k) clearance data, recalls, adverse event reports, Manufacturer and User Facility Device Experience (MAUDE) database records, device classifications, and Unique Device Identification (UDI) registrations. All of this FDA data is free.
The combination lets the AI do something neither source could enable alone. Internal quality data tells you what is happening with your specific device. OpenFDA data tells you what is happening across the market with similar devices, which complaints the FDA has flagged as recurring, which failure modes have driven recalls, and which product codes are attracting adverse event reports.
With both data sources connected, an engineering team preparing a product review can run a query in something close to real time. In the example demonstrated, the query was straightforward: the engineering team has a meeting to determine development priorities for a vascular needle line. The agent pulled internal customer feedback, CAPAs, and nonconformances, cross-referenced that data against OpenFDA records for similar devices, and returned a prioritized list of development recommendations with source citations.
Among the findings, the agent flagged a CAPA related to a sterility lot release problem as the immediate priority. It also surfaced market-level failure mode data from OpenFDA: breakage, blockage, leak splash, and contamination were the most commonly reported categories across vascular needle products, with supporting adverse event report links. And it pulled in customer feedback from a specific gauge variant, noting that while direct FDA evidence was limited for that specific configuration, the internal complaint signal was real and warranted attention.
Every recommendation came with a source citation. When asked to verify, the agent returned the exact OpenFDA query it had run, the product code it had used, and the regulation governing that product category. The engineers in the meeting could confirm exactly where each finding came from before deciding what to do with it.
Risk files and design inputs: the recurring gap
One of the sharper observations from this discussion is that risk files often operate on a yearly review cadence when they should be updated as soon as new field data arrives.
Risk management under ISO 14971 requires that post-market data be evaluated for its effect on residual risk. In practice, many teams schedule a formal risk file review annually or quarterly, which means complaints filed in month two of a product launch might not formally influence the risk file until months later. By then, design work may have already moved in a direction that the field data would have redirected.
The AI-connected workflow addresses this by giving the team a way to check the alignment between current field signals and the risk file on demand, rather than waiting for the scheduled review. The agent can pull the design history file, compare it against recent complaint trends, and flag cases where the risk profile appears to have shifted relative to what the documentation reflects.
The agent is not making risk decisions. Those remain with qualified engineers and quality professionals. But it surfaces the comparison quickly enough that the people with the judgment can act on current information rather than the state of affairs from six months ago.
Using AI for what you already know
There is a principle worth stating plainly about how these tools perform best. AI agents that are connected to your specific data, your QMS records, your design files, your field complaints, tend to perform well precisely because the people using them already understand the domain. A quality engineer who knows what a plausible complaint pattern looks like will immediately recognize when the agent's synthesis makes sense and when to push back.
When AI is used to cover unfamiliar territory, the person using it cannot evaluate the output. That is a risk worth taking in low-stakes situations, but for something that feeds into a product development decision or a risk management update, domain expertise is the check. The agent is doing the reading. You are supplying the judgment.
That framing also changes how to think about validation. Rather than validating the AI system in the conventional software validation sense, the practical approach is to build source transparency into how the agent responds. Before acting on any recommendation, ask the agent to cite the specific records and databases it used. Verify those citations. Treat the output the way you would treat a well-researched briefing from a new member of the team: useful as a starting point, requiring verification before anything formal happens.
Data hygiene matters more than AI sophistication
One thing that becomes clear when running these workflows in practice is that the quality of the output depends entirely on the quality of the data going in. An agent connected to a QMS with consistently documented complaints, well-categorized CAPAs, and clean design records will produce useful synthesis. An agent connected to a QMS where complaints are filed inconsistently or categorized differently by different team members will surface noise alongside signal.
Poor data quality is not a reason to delay building these connections. It is a reason to treat QMS data quality as infrastructure rather than as a compliance obligation. If you would want to ask an AI agent to analyze your complaint data six months from now, the time to start enforcing consistent documentation practices is today.
The same applies to how the agent is configured. Instructing the agent to prioritize data from known, defined sources, and to flag rather than suppress uncertainty, keeps the output grounded in the records you have verified rather than inferences drawn from the broader training data of the underlying model. Garbage in, garbage out is a principle that applies to AI just as it applies to any statistical analysis.
What comes next
The pattern described here, connecting an eQMS to external regulatory databases and using an AI agent to synthesize both in real time, represents one architecture for closing the loop, not the only one. Health Canada's MDALL database, EUDAMED in Europe, and IMDRF coding data all offer similar programmatic access points. For teams running clinical investigations, structured clinical data collection is another source that can feed the same pipeline, particularly for post-market clinical follow-up (PMCF) evidence. A team operating in multiple regulatory markets could build a single agent that checks field signals against the regulatory databases for each market simultaneously.
The immediate opportunity, though, does not require building that full architecture. A team that starts by connecting one data source, verifying that the output is grounded and useful, and then expanding from there has a practical path to significantly reducing the time it takes to get field intelligence in front of the people making product decisions.
The data already exists. The question is whether there is an organized pipeline moving it from post-market operations to the engineering meeting.
Keep reading
If you are building out your post-market quality processes, these related guides go deeper on the specific components:
- What comes after launch? A guide to post-market maturity
- Personalizing and triaging your quality management system
- Post-market surveillance: the complete guide
- Unpacking common FDA compliance gaps: pre-market vs. post-market realities
- ISO 14971 risk management guide
- What FDA investigators will look for under QMSR
BONUS RESOURCE: Click here to access our post-market quality resources
Watch the full on-demand session
If you want to go deeper, including a live demo of an AI agent pulling from a QMS and OpenFDA simultaneously, you can watch the full on-demand webinar here.
Will Sanders and Etienne Nichols walk through the specific technical setup, discuss the validation question that comes up every time this topic surfaces in medtech, and answer questions from quality and engineering professionals on how to apply this in practice.
BONUS RESOURCE: Change Impact Analysis Checklist
