Software companies in the life sciences (broadly speaking) tend to arrive at their first QMS in a similar way: They build a product, maybe a healthcare app, an AI tool, or a platform that pharma and biotech companies rely on. Then a customer schedules an audit, a prospect asks whether the product is Part 11-compliant, or an FDA investigator issues a Form 483.
The team is mostly programmers and similar professionals, not Quality, and very seldom is anything written down.
Those calls are the core of Jesse Hart’s work today. Jesse, MS, PMP, is a consultant in The FDA Group’s network and the principal consultant at Hart Compliance Services, which he founded in 2014. In 2025 he launched his Hart AI Governance practice.
His career started with 21 CFR Part 11 work in 1999. Since then, he’s worked across pharma, biotech, medical devices, and regulated software. Earlier this year, he led a Form 483 response and rebuilt the full quality system for a Class II device manufacturer. He also works as an auditor, so he sees quality systems from both sides of the table.
Our conversation focuses on the segment of the market he works with a lot: health tech and software companies, from startups to established vendors, whose products put them under quality and compliance requirements they weren’t built for.
For these teams, the requirements rarely stop at the FDA. HIPAA, GDPR, ISO 27001, and AI rules can apply alongside Part 11 or the QMSR, and much of Jesse’s advice is about working out which ones apply before building anything. Teams at traditional drug or device manufacturers will recognize some of it, but the advice here is framed for companies coming to regulated work from the technology side.
His answers have been edited and condensed for clarity, and some combine points he made at different points in our conversation.
When a health tech or software company comes to you needing its first QMS, what’s usually going on?
Most of the time it starts with a customer audit of some kind. A lot of teams are building AI applications now, and they can be really exciting, but there’s no documentation behind them. Then a customer says, “We’re going to audit you. Here are our criteria,” and they really don’t have anything.
The other common trigger is a 483. A company gets one from the FDA and doesn’t know what to do or how to respond.
Either way, the call sounds about the same: “We have nothing documented. We don’t know anything about this. But a customer asked us about Part 11,” or validation, or ISO, or whatever it is. They don’t know what they don’t know. Someone once contacted me on LinkedIn and said, word for word, “A potential customer asked us if we were Part 11 compliant, and we don’t know what that is.”
It isn’t only startups! I have a client right now who’s been around for 10 years. They write documents for pharmaceutical and biotech companies, and now they have a customer audit coming that they don’t think they’ll pass. From what I’ve seen, they won’t. They write documents for others and don’t have a QMS.
Sometimes it comes from the other direction. I worked with a company that had been around since the 1980s and simply wanted to be ISO 27001 certified because its customers had started asking for it. I helped with the pre-assessment and built the documents they were missing.
As for the products, the big thing today is healthcare apps, and a lot of voice technology is coming up, like applications that record meetings. There’s still plenty of “old-school” work, too, to get a proper QMS stood up. The 10-year-old company I mentioned is being audited on Part 11 and validation, which has nothing to do with AI.
If a health tech startup is building its first QMS from scratch, where should it start?
Figure out who you are and what you do. That’s what companies lack the most, and it determines which regulations apply. Most of these teams are builders. They’re not in the regulatory business, so they naturally don’t know which frameworks apply to them. A big part of my job is figuring that out.
In practice, the first thing I ask for is everything. I’ll sign an NDA. Send me your documentation, your design specs, anything you have. If a company truly has nothing, the minimum I need is a system description, which they usually have. I need the design because they built an application and their data flow. And I need to know what industry they’re in and exactly what they do.
Then I run a gap assessment, starting with basic intake questions: what you do, what kinds of customers you have, where you are. The answers start pulling in requirements. Do you handle health information for a hospital, clinic or health plan? That brings in HIPAA. Do you have customers in the EU? Then GDPR applies. Are you using AI? Then the EU AI Act comes into the picture. Many teams just don’t know these things because they’re busy building the product or service.
After that, I send follow-up questions, and it’s perfectly okay to answer “I don’t know.” You can figure it out from there.
What do those follow-up questions dig into?
Details that aren’t obvious. Where do you operate? I have customers in Bulgaria and the UK, and I’ve written a national AI framework for Liberia, so geography matters! Do you have any personal data?
Take the 10-year-old client. They told me, “We shouldn’t have any PHI, but we don’t control what our customers upload.” The question is whether they’re a business associate to anyone. If they are, HIPAA covers whatever lands in their systems, whether they meant to receive it or not.
Or someone might be building a healthcare application. They know it needs to be HIPAA-compliant, so that’s where they start. Hardly anyone is talking about AI governance yet. Then they forget that they used AI to build it, and now there’s a whole other set of requirements to meet. You keep digging as you go.
How do you separate what a company needs from the complexity it doesn’t need?
It always comes back to whether the QMS is built around who the company is and what it does. The most common error is including requirements they don’t need, like trying to comply with HIPAA when they don’t handle PHI.
Then write procedures for what you do, and keep them few and plain. I don’t believe in having 60 procedures that are 100 pages long and basically say nothing. Ask what you really need, what you don’t, and what can be combined.
There are many gray areas in this industry. Nothing is really black and white. You can be compliant with a requirement and meet it in your own way.
What are the biggest mistakes you see when these companies try to build a QMS themselves?
The biggest one is buying a toolkit and calling it a QMS. You get generic templates that could be for anybody, somebody going to the moon, it doesn’t matter. In my experience, it probably takes more time to turn someone else’s templates into your policies and procedures than to write your own. You can go through a generic template, redo the whole thing, and still miss one little detail, like whether you’re a data processor or a controller. The template doesn’t know what you are!
The second is procedures with no records. The QMS looks great, but at the end of the day there’s no evidence anything happened.
The third, which I’ve seen a lot recently, is policies that don’t match the technology. Especially at bigger companies, tech writers and validation people do the documentation, the tech team sits on the other side, and they often don’t talk. A writer who has done this for 20 years has a huge library of templates to reuse. They implement them, and then it turns out the documents don’t match the technology or what the company does.
Compliance platforms promise audit readiness. Where do you see them fall short?
The tool can’t tell you what you are. A psychiatry AI startup bought a compliance platform to get ready for HIPAA, and they didn’t need HIPAA!
That’s why I’m not a fan of GRC tools. A GRC checks a box, marks something green, and says you’re ready. You can literally pull solid evidence five minutes before an audit.
In those platforms, frameworks are an input. You select ISO 9001, ISO 27001, HIPAA, GDPR, whatever. But you don’t know if that’s all of them. When I do a gap assessment, I look at every framework that may apply, not just the ones you think apply, because it’s easy to miss one. People do it all the time. Then you find out it comes with a regulation you didn’t think about and needs evidence you don’t have.
Tell us about the medical device company whose QMS came from ChatGPT
I suspect this is going on a lot these days. That company used ChatGPT to create its documents two weeks before the inspection. The documents referred to things the company didn’t have, and the 483 mentioned ChatGPT twice. So on top of the response, I had to build their whole QMS because it didn’t exist.
The person running the company had been in business for years, and nothing like that had ever happened. Then it was, “I’ve got an inspection coming up. What do I do?” In that situation, I would have created an action plan. It’s better to be honest: Yes, we know we’re deficient. Here’s what we have right now, and here’s our plan for getting the rest done.
AI isn’t inherently bad or dangerous in this context if you know how to use it. It’s a tool and should be used as one. It shouldn’t be used as a magic machine that can generate anything you ask for from whole cloth. It will give you confident output that can be completely disconnected from what specifically you’re doing with it. Do not ask it to “create me these SOPs.” If you set up a project with all of your real documentation and carefully give it ample context and direction, it can be used to augment people doing this work. I’ve built applications that do it, and I have a trademarked methodology for using AI in quality work.
What bothers me more is something I’ve seen at companies I’ve worked with. Say I’m the Director of Quality, and someone who’s trying to help hands me an SOP and says, “ChatGPT gave me this.” I read it, and it has nothing to do with what we do. Did you tell it who we are, what we do, and what industry we’re in? Did you give it any context at all?
“Oh, I didn’t read it.”
And if you don’t have your AI tools under control, your data can end up as training data for them.
What parts of a QMS build take more work than software teams expect?
Records and evidence, by far. Writing a procedure can take someone like me an hour. Proving that it operates takes months. A QMS has to run for at least six months before you can really start gathering evidence that it works.
CAPA is another. Many startups and small firms don’t know what a CAPA is, what it’s for, when it’s due, or how to follow up on it.
Training is probably the other thing tied for number two, if not number one, that any auditor will ask for: “Let me see your training records.” A lot of companies say, “Well, we have the procedures.” Okay, where are your training records? “Oh, we don’t do that.” And they don’t treat it like a big deal. You need to document it!
