Article 50 landed — December 2 is the real deadline, not August

I stopped worrying about August and started worrying about December the moment Article 50 actually slipped into application. To be blunt: every AI system we already had running has until 2 December to add the disclosure. "We’ll do it in Q4" is how you end up fixing this in week 48 with three devs answering Slack at 22:00 and the Clinical Safety Officer approving wording from a phone on the tram. Been there; trying to avoid repeating it.

Here’s how I’m running the work right now — practical, low-friction steps for a tight RA/QA team that has a lot else to deliver.

Immediate triage (day 0–3)

First, treat this like a regulated change to a device, because it is.

• Inventory every product, subsystem and service that uses an AI component (on-device, cloud, inference pipelines, third-party APIs).
• Mark which ones are in-market, which are in clinical use, which are in beta.
• Assign an owner for each item (dev lead / product manager / RA) and create a single change ticket per product in your QMS. Traceability matters — link that ticket to the Technical File, risk assessment and IFU/label items.

In practice this means one central place where the disclosure work lives. If your eQMS doesn’t let you link change-to-Technical-File sections and risk items, you’ll pay for it in week 48.

What the work actually is (not just wording)

Adding a disclosure is not only a line of copy. Expect work in these areas:

• UX: where and how the disclosure appears (splash screen, settings, before each session). Usability and readability matter.
• Localisation: translations into EU languages used where you sell the device.
• Logging: ensure the system records when users saw/acknowledged the disclosure.
• Docs: update IFU, quick-start guides, online portals and the Technical File (Annex II).
• Software change control: version bump, release notes, regression testing per IEC 62304 processes.
• Risk assessment: update the risk management file (ISO 14971) for the disclosure’s impact (e.g., does the disclosure change intended use or operator decision-making?).
• Post-market: update your PMS/PMCF plans and PSUR templates to capture any new incidents tied to the disclosure or behavioural changes.
• Third parties: require vendors/APIs to provide their own disclosure evidence if they’re in your user flow.

If you try to treat the disclosure as “marketing copy” and drop it into a web banner at the last minute, you will fail the traceability and documentation checks in an audit.

Practical drafting and UX tips

I prefer a short, plain-language statement plus a link to more detail. Practically:

• Keep the headline one line: "This system uses an AI component to [what it does]."
• One follow-up sentence for limitations: "Outputs are probabilistic and should be reviewed by a qualified clinician."
• A link: "More information (how it works, data sources, performance, contact) →"
• Provide a way to replay or access the exact prompt or input used, where feasible, or explain why you cannot (privacy/cyber reasons).
• Ensure the disclosure is visible at the correct user journey point — before the AI output influences a clinical decision.

Test the disclosure with a clinician early. They’ll tell you whether the wording is noise or actually helpful.

Schedule backwards from 2 December

Don’t wait for a single sprint. My timeline template:

• Week 0–1: Inventory, owners, decision on UX location.
• Week 1–2: Draft disclosure copy, language list, confirm legal/clinical sign-off owners.
• Week 2–4: Implement UI changes, logging, translations.
• Week 4–5: QA/regression testing, accessibility/usability checks.
• Week 5–6: Release to production or staggered rollout; update Technical File and PMS artefacts.
• Buffer: 1–2 weeks for hotfixes and notified-body communications if required.

That’s deliberately compact. If you’re already in dev cycles, you can overlap steps — but you must not skip linking the change to your Technical File and risk documents.

QMS and notified body considerations

From a QMS perspective, treat this as a controlled change:

• Raise change control, update the Architecture and Software Description in the Technical File (Annex II).
• Update your risk management (ISO 14971) and clinical evaluation if the AI output affects clinician decisions (Annex XIV touches on continuing evaluation).
• If the disclosure or UI change affects claims, indications, or clinical performance, discuss with your notified body early — do not surprise them with a deployed change.
• Use your eQMS to create traceability: change → risk assessment → test evidence → IFU/label update → release note.

If your eQMS supports connected workflows and automated CAPAs, now’s the time to use them: generate the change ticket, route for clinical and legal review, and leave an auditable trail.

What I’m seeing go wrong

• Treating the disclosure as purely marketing copy and not documenting the decision rationale.
• Forgetting translations for every market.
• No logging of the disclosure being shown — audits love that.
• Assuming third-party AI providers will handle the disclosure for you — check contracts and require proof.
• “We’ll wait for the final guidance” — guidance will help, but it rarely removes the need for a documented product change.

To be fair, guidance can mitigate some implementation choices, but the obligation and the deadline are real. In my experience, the notified body will expect to see the change process and traceability, not a memo that you “plan to comply.”

Final practical checklist

• Single inventory and owner list
• One change ticket per product, linked to Technical File and risk file
• Drafted, clinically-reviewed disclosure copy and UX placement
• Translations and logging requirements specified
• Regression and usability testing completed
• Technical File, IFU and PMS updates completed
• Notified-body communication if change impacts clinical/performance claims

We’re implementing this in a single connected workflow in the QMS so engineering, clinical, and RA can see the same artefacts and approvals. That connectedness avoids last-minute rework and the week-48 panic.

Has your team scheduled the work and linked it into the QMS yet — or are you still in the "we’ll do it in Q4" camp?