The Purolea Warning Letter & Validating AI in Medical Devices - What FDA Actually Requires

May 11, 2026 ░░░░░░

#459 The Purolea Warning Letter & Validating AI in Medical Devices - What FDA Actually Requires

The MedTech industry widely misread the FDA's recent warning letter to Purolea Cosmetics Lab as a direct crackdown on Artificial Intelligence (AI). Host Etienne Nichols challenges this narrative, explaining that viewing the event strictly through an AI lens causes medical device manufacturers to miss the actual compliance lesson. At its core, the Purolea situation is not a story of bad software, but rather a fundamental failure of process validation and quality system oversight.

When stripped of its technical novelty, the regulatory citation reveals an inspector's nightmare: lack of microbiological testing, absent process validation, and a non-functional quality unit. The AI components were merely downstream symptoms of a quality vacuum. Purolea utilized AI agents to draft critical product specifications and master production records, blindly trusting the software without human oversight. When confronted, the company claimed the AI agent simply never informed them that process validation was a legal requirement.

For medical device companies shifting from pharmaceutical regulations to the Quality Management System Regulation (QMSR), this episode serves as an urgent reminder of human accountability. The FDA did not write new regulations for this case; they applied foundational principles of human ownership to automated outputs. Whether content is drafted by a junior intern or a Large Language Model (LLM), a qualified human must own, review, and validate the output against defined specifications within a controlled, compliant architecture.

Watch the Video:

Listen now:

Love this episode? Leave a review on iTunes!

Have suggestions or topics you’d like to hear about? Email us at podcast@greenlight.guru.

Key Timestamps

00:15 - The Purolea Cosmetics Lab warning letter and the media's misinterpretation of an FDA AI crackdown.
01:04 - The reality of the Purolea inspection: Pests, missing microbiological tests, and total quality vacuum.
01:42 - How Purolea used AI agents to draft production records and why blaming the algorithm failed.
02:18 - 21 CFR Part 211.22 and its medical device parallel (QMSR 820.20): Defining the Quality Control unit’s ultimate accountability.
03:11 - Treating AI as an internal consultant: The balance of sensitivity and specificity in automated tools.
04:00 - Can you validate an AI algorithm vs. inspecting outputs? Deterministic software vs. Machine Learning.
05:25 - The 3-Part Validation Data Framework: Training data, validation data (development set), and the holdout test data.
06:21 - When human-in-the-loop output verification works, and when 100% automated inspection fails.
07:22 - Deep dive into Computer Software Assurance (CSA) guidance and risk-proportionate validation rigor.
08:16 - Essential regulatory standards and guidance documents list for MedTech AI developers.
09:25 - The 2010s Paper vs. eQMS debate compared to modern unstructured AI chat windows.
10:35 - Five concrete questions to assess if your quality system is ready for an FDA AI inspection.

Top takeaways from this episode

Human-in-the-Loop Ownership: Automated tools must be treated like junior interns or external consultants. Every document, specification, or SOP drafted by an LLM requires rigorous, qualified human review and physical signature sign-off before entering a controlled QMS.
Strict Split for ML Data Sets: For true machine learning algorithmic validation, companies must strictly partition data into Training, Validation, and Holdout Test data. Merging or leaking data between validation and training sets entirely compromises the regulatory integrity of the submission.
Validation Rigor Must Match Risk Profile: Under Computer Software Assurance (CSA) principles and ISO 14971, validation intensity must be proportionate to risk. Low-risk form-populators do not require the same exhaustive testing protocols as automated diagnostic algorithms driving real-time clinical decisions.
Chat History is Not an Audit Trail: Pasting AI outputs from an uncontrolled chat window into unmanaged text editors violates electronic record standards. AI-assisted documentation must reside within an infrastructure that maintains version control and clear change histories.

References:

