Alle Artikel
AI Pharma

KI-Readiness: fünf Prüfspuren vor dem ersten Use Case

KI-Readiness beschreibt die Fähigkeit einer Pharma-Organisation, KI-Anwendungen wiederholbar, rechtlich belastbar und GxP-konform in den Betrieb zu bringen. Entscheidend sind nicht einzelne Pilotprojekte, sondern fünf Prüfspuren: Datenlage, Use-Case-Portfolio, Governance, rechtliche Einordnung und Kompetenzen. Der Artikel zeigt die Nachweise vor dem ersten produktiven Use Case.

KI-Readiness beschreibt die Fähigkeit einer Organisation, KI-Anwendungen wiederholbar, rechtlich belastbar und GxP-konform in den Betrieb zu bringen. Für Pharma-Hersteller reicht dafür kein Toolzugang und kein isolierter Proof of Concept. Entscheidend ist, ob Daten, Use Case, Rollen, Rechtsgrundlage, Anbietersteuerung, Validierung und Schulung zusammenpassen.

Seit dem 02.02.2025 gelten die AI-Literacy-Pflichten aus Artikel 4 EU AI Act. Weitere Pflichten des EU AI Act werden gestaffelt anwendbar. Parallel bereiten EMA, ISPE und nationale Behörden die Einordnung von KI im regulierten Arzneimittelumfeld weiter aus. Eine Standortbestimmung vor Projektstart verhindert deshalb nicht nur technische Fehlstarts, sondern auch rechtliche und regulatorische Nacharbeit.

Readiness im GxP-Kontext

KI-Reife ist kein Reifegrad einer einzelnen Lösung. Sie beschreibt die Organisation. Eine Anwendung kann technisch gut funktionieren und trotzdem nicht freigabefähig sein, wenn Datenherkunft, Rollenmodell, Datenschutzprüfung, Validierungsstrategie oder menschliche Kontrolle fehlen.

Im GxP-Umfeld kommen drei Anforderungen zusammen. Erstens muss der intended use des Systems klar sein. Zweitens muss die Organisation zeigen, dass Risiken für Patientensicherheit, Produktqualität, Datenintegrität und regulatorische Aufzeichnung kontrolliert sind. Drittens muss die rechtliche Rolle feststehen: Betreiber, Anbieter, Auftragsverarbeiter, gemeinsamer Verantwortlicher oder Vertragspartner mit Zugriff auf vertrauliche Informationen.

Eine Readiness-Prüfung vor dem ersten produktiven Use Case schafft keine fertige Validierungsakte. Sie klärt aber, ob ein Projekt überhaupt in Richtung Betrieb geplant werden kann oder erst Grundlagen fehlen.

Fünf Prüfspuren

Die Standortbestimmung lässt sich in fünf Prüfspuren aufteilen. Jede Spur braucht eine fachliche Bewertung und ein einfaches Nachweisartefakt.

PrüfspurLeitfrageMindestnachweis
DatenlageSind die Daten für den intended use verfügbar, integer und rechtlich nutzbar?Dateninventar mit ALCOA+-Bewertung und Datenklasse
Use-Case-PortfolioIst der Use Case regulatorisch, technisch und wirtschaftlich priorisiert?AI Use Case Inventory mit GxP-Impact
GovernanceWer entscheidet, prüft, validiert, betreibt und eskaliert?Rollenmatrix und Freigabeweg
RechtsprüfungWelche AI-Act-, Datenschutz-, Vertrags- und IP-Fragen entstehen?Legal Triage mit Rollen- und Datenprüfung
KompetenzenSind die beteiligten Rollen für KI im Prozess befähigt?AI-Literacy- und Schulungsmatrix

Die Spuren sind nicht gleichrangig in jedem Projekt. Ein KI-Tool für interne SOP-Recherche stellt andere Anforderungen als ein Computer-Vision-System in der visuellen Inspektion. Die Struktur bleibt jedoch gleich: Jede Entscheidung muss auf denselben intended use zurückführbar sein.

Datenlage

Datenreife beginnt mit Verfügbarkeit, endet aber nicht dort. Für KI-Anwendungen im Pharma-Umfeld zählen Datenherkunft, Datenklasse, Vollständigkeit, Struktur, Kontext, Zugriffsrechte und Integrität. ALCOA+ bleibt der Prüfmaßstab, wenn Daten in GxP-Entscheidungen oder GxP-Aufzeichnungen einfließen.

