AI in Laboratory Medicine: Build, Buy or Partner?

AI in laboratory medicine is already being implemented in very different ways across laboratories. Ask a group of laboratory directors and IT leads how they use AI today, and the answers are surprisingly varied. Some have built their own scripts, rule sets and analyses within laboratory IT. Others have purchased an AI module from their LIS vendor, an office copilot or a transcription solution. Others again are developing together with a partner. And a fourth group says openly: not at all yet – or only unofficially.

This fourth answer is the most revealing. “Not at all yet” rarely means that no AI is being used in the organization. It usually means that nobody has decided how it should be used. That is what this article is about: the question every laboratory will have to answer sooner or later – build, buy or partner?

The starting point is sobering across industries. According to an MIT study (“The GenAI Divide”, 2025), around 95 percent of enterprise GenAI pilots deliver no measurable impact on results. In January 2026, Gartner significantly raised its forecast for abandoned GenAI projects: at least half are discontinued after the proof of concept.

The causes Gartner identifies are telling: missing business value, data that is not ready, underestimated total cost of ownership, responsible AI as an afterthought, and weak change management. None of these is a technology problem. All of them are questions of implementation – and therefore exactly the questions behind the decision between build, buy and partner.

Build means in-house development – by laboratory IT, a university institute or contracted developers. The strengths are obvious: maximum fit, data sovereignty, know-how within the organization. The risks, however, are often underestimated: talent and operations must be secured permanently, individual projects quickly turn into script collections without a lifecycle – and anyone who develops software with a diagnostic intended purpose becomes a manufacturer in regulatory terms.

Buy means purchasing a finished product or SaaS solution. This promises fast time-to-value, predictable costs and a vendor who carries certification and further development. The price is limited adaptability, potential dependencies through proprietary formats and interface fees, and open questions about data outflow and processing location.

Partner means joint development on an existing platform – for example as co-innovation, as a managed open-source project, or as a pilot with clearly agreed goals. Here, the laboratory’s domain knowledge meets the partner’s technology and regulatory experience. Importantly, partnership is not a euphemism for purchasing. The difference lies in shared responsibility, a joint roadmap and genuine risk sharing. This requires clear governance – and an exit strategy.

In practice, most successful implementations are hybrids. The real question is therefore not “Which path?” but “Which path for which part?”

A helpful mental model places every use case along two axes: how strongly does the capability differentiate one’s own laboratory – and how close is it to the medical decision, and thus to MDR/IVDR and the AI Act?

• Low differentiation, low criticality: transcription, phone AI, translation, office copilots. Interchangeable and quickly available – buying standard solutions makes sense here.

• High differentiation, low criticality: referrer and portfolio management, custom rules, dashboards, analytics. It pays to shape these yourself – ideally on the interfaces of a stable platform, with tests and documentation.

• Low differentiation, high criticality: certified decision support, validation aids, report texts as a medical device. Ideally, the vendor carries the certification and the laboratory configures locally.

• High differentiation, high criticality: this is where laboratories can gain the most – and lose the most. Co-innovation with a partner who carries the regulatory burden is usually the most realistic path. In-house development requires dedicated QM and MDR expertise.

Or, put bluntly: whoever builds commodity in-house is investing in the wrong thing. Whoever only buys differentiation gives it away.

A second model comes from McKinsey and distinguishes takers, shapers and makers. Takers use AI products as they are. Makers train and operate their own models – with maximum differentiation, but also maximum responsibility, infrastructure and validation effort. In between are the shapers: they bring their own domain logic – SOPs, rule sets, reference ranges, referrer logic, their own knowledge base – into an existing platform without training a model of their own. For most laboratories, this is the sweet spot: taker for commodity, shaper for their own domain logic, maker only with a research mandate and a dedicated regulatory setup. A current trend fits this picture: organizations are buying finished applications more often again, while using several models in parallel. Models are becoming interchangeable – domain logic is not.

Translated into architecture, this results in a layered model with three levels:

1. A stable core – purchased or operated with a partner: core laboratory processes, certified decision support and a harmonized data model based on standards such as LOINC and FHIR. With direct access to one’s own data and no fees for using the interfaces.

2. A shared layer for everything that does not differentiate – device drivers, middleware, parsers, mappings. Developing these components jointly as open source creates transparency instead of a black box and prevents lock-in. They can be operated in-house – or purchased as a service.

3. Flexible extensions for one’s own differentiation – rule sets, workflows, dashboards via open APIs. What matters is that they are built as real software: with a lifecycle, tests and documentation, regardless of whether the laboratory, a partner or the vendor implements them.

Equally important is a seamless transition between configuration and code. Many laboratories today are stuck between classic LIS parameterization and an unofficial layer of Excel macros and scripts. What is missing is the level in between: customization by power users and medical informatics – rule sets, reflex testing, workflows – safeguarded by simulation and automated tests before a change goes live.

AI is also changing the calculation on the build side. With AI-assisted programming, often called “vibe coding”, small, specialized use cases suddenly become buildable. In-house development becomes more tempting. But costs do not disappear, they shift: from development to operations, maintenance and responsibility. A workaround without tests and documentation remains a risk – even if it can be generated in minutes today.

Sustainable extensions therefore require five foundations: clean APIs and extension points, stable core processes, clear governance and ownership, documentation as a prerequisite for maintainability and auditability – and sound process analysis that distinguishes genuine differentiation from unnecessary complexity. Perhaps the most valuable use of AI in development is a different one anyway: as a thinking partner for process variants, together with the people who know the work.