FDA Guidance (2002): General Principles of Software Validation — The bedrock document for baseline software expectations in medical tech.
FDA Guidance Update: Computer Software Assurance (CSA) for Production and Quality System Software — The framework shifting focus from excessive paperwork to risk-based testing assurance.
International Standard ISO 13485: Medical devices — Quality management systems — The global standard now tied directly into US compliance via the QMSR transition.
International Standard ISO 14971: Medical devices — Application of risk management to medical devices — The foundational blueprint for mapping out software hazard severity.
Etienne Nichols' LinkedIn: Connect with the host directly for full access to the original Purolea blog post breakdown and further MedTech compliance discussions.

MedTech 101 Section

Algorithmic Data Splitting: The "Final Exam" Analogy

To understand how machine learning models are validated without testing every infinite possibility, think of the process like preparing a medical student for a board certification exam:

- Training Data (The Textbook): This is the information the AI studies. It looks at thousands of examples to learn what a pattern looks like.
- Validation Data (The Practice Quizzes): This data is used during development to fine-tune the model, fix minor errors, and adjust its parameters. The student takes these quizzes to see where they need to study harder.
- Test Data (The Final Exam): This is a completely hidden, clean set of data that the model has never seen before. True validation only happens here. If you test an AI on data it already saw during its training phase, it hasn't proven it can think—it has just proven it can memorize the answer key.

Memorable quotes from this episode

"If you use AI as an aid in document creation, you must review the AI generated documents to ensure that they were accurate and actually compliant... The person who signed off on them is responsible. This is nothing new." - Etienne Nichols

"A perfectly engineered AI agent drafting into a quality vacuum is going to produce the same results as a sloppy one." - Etienne Nichols

Feedback Call-to-Action

Did this episode change how you view your team's use of automated tools? Do you have a different take on how the QMSR handles machine learning validation? We want to hear from you. We read and personally respond to every listener message. Send your feedback, constructive pushback, or future episode topic suggestions directly to our production desk at podcast@greenlight.guru.

Transcript

Etienne Nichols: Hey, guys. Welcome back to our second part of the series about AI.

In April 2026, FDA issued a warning letter to a company called Purolea Cosmetics Lab and immediately started making the rounds on LinkedIn and everywhere else. Wherever you get your news, you probably saw headlines like the FDA cracks down on AI in manufacturing.

And I get why a lot of people framed it that way. There's a lot, there's a lot in that headline energy right now. You and I might have even got up a little bit, thought of that a little myself when I first started reading it. But as I got a little bit deeper and people said, hey, have you written anything about it? I thought I wasn't going to write anything about it.

Well, the more I thought about it, I think that's the wrong way to read this warning letter. If you build medical devices, not cosmetics, medical devices, treating this as an AI cautionary tale will cause you to miss the part that actually applies to you. And I wrote a piece about this for the Greenlight Guru blog.

If you're interested in reading that. I'll put a link in the show notes. But the response told me this is something people are genuinely confused about. So today we're going to work through it just a little bit because the PUR letter is really a story about validation.

What it means, what it requires, and why.

When it comes to AI specifically, most companies I talk to, they're really were asking the wrong question.

Etienne Nichols: So let me give you the quick version of what actually happened at Purolea. I hope I'm saying that name right, but if you strip away the AI angle entirely, the FDA findings, they were more like an inspector's worst day list.

You know, the, the worst things we can see, there were insects or pests in the manufacturing area. There were unapproved drugs labeled to treat serious conditions.

You know, to think homeopathic remedies saying they clear cancer or something. I mean, that's a little extreme, but that's essentially what it's saying. No microbiological testing of the finished product, no process validation before distribution.

A quality unit that essentially didn't function was ultimately the underlying tone. The quality unit was not doing what they were supposed to be doing. Those were the real problems.

Everything in that letter about AI is downstream of that.

Okay.

Where FDA addresses the AI specifically, the language is pretty precise purely. I told inspectors that they'd used AI agents to draft their drug product, product specifications, their procedures and master production records.

And when they were asked, why didn't you have a process validation before distribution?

That's an obvious requirement. Well, I should, I shouldn't say obvious. Nothing's obvious, I don't suppose, but it's a clear requirement. If you're reading the standards under 21 CFR part 211.100, Purolea said that the AI agent never told them that was required. And here's what everybody quoted from that warning letter. If you use AI as an aid, this is the FDA speaking.

