Automating Compliance with AI in the MedTech SDLC

Injecting Compliance into Code: Automating Compliance with AI in the MedTech SDLC

Randy Horton

Published on: June 1st, 2026

Executive Summary

For MedTech software teams, the important AI question today is not whether a model can write code. It is whether AI can help make compliance, testing, traceability, and quality review better by making it continuous parts of the software development lifecycle (SDLC).

That was the focus of Orthogonal’s webinar. The panel discussed how generative AI and agentic systems are changing the development of Software as a Medical Device (SaMD), connected medical devices, mobile apps, cloud services, and embedded systems.

The panel argued that AI-assisted work should operate within the same design controls that govern the rest of the development process. When requirements, risk controls, tests, and other lifecycle artifacts are connected, agents can help maintain traceability, review documentation, identify inconsistencies, and surface missing evidence.

The goal of using this AI is not to replace human judgment. It is to create a development process in which compliance evidence is continuously maintained, quality issues are identified and addressed earlier, and experts spend more time on the key tasks of risk, architecture, and clinical context.

The panel also emphasized that AI development and quality practices commonly used in consumer and enterprise software cannot simply be ported to medical devices. The discussion noted that error rates or failure modes acceptable in lower-risk applications become far less tolerable when software affects patient care. AI-enabled workflows in MedTech require purposeful validation, governance, and human oversight.

For MedTech organizations, the question is where AI can provide measurable value and how to introduce it responsibly.

Why Compliance Needs to Move Closer to the Code

Rather than treating compliance as a separate activity that happens after development, the webinar emphasized that compliance work should be integrated into the development process itself.

In many organizations, engineering creates the product while quality and regulatory teams assemble the evidence around it. Requirements, test results, risk controls, traceability, reviews, and documentation may live in separate tools or documents. When teams prepare for a release, audit, or submission, they spend time reconnecting two disparate sets of nformation that should already be linked.

That becomes harder as the product grows more complex.

AI and automation enable a different model. Instead of rebuilding compliance evidence at the end of a development phase, teams can create and maintain it from the artifacts produced during the lifecycle.

The panel discussed several examples:

Drafting regulatory submission content from source documents and artifacts
Generating and reviewing design-control and QMS artifacts
Maintaining traceability as requirements, code, tests, and risk controls change
Identifying missing evidence
Detecting functions that may not have been implemented

For SaMD and MedTech teams, this matters because the lifecycle must produce both a functioning product and the evidence demonstrating that it was developed under appropriate controls.

Human review remains necessary. The difference is that quality and systems experts can spend less time locating disconnected information and more time deciding whether the evidence supports the right conclusion.

How AI Changes the Role of Software Teams

AI changes how software engineers, systems engineers, quality professionals, and regulatory teams contribute to product development.

Traditionally, MedTech professionals often measure their contribution by the artifacts they create: specifications, designs, code, test plans, traceability matrices, and quality documents.
Agentic AI changes the economics of that equation.

As agents take on more drafting, analysis, review, and execution work, the human role shifts toward defining objectives, setting constraints, providing context, and evaluating results. Value comes less from producing every artifact manually and more from ensuring the outcome is safe, useful, and verifiable.

The panel described a rapid progression in how AI is used in software development:

First, developers used AI to help write code.
Then they used it to generate modules and features.
Now, agents can help define the feature itself.
The next stage may involve giving agents direction and constraints, then asking them to help determine what should be built.

This does not mean engineers, quality professionals, or systems engineers become people managers. It means their work starts to resemble the management of a digital workforce. It means they spend less time producing routine artifacts and more time defining goals, giving agents the right context, reviewing the outputs, and deciding whether the result is safe, useful and acceptable.

Why Design Controls Give MedTech a Head Start

Agentic AI is making guardrails more important, not less. As software teams outside regulated industries experiment with AI agents, many are discovering that agents perform better when the work is bounded by clear requirements, intended behavior, and acceptance criteria.

This is familiar territory for MedTech.

The panel argued that MedTech may be better prepared than many industries to apply AI in medical device software development because design controls already provide a structured way to define what the product should do, how it should behave, what risks must be managed, and how the team will verify that the work meets its intended purpose.

Outside of regulated environments, teams are learning that agents perform poorly when they receive vague instructions. To build or modify a feature safely, an agent needs a clear description of intended behavior, relevant constraints, and acceptance criteria.

MedTech teams already work with many of the input elements that AI agents need:

User needs
Intended use
System requirements
Design inputs
Acceptance criteria
Risk controls
Verification evidence
Validation evidence
Traceability

