Ask any eQMS vendor today: "the AI Act transparency rules came into force on 2 August — what did you change, and can you show me?" How they answer tells you more about their product and mindset than any brochure ever will.
I asked that exact question across three demos last week. One vendor gave me a single, concrete sentence and then walked me through artefacts in ten minutes. The others danced around policy and roadmap promises. To be fair, the AI Act spans several obligations and implementation is not trivial — granted — but in practice this means an eQMS used by regulated device manufacturers must do two things well: produce the artefacts regulators expect, and reliably tie those artefacts into the rest of your QMS (risk, change control, supplier management, validation).
Why one sentence matters
If a vendor can answer succinctly, they are usually telling you:
- They have implemented specific capabilities (not just a high-level plan).
- They have thought through how AI documentation fits into regulated workflows.
- They can show traceable outputs quickly in a demo environment.
If they deflect, waffle about "guidance evolving", or promise "we'll add a feature", they are telling you:
- The feature is not materially available today, or
- They see the AI Act as a product marketing opportunity rather than something that must integrate with your regulatory artefacts.
Genau — the difference is practical, not philosophical.
What the AI Act transparency obligations mean for a medtech eQMS
You do not need the vendor to be your regulatory consultant, but you do need the eQMS to support the documentation and traceability the Act expects. For a medical device manufacturer that already follows MDR 2017/745, these are the practical implications I expect to see supported:
- Structured artefacts: model cards / system descriptions, documentation of intended use, and user-facing transparency statements that can be versioned and exported into the Technical File (Annex II relevance).
- Provenance and datasets: records of training/validation datasets, who supplied them, and any preprocessing steps — linked to supplier management and data agreements.
- Change & version control: model version history, release notes, and ability to link each model version to its risk assessment and validation evidence (IEC 62304 / ISO 14971 ties).
- Audit trail & explainability logs: immutable logs that show how an inference engine was tested/validated and how decisions are explained for a given release.
- Supplier/subcontractor evidence: contracts, subcontractor assessments, and evidence of AI component validation retained in one place.
- User-facing disclosures: templated text for information to users/clinicians and a way to evidence when disclosures were deployed.
- Post-market monitoring linkage: ability to correlate incidents, PSUR/PMCF data, and model performance drift with model versions and trigger CAPAs (automated CAPAs, preferably).
If your eQMS does not make these linkages easy, you will be stitching evidence together manually — slow, error-prone, and uncomfortable in a notified-body audit.
What a good one-sentence vendor answer looks like
A strong, credible one-liner is specific, not vague. Examples of the shape of a good answer (you can ask for this exact phrasing in a demo):
- "We added an AI transparency module that produces model cards, stores dataset provenance, and links each model version to validation evidence, change control, and risk assessments — here's a demo record."
- "We extended our Change Impact Mapping so model updates automatically populate the MDR-relevant Technical File annex and create a linked CAPA template when performance drift exceeds thresholds."
- "We have a templated transparency statement that can be signed, versioned, and exported into your Technical File; it includes a model provenance report and a dataset manifest."
If a vendor says any of the above and then shows you a real record in the demo tenant, that is meaningful.
Concrete things to ask for in the demo (and what to expect)
Ask for these demonstrations. A vendor who can do each in five minutes is not selling smoke:
- Show me a model card for a deployed model and the dataset provenance record that created it.
- Show me the model version history and the linked validation evidence (test reports, IEC 62304 artefacts).
- Trigger a simulated model update and show the change control workflow + automated risk assessment link.
- Export the artefacts you would include in an Annex II Technical File export for a software update.
- Show how post-market performance data is linked to model versions and how a CAPA is opened automatically.
Red flags during the demo:
- No linked artefacts — everything is "in a PDF" or in separate systems.
- "That's on our roadmap" without a target date or sandbox.
- No immutable audit trail for model decisions and versioning.
Validation and QMS reality
Validation of software remains obligatory — you will still need documented software validation per your QMS and relevant standards. Expect to map the eQMS outputs into:
- ISO 13485 process records,
- IEC 62304 software lifecycle documentation,
- ISO 14971 risk management outputs,
- Your MDR Technical File (Annex II/III) and post-market files.
An eQMS that claims AI support but cannot demonstrate how it feeds validated artefacts into these outputs is not worth the powerpoint.
Final practical note
In regulated medtech, transparency obligations are not a marketing checkbox — they are traceability, and notified bodies will want to see the chain from model development to deployment to post-market monitoring. Your eQMS should make that chain discoverable and auditable, not just possible with heroic searches.
What did your current or prospective eQMS vendor say when you asked this question — and did they show it?
Top comments (0)