I've written before about the gap between running an FMEA in a spreadsheet and running one in a purpose-built app where failure modes actually link to design inputs, verification activities, and risk controls instead of sitting in a flat row. That post got more engagement than I expected, mostly from engineers who'd lived through the spreadsheet version and knew exactly what I meant. This is the fuller version of that story, from a real design FMEA population job for a client, with the device specifics generalized enough to protect the client's work but the substance left intact.

The setup

The device in question is a soft-tissue implant with a hydration-dependent polymer body and fiber reinforcement, delivered via minimally invasive surgical technique, single-use, terminally sterilized. I handed an AI model a blank design FMEA table plus three source documents: a device characteristics document, a Design Requirements Traceability Matrix, and a device description. The ask was straightforward on paper: populate component and feature, function, potential failure mode, potential effects on the user or patient, potential cause of failure, and suggested existing risk controls.

The AI read all four documents, extracted the device architecture, and built the table out section by section, covering labeling, packaging, sterilization, and the main device. It continued the numbering scheme from the existing template rather than restarting, and it slotted new rows in around entries that were already there. Mechanically, that's the boring part, and it's also the part that used to eat the most time. What happened next is the part worth writing about.

What it got right

It caught a cross-cutting failure cascade that wasn't explicit in any single document. The polymer body's mechanical properties depend on hydration, which the packaging system is responsible for maintaining. A packaging integrity failure doesn't stay a packaging problem. It propagates into a device mechanical failure, because a dehydrated polymer body behaves differently under load than a properly hydrated one. No single source document said this in so many words. The Device Characteristics doc described the polymer's hydration sensitivity. The packaging documentation described the humidity-maintenance function. The link between the two, dehydration in packaging becomes a mechanical failure mode in the device, only showed up when the AI read both documents together and asked what happens at the boundary between them. That's the kind of connection that's easy for a human reviewer to miss too, precisely because it lives between two sections of the documentation that different people usually own.

It found a gap in the template itself. The blank table the client gave me had no sterilization section. Rather than silently skipping straight from packaging to the main device, the AI added a sterilization section to fill the logical gap, reasoning correctly that a terminally sterilized single-use device needs its own failure mode analysis for the sterilization step, separate from packaging and separate from the device itself.

It flagged an interface ownership question I would have wanted flagged. The device's fixation approach uses a third-party interference screw, a component cleared as its own device by a different manufacturer. The AI raised the obvious but easy-to-skip question: whose risk file owns the interface between the screw and the implant, when the screw itself is someone else's cleared device with its own risk documentation? That's a design-interface question that inexperienced teams routinely miss, because it falls in the gap between "components we control" and "components we integrate with," and nobody owns that gap by default.

It scoped biocompatibility correctly. It flagged that a novel combination of a hydration-dependent polymer and a reinforcing fiber, used as a permanent implant, likely needs a full ISO 10993-1:2018 biocompatibility evaluation matrix rather than an abbreviated one, which is the right instinct for a novel material combination in a permanent implant application.

It pulled the right standards into suggested controls. ISO 14971 as the overall framework, the relevant ISO 10993 series entries for biocompatibility, and a set of ASTM standards appropriate to a fiber-reinforced polymer implant under mechanical load, including standards for tension testing, cyclic fatigue, shipping and distribution simulation, and accelerated aging, plus the sterilization validation standards appropriate to the sterilization modality used. None of that required prompting toward specific standard numbers. It came from correctly identifying the device class and its failure-relevant properties.

What still needed the engineer

Here's where I want to be precise, because "AI gets right" articles have a way of undercounting this half.

Scoring stayed human, deliberately. Severity, occurrence, and RPN were left blank as a team decision, not a technical limitation. The AI offered parenthetical severity suggestions in cases where the risk tier was obvious against the client's own ISO 14971-aligned scoring scale, but assigning actual scores is a mix of engineering judgment and clinical input. It's not a pattern-matching task, and treating it as one is how you end up with an FMEA that looks quantitatively rigorous but isn't.

Every failure mode, effect, and cause still needed engineering review before anyone could trust it. Understanding how a hydrogel-like polymer creeps under sustained load, or how a reinforcing fiber behaves at a fixation interface over time, requires someone who understands the device physics and the clinical environment it operates in. The AI drafted structure fast. It did not validate substance, and it shouldn't have tried to.

Scope judgment calls stayed with the engineer. Whether the new sterilization section belonged in this design FMEA or should live in a separate process FMEA, and whether the third-party interface question belonged in this risk file at all or in a supplier-facing risk assessment instead, are decisions that require understanding the client's broader risk management file structure, not just this one document.

The honest framing

What the AI did here was compress what's normally a multi-day blank-page exercise into a review exercise. That's a real and valuable shift, but it's a shift in kind, not just speed. The engineering value moved from authoring to reviewing, and reviewing a populated FMEA properly still demands full engineering competence, arguably more vigilance than authoring one from scratch, because a wrong entry that looks plausible and well-formatted is easier to wave through than a blank cell that obviously needs work.

That's the risk worth naming directly: a design FMEA populated by AI and reviewed by nobody is worse than no FMEA at all, because it looks finished. It'll pass a cursory audit glance. It won't hold up the first time someone traces a failure mode back to see if the reasoning behind it actually makes sense for this device. Used well, AI-assisted FMEA population is a genuine productivity gain for the structural, connective work that used to consume the most calendar time. Used carelessly, it's a way to generate a document that has the shape of due diligence without the substance of it. The tool didn't change which one you get. The engineer reviewing it still does.