I asked our eQMS vendor in July what they were changing to meet AI Act transparency obligations. I asked again last month, now that the Act is in force. Still nothing — no roadmap, no documentation, no acknowledgement beyond “we’re monitoring.” As the quality lead for a Class II device, that silence triggered a lot of internal questions: how long do I keep chasing? At what point does vendor silence become a compliance escalation rather than a procurement annoyance?
I wanted to share the sequence we used and the concrete checks that made the decision to escalate obvious. This isn’t legal advice — it’s what worked in a mid-size medtech setting where the QMS and traceability must be defensible to auditors and notified bodies.
Why this matters (practically)
The EU AI Act’s transparency obligations are not academic for regulated medical device makers. If your supplier’s service includes AI-driven decision support, risk-scoring, automation of controlled processes, or anything that affects design history files, complaint triage, or CAPA assignment, their lack of evidence can create a downstream gap that you — the manufacturer — have to own.
A few practical effects we worried about:
- Unclear documentation for audits: “How does the vendor support human oversight?” — answer: nothing on file.
- Traceability gaps: if the vendor changes an algorithm or model, how would we detect and link that change to our DHF or risk assessment?
- Contractual exposure: no contractual obligation to notify changes that would trigger our change control or revalidation activities.
That’s the risk vector that moved us from “keep chasing” to “escalate.”
What we did before escalation (don’t skip the basics)
Before making escalation formal, we exhausted the low-friction paths:
- Documented every contact: date-stamped emails, support tickets, and the responses (or lack thereof).
- Asked specific questions — not “are you compliant?” but:
- Do you consider your product an “AI system” per the AI Act?
- What documentation do you have that demonstrates transparency obligations (explainability info, logs, versioning, human oversight description)?
- Will you notify customers of model/algorithm changes and provide a changelog?
- Do you have contractual assurances / DPA updates reflecting the new legal landscape?
- Requested a technical artifact: a short technical note, model/version change policy, or an “AI transparency” annex.
- Checked contracts for audit rights and notification clauses — and whether those clauses had any teeth.
In our case, the vendor responded twice with generic PR-style copy and then went quiet. That’s what pushed me over the line.
Triggers that made escalation necessary
For us, escalation wasn’t emotional — it was a checklist of missing guardrails that matter to regulatory defensibility. We escalated when:
- The vendor’s responses were non-specific and didn’t address transparency artifacts we needed (no changelog, no model governance evidence).
- Contractual obligations to notify or allow audits were weak or ambiguous.
- The vendor is a single point of failure for a control in our QMS (e.g., they host the CAPA triage workflow or perform automated classification that feeds complaint handling).
- The silence continued beyond reasonable follow-up windows despite the regulatory deadline passing.
You can codify “reasonable follow-up” for your org. For us, if a vendor takes longer than 30 calendar days to provide substantive artifacts after a targeted request, and the service impacts regulated processes, we escalate.
How we escalated (concrete steps)
We treated this like any other supplier nonconformance that could affect product quality:
-
Internal alignment
- Pulled in RA/legal, procurement, and the folks who rely on the vendor (support, R&D).
- Agreed the risk tolerability: can we keep using the tool with mitigations while this is resolved?
-
Formal written request
- Sent a formal compliance information request (CIR) with a 14–30 day deadline. Said what we needed: documentation, notification policy, and contract amendment language.
-
Risk mitigation plan
- Implemented interim controls: increased monitoring of outputs, added manual review steps, and temporarily frozen auto-deploys that relied on vendor-side models.
- Logged the mitigation as a controlled change and added traceability records.
-
Invoke contract / audit rights
- If the vendor has audit rights, we scheduled a supplier audit. If not, we sought a contract amendment for notification and remediation obligations.
-
Escalate vendor status
- Marked vendor as “conditional” in supplier management, flagged for replacement timeline if no satisfactory response.
-
Communicate to leadership/board
- Summarized the exposure, mitigation, and proposed next steps so leadership could weigh business impact.
What I’d expect a reasonable vendor to provide
If your vendor is serious about compliance the following should be straightforward to produce:
- A short technical transparency statement describing how the system supports human oversight and what explainability artifacts exist.
- A changelog/versioning policy for models or algorithmic components, including notification thresholds for customers.
- Evidence of testing/verification that algorithm changes don’t silently affect regulated outputs (or a documented process to re-verify).
- Contractual language or an amendment guaranteeing notice and the right to audit or request specific artifacts.
If you don’t get these, it’s not unreasonable to escalate.
What escalation looks like in the long run
Escalation isn’t just a threat — it’s a process. You might end up with:
- A contract amendment requiring advance notice of changes and an SLA for compliance artifacts.
- A supplier improvement plan with milestones.
- Or a gradual replacement plan if the vendor cannot meet the basic governance expectations.
We prefer to keep suppliers, but not at the expense of traceability and defensibility. Remember the principle: traceability should follow the work, not chase it. If your vendor’s processes leave gaps that force you to recreate traceability after the fact, that’s a red flag.
Final thought
If your org hasn’t defined a supplier response timeline for live regulatory obligations, now is the time. Treat silence as data: it’s an input to your supplier risk tiering and your remediation plan.
How have other medtech teams handled vendor silence on AI Act (or similar) obligations — what response timelines and escalation paths worked for you?