If you use AI as an aid in document creation, you must review the AI generated documents to ensure that they were accurate and actually compliant with CGMP. Your failure to do so is a violation of 21 CFR 211.22 C.

And if you look at that citation, 21 CFR 211.22, that is not an AI regulation.

That is the rule that defines the responsibilities of the Quality Control unit, the QC, or the QA.

It's a rule that has governed pharmaceutical quality for literally decades. And FDA didn't write that rule to be new for AI. They simply applied an existing rule to a new situation.

A qualified human accountable to a defined quality system.

They own the output. That quality engineer owns the output.

Etienne Nichols: That principle. This principle isn't changing because the draft came from a large language model, an LLM, instead of a junior employee. If you think about it like had you hired an internal to write all of your, all of your procedures and SOPs, and then you blindly signed off on them.

Who's held responsible?

Do you point to the intern, say, well, our intern didn't tell us we needed that? No, the person who signed off on them is responsible. This is nothing new.

And the…

In another interview, the FDA actually came out and said that you need to treat the AI as a consultant, you're still ultimately held responsible.

So, for medical device companies, again, we're talking about a drug letter warning. The parallel citation is 820.20 under the QMSR, the Quality Management System Regulation, and 21 CFR part 11, which governs electronic records and signatures, same principle, same obligation. It's the same idea. It's just a different section of the Code of Federal Regulation. So, the takeaway in my mind is purely it didn't fail because their AI was bad.

People are still pointing at AI. And so, the AI failed them.

No, they failed because their quality system existed for the AI's output to enter, meaning a perfectly engineered AI agent drafting into a quality vacuum. It's going to produce the same results as a sloppy one.

The people are not actually paying attention. They've turned their brains off and they're allowing the AI to do this for them without actually checking it, checking the references, checking to make sure, uh, it's comprehensive and thorough. One thing, you know what, let me just go one step further with this and that is I think AI is excellent to get started.

Etienne Nichols: AI is an excellent tool to find a something wrong with something, but do not trust it. If it tells you something is right about something.

It's kind of like sensitivity and specificity. You can have false false positives and false negatives.

I'd much rather a false negative, the AI telling me, well, there is this, this, this and wrong about your process and procedures. And then you go and see if that's true and if you need to fix that, rather than trusting it.

If he says, oh, everything's right about your procedures. Okay, see where I'm coming from?

All right. Where I want to spend the most of our time today though, because this is the question I get most often when I talk to QARA professionals a bit about AI is can you actually validate an AI or do you just inspect the outputs?

Which is a good question.

And the answer is it depends on what kind of AI you're talking about and what it's doing. So let's break this down just a little bit.

Etienne Nichols: If you've been in this industry for more than five minutes, you know about software validation. The FDA's General Principles of Software Validation guidance from 2002 is, is one of the primary documents.

Now we also have computer assurance, the computer software assurance guidance.

Those are different types of frameworks. But the essential idea is you define the requirements; you test to those requirements and then you document that testing and you have the evidence that the software performs its intended function in its intended environment.

The IEC 6304, which is the Medical Device lifecycle standard, builds on this with a risk-based approach to software classification.

For traditional deterministic software, that works pretty well given input. Input A, the software always produces output. B, you can test exhaustively enough to have high confidence in that output.

Where AI is different.

Well, AI is just different, let me say it that way. And this is where a lot of companies get into trouble because AI kind of breaks the traditional validation model a little bit.

An AI algorithm, particularly a machine learning model, is not deterministic in the same way.

Given the same Input. A well-trained model should produce a consistent output. But the nature of machine learning is that the model generalizes from patterns in training data to new inputs it hasn't seen before.

So, you can't, because of that, you can't test every possible input.

Etienne Nichols: By definition, you're going to be putting new inputs once it's out in the field. So, you validate by testing all possible cases.

That's not a viable approach.

But here's what you can do.

You can demonstrate that the model's performance meets defined criteria across a statistically representative sample of inputs from your intended use population.

That's what validation means for AI.

And the way I would illustrate this is I remember back when I was a manufacturing engineer and we had certain people assembling parts, those were humans.

