Introduction
For decades, device regulation rested on a quiet assumption: the thing you cleared is the thing you ship, and if you change it meaningfully, you come back. Machine learning breaks that assumption in the most literal way possible — the value of many AI-enabled devices lies precisely in their ability to change. The regulatory profession is still catching up, and that gap between what products do and what most regulatory teams know how to handle has become one of the most visible skills shortages in the device industry.
This article looks at why AI-enabled devices strain the traditional regulatory skill set, what specific competencies employers are now hiring for, and how a working regulatory professional can build each one deliberately rather than by accident.
Why AI Devices Strain the Traditional Skill Set
Three properties of machine-learning-based software push against the classic regulatory playbook.
Change is the product. A conventional device changes when engineering changes it. A learning system is designed to be retrained — on new data, for new populations, against drift. A regulatory function built around discrete change assessments struggles when change is continuous by design.
The evidence is data-shaped. The questions that decide an AI submission — was the training data representative, how was the test set kept independent, what happens to performance at the edges of the intended population — are statistical and data-governance questions. They cannot be delegated entirely to data scientists, because the regulatory professional signs the argument that the evidence supports the claim.
The failure modes are unfamiliar. Performance degradation from dataset shift, automation bias in users, opaque model behavior under rare inputs — these do not map neatly onto the hazard categories most risk files were built around, and regulators increasingly expect them to be addressed explicitly.
The Regulatory Landscape Is Moving Toward Lifecycle Thinking
Regulators have responded by shifting from point-in-time review toward lifecycle oversight, and the vocabulary of that shift is exactly what shows up in job postings.
In the United States, FDA has built out its thinking on predetermined change control plans — the mechanism by which a sponsor pre-specifies, in the marketing submission itself, what classes of model modifications it intends to make and how each will be validated before deployment. Getting a PCCP right is a genuinely new craft: scope it too narrowly and it buys you nothing, too broadly and it will not survive review.
In Europe, AI-enabled devices sit at the intersection of the MDR or IVDR and the EU AI Act, whose obligations for high-risk systems phase in through the second half of the decade. The practical consequence for regulatory teams is a second layer of requirements — risk management, data governance, transparency, human oversight — that must be reconciled with existing technical documentation rather than bolted on separately. Professionals who can read both frameworks and produce one coherent evidence set are scarce, and hiring managers know it.
None of this is static; guidance in this space is revised frequently. That, too, is part of the skill: teams now need someone whose job includes watching the landscape move.
The Skills Employers Are Actually Hiring For
Software lifecycle literacy. You do not need to write code. You do need to speak IEC 62304 fluently — software safety classification, development planning, configuration management, maintenance — and understand where machine-learning workflows fit awkwardly into it, because reviewers will ask.
Change-control strategy. The core intellectual work of an AI device submission is often the modification strategy: which changes are pre-specifiable, which trigger new review, and how the boundary is justified and verified. Practitioners who can design and defend that boundary are the single most requested profile in this niche.
Data governance. Provenance, representativeness, labeling quality, independence of test data, handling of site and population shift — the regulatory professional needs enough statistical literacy to interrogate a validation report rather than merely file it.
Clinical performance argumentation. AI claims live or die on the match between the claimed intended use and the population, sites, and conditions the evidence actually covers. Constructing that argument — and conceding honestly what it does not cover — is classic regulatory craft applied to unfamiliar material.
Cybersecurity fluency. Connected, updatable software brings premarket cybersecurity expectations with it, including secure update mechanisms and postmarket vulnerability handling. Cyber documentation has become a standard deficiency-letter topic, which makes it a standard interview topic.
Postmarket monitoring design. Lifecycle oversight means the surveillance plan is no longer an appendix — performance monitoring, drift detection, and defined action thresholds are becoming part of the approval story itself.
How to Build These Skills Deliberately
The good news: this niche is young enough that nobody has a twenty-year head start.
- Read the primary sources — the relevant FDA guidance on AI-enabled device software functions and change control plans, published authorization summaries for AI devices in your clinical area, and the high-risk provisions of the EU AI Act. Decision summaries are especially instructive: they show what evidence actually sufficed.
- Get literate in the standards that anchor reviews — IEC 62304 for software lifecycle and IEC 62366 for usability, plus the growing body of AI-specific good machine learning practice principles regulators have endorsed.
- Work one project cross-functionally. Volunteer for the change-control board, sit with the data science team through one validation cycle, own the cybersecurity section once. One real project teaches more than any course.
- Use the professional bodies deliberately. RAPS, DIA, and the standards organizations all now run AI-focused workshops, working groups, and conference tracks. The content varies, but the durable value is calibration: hearing how other companies are scoping change control plans and answering data questions tells you where the field's center of gravity actually is, which no guidance document states outright.
- Practice explaining the material to non-specialists. A large part of the AI-regulatory job is translation — telling a clinical team why the test set cannot include training sites, or a commercial team why a claim must shrink to match the evidence. If you can explain dataset shift to a marketing director in three sentences, you have the skill postings call "cross-functional communication" and interviews actually test.
- Follow deficiency patterns. Where companies publish or discuss review questions, the same themes recur — test-set independence, generalizability, update mechanics. Those recurring questions are a free syllabus.
What the Job Market Signals
Read a sample of current postings for regulatory roles at AI-forward device companies and the pattern is hard to miss. Alongside the traditional submission-experience requirements, postings now routinely ask for familiarity with software as a medical device frameworks, experience supporting machine-learning or SaMD products, comfort working directly with data science teams, and specific exposure to change-control planning for adaptive systems. Titles are shifting too: "regulatory affairs specialist, digital health" and "SaMD regulatory lead" barely existed as categories a decade ago and are now standing requisitions at many device companies and the technology firms entering the space.
Two things follow for candidates. First, hybrid profiles command a premium — the market pays for the intersection, not for either skill alone. A solid submissions professional who can also interrogate a validation dataset is worth more than the sum of those two capabilities, because the intersection is what is scarce. Second, the door is open from both sides: conventional regulatory professionals can move toward the data, and quality or clinical-data professionals with strong documentation instincts can move toward regulatory. The intersection is underpopulated enough that the direction of travel matters less than starting.
It is also worth naming what does not appear in serious postings: demands for machine-learning engineering skills. Employers hiring regulatory professionals for AI portfolios want regulatory judgment applied to new material — they already have engineers.
What This Means for Hiring Teams
For managers, the scarcity is real, and waiting for fully formed AI-regulatory hires is usually a losing strategy. The pattern that works is pairing: put a strong conventional regulatory professional next to the data science function on one live project, with explicit time to learn the material. Regulatory judgment transfers; the data vocabulary can be acquired. The reverse — teaching regulatory judgment to a technologist — is the slower road.
Retention deserves equal attention. Professionals who invest a year becoming fluent in this material discover their market value quickly, and the companies that keep them are the ones that convert the new capability into scope — a seat at the product-strategy table, ownership of the change-control framework, a title that names the specialty — rather than treating it as a bolt-on to an unchanged role. If the role does not grow with the skill, the skill walks. Budgeting for that growth up front is cheaper than replacing the person who acquired it.
Conclusion
Every few decades, a technology arrives that does not fit the regulatory machinery and forces the profession to grow a new limb. Combination products did it; software as a medical device did it; adaptive algorithms are doing it now. The professionals who move early — who learn to reason about changing systems, data-shaped evidence, and lifecycle oversight — will spend the next decade being pursued rather than applying. The sources are public, the standards are readable, and the field is young. Early still counts.