The panel also noted that modern prompting guidance often resembles systems engineering guidance. Both rely on defined users and system interactions, intended use, constraints, boundaries, and expected behavior.

That does not mean every existing design-control system is ready for AI-enabled work. Requirements can still be ambiguous, inconsistent, incomplete, or too focused on implementation details. Those weaknesses limit how effectively agents can support development.

Still, the discipline of design controls and systems engineering provides a strong foundation. When teams define intended behavior, safety boundaries, and acceptance criteria clearly, they create a stronger basis for code maintenance, bug remediation, test generation, requirements analysis, and documentation review.

Writing Requirements for Agents

A common assumption is that agents need extremely detailed, implementation-level requirements to produce reliable results.

The panel argued that this approach can actually be counterproductive.

Instead, requirements should be detailed enough to define the behavior and constraints that matter for safety, performance, and reliability. They do not need to prescribe every internal design or implementation decision.

Overly prescriptive requirements can shift attention from the outcome that needs to be achieved to the mechanism used to achieve it. They can also make requirements harder to maintain because design changes may trigger unnecessary document changes.

The panel recommended focusing requirements on:

The user need
The intended clinical or business outcome
Safety constraints
Performance requirements
Critical behaviors
Acceptance criteria or acceptance tests
Boundaries and prohibited behaviors

For example, a requirement may specify that an alarm condition must be detected within a defined time and that the user must receive a notification in a particular way. It does not necessarily need to dictate the internal algorithm unless the implementation itself is safety critical.

This gives agents room to help solve the problem while keeping the work inside a clear, testable, and reviewable framework.

The Quality Work AI Can Support

Once the work is bounded by design controls and clearer requirements, AI can begin to support the quality, systems engineering, and regulatory activities that surround development.

Software engineering has long used techniques such as regression testing, integration testing, continuous integration, test-driven development, behavior-driven development, and automated test execution to find defects earlier.

The panel argued that AI can support quality, systems engineering, and regulatory work in a similar way: not by replacing experts, but by helping them review, compare, and analyzer lifecycle artifacts more efficiently.

This is not a criticism of quality, systems engineering, or regulatory professionals. It reflects a practical limit: no individual can maintain awareness of every relationship across a large set of requirements, specifications, risk records, tests, and related documentation.

The panel separated AI-supported quality review into two categories.

Expert review of a single document or record

An agent can help assess whether a design input, risk record, specification, or quality document is clear, internally consistent, and complete enough for its intended purpose. It can flag ambiguous language, missing information, or unsupported assumptions before the work moves further through the lifecycle.

System-wide consistency review

An agent can also analyze relationships across large sets of requirements, specifications, risk controls, and test records. It can surface potential conflicts, detect traceability gaps, or flag risk controls that lack corresponding verification activities.

Again, the value is not that AI replaces the expert. The expert spends less time on manual comparison and more time evaluating whether the system is correct, complete, and appropriate for its intended use.

Why Artifact-Driven Lifecycles Create Stronger Feedback Loops

AI performs best when lifecycle information is stored in connected artifacts and structured data rather than scattered across disconnected documents.

Post-market surveillance was one example discussed in the webinar. AI can help teams identify trends, recurring issues, and potential safety signals. But those insights only create value if the organization can connect them back to requirements, risk controls, design decisions, and verification activities.

When lifecycle information is fragmented across separate documents and systems, assessing the impact of a finding and implementing the right change becomes more difficult.

Organizations that manage lifecycle information through connected artifacts can maintain stronger links across:

Product requirements
System specifications
Risk analysis
Test evidence
Traceability
Quality review records
Regulatory documentation
Post-market data

Those links support impact analysis, traceability review, and change management.

The panel reported that some organizations using these approaches have reduced documentation effort, shortened software release cycles, improved detection of traceability gaps, and experienced fewer software defects in production.

These outcomes are not guaranteed. They illustrate what can happen when AI and automation operate on connected lifecycle artifacts rather than disconnected manual processes.

The panel also noted that R&D and post-market activities represent only part of the effort required to bring a medical product to market. Clinical studies, regulatory submissions, reimbursement, commercialization, and broader healthcare-system processes remain significant contributors to cost and schedule.

Human Judgment Remains Essential for Complex Decisions

AI is well suited to processing and organizing large amounts of information. It can draft content, compare records, identify patterns, and synthesize information across requirements, specifications, tests, and lifecycle data.