And it was hard to validate a human assembling a component or a subsystem of the overall system. So, what we did was we qualified those individuals.

Etienne Nichols: We tested them at different points, almost like performing in an IQ OKU PQ with different types of parts to see what they would do. Would they do this consistently the way another operator would?

And we compare them against another operator, knowing that humans are going to experience additional inputs and their brains are going to do something with that. But we would qualify them. They weren't truly validated, but they were qualified.

So, the three-part validation framework for AI and ML that I would suggest is FDA's guidance on AIML based SaMD and the computer software assurance guidance from 2022, which if you think about it, that kind of updated FDA's thinking from a pure validation toward a risk-based assurance model.

That gave us a framework with three distinct phases of data. So, the first one is the training data.

This is what the model learns from validation is not performed on trading data.

Etienne Nichols: If you test your model on data it was trained on your performance metrics, really, they're going to be meaningless, that the model has already seen the answers.

So, the second part is the validation data, which is sometimes called the development set.

This is the part that is used during the development process to tune the model, adjust itself parameters, prevent overfitting, compare different architectures. It's still not an independent validation or evaluation.

This is the validation data. Then there's the test data. This is the holdout set. It's the only data that counts for the validation purposes. The model's never seen it. It was set aside before training began; it wasn't touched until you're ready to run your final performance evaluation.

And you've got to separate that data, it's not optional. If your validation data set overlaps with your training data set in any way, your validation is going to be compromised.

And FDA reviewers are going to ask you about this. They'll ask you how the split was done, when it was done, how you ensured no leakage between the sets, etc.

So, let's get back to the question we actually are asking.

Etienne Nichols: When we ask about this inspection versus verification validation process, can you skip algorithmic validation and just inspect every output?

And the answer is, I guess the short answer is sometimes for some use cases and some risk levels, yes, it's a valid approach, it's a risk mitigation, but it's not validation. We're talking about an AI enabled medical device right now. So, here's the distinction.

If your AI generates a draft document that a qualified person reviews before it enters the quality system, like FDA said to purely that review process is sort of a form of output verification. The humans in control and you have a human in the loop, and that works.

When the outputs are reviewed by a qualified person in a reasonable amount of time, the error rate of the AI should be detectable by the human review and the consequences of that missed area, missed error potentially are going to be likely acceptable in that situation.

But if your AI is making a clinical decision that a clinician acts on in real time, or, or if the output volume is so high that 100% human review isn't practical, which is, let's face it, that's totally possible in the age of AI and how quickly it spits out documents, or if the nature of the error is something a human reviewer might not catch, I mean, it's outside their realm of expertise. You're utilizing them for, let's just say, for something you're not good at, let's say legal, for example, something outside your realm of expertise.

Etienne Nichols: In those cases, output inspection isn't sufficient. You need to have validated that the algorithm performs at an acceptable level across its intended use population before it's deployed.

So, the thing about 100% inspection is it only works if the reviewer knows what to look for.

And at Purolea, clearly nobody was there to review. Nobody understood what they were reviewing if they did. Because I, I mean, I, I think the best of humans, I try to think the best and think positively of people, but there wasn't anybody qualified to review the AI generator procedures, and even if there had been, they didn't have the specifications to check against them.

So that was the quality system failure, it wasn't the AI failure.

And that's how I continue to look at it. And if you have different opinions, I'd love to hear about it.

But I want to flag the computer software assurance guidance from 2022 specifically because it changed how FDA thinks about software validation for device companies.

And I know this is. There actually was an update to this in February of this year, 2026 if I'm not mistaken.

But started coming out and see and it's not changed very much. But the thing that to think about with CSA is that The CSA replaced FDA's thinking on software validation and it was replaced with a risk-based assurance approach.

Etienne Nichols: The key thing to think about with this is you don't validate everything the same way to the same level of rigor. The same the level of assurance really is going to be proportionate to the risk if the software fails.

And this is again another way that the FDA is sort of coming in line with a lot of global standards for like ISO 1345 for example as QMSR is now incorporating that by reference and pointing everything to that, you'll see that that phrase a lot proportionate to the level of risk.

