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üfspur | Leitfrage | Mindestnachweis |
|---|---|---|
| Datenlage | Sind die Daten für den intended use verfügbar, integer und rechtlich nutzbar? | Dateninventar mit ALCOA+-Bewertung und Datenklasse |
| Use-Case-Portfolio | Ist der Use Case regulatorisch, technisch und wirtschaftlich priorisiert? | AI Use Case Inventory mit GxP-Impact |
| Governance | Wer entscheidet, prüft, validiert, betreibt und eskaliert? | Rollenmatrix und Freigabeweg |
| Rechtsprüfung | Welche AI-Act-, Datenschutz-, Vertrags- und IP-Fragen entstehen? | Legal Triage mit Rollen- und Datenprüfung |
| Kompetenzen | Sind 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:
- 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?
- Risikoklasse. Gibt es Anhaltspunkte für ein Hochrisiko-System, ein Transparenzrisiko oder eine verbotene Praktik?
- Datenschutz. Werden personenbezogene Daten verarbeitet, und tragen Rechtsgrundlage, Zweckbindung, Löschkonzept, Betroffenenrechte, Drittlandtransfer und Auftragsverarbeitung?
- Daten- und IP-Rechte. Dürfen Daten, Dokumente, SOPs, Studienunterlagen oder Lieferantendokumente für Training, Prompting, Tuning oder externe Analyse verwendet werden?
- Geheimnisschutz. Gelangen Geschäftsgeheimnisse, Herstellverfahren, Qualitätsdaten oder unveröffentlichte Zulassungsinformationen an Anbieter oder Modellbetreiber?
- 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.
| Stufe | Beschreibung | Typischer Nachweis |
|---|---|---|
| 1, verstreut | Einzelne Initiativen ohne gemeinsame Grundlage | Liste bekannter Tools oder Piloten |
| 2, koordiniert | Use Cases erfasst, erste Rollen benannt | AI Use Case Inventory und erste Governance |
| 3, kontrolliert | Daten, Recht, Risiko und Validierung sind pro Use Case bewertet | Risk Assessment, Legal Triage, Rollenmatrix |
| 4, skalierbar | Wiederholbarer Freigabe- und Betriebsprozess | SOPs, 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.