Engineers, quality professionals, systems engineers, and product teams remain responsible for the areas where context, judgment, and trade-offs matter most.

Decisions about architecture, clinical context, acceptable risk, and whether a product is safe and effective still require human domain expertise. These decisions often involve ambiguity and competing priorities that cannot be resolved through the pattern matching alone that AI excels at.

The panel described this partly as an economic shift. As AI reduces the cost of prediction, analysis, and information synthesis, teams gain access to more information and more possible courses of action. That increases the importance of judgment because engineers and subject matter experts still need to decide which actions are appropriate and which risks are acceptable.

For MedTech teams, this changes how different functions spend their time:

Quality professionals can spend less time checking basic artifact rules and more time evaluating whether a proposed approach addresses the relevant risk.
Systems engineers can spend less time manually comparing specifications and more time assessing whether the architecture supports intended behavior and safety requirements.
Developers can spend less time writing repetitive code and more time defining behavior, interfaces, constraints, and testability.

AI can increase the amount of work a team can review. It does not transfer accountability for decisions that affect product safety, effectiveness, or regulatory compliance.

Faster Feedback Loops, Not a Return to Waterfall

The webinar explored whether easier code generation changes the need for or the value of iterative development.

The panel’s answer was no.

Agile originally emerged because product development involves uncertainty. Teams learn through implementation, testing, user feedback, risk analysis, and changing technical conditions. Those realities do not disappear because coding becomes faster.

What changes with the advent of Agentic AI is the cost of experimentation.

When the coding effort decreases, teams can evaluate more ideas, eliminate weak options earlier, and use the results to improve requirements and specifications.

That enables shorter feedback cycles:

Define a small, meaningful piece of work.
State the user need, intended behavior, safety constraints, and acceptance criteria.
Build or modify the capability.
Run tests, checks, and reviews.
Use the results to refine the next set of requirements or specifications.

The panel also discussed simulation. In MedTech, simulation has often been useful but expensive to create and maintain across multiple products. AI may reduce the effort required to build simulations from requirements, CAD models, and related artifacts, allowing teams to evaluate behavior earlier and bring those findings back into the design process.

The point is not to reduce planning. It is to tighten the connection between planning, development, testing, and learning.

Connected Devices: Finding Edge Cases Earlier

The webinar also addressed a practical challenge for connected device teams: the large number of edge cases created by mobile applications, Bluetooth communication, device interfaces, operating system updates, cloud systems and changes to communication protocols.

A domain expert may have deep knowledge of a specific technology. However, no individual can continuously track every internal lesson learned, platform update, protocol revision, published issue, and real-world usage condition that could affect product behavior.

An agent can extend that expert’s reach by combining internal product knowledge, relevant external technical information, and product-specific requirements and constraints. It can help identify potential edge cases earlier so the human expert can evaluate them before formal verification, validation, or field testing.

That same approach applies across connected MedTech systems, including SaMD products that depend on mobile applications, cloud services, device interfaces, bring-your-own-device environments, and data exchanges.

Continuous Validation

Using AI within a regulated SDLC presents a different validation challenge than using a conventional software tool with fixed functionality.

Traditional validation often assumes that a tool can be validated, documented, and reassessed when a new version is released. That approach was already becoming harder to apply to cloud services, mobile operating systems, and other platforms that change continuously.

Agentic AI introduces additional variables of complexity to the challenge of tools validation.

For example, the underlying model may change. Prompts and context may change. The intended use of the agent may expand. Outputs may differ across executions. An agent that performs well in one environment may behave differently after changes to surrounding systems, data sources, or workflows.

The panel emphasized risk-based approaches to tools validation that include:

Continuous validation of AI-supported workflows
Computer software assurance practices
Representative evaluation datasets
Statistical analysis methods
Statistical process control
Monitoring for performance drift
Periodic review of high-risk AI use cases

Agent Factors: Applying a Human Factors Lens to AI Agents

The discussion also introduced the concept of “agent factors.”

Human factors engineering helps organizations understand how users, clinicians, and engineers interacting with a system make mistakes, misinterpret information, become distracted, and respond to interfaces and workflows. Those insights help teams design systems and processes that reduce foreseeable use errors and mitigate human limitations.

Agent factors applies a similar lens to AI agents.

The idea is to study how agents behave, where they are likely to fail, and what controls are needed to manage those failures. Agents can resemble humans in some ways because LLMs are trained on human-generated language and can mimic patterns of human reasoning and communication. But agents also behave differently from people. They can process more context, operate faster, and generate outputs at a scale humans cannot match. They also have failure modes that differ from human failure modes.

