Fail: On Tuesday, my hope of finally finding a company where I could build a custom, one-off software solution on my own this summer fell apart. I wanted to prove my hypothesis that tailor-made software with a production volume of n = 1 is the future.
Fail: By Wednesday lunchtime, I had promised my colleagues I’d automate the review of design inputs (in the technical documentation) using AI by the evening. By nightfall, all I had produced were several megabytes of hallucinated text.
Fail: And by Friday, I felt completely overworked – despite, or maybe because of, AI – and too drained to run my usual AI experiments over the weekend.
I learned something from all three. And I want to share those insights with you:
Fail: Executive Corner
Fail: Two practical tips
Fail: More next week, here in the MDB
But first, back to our usual agenda: Regulatory Updates.
Representative & separated data: Training and test datasets must be strictly separated and accurately reflect the real target population to avoid bias.
AI-specific risk management: New risks – like blind trust in automation (“automation bias”) and lack of explainability (“black box”) – require targeted controls.
The “human-AI team”: You can’t validate AI in isolation; what matters is the safe interaction between user and AI in real clinical workflows under continuous human oversight.
Continuous monitoring: Since AI models can degrade over time due to changing conditions (“data drift”), their performance must be continuously tracked in real-world use.
Cybersecurity & transparency: Training data and models must be protected against manipulation (poisoning), while users must be clearly informed about limitations through proper labeling.
What’s unclear to me is the added value of this document on existing standards and guidances – especially since long text passages reduce readability and likely also implementability. Most of these requirements already exist elsewhere, often formulated more precisely, more granularly, and therefore more operationally – for example, in our AI guidance.
And with the quality metrics listed in Annex B, the document already feels somewhat outdated. These aren’t the metrics many modern AI-based medical devices rely on today – like those for segmentation or evaluating generative models.
b. EU on Health Data Space
The latest drafts of the EU’s implementation regulations on the European Health Data Space, Ares(2026)3673210 and Ares(2026)3843449, leave me with mixed feelings.
Objective
The EU aims to ensure interoperability of health data across national borders to achieve the goals of the European Health Data Space. To that end, the EU has compiled lists of “administrative” attributes that should be exchanged.
Implementation & assessment
However, the EU has not defined data types or semantic standards for these attributes. That means none of the four levels of interoperability have been sufficiently specified. Yet those would be essential to actually achieve interoperability.
Let’s see what the next implementation regulation brings, especially regarding interoperability of the actual clinical data.
Implications for manufacturers
Even so, the annexes already allow manufacturers – especially of clinical information systems – to assess how completely their systems manage relevant information. And the EU is actively inviting feedback, which is worth using.
Executive Corner: Are The Bosses To Blame?!
a. The context
I’m planning to build a custom AI this summer – on my own – for a single manufacturer, automating their core regulatory processes. That’s why I had a meeting last week with a potential partner.
b. The moment of realization
The key moment came when I casually explained the difference between a manager schedule (meeting to meeting) and a creator schedule (large, uninterrupted blocks for real work).
My takeaway: in this company, nobody has a creator schedule. Which probably means there’s no way they can keep up with the speed I’d need.
So, not a candidate for my experiment again.
c. The symptoms, and my diagnosis
I genuinely understand how people end up in this situation. But it comes at a cost:
No breathing room in calendars. Days packed with alignments, reviews, recurring meetings. What’s missing: time to think, not just talk. The result: Nobody improves the system – they just maintain it.
Too many voices, too few decisions. The bigger the organization, the more people need to be heard. Sounds democratic – ends up diluting decisions. The result: Projects that could be done in days take months – or die quietly.
Size mistaken for strength. Companies think they’re running agile speedboats. In reality, they’ve built aircraft carriers, or tankers, as I called them in MDB 11/26. Impressive, but not maneuverable. The result: Even when there’s will to innovate, mass kills speed.
Each of these symptoms alone is manageable. Together, they create something else entirely: A system that holds itself back.
While it does, the market moves on: regulation gets more complex, tools more powerful, and leaner competitors pull ahead.
That doesn’t just threaten business models. It threatens jobs, especially those of the people working the hardest today.
d. The “Therapy”
What would help – but usually doesn’t happen
A clear top-down signal. Leadership cuts through complexity, removes obstacles, sets direction: top-down, decisively and fast.
But let’s be honest: this is exactly what doesn’t happen in most organizations. I don’t know whether it’s a lack of awareness, competing priorities, lack of courage – or, in the worst case, simple overload. It doesn’t really matter. The outcome is the same.
What this means for us
So there’s no way around it. You (!) have to take action yourself – bottom-up.
And chances are, you have more room to maneuver than you think.
Pick one problem that genuinely annoys you. A task that takes too long. A document nobody likes writing.
Find one or two allies at most, just enough to cover regulatory expertise, domain knowledge, and technical skills. That’s it.
Block four sessions of three hours within two weeks. Real blocks, no leftovers between meetings.
Run an experiment and see what happens when you unleash an AI on that issue. Not perfect, not aligned, not approved – just an experiment.
Measure the outcome. If it works, show it. If it doesn’t, you’ve invested 12 hours and learned a lot.
e. Final thoughts
I’m still seeking a partner for my summer project (unless I end up building the whole thing myself before then).
But one thing became clear this week: The companies that will lead in two years won’t be the biggest ones. They’ll be the ones where, at some point, someone simply decided to make things easier. And started.
Practical Tips
a. Consider what the LLM can actually know
Problem I tried to use AI to automatically assess design inputs – especially stakeholder and product requirements. What I got back was a messy mix of requirements. A complete jumble of requirement types.
Analysis And honestly, I’ve seen the same chaos in nearly every technical documentation I’ve reviewed so far:
User Needs
User Requirements
Customer Requirements
Regulatory requirements
Functional requirements
Product requirements
Product specifications
Everything mixed. No clear structure.
And that’s exactly the kind of data the AI has been trained on. So what are we expecting? That it magically untangles the mess?
Solution
It took me, together with Thomas Geis, an entire book ("Usability Engineering als Erfolgsfaktor" | German only) to really disentangle these distinctions. And it still takes me hours to teach these mental models to new team members.
That’s exactly what we need to do with AI as well. How else is it supposed to know?
The good news: Once you do this, the results improve significantly. My automated review of design inputs is now up and running.
b. Let the LLM derive the theory first
Problem
You ask your AI to complete a task – draft a document, review materials, whatever it may be. The AI delivers without hesitation.
But now you’re stuck with a different problem: You have to assess whether the results are correct and complete. In the worst case, this takes more time than doing the task yourself.
Analysis
Whenever you delegate work, whether to an LLM or to another person, the real challenge is defining clear success criteria, such as quality metrics. That’s why it often doesn’t happen. Or only happens after the results are already on the table.
Solution
Before asking your LLM to perform a task, first ask it to derive the relevant quality metrics and outline the underlying theory. This forces clarity about what you actually want.
Once you have that, you can brief both AI and humans much more precisely – and evaluating the results becomes significantly easier.
Best regards,
Christian
Founder Johner Institute
PS: In the latest podcast episode (German), my colleague Margarita Rozhdestvenskaya provides an overview of the requirements for different types of authorized representatives in the EU, Switzerland, the UK, or the US. Per usual, you can download an English transcript soon.
Upcoming seminars
Person Responsible for Regulatory Compliance according to Article 15 MDR
May 05, 2026 In this seminar, you will learn about the tasks and duties of the Person Responsible for Regulatory Compliance (PRRC) required by the MDR and IVDR and how to perform your new role in the company in accordance with the requirements.
As a US manufacturer, you are familiar with the FDA requirements in 21 CFR Part 820. But do you know what the new QMSR requires? What does harmonization with ISO 13485 mean? How much additional effort will you have to put in? The FDA does not tolerate deviations. In the worst case, your products could be banned from the market.
Learn how to solve this problem within two half-day sessions.
In this seminar, as a manufacturer of medical devices, you will learn about the regulatory requirements for IT security and data protection for medical devices and how to implement them professionally in your company.