Then there is regulation. Anyone who develops software with a diagnostic intended purpose in-house takes on manufacturer obligations: a QM system, technical documentation, clinical evaluation, vigilance. The MDR‘s in-house exemption is subject to strict conditions and is no free pass. Those who buy remain operators – with their own obligations regarding intended purpose, training, data protection impact assessment and NIS2 risk management. A partnership requires a clear responsibility matrix: who certifies, who validates locally, who reports, who is liable? The AI Act grants time, but not indefinitely: transparency obligations already apply, and high-risk obligations for AI in medical devices take effect – as things currently stand – from August 2028.

Back to the fourth answer from the beginning. According to MIT, employees in more than 90 percent of companies use private AI tools for their work – while only around 40 percent have official licenses. IBM’s “Cost of a Data Breach Report 2025” puts the additional cost of a data breach involving shadow AI at around USD 670,000 on average; 63 percent of organizations do not yet have an AI governance policy.

In the laboratory, this means that report texts, discharge letters or patient data end up in consumer tools if no approved alternative exists. An early, secure purchase or partnership is therefore often the most effective governance measure. Security and privacy are the number one selection criterion – not a brake.

The risks themselves apply to all three paths: prompt injection via ingested documents and reports, patient data in prompts and logs, use of one’s own data to train third-party models, data outflow to providers outside the EU, dependencies through proprietary formats, unclear responsibilities, and black-box results that neither physicians nor auditors can follow. The difference lies in who demonstrates control: with build, the laboratory itself; with buy, the vendor – through contracts, certificates and audit rights; with partner, the jointly agreed responsibility matrix.

When it comes to the operating model, too, the question is not “cloud yes or no” but: which data may go where? On-premise offers full control but requires GPU infrastructure and operational know-how. Pure cloud solutions are fast, but call for a close look at processing location, sub-processors and cost development over five years. For many organizations, a hybrid approach is the pragmatic route: core logic and patient data stay in-house, and only anonymized text tasks go to a language model hosted in Germany or the EU.

Looking beyond the laboratory reveals the patterns. In 2024, Klarna replaced large parts of its customer service with AI – and returned to a hybrid model in 2025 because, according to its CEO, cost had been too dominant an evaluation factor. The lesson: the success metric is quality, not just cost and speed. IBM Watson Health was sold after billions in investment – among other reasons because data and workflow fit were missing. Domain knowledge cannot simply be bought.

In healthcare, build and partner turn out not to be contradictory. Mayo Clinic is developing its own model from de-identified data together with Microsoft – and retains ownership of it. At the University Medical Center Freiburg, more than 93 percent of discharge letters generated with a non-commercial language model were usable with minimal adjustments: differentiation through local adaptation of an open model, without any in-house model training. And large university AI institutes openly report that much research is being done, but too little reaches patient care – the transfer often fails because of regulation and operations.

Laboratory projects reveal patterns too. When a widely used integration engine switched from open source to a proprietary licensing model in 2025, many laboratories suddenly faced a strategic decision – and experienced how quickly dependencies become expensive. Open, laboratory-specific middleware is a kind of fourth path here: the exit option is preserved, while operations can still be purchased. The same applies to LIS modernization: instead of a risky big bang, modules for order entry, validation or analytics connect to the existing core via FHIR and LOINC. And contract models that tie payments to jointly defined goals turn a supplier into a partner – because both sides work towards measurable results.

Condensing these experiences reveals clear patterns. What fails: proofs of concept without an operating and funding concept, cost or speed as the only success metric, script collections without ownership, lock-in through proprietary middleware and interface fees, and black-box results that nobody trusts. And AI that comes before the data foundation fails: anyone who cannot answer what data exists, where it comes from and what it means will achieve little even with the best model – a topic we explored in more detail in our article on intelligent metadata management.

What works, on the other hand: starting small, with clear benefits and measurable goals. Choosing the right level – buy commodity, shape domain logic, keep the core stable. Defining ownership for every extension. Open standards such as FHIR, LOINC and SNOMED CT and data portability from day one. Keeping a human in the loop. And anchoring an exit strategy in the contract – the best insurance against lock-in.

1. At which level does the use case sit – tool, process or medical device?

2. Is the capability commodity or differentiation for us?

3. Who carries regulatory responsibility – manufacturer or operator?

4. Which class of data are we processing – and where may it be processed?

5. Is our data structured and described – with LOINC, FHIR and metadata?

6. What is the total cost over five years – operations, tokens, staff, certification?

7. Who is responsible for the lifecycle, tests, documentation and updates of the extension?

8. How do we measure success – quality, time, cost, acceptance?

9. How do we get out again – data portability, open interfaces, open source?

10. What happens if we do nothing?

The more answers point towards “high differentiation, high criticality, limited in-house capacity”, the more the partner path pays off.

Build, buy or partner is not an either-or decision. The level determines the answer: tools are bought, processes are shaped – alone or with a partner – and for medical devices, one either buys certified solutions or develops jointly with someone who can carry the regulatory responsibility. Security and privacy are not an obstacle but the most important selection criterion. And building faster does not mean building better: even in the age of AI-assisted development, extensions need interfaces, ownership, tests and documentation.

In the end, the most expensive option is not the wrong choice between build, buy and partner – it is making no choice at all. We look forward to exchanging ideas with everyone who is currently working through these questions for their laboratory or hospital – about successful approaches as well as projects that offered lessons to learn from.