Device complaint handling with AI agents

The complaint front door is the messiest room in a device manufacturer's quality system. Reports arrive by phone, email, sales-rep note, portal form, distributor forward, and the occasional social-media screenshot. Some are duplicates of the same event reported three ways. Some are barely legible. Some are nothing. And buried in the noise are the ones that start a regulatory clock. Whoever runs that room is the first — sometimes only — person between a real signal and a missed report.

This is the work an AI agent is genuinely good at: reading high volumes of messy language, normalizing it, and sorting it. The danger is not in letting the agent into the room. It is in letting the agent decide which complaints get to leave.

The front door is not the verdict

Complaint handling and medical device reporting are often discussed as one pipeline, and that conflation is exactly where teams get into trouble. They are two jobs with two different risk profiles.

The front door is intake and triage: receive the complaint, capture it as a record, strip out the duplicates, structure the event, and route each case to the right queue. This is logistics — high-volume, repetitive, and language-heavy, and an agent does it faster and more consistently than a tired human on the two-hundredth complaint of the day.

The verdict is reportability and closure: the formal determination of whether an event must go to a regulator, on what timeline, and — at the other end — the decision that a complaint has been investigated, dispositioned, and can be closed. Those are regulated judgments with named, accountable owners. We covered the reportability call in depth in medical device reporting with AI agents. This article is about the front door, and about keeping it from quietly becoming the verdict.

What the agent should own

Give the agent the logistics and nothing past them. Done well, the front-door work is substantial:

• Intake. Pull complaints from every channel and turn each one into a structured record — device, model, lot, event description, patient outcome, reporter, dates. Flag the fields that are missing so a follow-up goes out the same day instead of a week later.
• Deduplication. Match the new report against existing complaints. The same pump failure reported by the patient, the nurse, and the sales rep is one event, not three — and three open files for one event is how investigations get lost and counts get distorted. The agent proposes the merge; it does not silently collapse records.
• Triage and classification. Read the case, propose a complaint category and a preliminary severity, and surface whether it looks like it could involve a death, a serious injury, or a malfunction that could cause one.
• Routing. Send the case to the right queue — the engineering investigation, the regulatory-affairs reviewer who owns reportability, the field-safety team.

Notice the verbs: intake, match, propose, route. Not decide, not close, not report. The agent moves work to the people who own the calls. It never makes the calls.

Where scope creep starts

The reason this matters is that a capable agent invites its own expansion. It read the complaint well, so let it set severity for real. It deduplicated well, so let it auto-close the duplicates. It triaged well, so let it mark the obvious non-events as not-reportable and clear them off the queue. Each step is a small, reasonable-sounding extension. Together they hand the verdict to a system no inspector can hold to account.

The two decisions worth guarding most are the ones that remove a complaint from human view. Auto-closing a duplicate is a deletion in disguise — if the agent is wrong about the match, a distinct event vanishes. Clearing a case as non-reportable stops the regulatory clock before a person ever looked. Both are the verdict wearing the costume of triage.

A control plane stops the drift by making capability explicit and deny-by-default. The agent acts as a named identity holding one role, and that role is granted exactly the skills it needs and no others — the model we describe in the six primitives. Closing a complaint, deciding reportability, and filing with a regulator are not switched off by a polite line in the prompt. They are simply never granted. The agent cannot open a door it was never given a key to, and every grant is versioned, so you can reconstruct exactly what the intake agent was permitted to do on the date any given complaint arrived.

Two gates, not one

Most descriptions of governed complaint handling stop at the reportability gate. A complaint file has two one-way doors, and both belong to people.

The first gate is reportability — does this go to the FDA under the agency's Medical Device Reporting rule, or to the relevant authority under EU MDR vigilance, and on what timeline. The agent's proposed classification arrives at this gate as a proposal, marked as such, and the run stops until a named regulatory-affairs reviewer signs.

The second gate is closure — the decision that the complaint has been investigated and dispositioned and can leave the open queue for good. Closure is where a missed signal goes to die quietly, so it deserves the same treatment as reportability: a named owner, a captured rationale, a record.

At each gate the controls are the same, and they are the point:

The word doing the work in that table is cannot. It is not enough for a policy to say the agent should stop at triage. The agent that prepared a case must be structurally unable to act as both the maker and the checker on the same run — a separation we unpack in pharmacovigilance and AI agents. The attempt to self-approve is refused, and the refusal lands in the log, which is frequently the exact evidence an inspector wants to see.

The complaint file is the evidence

When an inspector pulls your complaint files, they test two things: that reportable events were recognized and routed on time, and that the records are complete and intact. Agents make the second harder — an automated pipeline that can write to and close its own records is a pipeline whose records are hard to trust.

MakerChecker writes every action, every model call, and every human signature to an append-only, hash-chained ledger, each entry cryptographically signed. Change one record after the fact and the chain visibly breaks. The export verifies offline, against a published open specification, by someone with no access to your systems and no reason to trust the vendor.

That maps onto the predicate rules you already live under. Tamper-evident audit trails are 21 CFR 11.10(e). Signatures that carry their meaning — review, approval, responsibility — are 21 CFR 11.50, and binding a signature to the exact record it approves is 21 CFR 11.70, the controls we cover in Part 11 and AI agents. The two human gates are the decisions the complaint-handling and reporting rules assume a person makes. MakerChecker does not invent any of this. It implements, for an agent, the controls regulators have demanded of people for decades.

What this is not

This is not a content-safety filter. Guardrail products ask "is this output dangerous or off-policy?" — useful and complementary. MakerChecker answers a different question: is this actor authorized to take this action, and can you prove it? An intake agent can produce perfectly clean, well-structured case records and still have no business closing a complaint or clearing it as non-reportable. The guardrail checks the words; the control plane checks the authority.

It is also not a claim that the software makes you compliant. No tool does. MakerChecker is designed against the rules your auditors already enforce, and it gives you the structural controls and the evidence to stand behind your own determinations. The front door gets fast. The verdict stays human. The complaint file proves the line was never crossed — exactly what the downstream MDR process needs to inherit.

See how it works, or book a demo to watch an agent get blocked from approving its own work — live.