A lot of the different clauses within ISO 1345 mention this. So, for AI in a medical device this means that your validation strategy has to be tied to your risk management, which is ISO 14971. What's the severity of a false positive? What's the severity of a false negative?

What patient harm could result if the algorithm performs differently in this user population for that versus that user population?

Those risk assessments should be driving the rigor of your validation approach.

And a low-risk administrative tool using AI to populate a form. It doesn't need the same level of valuation or validation as an AI enabled diagnostic rhythm algorithm making clinical recommendations.

Etienne Nichols: That seems obvious, you know, but you'd be surprised by how many companies either under validate their high-risk AI or over validate everything indiscriminately just because they feel like everything has to be validated to the same level of rigor.

For AI validation specifically, this is. These are some of the guidances that I would recommend that you need to have read. So, there's the FDA General Principles of software validation from 2002. That's the foundation still current.

There's the IEC 62304 which is the Medical Device Software Lifecycle Standards, Software classification and Risk Based development.

There's the CSA guidance document, the FDA's Computer Software Assurance guidance document that was originally introduced in 2022, updated as of February of 2026 the FDA AI ML based SaMD action plan from 2021, the FDA predetermined change control plan guidance from 2023.

There's also the FDA 510(k) considerations for AIML based SaMD.

And then of course you know the ones that you should be reading just if you're in medical device or MedTech in general is 21 CFR part 820 which is now QMSR as it references ISO1345 2026, 2021 CFR part 11, which is electronic records and signatures required for AI assisted documentation in a controlled system.

Etienne Nichols: Of course, ISO 14971 which is risk management for your validation or risk management in general, but your validation rigor should follow that risk analysis. And then lastly, I suppose would be there's a clinical evaluation framework for SaMD IMDRF SaMD N41 guidance.

So that list is not exhaustive by any means.

If you are interested in an exhaustive list of SaMD or AIML standards that you should be referencing, let me know. Reach out to me on LinkedIn. If I cannot help you, then I can certainly put you in touch with someone who can. That list isn't exhaustive, but like I said but if you've read all those documents, you'll be better prepared than most people as they're working on these kinds of devices.

So let me make this a little bit more concrete. We've referenced a lot of documents. I've given you a lot of homework.

But there's an analogy I used in that purely a blog post that I wrote for Greenlight Guru that I want to bring up again.

The device industry had a long, expansive argument in the 2010s about paper QMS versus an eQMS electronic QMS.

Paper was most familiar. Paper was cheap. It's low risk, or at least it seemed low risk. Companies that held on the longest found out this the hard way when an auditor showed up and asked who reviewed what when against which version, and the answers weren't always there.

The AI generated content in a chat window, whether that's pasted into a generic document editor or sitting in an email thread.

Etienne Nichols: If you think about it, that's kind of like the 2026 version of paper in a drawer or in that. I don't know if you guys have ever had the vault where you had to get document control to unlock the vault so that you could look up certain DMRs or DHRs.

I've certainly gone through that and it's painful.

Paper when you're in person, it seems like it's the fastest route.

It seems like a complicated filing system is progress and it looks defensible. Seems like you ought to be able to, hey, there's, there's someone who has a key to that room. You know, that's, that seems very defensible when an inspector walks in.

But the FDA doesn't always see it that way. So, the review has to be real.

It has to be done by a qualified person.

It has to be done against a specified, well, a defined specification, and it has to be captured in a controlled way that has an audit trail. If you're electronic, which I don't, it's hard for me to imagine anyone who's not electronic at this point just because due to the nature of remote work, how are we not working with an electronic system in some way or another?

Etienne Nichols: But if you are, then you have to be Part 11 compliant. You have to have version history; you have to have all of these things in controlled records.

Anything less, in the FDA's words, if you look at the pure LEA letter, is a violation of 21 CFR part 211.22 C on the device side, that's 820.20.

So, if the FDA, let's just kind of put all that aside for a second. If the FDA walked into your area, into your organization tomorrow and asked you to show for any AI assisted documents in your QMS, whether it's a risk analysis, a CAPA, a validation protocol, a design input, like I mentioned, those DHRs, VERs, DMRs, I know QMSR got rid of those acronyms. I'm going to not, I'm going to start using, I keep using those acronyms. I'm sure for a while it's going to be hard to get rid of them.

