The Best ALM Tools for AI and Machine Learning Medical Devices
The best ALM tools for AI and machine learning medical devices are the ones that treat the model version as a controlled record, link it to the data, risks and signed evidence behind it, and hold the change plan as structured content you can execute. Short answer: for 2026 the ranking is Matrix Req first, then Ketryx, Jama Connect, Siemens Polarion ALM, Perforce ALM, Greenlight Guru, PTC Codebeamer and Orcanos. Matrix Req is first because it keeps the clinical claim, the algorithm requirement, the model version and its evidence in one traceable chain, manages AI failure modes under ISO 14971, holds the records a PCCP relies on, and generates one design history for the MDR, IEC 62304 and the EU AI Act.
We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. Every EU statement below is tied to a numbered article or annex point of Regulation (EU) 2024/1689, the AI Act, read on EUR-Lex on 15 October 2026, and every FDA statement to a guidance title and date. Every competitor fact was read on that vendor's own website on 15 October 2026, and we quote no pricing a vendor does not publish itself.
Matrix Req is a requirements management and design controls tool for medical device and regulated product teams, including software, imaging and AI diagnostic devices. Matrix One has built it since 2014, says more than 500 life sciences and medical device companies use its products, and publishes a dedicated page on Matrix Req for medical imaging and AI. External reviewers describe it as built for small and mid-sized medical device teams that want a configurable, validated requirements and traceability tool, rather than for enterprises running one ALM platform across many industries.
8 best ALM tools for AI and ML medical devices shortlist
| Tool | Best for |
|---|---|
| Matrix Req | AI device teams that want claims, algorithm requirements, model versions, AI risks and evidence in one traceable design history |
| Ketryx | AI and software device teams that want PCCP boundaries and model traceability enforced inside Jira, Git and CI |
| Jama Connect | Larger organisations running complex AI-enabled programmes across many teams |
| Siemens Polarion ALM | Enterprises on Siemens engineering software that want requirements linked into their MLOps toolchain |
| Perforce ALM | Teams that want requirements, tests and issues in one established ALM with algorithm change history |
| Greenlight Guru | Device companies that want design controls and an eQMS from one medtech vendor |
| PTC Codebeamer | Groups whose platform spans medical devices and other regulated industries |
| Orcanos | Smaller SaMD manufacturers that want ALM and QMS on one data model |
How do the 8 tools compare at a glance?
| Tool | Built for | Strongest on |
|---|---|---|
| Matrix Req | One design history for MDR, IEC 62304 and the AI Act | Model versions as controlled items, AI failure modes under ISO 14971, records behind a PCCP |
| Ketryx | Developer-native AI device evidence | Training data and model versions traced to tests, PCCP boundaries enforced in connected tools |
| Jama Connect | Many programmes, many teams | Live traceability and review at scale |
| Siemens Polarion ALM | Siemens engineering estates | Requirements linked to training datasets through MLOps integration |
| Perforce ALM | Established all-in-one ALM | Version control and traceability for algorithm changes |
| Greenlight Guru | Design and quality in one product | Design controls beside its own medtech QMS, ISO/IEC 42001 certified AI governance |
| PTC Codebeamer | Cross-industry regulated platforms | Standards templates spanning medical, automotive and more |
| Orcanos | ALM plus QMS for small teams | One data model across design control and quality |
How is this different from choosing any ALM tool for a medical device?
Most of the job is the same, and we have ranked that job already: our ALM tools ranking covers ALM for device development in general, and our IEC 62304 tools ranking covers the software life cycle clauses. This page is about the records an AI device adds on top: model versions, the link to training and test data, a plan for changes after clearance, and the AI Act.
It is also not about the AI features inside the tools themselves, which is a separate buying question with its own validation issues. That is covered in our ranking of requirements tools with AI features. Here, the AI is in your device, not in the tool.
Is an AI medical device high risk under the EU AI Act?
Usually, and the test is mechanical. Article 6(1) of Regulation (EU) 2024/1689 makes an AI system high risk where two conditions are both met: it is a safety component of a product, or is itself a product, covered by the Union harmonisation legislation in Annex I, and that product has to undergo a third-party conformity assessment under that legislation. The MDR and the IVDR are both in Annex I.
So an AI device that needs a notified body under the MDR, which is class IIa and above and some class I devices, is high risk under the AI Act. A self-certified class I device with no notified body involvement does not meet the second condition and is not caught on that route.
The date has moved. Article 113 originally applied the Article 6(1) obligations from 2 August 2027. As amended, Article 113(c) now applies them from 2 August 2028 for systems that are high risk under Article 6(1) and Annex I, which is the medical device route.
Can one technical file cover both the MDR and the AI Act?
Yes, and the AI Act says so twice. Article 8(2) gives providers of a product covered by Section A of Annex I "a choice of integrating" the AI Act testing, reporting and documentation into the documentation and procedures that already exist under that legislation, expressly "to ensure consistency, avoid duplication and minimise additional burdens".
Article 11(2) goes further: where a high-risk AI system relates to a product covered by Section A of Annex I, "a single set of technical documentation shall be drawn up" containing the AI Act Annex IV information as well as the information required under the MDR or IVDR.
That is the strongest argument for running an AI device in one traceable system: the MDR Annex II file and the Annex IV content are far easier to keep consistent if they are generated from the same requirements, risks, model versions and test records.
What does AI Act Annex IV add that an MDR file does not already hold?
Most of Annex IV overlaps with what a device team already keeps for MDR Annex II and IEC 62304. The additions are concentrated in point 2, the description of the development process, and they are where a tooling choice shows.
| Annex IV point | What it asks for | What the tool has to hold |
|---|---|---|
| 1(a) | Intended purpose and "the version of the system reflecting its relation to previous versions" | Model and system versions as controlled items with lineage |
| 2(a) | Development methods, including recourse to pre-trained systems or third-party tools and how they were used or modified | Pre-trained components recorded like SOUP, with the reason for using them |
| 2(b) | Design specifications: general logic, key design choices and their rationale, what the system optimises for, expected output quality, trade-offs | Algorithm requirements with rationale attached, not just the requirement text |
| 2(d) | Datasheets: training methodologies, training data sets, provenance, scope, how data was obtained and selected, labelling and cleaning | A reference from each model version to the dataset versions it was trained and tested on |
| 2(e) | Assessment of human oversight measures under Article 14 | Human oversight requirements traced to risks and to verification |
| 2(f) | A detailed description of pre-determined changes to the system and its performance | The change plan held as requirements, with the verification each change needs |
| 2(g) | Validation and testing procedures, data, metrics for accuracy and robustness, "test logs and all test reports dated and signed by the responsible persons" | Signed, dated test records linked to the model version and the metric they evidence |
Annex IV wants the reasons and the lineage, not only the results: which version, trained on what, chosen why, tested how, and signed by whom.
What is the EU equivalent of a predetermined change control plan?
It sits in Article 43(4). A high-risk AI system that has already been through conformity assessment needs a new one after a "substantial modification". The second subparagraph then carves out learning systems: changes to the system and its performance that "have been pre-determined by the provider at the moment of the initial conformity assessment" and are part of the technical documentation under Annex IV point 2(f) "shall not constitute a substantial modification".
In practice that is a European PCCP. Changes you describe in advance, with the technical solutions that keep the system compliant, can be made without a new conformity assessment; changes you did not describe cannot. The MDR route for the device itself still applies alongside it, including the notified body change approval in MDR Annex IX Section 4.10 for certificated devices.
For tooling, the consequence is the same on both sides of the Atlantic. The plan has to be held as structured, traceable content: the permitted change, the requirements and risks it touches, the verification protocol it triggers and the acceptance criteria. When a retrained model ships, you need to show that the change was inside the plan and that every verification the plan named was run and signed.
What does Article 10 require of training, validation and test data?
Article 10(2) requires training, validation and testing data sets to be subject to data governance and management practices covering, among other things, the design choices, data collection processes and the origin of the data, data preparation such as annotation, labelling and cleaning, the assumptions about what the data represents, an assessment of availability, quantity and suitability, examination for possible biases and the measures to mitigate them, and the identification of data gaps.
Article 10(3) adds that the data sets shall be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose".
None of that is done inside an ALM tool. What the ALM tool has to do is hold the governance decisions as records and link each model version to the dataset versions, the bias examination and the performance claims that depend on them, so a reviewer can follow the chain from a claim about a population to the data that supports it.
What does the FDA expect in a predetermined change control plan?
The FDA's final guidance, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, was issued on 4 December 2024 and reissued on 18 August 2025 under docket FDA-2022-D-2628. Its statutory basis is section 515C of the FD&C Act, added by FDORA in the Consolidated Appropriations Act, 2023, enacted on 29 December 2022.
The guidance says a PCCP "should consist of a detailed Description of Modifications, a Modification Protocol, and an Impact Assessment". The first lists the changes you intend to make, the second how each will be developed, verified and validated against acceptance criteria, and the third weighs their benefits and risks.
Every one of those three parts is a set of linked records rather than a document. Each planned modification touches requirements and risks, triggers named verification, and has to produce signed evidence when it is executed. A tool that can show, for a retrained model, which plan entry it falls under, which tests the protocol required and whether they passed, turns the FDA's question "was this change inside the plan?" into a query.
Which other FDA and EU documents shape the AI device file?
Four more documents sit beside the PCCP guidance, and a tool should be able to hold a checklist for each. The FDA draft guidance Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations, January 2025, docket FDA-2024-D-4488, is still a draft as of this page's date. The general draft guidance Predetermined Change Control Plans for Medical Devices, August 2024, docket FDA-2024-D-2338, extends the idea beyond AI and is also still a draft.
Good Machine Learning Practice for Medical Device Development: Guiding Principles was released by the FDA, Health Canada and the MHRA in October 2021 with ten principles, and the IMDRF published its final version as IMDRF/AIML WG/N88 FINAL:2025 on 27 January 2025. In the EU, MDCG 2025-6, also numbered AIB 2025-1 and published in June 2025, covers the interplay between the MDR, the IVDR and the AI Act, and confirms that Article 11(2) means a single set of technical documentation for medical device AI.
Is a model version a configuration item?
It has to be. IEC 62304 clause 8.1 requires configuration identification for software items, and the regulators' questions about an AI device all start from a version: which model was cleared, which one is deployed, and what changed between them. AI Act Annex IV point 1(a) asks for the version of the system "reflecting its relation to previous versions", and point 2(g) wants the test reports tied to what was tested.
In a document-based system, the model version is a string in a report. In a traceability tool, it is a record linked to the requirements it satisfies, the risk controls it implements, the dataset versions it was trained on, the verification that passed against it, and the release and submission it shipped in.
How do AI failure modes fit into ISO 14971?
The same way any other hazard does, with some new sources. ISO 14971:2019 does not change for AI, but the hazards do: incorrect classification, input outside the training distribution, performance drift after deployment, automation bias in the user, and degraded performance on a sub-population the data under-represented. AAMI TIR34971 is the guidance most teams use to apply ISO 14971 to machine learning.
Each of those hazards needs a risk control, and each control needs verification of implementation and of effectiveness under ISO 14971 clause 7.2.
For an AI device, the controls are often requirements on the model itself (a performance threshold on a named population), on the data (representativeness of a subgroup), or on the user interface (how uncertainty is shown). The tool has to link all three kinds back to the hazard. AI Act Article 9 then asks for a continuous, iterative risk management system across the whole lifecycle, and Article 8(2) lets you fold the resulting documentation into the procedures you already keep under the MDR.
How did we rank them?
We ranked against the records an AI device file needs that a conventional device file does not: model versions as controlled items, the link from model to data and to signed evidence, a change plan that can be held and executed as structured content, AI-specific hazards inside ISO 14971, and one design history that serves the MDR or IVDR and the AI Act together, as Articles 8(2) and 11(2) allow.
We then read what each vendor publishes on its own site about building AI or machine learning medical devices, and separated product claims from articles that only explain the regulation. Where a vendor makes no AI device development claim, we say so and make none on its behalf.
Which are the 8 best ALM tools for AI and ML medical devices, ranked?
1. Matrix Req
Matrix One publishes a dedicated Matrix Req page for medical imaging and AI diagnostics. It says Matrix Req keeps "the clinical claim, the algorithm requirement, the model version and the evidence that proves it in one traceable chain", and describes model versions as controlled items: which model version was verified by which evidence and shipped in which release, linked to the requirements it satisfies.
The same page lists ISO 14971 risk management for AI failure modes, naming incorrect classification and out-of-distribution input, with risk controls linked to the requirements and tests that address them. For change plans, it says Matrix Req holds the records a PCCP relies on, the requirements, risk assessments, verification protocols and results, while impact analysis shows what a specific change touches before it is made. Imaging hardware, firmware and analysis software can sit in one project.
On the AI Act, Matrix One is explicit about the boundary: Matrix Req does not classify your product under the AI Act, but holds the requirement, risk and evidence records so the MDR or IVDR, IEC 62304, ISO 14971 and AI Act obligations are answered from one design history. That is the single set of technical documentation Article 11(2) asks for.
The published specifics from the Matrix Req product and technical documentation pages: technical file, design history and trace matrices generated from live records as PDF, Word or HTML; 21 CFR Part 11 electronic signatures and frozen documents; revision history recording who, what, when and why; native two-way integrations with Jira, Azure DevOps, GitHub and GitLab; a Compliance Checker that imports a standard as a checklist and assesses your evidence against it; a typical 2 to 3 month implementation; and Comprehensive Onboarding at $8,000.
2. Ketryx
Built for AI and software device teams that want compliance enforced inside their developer tools. Ketryx makes the most specific AI device claims of any competitor here: its AI/ML page says it "traces training data and model versions to requirements, risks, and test executions", and offers to "enforce your PCCP within all connected systems so changes stay within pre-approved boundaries".
It also publishes an EU AI Act use case page, a free PCCP template white paper, and named AI and ML customer stories including HeartFlow, Beacon Biosignals, Aignostics and Dexcom. For a team whose models, data pipelines and tests already run through Jira, Git and CI, it is the strongest developer-native option on this list.
3. Jama Connect
Built for larger organisations running complex, multi-team device programmes. Jama's FDA AI guidance article says Jama Connect "provides the end-to-end traceability needed to manage the development of complex AI-enabled systems", and its AI in medtech article describes AI system requirements staying connected to design decisions, test results and regulatory submissions.
We found no Jama claim specific to PCCPs, model or dataset versioning, or the AI Act, so the AI-specific structure is something to see configured in a demo. Its strength is live traceability and review at scale across distributed teams.
4. Siemens Polarion ALM
Built for enterprises standardised on Siemens engineering software. A Siemens Polarion blog post on responsible AI describes using Polarion to "bridge the gap between Requirements and the actual training datasets", with the ability to integrate with MLOps toolchains.
That post is framed for responsible AI generally rather than for medical devices, and we found no medical AI or PCCP claim on Siemens' pages. Polarion X for Medical Devices supplies the preconfigured design control templates, and the MLOps integration angle is a genuine strength for a group that already runs its data platform at enterprise scale.
5. Perforce ALM
Built for teams that want requirements, tests and issues in one established ALM, formerly Helix ALM. Perforce's medical device requirements guide says Perforce ALM "supports version control and traceability for algorithm changes", enabling documentation of model updates and validation results.
That claim sits in a guide rather than on a product page. Perforce announced ISO/IEC 42001 certification in February 2026 for several products in its portfolio; Perforce ALM was not among the products listed, so it does not apply here.
6. Greenlight Guru
Built for device companies that want design controls and an eQMS from one medtech vendor. Greenlight Guru publishes a detailed explainer on predetermined change control plans, but we found no product feature claim for PCCPs, model versioning or dataset traceability.
It holds an ISO/IEC 42001:2023 certificate for its artificial intelligence management system, announced 30 June 2026. That certificate covers the AI inside Greenlight Guru's own products, not support for customers building AI devices, but it is still the only independently certified AI governance among the medtech-specific vendors here.
7. PTC Codebeamer
Built for groups whose platform spans medical devices and other regulated industries. Codebeamer's medical templates cover IEC 62304, ISO 14971, IEC 82304-1 and the EU MDR, and PTC's medtech blog discusses PCCPs as part of the regulatory landscape.
We found no AI Act, PCCP or machine learning template or product claim, so an AI device team would configure that structure itself. Its strength is one platform across industries for groups that also build automotive or industrial products.
8. Orcanos
Built for smaller manufacturers that want ALM and QMS sharing one data model. Orcanos says SaMD and software-enabled device teams use it to trace requirements through to code-level testing and defects.
We found no AI or machine learning device development claim beyond that general SaMD traceability; its AI assistant is a feature inside the tool, which is a different question covered in our AI features ranking.
Which other tools did we look at?
IBM DOORS Next and Visure Requirements are credible requirements tools in regulated industries. IBM's medical devices page lists the standards Engineering Lifecycle Management supports but mentions no machine learning, dataset, PCCP or AI Act capability. Visure publishes a thorough guide to the AI Act, PCCP and GMLP, but its product claims are general traceability and templates for IEC 62304, ISO 13485, ISO 14971 and Part 11.
Neither made the eight because neither publishes an AI device development capability on its own site. Both belong on a long list for teams whose main need is very large requirement sets or broad integrations.
What Matrix Req is built for, and what you would buy alongside it
Matrix Req is built for AI and imaging device teams whose hard problem is the design history: claims, algorithm requirements, model versions, AI-specific hazards and signed evidence held as linked records, and one technical file generated from them for the MDR or IVDR, IEC 62304 and the AI Act. Every specific in its entry above comes from Matrix One's own pages.
It is not an MLOps platform and it does not hold your training data. Matrix One's imaging and AI page claims model versions as controlled items, not dataset management, so the data, training runs and metrics stay in your ML stack and are referenced from the traceable record. You would run your data platform alongside it.
The axis we concede is developer-native enforcement. Ketryx publishes that it traces training data and model versions to tests from inside the connected tools and enforces PCCP boundaries there, with named AI customers behind it. For a team that will not leave Jira, Git and CI, that is Ketryx's strength. Matrix Req integrates two ways with Jira, Azure DevOps, GitHub and GitLab, but the controlled record lives in Matrix Req.
What should an AI device team define before buying an ALM tool?
Write down your item types first. A workable AI device set is clinical claim, intended population, algorithm requirement, model version, dataset version reference, hazard (including the AI failure modes above), risk control, verification protocol, test run, change plan entry and release. Then decide which links are mandatory: every performance claim to a population and to signed evidence, every model version to the dataset versions and the verification run against it.
Write the change plan before you choose the tool. Whether it is an FDA PCCP or the Annex IV point 2(f) description, list the modifications you expect, what each one touches and which verification it triggers. Then ask each vendor to load one entry from your plan, simulate a retrained model, and show the impact analysis, the re-verification and the signed record that results.
Decide where the boundary with your ML platform sits. Training runs, metrics dashboards and the data itself belong in your MLOps stack. The ALM tool needs the identifiers, the decisions and the signed evidence. Ask each vendor how a model version and a dataset version arrive in the tool, by integration, import or hand entry, and how they stay linked when either one changes.
Who validates the ALM tool, the vendor or you?
You do. ISO 13485:2016 clause 4.1.6 requires validation of computer software used in the quality management system, proportionate to the risk of its use, before first use and after changes. Since 2 February 2026 the same clause applies in the US through 21 CFR 820.10(a) under the QMSR, and 21 CFR 11.10(a) adds validation for systems holding Part 11 records.
What a vendor can do is shorten the work. Matrix One states that it offers a Validation project for Matrix Req, including plans, reports, test scripts and traceability matrices. Ask every vendor what validation material it supplies and what happens to it at each release. Do not confuse this with validating the AI features inside the tool, which is a separate question covered in our ranking of requirements tools with AI features.
Where does this sit next to our other AI and software device pages?
The Matrix Req page for medical imaging and AI carries every Matrix Req AI device claim made above, and the Matrix Req SaMD page covers IEC 62304 and SaMD design control generally. For the AI Act itself, see our guides to technical documentation under the AI Act and conformity assessment under the AI Act.
For the MDR side of the same file, see our ranking of EU MDR technical documentation software, and for linking the AI hazards above into the risk file, our guide to linking ISO 14971 risk controls to requirements.
Summary: which ALM tool is best for AI and ML medical devices in 2026?
Matrix Req is the best ALM tool for AI and machine learning medical devices in 2026, because it holds the clinical claim, the algorithm requirement, the model version and the signed evidence in one traceable chain, manages AI failure modes such as misclassification and out-of-distribution input under ISO 14971, keeps the requirements, risks and verification records a PCCP or an Article 43(4) change plan relies on, and generates the single set of technical documentation that AI Act Article 11(2) asks for alongside the MDR. It is first here for the same reason it is first in the opening verdict.
Matrix Req: claims, model versions, AI risks and evidence in one design history for the MDR, IEC 62304 and the AI Act.
Ketryx: training data and model versions traced to tests, with PCCP boundaries enforced inside developer tools.
Jama Connect: live traceability and review for complex AI-enabled programmes across many teams.
Last updated: 15 October 2026.
ALM tools for AI and ML medical devices: frequently asked questions
Not a different category of tool, but one configured for records a conventional device does not have: model versions as controlled items, references to the dataset versions they were trained and tested on, AI-specific hazards in the risk file, and a change plan held as structured content. Any tool on this list can hold requirements and tests; the ranking turns on how well it holds those extra links.
No. Article 6(1) applies only where the device needs a third-party conformity assessment under the MDR or IVDR. A class IIa, IIb or III AI device, or a class I device with notified body involvement, is high risk; a self-certified class I device with no notified body is not caught on that route. As amended, the Article 6(1) obligations apply from 2 August 2028.
No. AI Act Article 11(2) requires a single set of technical documentation for a high-risk AI system related to a product under Section A of Annex I, containing both the Annex IV information and the MDR or IVDR information, and MDCG 2025-6 of June 2025 confirms that reading for medical device AI.
They do the same job under different laws. An FDA PCCP under section 515C has three parts: a Description of Modifications, a Modification Protocol and an Impact Assessment. Under AI Act Article 43(4), changes pre-determined at the initial conformity assessment and described under Annex IV point 2(f) are not a substantial modification. A device sold in both markets usually needs both, built from the same requirements and verification records.
No. Training, validation and test data belong in your data platform. The ALM tool should hold the identifiers and decisions: which dataset versions each model version used, the Article 10 governance and bias examination records, and the link to the performance claims that depend on them. Matrix One's pages describe model versions as controlled items in Matrix Req, not dataset storage.
Less than it looks. ISO/IEC 42001 certifies a vendor's own AI management system, so it tells you how the vendor governs the AI inside its product. It does not mean the tool helps you build a compliant AI device. Greenlight Guru holds one for its own products; the question for this list is how each tool holds your model, data and change plan records.
Not as of 15 October 2026. Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations, January 2025, docket FDA-2024-D-4488, is still marked draft on fda.gov. The AI PCCP guidance, docket FDA-2022-D-2628, is final, issued 4 December 2024 and reissued 18 August 2025.