I run regulatory work for devices under EU rules; I see the same jurisdictional lesson repeating with the EU AI Act that we lived through with GDPR: where your users are matters more than where your head office sits. For US/Canada QMS teams building AI features — triage, supplier‑risk suggestions, automated root‑cause hints — that should set off an immediate checklist in your backlog.
The practical hook: your SaaS AI + an EU user = possible “deployer” obligations
You might be headquartered in Boston or Toronto, your legal counsel might have told you “EU law doesn’t apply”, and to be fair that was often true three years ago. But the EU AI Act is designed to regulate systems that are placed on the EU market or put into service in the Union. In practice this means: if an EU-based customer accesses and uses your AI feature while physically in the EU, your company can be treated as a relevant actor (provider or deployer) even if incorporated elsewhere.
Concrete examples I see in the field:
- A QMS module that auto-classifies complaint narratives and proposes CAPA owners — used by an EU site of a multinational.
- An AI suggestion engine that ranks supplier non-conformances for escalation, used by an EU contract manufacturer.
- An evidence-triage assistant that flags missing clinical evidence for EU device submissions.
All these are textbook scenarios where the presence of an EU user is the jurisdictional hook.
What this looks like in reality for a QMS team
The Act brings obligations you will recognise if you live in device regulation land — documentation, risk management, transparency, monitoring — but applied to AI behaviour and lifecycle:
- Transparency to end users: inform that an AI is being used and what its limitations are.
- Risk assessment and mitigation: show you examined how wrong or biased outputs could harm decisions (e.g. incorrect CAPA prioritisation).
- Traceability and record-keeping: logs that allow reconstruction of decisions (inputs, model version, key parameters).
- Post‑deployment monitoring: ongoing performance checks and reporting arrangements.
- Human oversight: reasonable controls so a human can step in and not blindly follow the AI suggestion.
In other words, this feeds directly into your QMS documents — change control, risk management file, supplier control, and CAPA workflows.
Quick checklist for a QMS product team (start here this week)
- Map where your users actually are. Don’t rely on billing address alone — IP, declared site, and actual use matter.
- Decide intent: do you want to serve EU users at all? If not, can you reliably block EU traffic? Geo‑blocking is feasible but brittle.
- Update contracts and ToS: require EU customers to take on regulatory responsibilities where acceptable, and include data processing terms that reflect EU requirements.
- Add AI-specific documentation into your Technical Documentation or QMS:
- Model description, training data provenance (high level), intended use, known limitations
- Versioning policy and deployment logs
- Risk assessment focused on patient/safety/reliability impact
- Add monitoring and incident handling into your CAPA and change workflows:
- Define AI performance KPIs
- Link anomalies to CAPA-driven risk assessment and corrective loops (automated CAPAs or AI-assisted triage can speed this, but keep human review)
- Consider appointing an EU legal representative if you can’t avoid the EU user base; this is the GDPR playbook repeated.
Where this will touch your audits and notified-body conversations
Expect auditors to want evidence that AI features underwent the same rigour as any safety-related change:
- Traceability from user complaint -> AI suggestion -> CAPA action.
- Change impact mapping showing the AI model update was evaluated for effect on safety and effectiveness.
- Documented human oversight procedures so decisions are reviewable and reproducible.
If your AI affects clinical decision-making or fundamental safety (for medical-device-adjacent modules), you will also need to coordinate with your device regulatory strategy — the AI Act does not exist in a vacuum.
Practical mitigations that are common and realistic
- Limit EU exposure: disable the feature for EU accounts until you can comply.
- Narrow intended use: make the AI clearly advisory and require documented human sign-off in the workflow (in practice this means UI/UX changes and audit trails).
- Build the traces now: model version tags, input snapshot links, decision rationale fields. These are cheap to add compared to rebuilding later.
- Fold AI governance into the QMS: change control templates, supplier assessment (model/data suppliers), and post-market surveillance analogues.
To be clear: none of this is impossible. Granted, it is extra work and it touches core product behaviours. But these are the same principles we apply for clinical evidence and PMS under MDR — document, evaluate, monitor, and be able to show you did it.
Final note — what your legal and RA teams will ask for
Legal will want contractual cover and a representative strategy; RA/QA will want the traceability, monitoring, and CAPA linkages. The single most useful thing you can do today is an impact map: which features call AI, which customers/countries use them, and which QMS records must change if the feature is “on” for an EU user.
I’ll leave you with this question: have you mapped which of your AI-driven QMS features are already being used from the EU, and if so, what’s the smallest change you could make this week to reduce your immediate regulatory exposure?
