Die Zahl, an die sich gerade die halbe Branche klammert
Im Mai 2026 hat Benchling den Biotech AI Report 2026 veröffentlicht: n = 100, ausschließlich KI-Verantwortliche aus Biotech-Unternehmen, ehrliche Selbsteinschätzungen zur Frage „Warum scheitern unsere Pilotprojekte?“. Die meistzitierte Zahl: 55 Prozent nennen schlechte Datenqualität als Hauptgrund.
Die Zahl stimmt. Der naheliegende Schluss, „wir brauchen besseres Datenmanagement, also eine neue Datenplattform“, ist falsch, zumindest aber unvollständig. Wer ihn ungeprüft übernimmt, kauft eine Plattform und scheitert weiterhin.
Warum? Weil „Datenqualität“ in KI-Pilotprojekten der Pharmabranche zwei sehr verschiedene Dinge meint und die Branche sie systematisch verwechselt.
Was „Datenqualität“ wirklich heißt: zwei verschiedene Probleme
Wenn ein medizinalchemisches Team berichtet, „unser KI-Pilot ist an der Datenqualität gescheitert“, meint es normalerweise eines von zwei Dingen:
1. Datenqualität auf der Eingangsseite. Die Strukturdaten im internen ELN sind inkonsistent, SMILES stehen manchmal in Sondersyntax, Assay-Werten fehlen die Einheiten. Das ist ein klassisches Datenmanagement-Problem. Hier hilft eine Datenplattform. 2. Reproduzierbarkeit auf der Ausgangsseite. Der Agent liefert für dieselbe Frage in zwei Durchläufen unterschiedliche logP-Werte, ICH-M7-Einstufungen schwanken zwischen „high concern“ und „low concern“, Stabilitätsvorhersagen sind beim dritten Aufruf nicht mehr identisch mit dem ersten. Das ist kein Datenmanagement-Problem. Eine bessere Datenplattform behebt das nicht.
Beide Probleme werden in der Benchling-Umfrage unter „poor data quality“ zusammengefasst. Wer in einem Pharmaunternehmen mit GxP-Anspruch arbeitet, weiß: Das zweite Problem ist das, woran Pilotprojekte tatsächlich scheitern. Sie können die saubersten Eingabedaten der Welt haben; wenn Ihre validierungsrelevante Antwort beim 1.000. Aufruf anders aussieht als beim ersten, kommt das Projekt nie über den Machbarkeitsnachweis (PoC) hinaus.
Die drei echten Fehlermuster von Biotech-KI-Pilotprojekten
Aus den Erstgesprächen, die wir in den letzten zwölf Monaten zu gescheiterten Pilotprojekten geführt haben, kristallisieren sich drei Muster heraus. Keines ist in erster Linie ein Datenproblem:
1. Halluzination im Werteraum.
Der LLM-Agent erfindet plausible, aber falsche Zahlen: logP 2,3 statt 4,1, ein pKa von Pyridin „etwa 5“, wenn die richtige Antwort 5,23 lautet. Im akademischen Umfeld reicht „etwa“. Bei einer behördlichen Einreichung bedeutet ein um 1,8 Einheiten falscher logP, dass der Prüfer das Dossier beanstandet. Symptom: Pilotprojekte, die in der Demo glänzen und in der Validierung scheitern.
2. Fehlender Audit-Trail.
Der Agent liefert eine Antwort, drei Wochen später fragt jemand „Wie kam diese Antwort zustande?“, und niemand kann sie reproduzieren. Im Umfeld von EU-GMP-Annex 11 und 21 CFR Part 11 ist eine nicht reproduzierbare Antwort so gut wie keine Antwort. Symptom: Das Pilotprojekt wird aus der QA-Audit-Schleife genommen.
3. Inkonsistenz zwischen Durchläufen.
Gleiche Eingabe, andere Antwort. Bei einer Temperatur von 0 sollte ein LLM deterministisch sein, ist es aber nicht zwingend: Die Inferenz-Pipeline bringt Gleitkomma-Schwankungen mit, und viele „Tool-Calls“ sind in Wahrheit neue LLM-Inferenzen mit leicht verschobenem Kontext. Symptom: Das Validierungsprotokoll lässt sich nicht abschließen.
Was alle drei Fehlermuster verbindet: Sie sitzen nicht in den Eingabedaten, sondern in der Inferenzschicht. Eine bessere Datenplattform ändert daran nichts.
Wo die Lösung liegt: deterministische Tools statt LLM-Inferenz für Berechnungen
Die Architektur, die diese drei Fehlermuster adressiert, heißt nicht „mehr LLM“ oder „besseres Prompt-Engineering“. Sie besteht in der strikten Trennung zweier Schichten:
- LLM-Schicht: erzeugt Hypothesen, schlägt Arbeitsabläufe vor, interpretiert Ergebnisse, kommuniziert mit dem Nutzer. Hier ist Halluzination tolerierbar, weil ein Mensch in der Schleife sitzt.
- Tool-Schicht: führt deterministische Berechnungen aus. logP über RDKit, ICH-M7-Klassifikation über ein versioniertes (Q)SAR-Modell, Stabilität über Arrhenius-Kinetik. Hier ist Halluzination fatal, also wird sie technisch ausgeschlossen: Die Berechnung findet nicht im LLM statt, sondern in einer reinen Python-Funktion mit fest definierter Ein- und Ausgabe.
Als Idee ist das nicht neu. Neu seit 2024 ist, dass es dafür einen Standard gibt: das Model Context Protocol (MCP), spezifiziert von Anthropic und seit 2025 von Anthropic, OpenAI und großen Open-Source-Projekten gemeinsam gepflegt. MCP standardisiert die Schnittstelle, über die ein LLM-Agent diese deterministischen Tools aufruft.
Was das in Zahlen heißt
Wir haben das auf einem unabhängigen Benchmark gemessen: MolecularIQ vom Klambauer Lab (JKU Linz), 3.540 verifizierte Chemie-Aufgaben (arXiv:2601.15279). Vier aktuelle Spitzenmodelle:
- Claude Haiku 4.5: 21,2 % Genauigkeit ohne Tools, 85,4 % mit CovaSyn-MCP. 4,0-fache Steigerung.
- Claude Opus 4.7: 40,8 % → 91,5 %. 2,2-fach.
- OpenAI GPT-5.5: 22,3 % → 89,9 %. 4,0-fach.
- Gemini 3.5 Flash: 13,7 % → 75,7 %. 5,5-fach.
Die Steigerung ist nicht modellspezifisch. Sie kommt nicht daher, dass das neuere Modell mehr gelernt hat, sondern daher, dass die deterministische Tool-Schicht die Halluzination ausschaltet. Methodik und vollständige Zahlen unter /de/benchmark.
Bleiben wir bei Benchlings 55 %: Wer diesen Anteil halbiert, kann sich in der Branche profilieren. Wer ihn auf ein Drittel senkt, hat einen Wettbewerbsvorteil, den die anderen in den nächsten zwei Jahren nicht aufholen. Der Hebel dafür ist die deterministische Tool-Schicht, nicht die Datenplattform.
Konsequenz für die Planung von Pilotprojekten
Wenn Sie nächste Woche ein KI-Pilotprojekt in Ihrem Labor oder Ihrer CDMO planen, gilt diese Reihenfolge:
1. Legen Sie die zwei oder drei berechnungskritischen Schritte fest. Wo muss das Ergebnis reproduzierbar und auditfähig sein? In den meisten Pharma-Workflows sind das ICH-konforme Analysen, toxikologische Triage und Stabilitätsmodellierung. 2. Leiten Sie diese Schritte durch deterministische Tools, nicht durch das LLM. MCP-Server, spezialisierte Cheminformatik-Bibliotheken, intern entwickelte Python-Funktionen mit Testabdeckung: alles besser als „das LLM rechnet es einfach aus“. 3. Lassen Sie das LLM alles andere erledigen. Hypothesenbildung, Literaturrecherche, Synthesevorschläge, Ergebniskommunikation. Dort ist es stark, dort schadet Halluzination nicht. 4. Erst danach die Datenplattform. Stimmt die Architektur des Pilotprojekts, lohnt es sich, die Eingabedaten zu konsolidieren. Stimmt sie nicht, ist die Datenplattform die teuerste Notlösung.
Was wir konkret anbieten
CovaSyn ist genau diese deterministische Tool-Schicht für Pharma, Biotech und Chemie: Werkzeuge für NMR, MS, Stabilität, Toxikologie und mehr, MCP-kompatibel, mit Audit-Trail ab Werk. Drei Einstiegswege:
- Kostenloser Zugang zum Ausprobieren: der volle Werkzeugumfang, anbindbar an Claude Desktop, Cursor, VS Code oder Ihren eigenen Agenten, workspace.covasyn.com.
- Benchmark-Methodik zum Nachvollziehen: /de/benchmark.
- Selbst gehostete Variante, wenn Ihre IT-Sicherheit externes Hosting ausschließt: Details zum Chemie-MCP-Server für die Wirkstoffforschung.
Quellen
- Benchling Biotech AI Report 2026, n = 100 KI-Verantwortliche: Ankündigung auf LinkedIn. 55 % nennen Datenqualität als Hauptgrund für gescheiterte Pilotprojekte.
- Lingaro, State of AI Readiness in Pharma 2026, n = 150 Führungskräfte aus der europäischen Pharmaindustrie, Reuters Events Pharma 2026: Ankündigung auf LinkedIn. 50 % können KI nicht in den Produktivbetrieb überführen, nur 10 % gelten als „AI-ready“. Das bestätigt das Muster mit einer anderen Methodik.
- CovaSyn-Benchmark auf MolecularIQ (Klambauer Lab, JKU, arXiv:2601.15279): /de/blog/iclr-2026-molecular-iq-benchmark.
- KI-Forscher-Trio in Nature, 19. Mai 2026 (Robin, Co-Scientist, ERA): /de/blog/ai-scientist-mcp-tools-nature-2026.