QMS Nordic · AI System Card
QMS Nordic QMS — AI Assistance Disclosure
QMS Nordic embeds AI-assisted drafting, suggestion, and retrieval features into the QMS workflow. This page describes what the AI does, what it does not do, the foundation models it relies on, the safeguards in place, and your rights as a user. It is published in accordance with EU AI Act Articles 11, 13, and 50.
1 · Intended purpose
QMS Nordic's AI assists humans drafting regulatory documentation — risk-management plans, clinical evaluation reports, post-market surveillance plans, software development plans, and similar QMS artefacts — by producing draft text grounded in a maintained registry of regulatory clause citations (ISO 14971, EU MDR/IVDR, 21 CFR §820, IEC 62304, IEC 62366-1, MDCG guidance, etc.).
It also performs ancillary tasks: explanation of regulatory concepts, root-cause and hazard suggestion in CAPA / risk flows, and helpdesk reply suggestions.
2 · Out-of-scope uses
- QMS Nordic AI is not a substitute for a Notified Body, a regulatory consultant, or an internal subject-matter expert.
- AI-generated text must be checked by a person before a document is released. A document the AI drafted in sections cannot be sent for review, approved or made effective until a colleague — not the person who ran the draft — has verified every section. A document the AI drafted as one piece has no sections to verify. Every document, AI-drafted or not, must be approved by someone other than its author. The platform enforces both rules on the server.
- QMS Nordic AI does not make clinical decisions, does not generate patient-facing diagnoses, and does not autonomously approve documents.
3 · Foundation models and providers
- Anthropic Claude (Sonnet 4.6) — primary drafting model. Anthropic is listed as a sub-processor on our sub-processor page. Customer documents are NOT used to train Anthropic models — this is contractually enforced via our zero-retention deployment configuration.
- OpenAI text-embedding-3-small — used for retrieval (RAG) over your tenant's own documents. Embeddings are tenant-scoped; no cross-tenant retrieval is possible.
4 · Accuracy expectations and limitations
Foundation models can produce incorrect, outdated, or inappropriate text. Specifically, QMS Nordic AI may:
- Hallucinate clause numbers, statistics, or device characteristics — which is why every claim must be human-verified against the provided citation registry.
- Lag behind very recent regulatory updates (training-data cutoff plus our deployment lag — typically 0–6 months).
- Produce drafts that read as confident but miss tenant-specific context the model wasn't given.
For these reasons, the verification gate (see Section 6) is mandatory.
5 · Logging and record-keeping (Article 12)
Every AI inference creates an immutable record:
- SHA-256 hash of the prompt and output (raw text never persisted)
- Model id, token counts, retrieved-chunk ids, timestamp, user id
- An “AI draft generated” or “AI populated” entry in the hash-chained audit log
Logs are retained for the tenant lifetime (well beyond the 6-month minimum). Tenants can query their own logs via the audit log.
6 · Human oversight (Article 14)
AI-populated documents enter a structured verification flow on the document's Verify page. Each section starts as ai-generated and only counts toward release once a verifier signs it off. The author of the AI populate run cannot self-verify; verification requires a separate person. Editing a section resets it to edited, requiring re-verification.
While any section of an AI-drafted document is unverified, the server refuses to send it for review (from the page or as an edited Word file), approve it, start an approval route on it, or make it effective, and tells the person how many sections are verified. Each verification is recorded in the audit trail with who verified the section and when; a refused step is shown to the person who tried it and is not itself recorded there. A document the AI drafted as one piece — in the composer, or with AI drafting chosen when the document was created — has no sections, so this check does not apply to it; the check that does is the one every document has: someone other than its author must approve it.
7 · Marking AI-generated content (Article 50)
AI-generated content is marked with the icon throughout the UI. Each AI-populated document carries a aiProvenance JSON record listing the model id, prompt/output hashes, verification status per section, and verifier identities — preserved across human edits. A machine-readable X-AI-Generated header is set on downloads of any AI-touched artefact.
8 · Cybersecurity and accuracy controls (Article 15)
- TLS 1.3 in transit; AES-256 at rest (managed by Neon)
- Per-tenant FORCE RLS in Postgres — cross-tenant data leakage prevented at the database layer
- Sentry runtime monitoring with PII scrubbing for anomaly detection
- Per-tenant AI budget caps — protect against runaway costs and rate-limit attacks
- Regression test suite against a curated benchmark of reference QMS documents (extending coverage in 2026)
9 · Reporting an AI incident
If QMS Nordic's AI output causes harm, a near-miss, or a serious accuracy failure, tell us at support@qmsnordic.com with what was asked, what the AI produced and what followed. We will investigate it through our own CAPA process and, where required, notify market surveillance authorities under Article 73. If it touches your own devices or records, also record it in your complaints register, saying in the description that it concerns AI output: the register has no separate source for AI incidents, and a complaint there is your record, not a report to us.
10 · Versioning
This system card is versioned in source control alongside the QMS Nordic codebase. The current revision corresponds to the deployment fingerprint shown on the status page. Material changes are announced via the sub-processor list and to admins of affected tenants by email.
Last reviewed: April 2026 · Maintained by QMS Nordic Compliance · DPA · deployer dashboard
