The Regulatory Intelligence Gap Nobody Talks About
A regulatory affairs professional posted something on Reddit last week that sums up a problem we see constantly. Her company built an entire department for regulatory intelligence, spanning medical devices, pharma, and consumer products across global markets, with a RIM system plus extra tools stacked on top. Her conclusion: the tools tell her something changed. They don't tell her what to do about it. She also tried AI for triage. "Incredibly unreliable," as she put it.
Monitoring and intelligence aren't the same thing
You can read the full thread here. Part of the confusion is a labeling problem. "Regulatory intelligence" gets used as a synonym for "regulatory monitoring," but they're different jobs. Monitoring tells you something changed. Intelligence starts where monitoring ends: turning that change into business impact, compliance actions, and a decision someone can actually act on. A RIM system that only monitors will always leave that second half undone, no matter how many feeds you bolt onto it.
When new guidance lands, someone still has to answer three questions before real assessment happens: which product does this touch, which requirement or risk control does it change, and who owns fixing it. If your documentation lives in static binders or a QMS without built-in traceability, answering those means manually re-reading your own files against the new document, every time, for every product line. That's not a monitoring failure, it's structural.
Why AI stumbles here too
AI is good at summarizing a guidance document or flagging that a paragraph looks relevant. It's bad at knowing that paragraph maps to a specific risk file section or design control, because that mapping usually doesn't exist anywhere machine-readable. AI can't triage against a map that was never drawn.
This isn't unique to one company. AI is already used across regulatory submissions, information management, document review, and decision support throughout healthcare, pharma, and medical devices, with real efficiency gains, but also new compliance challenges. Policymakers are trying to write rules that encourage that innovation while still protecting people, a hard needle to thread when the technology moves faster than the guidance meant to govern it.
WHO's regulatory considerations on AI for health (2023) already named what serious AI use here needs: risk-benefit assessment, continuous monitoring, transparency, regulatory oversight. Three years later, most of that still isn't something you get from tooling alone.
AI can support regulatory intelligence. It can't yet replace it.
What actually closes the gap
Not a better alert feed. Building the connective tissue between requirements, risk controls, and software from the start, so it already exists when new guidance shows up:
- Requirements traced to risk controls, to design, to verification evidence, as a living structure.
- Changes assessed against that structure, not against memory.
- Ownership assigned at the architecture level, so nobody scrambles to find out who should be looking at a new document.
This is why we treat regulatory-grade software development as a lifecycle, not a phase. Being compliant on day one is one thing. Staying that way for years without losing track of what changes downstream is the harder problem most vendors don't build for.
Smaller companies have it worse
If a company with a whole department and multiple RIM systems struggles with triage, a smaller MedTech company with one regulatory affairs person is worse off, not better. Every new guidance document becomes a fire drill instead of a checklist.
The cheapest time to build traceability is before you have years of documentation to retrofit. If you're past that point, the fix is building the traceability layer on top of what exists, product by product. Either way, it's an architecture decision, not a tooling purchase.