But if it, if, if the FDA comes in, asks for any of those things, and those were in part generated by an AI tool of some sort, they're still going to want to know who approved it, against what specification, what was the date, what was the signature, under what version of the procedure, how long would it take for you to answer all of those questions?

The answer to this, to me asking you, the answer to that, is the real measure of whether your quality system is ready for that inspection, the way they're going to be inspected. So, before you ship any AI assisted content into your quality system, the first thing to ask is, is this a controlled document? If it is, needs to go through document control.

I wish I; I don't have the exact clause in ISO 1345:2016. I used to have that on my desk, but it used to be 21 CFR party at 20.40.

You know, at some point, I'll be able to tell you where it is in ISO 3045. Even though as a lead auditor. Certified lead auditor, I should be able to tell you this.

It's just been a long time since I've done any of that stuff. But the fact that AI drafted the document does not negate. That those sections of ISO 1345:2016 are still relevant is still important.

Etienne Nichols: Okay. Second of all, who is the qualified reviewer of this document? You have to be able to put their name on the signature line. They own the output. Express to them how important it is that they own it.

When I was first introduced into the medical device industry as a manufacturing engineer, I remember being at the printer and the...

It was the. The vice president of quality came out of his office and he said, hey, I heard you're the new manufacturing engineer. Just want to introduce you, let you know what it is that we do in quality.

We make sure that you guys don't get in trouble.

And I thought that was incredibly important because he kind of emphasized to me that the documents you sign, those are your documents, and you own that. But we're here to make sure that you understand what it is you're signing and make sure that it's in keeping with our specifications and so on.

So, it's very, very powerful that I learned that early in my career.

Third, what are those people checking these documents against? There has to be a special specification. There has to be a procedure, a requirement.

Not. I read it. Felt right. Seemed right. That's not a review.

Fourth is the review captured in a controlled system with an audit trail.

Etienne Nichols: Remember, part 11 requires that electronic records be trustworthy, reliable, and equivalent to paper records.

So a chat window is not.

It's not a controlled system.

If it is, you have to be able to prove that it is and how it is.

And then fifth, for your AI algorithm, specifically, can you produce the chain of custody, from training data to validation to the submission? If there's a gap in that change, you need to figure it out, figure out how to close that gap.

All right. I'll kind of close with the fact that in my opinion. And I'd love to hear if you have a different one, purely. And that warning letter is not really an AI story.

It's a story about quality.

The AI is just the thing that made that problem visible.

Etienne Nichols: Your job is to make sure that when AI is involved in your quality system, whether it's helping draft documents or whether it's built into the device itself, is that the quality system controls are in place before the AI gets anywhere near it. So, if you reverse that order, you're purely with better software. So next week we're looking forward. We're going to be looking forward in time.

Where is the FDA's AI regulation heading? What international alignment?

What does that mean for global medical device companies and what does this mean for your career, specifically? Because I think that's what a lot of us are interested in. I love the big meta picture, but I especially appreciate it when we can tie it back to what it means for our careers especially.

So I'm going to try to do that as well.

Yeah, we'll see you next week.

Etienne Nichols: Thanks for tuning in to the Global Medical Device Podcast. If you found value in today's conversation, please take a moment to rate, review and subscribe on your favorite podcast platform. If you've got thoughts or questions, we'd love to hear from you.

Email us at podcast@greenlight.guru. Stay connected.

For more insights into the future of MedTech innovation and if you're ready to take your product development to the next level. Visit us at www.greenlight.guru. Until next time, keep innovating and improving the quality of life.

About the Global Medical Device Podcast:

Untitled (8.5 × 3 in)

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.

Etienne Nichols

Etienne Nichols is the Head of Industry Insights & Education at Greenlight Guru. As a Mechanical Engineer and Medical Device Guru, he specializes in simplifying complex ideas, teaching system integration, and connecting industry leaders. While hosting the Global Medical Device Podcast, Etienne has led over 200...