Das Mindestartefakt ist ein Dateninventar pro Use Case. Es benennt Quelle, Owner, System, Datenformat, Aktualität, personenbezogene Daten, Geschäftsgeheimnisse, GxP-Relevanz und bekannte Qualitätslücken. Bei KI-Modellen kommen Trainingsdaten, Validierungsdaten, Betriebsdaten und Prompt-/Output-Protokolle hinzu.

Die rechtliche Dimension beginnt bereits hier. Daten dürfen technisch verfügbar sein und rechtlich trotzdem nicht für Training, Tuning oder externe Verarbeitung nutzbar sein. Datenschutz, Zweckbindung, Vertraulichkeitsverpflichtungen, Lizenzbedingungen und Rechte an Datenbankinhalten gehören deshalb in dieselbe Bewertung wie Datenqualität.

Use-Case-Portfolio

Ein AI Use Case Inventory verhindert, dass einzelne Abteilungen ihre KI-Initiativen nach Sichtbarkeit priorisieren. Jeder Use Case braucht eine kurze Beschreibung des intended use, der Prozessfunktion, der Datenbasis, der GxP-Relevanz, des erwarteten Nutzens und der Betriebsnähe.

Für Pharma reicht eine reine Nutzenmatrix nicht aus. Der Use Case muss nach regulatorischer Schwere eingeordnet werden: berührt er Produktqualität, Chargenfreigabe, Laborrohdaten, Pharmakovigilanz, klinische Daten, Regulatory Submissions oder nur administrative Recherche? Diese Einordnung bestimmt, ob eine einfache Governance-Freigabe genügt oder ein Validierungsdossier vorbereitet werden muss.

Rechtlich wird hier die AI-Act-Rolle sichtbar. Pharma-Hersteller sind bei zugekauften KI-Tools meist Betreiber im Sinne des EU AI Act. Bei Hochrisiko-Systemen kann eine Anbieterrolle entstehen, wenn das System unter eigenem Namen bereitgestellt, wesentlich verändert oder in seiner Zweckbestimmung geändert wird (Art. 25 EU AI Act). Diese Prüfung gehört in die Readiness-Phase, nicht erst in die Vertragsprüfung.

Governance

Governance klärt, welche Instanz einen Use Case von der Idee in Pilot, Validierung und Betrieb überführt. Ohne diese Entscheidung bleibt ein KI-Projekt im Pilotstatus, auch wenn die technische Lösung funktioniert.

Eine belastbare Rollenmatrix enthält mindestens Fachbereich, QA, IT-Validation, Regulatory Affairs, Datenschutz, Informationssicherheit, Legal, Data Owner, System Owner und Lieferantenmanagement. Nicht jede Rolle entscheidet in jedem Use Case. Aber jede Rolle muss wissen, wann sie eingebunden wird.

Für GxP-nahe KI ist die Freigabekette besonders wichtig. Der Fachbereich beschreibt den Prozessnutzen. QA bewertet Produktqualitäts- und Auditrisiko. IT-Validation bewertet Systemklasse, Teststrategie und Betriebsnachweis. Regulatory Affairs prüft, ob externe Dokumentation, Variation, Submission oder Behördenkommunikation berührt sind. Legal und Datenschutz prüfen Rollen, Verträge, Datenflüsse und Schutzrechte.

Rechtsprüfung

Die rechtliche Prüfung ist keine Schlusskontrolle am Ende des Projekts. Sie gehört in die frühe Readiness-Phase, weil rechtliche Grenzen den Use Case verändern können.

Sechs Fragen reichen für die erste Triage:

  1. AI-Act-Rolle. Ist das Unternehmen Betreiber, Anbieter, Importeur, Distributor oder Produktintegrator, und kann bei Hochrisiko-Systemen eine Rollenverschiebung nach Artikel 25 EU AI Act entstehen?
  2. Risikoklasse. Gibt es Anhaltspunkte für ein Hochrisiko-System, ein Transparenzrisiko oder eine verbotene Praktik?
  3. Datenschutz. Werden personenbezogene Daten verarbeitet, und tragen Rechtsgrundlage, Zweckbindung, Löschkonzept, Betroffenenrechte, Drittlandtransfer und Auftragsverarbeitung?
  4. Daten- und IP-Rechte. Dürfen Daten, Dokumente, SOPs, Studienunterlagen oder Lieferantendokumente für Training, Prompting, Tuning oder externe Analyse verwendet werden?
  5. Geheimnisschutz. Gelangen Geschäftsgeheimnisse, Herstellverfahren, Qualitätsdaten oder unveröffentlichte Zulassungsinformationen an Anbieter oder Modellbetreiber?
  6. Vertrag und Haftung. Decken Vertrag, SLA, Audit-Rechte, Subprozessoren, Supportzugriffe, Output-Nutzung, Gewährleistung und Exit die geplante Nutzung ab?