An agent may use incomplete context, operate outside their intended scope, take unanticipated actions, or generate plausible output that fails a required criterion.

That is why agent factors should be incorporated into the risk model for AI-enabled development.

Symbolic Quality Assurance: Deterministic Checks Around Probabilistic AI

Continuous validation helps teams determine whether an AI-enabled workflow continues to perform as expected over time. Structural safeguards answer a different question: how do you keep a probabilistic system operating within a defined development process?

The panel used the term “symbolic quality assurance” to describe deterministic checks that can be applied to AI-generated work.

Those checks can verify whether:

Required traceability links exist
Required lifecycle activities were completed
Defined process gates were satisfied before work progressed
Required records and evidence are present
An agent’s output conforms to structural rules or acceptance criteria

These checks do not make an LLM deterministic. The model may still generate different wording, different reasoning paths, or different proposed outputs across runs. What becomes deterministic is the layer of verification around the model. The system can objectively check whether required traceability links exist, whether required lifecycle activities were completed, whether evidence is present, and whether the output satisfies predefined structural rules or acceptance criteria.

The goal is not to use AI to skip testing. It is to increase the scope and frequency of testing and verification. The panel described a model in which a team may perform fewer manual test executions while increasing requirements coverage, automating more tests, and running those tests more often.

From a quality perspective, broader coverage and more frequent execution are more meaningful indicators of rigor than the raw number of manually executed test steps.

Where to Start

The webinar did not recommend an organization-wide transformation all at once.

Instead, the panel recommended starting with a limited use case that demonstrates measurable value and expanding based on the results.

One option is to apply AI across the full lifecycle of a small product line or a software-focused product line with frequent releases. This creates a controlled environment for evaluating the approach, measuring outcomes, and refining processes before broader adoption.

Another option is to introduce AI into workflows one at a time across multiple products. Initial use cases might include:

Reviewing requirements for completeness and consistency
Checking traceability relationships
Reviewing QMS artifacts
Generating or improving test cases
Drafting portions of regulatory submissions
Supporting risk-management activities
Analyzing post-market data

The appropriate starting point depends on where the organization spends significant manual effort and where improvement can be measured using defined metrics.

The first step should not be selecting a tool. It should be defining a specific use case with a known problem, clear constraints, measurable success criteria, and a review process that matches the associated risk.

Defining Agent Personas

One of the webinar’s key themes was that AI agents do not automatically understand how a MedTech organization performs its work. An agent needs a clearly defined role and operating context.

Teams need to define:

The tasks the agent is allowed to perform
The role it is intended to support
The information and artifacts it can access
The instructions it should follow
The outputs it is expected to produce
The standards, constraints, and boundaries it must obey
The situations that require human review or escalation
The criteria reviewers will use to assess its output

This work often exposes knowledge that exists only in the experience of engineers, quality professionals, systems engineers, regulatory specialists, and other subject matter experts rather than in documented processes. New employees may learn that knowledge through training and collaboration with colleagues. An agent requires explicit instructions and access to relevant context.

Well-defined agent personas can also become reusable assets that capture how an organization performs requirements analysis, quality review, test design, regulatory drafting, and systems engineering.

Key Takeaways

Use design controls to give AI the right context

Requirements, acceptance criteria, risk controls, traceability, and verification evidence provide the structure agents need to support regulated development. Write requirements around outcomes, constraints, and acceptance conditions rather than unnecessary implementation details.

Make compliance a continuous output of development

Documentation, traceability, test evidence, and quality review should be connected outputs of the lifecycle, not manual activities performed after development is complete.

Use AI where scale and complexity exceed human capacity

AI is well suited for large-scale review, cross-system consistency checks, traceability analysis, submission drafting, and other tasks that require synthesizing information across many artifacts.

Keep humans responsible for judgment and govern AI continuously

Engineers, quality professionals, systems engineers, product teams, and clinical experts remain responsible for risk decisions, clinical context, architecture, and final judgment. AI-enabled workflows require ongoing validation, drift monitoring, and deterministic controls around traceability, process execution, and required evidence.

Start small and define agent roles clearly

Begin with a bounded product line or high-friction workflow, prove value, and expand based on evidence. Define agent personas with clear roles, context, boundaries, and review expectations before scaling their use.

Watch Webinar Recording

Larkin Lowrey, Senior Director of Software Engineering for Digital Health, Tandem Diabetes

Randy Horton, VP of Solutions and Partnerships, Orthogonal