We taught AI to draft your FMEA. Here's why that's harder than it sounds.

Ask any RA engineer where their risk management file bogs down, and they'll say the same thing: Hazard Identification. Not because it's conceptually hard — because it depends entirely on who's in the room that day.

We built Risk Analysis to fix that. Here's what it does, and just as important, what it refuses to do.

The problem isn't FMEA. It's doing FMEA by hand.

FMEA — Failure Mode and Effects Analysis — is how most device makers operationalize ISO 14971. Not because the standard requires it (it doesn't; ISO 14971 only mandates the process: hazard identification → risk estimation → risk control → residual risk evaluation), but because a row-per-hazard table happens to be the format every reviewer already trusts.

Doing that table by hand has five predictable failure modes:

• Coverage depends on who showed up to the brainstorm. Mechanical engineers nail energy hazards. Information hazards — unclear labeling, missing IFU warnings, misleading alarms — get two lines and a shrug.
• Scoring drifts. The same "mild skin irritation" gets a 2 in row 12 and a 3 in row 47, because two different people filled them in on two different days, and neither wrote down why.
• One threshold change means re-touching the whole file. Move your risk matrix cutoff and every row's acceptability call has to be manually re-checked.
• Controls and evidence live in separate tabs, cross-referenced by memory. "See verification report" — which one, which section? Nobody writes that part down either.
• Control measures don't get ranked. ISO 14971 §7.1 is explicit about hierarchy: inherent safety by design first, protective measures second, information for safety last. In practice, "warn the user in the IFU" often gets treated as if the risk is closed — when it's the lowest tier in the standard, not a substitute for the other two.

None of this is incompetence. It's what happens when a compliance-critical document is produced entirely from human memory, under deadline, by people who also have day jobs.

What we built

Risk Analysis runs the full pipeline — hazard identification, risk estimation, risk control — from a device profile you fill in once, and hands back a five-sheet workbook.

Three inputs, then it runs on its own.

1. Device profile. Device type (MD / IVD / SaMD), intended use, users, environment. Upload the IFU and the AI extracts the rest — and tells you which device type it thinks you're building, with reasoning. It only fills blanks; anything you've already typed stays untouched.

2. Risk matrix. Your severity and probability scales, your thresholds, fully editable. The color-coded matrix updates live as you adjust it.

3. Run settings. Standard or deep analysis. Deep mode adds MAUDE adverse-event and recall lookups (free, no extra cost) and reference document upload. Misuse scenarios (IEC 62366-1) and full lifecycle coverage are on by default — because those are exactly the categories manual FMEA tends to miss.

Hit run. Close the tab if you want — it finishes in the background, and you download an XLSX when it's done.

Every conclusion needs review by a qualified person before submission. This is drafting assistance, not a finished regulatory document.

The workbook

Five sheets: Device Profile, Risk Matrix, Hazard Identification (HID), FMEA, and Risk Control Measures.

The last one is where the design decisions actually show up. Every control measure is tagged CN1 / CN2 / CN3 — inherent safety by design, protective measures, or information for safety — ranked in the order §7.1 requires, not dumped in one undifferentiated column. Each measure links back to its hazard ID. Verification method and evidence reference are their own columns, not a note that says "see elsewhere."

If the same control text gets classified two different ways across the analysis, we don't quietly merge them. We keep both rows. That disagreement is a signal worth a human's attention, not something to smooth over.

Where we drew the line on what AI gets to decide

We spent more time on this question than on the UI: what should the model own, and what should it never touch?

Risk scores and acceptability are computed, not generated. Probability is min(P1, P2) — P1 for the hazardous situation occurring, P2 for it leading to harm — calculated server-side. Risk level and acceptability follow from that calculation. The model doesn't get to write "S=3, P=2" in one column and "High Risk" in another if the math doesn't say so, because the math is the only thing writing that column.

Detectability doesn't get to override acceptability. ISO 14971's acceptability call is a function of severity and probability. Detectability is real and useful — it's carried as an FMEA prioritization signal — but it never pushes a row across an acceptability line by itself.

Evidence IDs are verified, not trusted. When deep mode pulls MAUDE records, every report number the model cites gets checked against what was actually retrieved. Fabricated IDs are discarded and logged as a warning. The instruction to the model is blunt: only use identifiers that appear verbatim in retrieved evidence — never construct, complete, or guess one.

Unclassifiable controls stay unclassifiable. If a control measure doesn't map cleanly to CN1/CN2/CN3, we don't force a guess. We flag it as a gap. Given that §7.1 is a strict hierarchy, a wrong classification is worse than an honest "we're not sure."

Every conclusion carries its reasoning. Confidence level, review flags with a stated reason, and evidence references — for severity, P1, and P2 independently. So when someone asks "why is this a 3" in a review six months from now, the answer is already written down.

Excel add-in

Same backend, same prompts, same matrix logic — different interaction model. The add-in runs as a task pane with one tab per stage, and it gives you something the web flow doesn't: a manual checkpoint between each phase. Review hazard identification, edit it in the live workbook, then move on to risk estimation when you're satisfied. Results write in-place as you go, instead of downloading as a finished file.

If your team likes reviewing as it goes, use the add-in. If you'd rather submit and come back to a finished draft, use the web flow. Same engine either way.

What this doesn't replace

We say this in the wizard, in the workbook, and here: every conclusion needs review by a qualified person before it goes anywhere near a submission.

The model doesn't know the design decision your team made three versions ago that isn't written down anywhere. It doesn't make the judgment call on whether residual risk is acceptable — that's a signature, not an output. And systematic coverage beats individual memory, but it isn't a guarantee of zero gaps.

What it does do: turn a blank table into a fully reasoned first draft, with a citation for every score. The review work shifts from "fill in sixty rows from memory" to "check sixty rows that already have their reasoning attached."

That's the trade we're offering. Not less oversight — less typing.

Risk Analysis is live now on web and in the Excel add-in (plan-gated; deep mode requires separate access).

Try it, and tell us which hazard it missed.