I used to mark my calendar for "August" when people talked about AI compliance milestones. After digging into Article 50 (as our legal team interprets it) and the guidance we've been handed, the real hard date for systems already in production is 2 December. In plain terms: every AI-enabled system we already have running needs the disclosure in place by then.
At a 200-person, Class II shop where I do quality and run traceability on Greenlight Guru, "we'll do it in Q4" is how you end up wiring a disclosure banner into production in week 48 while the dev team is on holiday and the notified body auditor emails for evidence. If you haven't scheduled the work, this is a practical write-up of how I'm planning to attack it and the things I've learned we can't leave to "sprint capacity permitting."
First pass: scope and inventory (take 48 hours, not 48 days)
Start by getting a single source-of-truth for what "AI" you actually have in production. We did this with a short form developers filled out and a review by product owners and SQA.
- Product/feature name
- Where it runs (cloud region, edge devices, embedded firmware)
- Inputs/outputs (what the model consumes and returns)
- User-facing touchpoints (UI screens, reports, labels, API responses, clinician-facing prompts)
- Current logging and telemetry locations
Make this an item on the next change-control agenda. If you can't prove you inventoried, auditors will assume you scrambled.
The disclosure itself — what you need technically
Legal will want a tested, consistent disclosure. From a developer point-of-view, the implementation patterns that save hours later are:
- Centralized disclosure component/service
- One React/Vue component or one server-side middleware that returns the disclosure payload. Reuse it everywhere so legal text can be updated centrally.
- Configuration-driven text
- Store the canonical disclosure text in a versioned repo or CMS; pull into the component at runtime so UI teams don't hard-code copies.
- Middleware for APIs and CLI outputs
- For machine-to-machine interfaces, emit a standard header or envelope field with the disclosure.
- Feature flags + canary rollout
- Use flags to roll the disclosure to internal users first, then clinics, then full production.
- Automated tests
- Unit/UI tests that assert disclosure component renders, API integration tests that assert header present, e2e tests for major flows.
- Telemetry and evidence
- Log an event when disclosure is shown and when consent/acknowledgement is captured (if required). Those logs are audit evidence.
QMS and change-control work (don't treat it as "just UI")
This is an engineering change with regulatory implications. Treat it like any design control:
- Raise a formal Change Request (ECN/CR) referencing the regulation and the 2 December date.
- Update relevant procedures: risk management if the AI decision could harm users, post-market surveillance processes, and user documentation/IFU as needed.
- Risk assessment: is the disclosure omission itself a hazard (e.g., false sense of automation)? Document mitigations.
- Verification plan: list tests and evidence you will collect — screenshots, logs, test runs, release notes.
- Review trail: include legal, RA, QA, lead dev, product owner in sign-offs — store approvals in the QMS (we add these as artifacts in Greenlight Guru).
Realistic timeline I proposed to leadership
I mapped the work into four blocks so it's visible in sprint planning:
- Week 0–1: Inventory + legal copy + CR creation
- Week 2–3: Engineering design + central component + tests
- Week 4: Internal rollout + telemetry verification + QA sign-off
- Week 5: Canary + production release + QMS evidence upload
That's 5–6 weeks, assuming a focused small team. If you start in mid-October, you're fine. Start in late November and plan on emergency overtime and missed evidence trails.
Integration gotchas I've hit
A few concrete issues that cause rework if you don't spot them early:
- Multiple client apps (mobile, web, desktop) each hard-code their own copy. Fix with a shared package or API.
- Embedded devices without a UI — the disclosure has to live in release notes / labeling or clinician training materials.
- Third-party components: if a third party exposes AI outputs (e.g., analytics vendor), you need agreements and evidence that the disclosure is present or that they will provide it.
- Localization: translations can take time — prioritize languages in the highest-risk markets.
- Accessibility: disclosure must be accessible (screen readers, readable font sizes) — test this in QA.
Evidence and audit posture (what auditors will want)
Prepare a bundle for auditors and internal compliance that includes:
- Inventory list and date-stamped screenshots
- The legal text version used (with version history)
- Release notes and change request with sign-offs
- Test results showing disclosure rendered / header present
- Telemetry logs showing rollout and exposure counts
- Risk assessment and any updated IFU or labeling
Store these in your QMS before the release. If an auditor asks for "proof you rolled it out by 2 Dec," having the bundle in one place matters.
Why "we'll do it in Q4" is dangerous
Q4 includes holidays, security freezes, and auditors trying to close findings. Putting this in "Q4" without a sprint commitment is asking for a chaotic week-48 rollout that leaves bad traceability. That leads to missing evidence, patch rollbacks, and CAPAs — the exact problems a thoughtful disclosure requirement is meant to avoid.
How I'm scheduling it on my team
I raised the CR, put the work in the next sprint as "high priority — regulatory," assigned a small cross-functional squad (1 UX, 1 backend, 1 QA, 1 RA), and booked a recurring 30-minute sync for the next 6 weeks. We also asked legal for the canonical text and a short checklist of mandatory elements so developers don't iterate on wording.
If you haven't scheduled this yet, pick a week in October and book the engineers now.
What I want to learn from you: has anyone already implemented a centralized disclosure service (client components + API + telemetry) that they could share patterns or a tiny checklist for? How did you structure the evidence bundle for auditors so it was discoverable and accepted without extra rework?
