Datenfundament und Betrieb für Forschungsdaten

Die meisten KI-Vorhaben in der Forschung scheitern nicht am Modell. Sie scheitern daran, dass die Daten nicht auffindbar sind, die Auswertung nicht wiederholbar ist und niemand den Prototypen betreiben kann. Wir bauen das Fundament, auf dem Modelle überhaupt aufsetzen können.

Ausgangslage

Forschungsdaten entstehen dezentral: in ELN und LIMS, in Geräteexporten, in Tabellen auf Netzlaufwerken, in Auswertungen einzelner Forschender. Jede Quelle hat ihre eigene Nomenklatur, und dieselbe Substanz, dasselbe Assay und dieselbe Zelllinie tragen in drei Systemen drei Bezeichnungen.

Darunter leidet nicht nur die KI. Betroffen ist auch die Nachvollziehbarkeit: Eine Auswertung, die nach zwei Jahren nicht mehr rekonstruiert werden kann, ist für eine Publikation und für eine regulatorische Einreichung gleichermaßen wertlos. Und die Wirtschaftlichkeit leidet, weil derselbe Aufbereitungsaufwand in jedem Projekt neu anfällt.

Typische Datengrundlage

Exporte aus ELN und LIMS, Gerätedaten, gewachsene Tabellenbestände, dazu die Referenzsysteme, gegen die normalisiert wird – etablierte Ontologien für Substanzen, Assays und Zelllinien.

Woran solche Vorhaben scheitern

Das vollständige Datenmodell zuerst. Achtzehn Monate Modellierung, kein nutzbares Zwischenergebnis, und irgendwann fragt jemand nach dem Nutzen. Wer nicht nach wenigen Monaten eine beantwortbare Frage vorweisen kann, verliert die Finanzierung, bevor die Basis steht.

Normalisierung ohne Zuständigkeit. Ontologie-Abgleich wird einmalig als Projekt durchgeführt und danach von niemandem gepflegt. Innerhalb eines Jahres divergieren die Bezeichnungen wieder, und der Aufwand fällt erneut an. Ohne benannte Zuständigkeit und einen Pflegeprozess ist FAIR ein Zustand von kurzer Dauer.

Monitoring ohne Empfänger. Eine Pipeline läuft im Betrieb, aber niemand im Fachbereich ist zuständig. Die erste Schemaänderung im Quellsystem bricht sie, die Warnmeldung landet in einem Postfach, das keiner liest. Drei Monate später arbeitet jemand mit veralteten Zahlen weiter.

Vorgehen

Vom Anwendungsfall her strukturieren, nicht vom Datenmodell. Wir beginnen mit den Fragen, die die Datenbasis beantworten soll. Ein vollständiges Datenmodell, das niemand nutzt, ist teurer als eine unvollständige Struktur, die trägt.

Bezeichnungen gegen Standards normalisieren. Erst wenn Substanzen, Assays und Zelllinien gegen Ontologien abgeglichen sind, werden Datensätze verknüpfbar, und erst dann ist das F in FAIR mehr als eine Absichtserklärung.

Reproduzierbarkeit in die Infrastruktur einbauen. Pipelines in etablierten Workflow-Systemen, containerisierte Werkzeuge, fixierte Versionen, versionierte Datensätze. Damit bleibt eine Auswertung Jahre später nachvollziehbar, ohne dass sich jemand erinnern muss.

Betrieb von Anfang an mitdenken. Monitoring, Retraining-Strategie, Drift-Erkennung, dokumentierte Modellstände. Der Übergang vom Prototypen in den Betrieb ist der Punkt, an dem die meisten Vorhaben stehenbleiben; wir behandeln ihn als Teil des Projekts, nicht als Anschlussthema.

Regulatorik als Architekturfrage. In der frühen Forschung greifen GxP-Anforderungen nicht; dort arbeiten wir eigenständig und schnell. Berührt eine Anwendung regulierte Prozesse, liefern wir die Dokumentation, die Ihre Validierung benötigt; die Systemvalidierung selbst verbleibt bei Ihnen.

Was dabei entsteht

Eine verknüpfte, abfragbare Datenbasis statt getrennter Quellen, reproduzierbare Auswertungspipelines, Monitoring im Betrieb und eine Dokumentation, die einem Audit standhält – inklusive der Nachweise, die für den EU AI Act relevant werden.