During a live walkthrough of Ultralight this May, someone typed a design input straight into the platform: "Data flow must be uploaded consistently." That sounded fine at first glance. Then the built-in AI checker flagged it as not verifiable and called out "consistently" as the offensive word. It wasn't specific enough to test. The person running the demo laughed and admitted the tool had a point.
That thirty-second exchange says more about where artificial intelligence (AI) is in medical device quality right now than most of the debate around it. The tool didn't rewrite anyone's design history file. It didn't skip a verification step to save time. It read a sentence an engineer had already written and asked a question a good reviewer would ask anyway: can you actually test this?
Skepticism about AI in a regulated industry is understandable
Quality and regulatory affairs (QA/RA) leaders have every reason to be cautious here. Every few years, a category of software promises to remove friction from device development, and every few years, some of that software turns out to be the reason an audit finding shows up. The Food and Drug Administration (FDA) has been building its own position on this for a while, and its guidance on AI-enabled devices makes clear that oversight expectations don't loosen just because a machine is involved.
The caution is warranted, even if lumping every use of AI into one risk category isn't. There's a real difference between an algorithm making an unreviewed clinical decision and an algorithm flagging vague language in a user need before a human ever signs off on it. One of those carries regulatory weight the FDA has spent years building frameworks around. The other behaves closer to a spell-check that also happens to understand design control language.
Our own benchmark research last year found something interesting: 62% of teams say they spend more time preparing for audits than they spend improving quality. That's obviously less than ideal... Run design and quality off a patchwork of spreadsheets and shared drives, and every proof of a decision has to be reconstructed by hand whenever someone needs it. Software-enabled device teams feel this acutely, because their engineering pace and their compliance pace rarely match.
What the AI in Ultralight actually does today
Strip away the buzz, and the AI functionality that already exists Greenlight Guru's eQMS can be split into three categories. All three focus on design controls rather than clinical decision-making.
The first is a brainstorming tool. Give it a short description of the device and tell it which part of the design and development record needs a starting point, whether that's user needs, verification, or validation, and it drafts a first pass. Nobody has to accept what it produces. The value shows up earlier than that, in the blank-page moment that stalls a lot of early-stage teams before they've written a single testable requirement.
The second is the verifiability checker from the opening example. It reads a design input's title and description and asks whether the item can actually be tested as written. That check echoes something every ISO 13485 lead auditor eventually says in a review meeting: a requirement has to be specific, measurable, achievable, and testable, or it functions as a wish rather than a requirement. Catching that disconnect during authoring (instead of during an audit) changes who finds the problem and when.
The third piece generates documentation directly from what's already in the platform. A User Needs specification, for example, pulls every item already logged in the matrix and formats it into the document reviewers actually expect to see, the kind that ends up filed in a design history file (DHF). Nobody retypes the same content twice. The more detail an engineer puts into the matrix itself, the less manual assembly work shows up later.
None of the AI features come with a mandate to use them. Greenlight Gurus broader AI capability, including the newer functions still in beta with a smaller group of customers, can be switched on or off per team. A startup racing toward a first submission might turn everything on. A team closer to post-market surveillance, with a more conservative risk appetite, might stick to the verifiability checker and skip the rest. Neither choice is wrong, and neither requires a conversation with a vendor to change later.
The human still signs off on everything
None of this changes who's accountable. Every AI-generated suggestion in Greenlight Guru has to be reviewed and accepted by a person before it becomes part of the record. The platform doesn't auto-populate a matrix behind anyone's back. That reflects a deliberate philosophy, not a compliance afterthought: build tools that help a team move faster while the team keeps final say over every output. In an industry where accuracy carries regulatory weight, that distinction matters more than the feature itself.
It shows up in how the platform handles approvals, too. Design reviews, change order sign-offs, and quality event approvals all route through Part 11 compliant electronic signatures tied to a user's own login credentials, regardless of whether AI touched any part of the underlying content. The AI can suggest language. It cannot approve anything, and that line stays fixed no matter which feature generated the first draft.
AI sitting inside the compliance layer, not bolted onto it
The reason this feels lower-risk than AI conversations in other industries is architectural as much as philosophical. Greenlight Guru's AI features sit on top of infrastructure that already had to satisfy International Electrotechnical Commission (IEC) 62304 software lifecycle requirements before AI entered the conversation: configurable release forms, change order evaluations built for software-specific impact assessments, and repository connections that pull directly from GitHub.
Take the software bill of materials (SBOM) tooling as an example. Pull a repository's dependency file, or upload one manually if the team isn't on GitHub, and the platform builds a snapshot of every known vulnerability tied to that build. Export the raw report, hand it to a reviewer, run it again after the next release. None of that requires AI. It requires the kind of cybersecurity traceability regulators already expect from connected medical devices, and it's the layer AI features get added to, not a separate system running alongside it.
The same discipline applies to documentation outside the AI-generated files. Templates for design and development records are configurable per product, not locked to a single format across a company's entire portfolio. A team can edit a template, upload its own version, or skip the template entirely and link an existing document, a risk analysis or a project plan someone already built, directly into the record instead. That flexibility exists because no two software-enabled device teams build the same way, and a compliance system that assumes otherwise turns into the disconnected tool it was supposed to replace.
Put the pieces together and a pattern emerges. Every AI feature in the platform touches a workflow that already had guardrails, an approval step, and an audit trail before AI became part of the story. That ordering is the only way AI belongs in a regulated product at all.
Keep reading
If you are building out an AI-in-design-controls process for a software-enabled device, these related guides go deeper on the specific pieces:
- SaMD: software as a medical device, classification and rules
- FDA guidance on AI-enabled devices
- Design history file (DHF), DMR, and DHR explained
- ALM and design controls
- IEC 62304 software lifecycle requirements
- Software validation, explained
The design input that got flagged during the May walkthrough was rewritten in about ten seconds: "Data uploads must complete without loss of records, verified against a checksum on each transfer." Specific, & testable. The kind of requirement a reviewer doesn't send back. That's the case for AI in a design control matrix: a system that catches the sentence your team would have caught eventually anyway, just sooner and with less rework. If you want to see the rest of what came out of that walkthrough, from the SBOM visualization to how software releases connect to the risk file, book a look at Greenlight Guru for yourself.