Diese Triage ersetzt keine Detailprüfung. Sie entscheidet, ob ein Use Case in die technische Bewertung gehen kann oder zuerst Vertrag, Datenschutzfolgeabschätzung, Anbieterunterlagen oder Datennutzungsrechte geklärt werden müssen.

Kompetenzen

Artikel 4 EU AI Act verlangt AI Literacy für Anbieter und Betreiber. Für Pharma-Hersteller entsteht daraus eine rollenbezogene Schulungsfrage. Ein generisches KI-Training belegt Grundwissen, aber nicht die Fähigkeit, KI in einem validierten Prozess zu nutzen.

Die Readiness-Prüfung ordnet Kompetenzen pro Rolle zu. QA braucht ein anderes Kompetenzprofil als Produktion, Labor, IT-Validation, Regulatory Affairs, Pharmakovigilanz oder Legal. Entscheidend ist, ob die Rolle Risiken erkennt, Grenzen des Systems versteht, Review-Barrieren einhält und Eskalationen auslöst.

Das Mindestartefakt ist eine AI-Literacy-Matrix. Sie verweist auf Schulungsmodule, SOPs, Use Cases, Systemrollen und Auffrischungstrigger. Neue KI-Funktionen, Modellupdates, geänderte Datenbasis, neue Anbieter oder neue regulatorische Vorgaben lösen eine erneute Schulungsbewertung aus.

Reifegradmodell

Vier Stufen machen die nächste Maßnahme klar erkennbar.

StufeBeschreibungTypischer Nachweis
1, verstreutEinzelne Initiativen ohne gemeinsame GrundlageListe bekannter Tools oder Piloten
2, koordiniertUse Cases erfasst, erste Rollen benanntAI Use Case Inventory und erste Governance
3, kontrolliertDaten, Recht, Risiko und Validierung sind pro Use Case bewertetRisk Assessment, Legal Triage, Rollenmatrix
4, skalierbarWiederholbarer Freigabe- und BetriebsprozessSOPs, Templates, Monitoring, Schulungsmatrix

Ein Unternehmen kann in Datenlage auf Stufe 2 und bei Governance auf Stufe 1 stehen. Die niedrigste relevante Stufe begrenzt den nächsten produktiven Use Case. Genau darin liegt der Wert der Standortbestimmung.

30-Tage-Readiness-Sprint

Ein Readiness-Sprint muss eng bleiben. Ziel ist kein vollständiges KI-Programm, sondern eine belastbare Entscheidung über die nächsten Use Cases und die fehlenden Grundlagen.

Tag 1 bis 10: Inventar. Alle bekannten KI-Tools, Piloten und geplanten Use Cases erfassen. Pro Eintrag intended use, Fachbereich, Datenquelle, Anbieter, GxP-Bezug und rechtliche Auffälligkeiten dokumentieren.

Tag 11 bis 20: Bewertung. Die fünf Prüfspuren bewerten. Dateninventar, GxP-Impact, AI-Act-Rolle, Datenschutzbedarf, Anbieterzugriff, Validierungsbedarf und Kompetenzbedarf je priorisiertem Use Case festhalten.

Tag 21 bis 30: Entscheidung. Drei Listen erstellen: freigabefähige Use Cases, Use Cases mit Vorbedingungen und Use Cases mit Stop-Kriterium. Dazu eine Roadmap für Datenbereinigung, Governance, Rechtsprüfung, Anbieterunterlagen, Validierung und Schulung.

Das Ergebnis ist eine Management-Entscheidung mit Auditspur. Sie zeigt, warum ein Use Case starten darf, warum ein anderer warten muss und welche Grundlagen vor dem produktiven Einsatz fehlen.