Warum eine lokale KI-Gießerei und welche GxP-Änderungen

Teil 1 von 6. Der Serienindex mit Links zu jedem veröffentlichten Teil ist Teil 0: Einführung und Serienübersicht. Diese Reihe richtet sich an die Personen, die sich für gemeinsame KI-Fähigkeiten in einer regulierten Life-Sciences-Organisation einsetzen müssen: Architekturleiter, CTOs und VPs der Technik sowie ihre Partner in den Bereichen Qualität, Validierung und Sicherheit. Es wird davon ausgegangen, dass Sie wissen, was ein Sprachmodell und ein Vektorindex sind. Grundlegende Begriffe werden im Glossar am Ende der Serie definiert. Der regulatorische Status gilt ab September 2026 und wird sich ändern. Dies ist ein technischer Leitfaden, keine Rechtsberatung.

Das Problem, das diese Serie löst

Die meisten Life-Science-Softwareunternehmen starten KI auf die gleiche Weise. Ein Produktteam nennt ein gehostetes Modell. Ein anderer wählt ein anderes Modell. Ein Drittel baut seine eigene Abrufpipeline auf. Jedes Team trifft eine sinnvolle lokale Entscheidung. Die Organisation steht vor einem Problem, das niemand gewählt hat.

Die Symptome sind vorhersehbar.

• Dokumente werden in mehrere Indizes kopiert und die Kopien weichen von den genehmigten Versionen im Dokumentenmanagementsystem ab.
• Zugriffsregeln werden von einigen Integrationen erzwungen und von anderen nicht, sodass derselbe Benutzer unterschiedliche Antworten auf die Frage „Darf ich das sehen?“ erhält.
• Eingabeaufforderungen sind im Code, in Tabellenkalkulationen und in Chatverläufen enthalten, und niemand kann sagen, welche Eingabeaufforderung die Ausgabe des letzten Monats erzeugt hat.
• Es gibt keine gemeinsame Bewertungsgrundlage, daher sind „das Modell wurde besser“ und „das Modell wurde schlechter“ Meinungen und keine Messungen.
• Jede Integration führt ihre eigenen Protokolle, in ihrem eigenen Format, mit ihrer eigenen Aufbewahrungsfrist oder ohne.

In einer GxP-Umgebung sind dies keine technischen Ärgernisse. Es sind Inspektionsergebnisse, die darauf warten, umgesetzt zu werden. Ein Prüfer, der eine von der KI erstellte Abweichungszusammenfassung sieht, wird eine Reihe von Fragen stellen. Welche Version der Prozedur hat das System gelesen? Wer durfte es sehen? Welches Modell und welche Eingabeaufforderung erzeugten den Text? Was hat sich seit der Validierung des Systems geändert? Wer hat die Ausgabe überprüft, bevor sie in das Protokoll aufgenommen wurde? Ein Ad-hoc-Nachlass kann diese Fragen nicht konsistent beantworten, und eine inkonsistente Antwort ist schlimmer als keine Antwort.

Es gibt Belege dafür, dass sich der Ad-hoc-Weg selten lohnt, selbst außerhalb regulierter Arbeit. Eine MIT-Studie aus dem Jahr 2025 zur generativen KI in Unternehmen, die auf einer Umfrage unter 153 Führungskräften, 52 Interviews mit Führungskräften und einer Analyse von mehr als 300 öffentlichen Einsätzen basiert, ergab, dass etwa 95 Prozent der Pilotprojekte keine messbaren Auswirkungen auf Gewinn und Verlust hatten [16]. Die Studie macht eine Lernlücke und eine schwache Integration in reale Arbeitsabläufe verantwortlich, nicht die Modellqualität. Die Gewinner waren schmale Back-Office-Systeme, die in einen bestehenden Prozess passten, und Organisationen, die mit Spezialisten zusammenarbeiteten, waren etwa doppelt so erfolgreich wie diejenigen, die alleine bauten [16]. Ein RAND-Bericht aus dem Jahr 2024 stellt fest, dass Schätzungen zufolge mehr als 80 Prozent der KI-Projekte scheitern, doppelt so häufig wie bei anderen IT-Projekten. Aus 65 Interviews mit Datenwissenschaftlern und -ingenieuren werden fünf Hauptursachen identifiziert: ein missverstandenes Problem, unzureichende Daten, die Jagd nach der Technologie statt nach dem Ergebnis, zu geringe Investitionen in die Bereitstellungsinfrastruktur und Probleme, die über die Möglichkeiten der aktuellen KI hinausgehen [17]. Die meisten dieser Ursachen sind organisatorischer Natur, und eine Plattform ist eine organisatorische Antwort.

Eine lokale KI-Foundry ist diese Antwort. Es handelt sich um eine gemeinsam genutzte, selbst gehostete Plattform, die Modelle, Abruf, Richtliniendurchsetzung, Bewertung, Prüfung und Betrieb für jedes Produkt bereitstellt und gleichzeitig die Daten, Berechtigungen, Eingabeaufforderungen und Qualitätsschwellenwerte jedes Produkts isoliert hält. Produktteams nutzen eine kleine, stabile API. Das Plattformteam ist für die Kontrollen verantwortlich, nach denen die Inspektoren fragen.

Die Aufteilung der Verantwortlichkeiten ist der Kern der Idee.

Das Wort „Gießerei“ ist bewusst. Eine Gießerei entscheidet nicht, was gegossen wird. Es garantiert, dass alles, was gegossen wird, einem Standard entspricht.

Was „lokal“ hier bedeutet

„Lokal“ hat in dieser Serie eine genaue Bedeutung.

• Selbstgehostet. Modelle, Indizes, Eingabeaufforderungen und Protokolle werden auf der von der Organisation kontrollierten Infrastruktur ausgeführt.
• Air-Gap-fähig. Die Plattform muss ohne ausgehende Konnektivität funktionieren. Modellgewichtungen, Container und Abhängigkeiten werden einmal eingebracht und durch Änderungskontrolle aktualisiert.
• Souverän. Keine Eingabeaufforderung, kein Dokumentabschnitt oder keine Ausgabe verlässt die Grenze, es sei denn, eine dokumentierte Entscheidung erlaubt dies.

Warum so weit gehen? Dafür gibt es vier Gründe, und nur einer davon betrifft die Daten, die das Gebäude verlassen.

Validierter Zustand. Ein computergestütztes GxP-System wird für seine beabsichtigte Verwendung validiert und dann in diesem Zustand gehalten [2][10]. Ein gehostetes Modell, das sich unter Ihnen durch ein stilles Versionsupdate ändert, unterbricht diesen Zustand, ohne dass Sie eine Änderungsanfrage stellen müssen. Eine lokal angeheftete Modellversion ändert sich nur, wenn Sie dies durch Änderungskontrolle und mit Beweisen entscheiden.

Überprüfbarkeit. Teil 11 und Anhang 11 erwarten, dass Prüfprotokolle, Zugriffskontrolle und Datenaufbewahrung unter Ihrer Kontrolle stehen [8][10]. Dies lässt sich viel einfacher nachweisen, wenn die Protokolle, Eingabeaufforderungen und der abgerufene Text in von Ihnen verwalteten Systemen gespeichert werden.

Verantwortung der Lieferanten. Im Entwurf von Anhang 22 heißt es, dass die Verantwortung für die KI-Ausgaben beim regulierten Unternehmen verbleibt, und Anhang 11 sieht eine Aufsicht über Lieferanten und Dienstleister vor [10]. Sie können diese Aufsicht nur über Komponenten ausüben, die Sie inspizieren und fixieren können.

Kostenvorhersagbarkeit. Bei der nutzungsabgerechneten Inferenz handelt es sich um variable Kosten, die davon abhängen, wie Menschen das System nutzen. Eigene oder geleaste Hardware bei regelmäßiger Auslastung ist ein bekannter Kostenfaktor. Teil 6 kehrt zu den Zahlen zurück.

Hybride Designs sind möglich und die Regulierungsbehörden verbieten die Cloud nicht. Die Assurance-Richtlinien der FDA decken explizit Cloud-Modelle wie Software as a Service, Platform as a Service und Infrastructure as a Service ab, wenn sie für die Produktion oder Qualitätssystemarbeit verwendet werden, und skalieren die Assurance auf die beabsichtigte Verwendung und das Risiko [3]. Der Punkt ist nicht, dass die Cloud verboten ist. Der Punkt ist, dass eine nicht regulierte Arbeitslast, eine Entwicklungsumgebung oder ein Experiment mit synthetischen Daten möglicherweise auf gemieteter Kapazität ausgeführt wird, während alles, was GxP-Daten oder GxP-Entscheidungen berührt, standardmäßig innerhalb der Grenze läuft. Jede Ausnahme ist eine aufgezeichnete Entscheidung, keine Bequemlichkeit.

Drei Tests trennen „lokal“ von „lokal installiert“.

1. Der ausgehende Test. Blockieren Sie den gesamten ausgehenden Netzwerkverkehr von der Plattform. Funktioniert noch jede Funktion? Ein Tool, das einen gehosteten Endpunkt für Einbettungen, Moderation, Lizenzprüfungen oder Telemetrie aufruft, besteht diesen Test nicht.
2. Der Update-Test. Können Sie ein neues Modell, einen neuen Container oder eine neue Abhängigkeit von Medien, die Sie eingebracht haben, über Ihre eigene Änderungskontrolle installieren, ohne dass der Server des Anbieters erreichbar ist?
3. Der Abhängigkeitstest. Verfügen Sie über eine Stückliste für jedes Modell, jeden Container und jede Bibliothek auf der Plattform, sodass eine Schwachstellenmeldung auf das zurückgeführt werden kann, was Sie tatsächlich ausführen?

Teil 6 wendet diese Tests auf reale Werkzeuge an.

Was sich „reguliert“ ändert

Reguliert bedeutet nicht, am Ende eine Compliance-Checkliste hinzuzufügen. Es verändert das Design. Die Tabelle ordnet die für Pharma- und Medizingeräteunternehmen wichtigen Rahmenbedingungen den jeweiligen Anforderungen an die Plattform zu. In den Absätzen nach der Tabelle werden diejenigen erläutert, die die Architektur am stärksten beeinflussen.

GAMP 5 und der GAMP AI Guide. GAMP 5 ist kein Gesetz. Es handelt sich um die branchenübliche Standardmethode zur Validierung computergestützter Systeme im GxP-Bereich, und die Inspektoren sind damit bestens vertraut. Die 2022 veröffentlichte zweite Ausgabe fügte einen Anhang zu KI und maschinellem Lernen hinzu. Im Juli 2025 veröffentlichte ISPE einen eigenständigen KI-Leitfaden, der parallel dazu verwendet werden soll [1][2]. Der KI-Leitfaden deckt den KI-Lebenszyklus vom Konzept bis zur Außerbetriebnahme ab, enthält Anhänge zum Lieferantenmanagement und zu Quality by Design, berücksichtigt ISPEs Aufzeichnungen und Leitlinien zur Datenintegrität und berücksichtigt ausdrücklich ISO/IEC 42001 [1]. Der Schwerpunkt liegt auf dem gleichen Niveau wie bei der zweiten Ausgabe: Patientensicherheit, Produktqualität, Datenintegrität und kritisches Denken statt Ankreuzen von Kästchen. Für einen Architekten ist die praktische Botschaft einfach. KI-gestützte Systeme sind validierte Systeme, und der Validierungslebenszyklus muss die Modelle und die Daten abdecken, nicht nur den Code.

FDA Computer Software Assurance. Im September 2025 stellte die FDA ihre CSA-Leitlinien für Software zur Verwendung in Geräteproduktions- und Qualitätssystemen fertig und ersetzte Abschnitt 6 ihrer Softwarevalidierungsleitlinien aus dem Jahr 2002 [3][4]. Der Ansatz ist risikobasiert und am wenigsten belastend. Sie identifizieren die beabsichtigte Verwendung jeder Softwarefunktion, bewerten deren Risiko für die Patientensicherheit und Produktqualität und wählen die entsprechenden Sicherungsaktivitäten aus: skriptbasierte Tests, wenn das Risiko hoch ist, nicht skriptbasierte oder explorative Tests, wenn das Risiko geringer ist, kontinuierliche Überwachung als fortlaufende Evidenz und Lieferantenevidenz, sofern vorhanden [3]. Dies gilt sowohl für On-Premises- als auch für Cloud-Software und gilt nicht für Software, die selbst ein medizinisches Gerät ist [3]. Sein formaler Anwendungsbereich sind Geräte, aber der Ansatz ist auch zum gemeinsamen Vokabular für Pharma-Qualitätsteams geworden, da GAMP 5 bereits in die gleiche Richtung geht. Teil 4 baut darauf den Validierungsansatz auf.

Der Entwurf des Glaubwürdigkeitsrahmens der FDA. Der Leitlinienentwurf der FDA vom Januar 2025, der im September 2026 noch ein Entwurf ist, schlägt einen siebenstufigen Rahmen zur Feststellung der Glaubwürdigkeit eines KI-Modells für einen bestimmten Nutzungskontext vor [5]. Die Schritte sind: Definieren der interessierenden Frage; den Nutzungskontext definieren; das Modellrisiko als Funktion des Modelleinflusses und der Entscheidungskonsequenz bewerten; einen Plan entwickeln, um Glaubwürdigkeit herzustellen; den Plan ausführen; die Ergebnisse und etwaige Abweichungen dokumentieren; und stellen Sie fest, ob das Modell für den Nutzungskontext geeignet ist [5]. Im Entwurf geht es um KI, die zur Unterstützung regulatorischer Entscheidungen für Medikamente und Biologika eingesetzt wird, nicht um jedes Geschäftsinstrument. Aber seine beiden zentralen Ideen, Nutzungskontext und Risiko als Einfluss multipliziert mit Konsequenzen, sind die sauberste Art, über KI-Funktionen in einem regulierten Produkt nachzudenken. Diese Serie verwendet sie durchgehend.

Die gemeinsamen Grundsätze von FDA und EMA. Im Januar 2026 veröffentlichten die beiden Behörden zehn unverbindliche Grundsätze für gute KI-Praxis in der Arzneimittelentwicklung, aufbauend auf dem Reflexionspapier der EMA von 2024 [6][15]. Sie umfassen menschenzentrierte Werte, die Einhaltung von Standards, einen risikobasierten Ansatz, einen klaren Nutzungskontext, Datenverwaltung, multidisziplinäres Fachwissen, Lebenszyklusmanagement, Transparenz, menschliche Aufsicht und internationale Zusammenarbeit [6]. Für einen GAMP-Praktiker ist das alles nichts Neues. Entscheidend ist, dass die beiden größten Regulierungsbehörden nun in einem Dokument dasselbe sagen.

Aufzeichnungen und Datenintegrität. 21 CFR Part 11 erfordert sichere, computergenerierte, mit Zeitstempel versehene Prüfprotokolle, die Datum und Uhrzeit von Bedienereingaben und -aktionen aufzeichnen, die elektronische Aufzeichnungen erstellen, ändern oder löschen, und die mindestens so lange aufbewahrt werden, wie die Aufzeichnungen selbst [8]. Die Richtlinien zur Datenintegrität der FDA legen ALCOA+ fest: Aufzeichnungen müssen zuordenbar, lesbar, aktuell, originell und genau sowie vollständig, konsistent, dauerhaft und verfügbar sein [9]. In der EU stellt Anhang 11 ähnliche Erwartungen an computergestützte Systeme, und PIC/S PI 041 gibt Inspektoren eine gemeinsame Sicht auf die Datenintegrität in GMP- und GDP-Umgebungen [10][24]. Für eine KI-Plattform wirft dies eine Frage auf, die sich die meisten Teams noch nicht gestellt haben. Wenn eine KI-Ausgabe eine GxP-Entscheidung beeinflusst, ist die Ausgabe selbst ein Datensatz? Die sichere Antwort ist ja. Teil 2 entwirft dafür.

Anhang 22, der Entwurf, der am wichtigsten ist. Im Juli 2025 eröffnete die Europäische Kommission eine Konsultation zu einem überarbeiteten Kapitel 4, einem überarbeiteten Anhang 11 und einem neuen Anhang 22 zu KI in der GMP, die mit der Arbeitsgruppe der EMA- und PIC/S-Inspektoren erstellt wurden [10]. Die Konsultation endete am 7. Oktober 2025 mit rund 1.300 Kommentaren. Mit Stand September 2026 sind alle drei Texte noch Entwürfe, der Arbeitsplan der EMA sieht einen endgültigen Text für Ende 2026 vor, und es wurde kein Datum für das Inkrafttreten bekannt gegeben [10]. Der Anwendungsbereich des Entwurfs ist KI in kritischen GMP-Anwendungen, also solchen mit direktem Einfluss auf die Patientensicherheit, Produktqualität oder Datenintegrität. Seine zentrale Aussage ist, dass dynamische Modelle, Modelle, die unterschiedliche Ausgaben für identische Eingaben zurückgeben können, generative KI und LLMs in diesen kritischen Anwendungen nicht verwendet werden sollten [10]. Für die statischen Modelle, die es zulässt, werden ein definierter Verwendungszweck, Validierungsdaten, die reale Betriebsbedingungen darstellen, Erklärbarkeit, Konfidenzschwellen (sofern zutreffend), menschliche Aufsicht, Änderungskontrolle und laufende Leistungsüberwachung erwartet [10]. Es ermöglicht generative KI in unkritischen Anwendungen, wie der Zusammenfassung eines Abweichungsberichts oder Suchverfahren, wenn eine qualifizierte Person die Ausgabe überprüft und die dokumentierte Verantwortung behält. Und es wird ausdrücklich darauf hingewiesen, dass die Verantwortung beim regulierten Unternehmen und nicht beim Lieferanten liegt. Die EMA veranstaltete am 30. Juni und 1. Juli 2026 einen Workshop, um zu prüfen, ob adaptive und generative Modelle im Rahmen risikobasierter Schutzmaßnahmen behandelt werden könnten, der veröffentlichte Text hat sich jedoch nicht geändert [10]. Eine umsichtige Plattform behandelt den Entwurf jetzt als Designrichtlinie. Wenn der endgültige Text die Regel lockert, geht nichts verloren. Ist dies nicht der Fall, ist die Plattform bereits ausgerichtet.

Das EU-KI-Gesetz in der geänderten Fassung. Das KI-Gesetz trat im August 2024 in Kraft. Im Juli 2026 wurde es vom Digital Omnibus on AI geändert und der Zeitplan geändert [11][12]. Transparenzpflichten gemäß Artikel 50, wie etwa die Mitteilung an Personen, dass sie mit KI interagieren, und die Kennzeichnung generierter Inhalte in maschinenlesbarer Form, gelten seit dem 2. August 2026, mit einer Schonfrist bis zum 2. Dezember 2026 für bereits auf dem Markt befindliche Systeme [12]. Die Hochrisikopflichten gelten nun ab dem 2. Dezember 2027 für in Anhang III aufgeführte eigenständige Systeme und ab dem 2. August 2028 für KI, die in Produkte eingebettet ist, die unter das EU-Produktrecht gemäß Anhang I fallen, wie beispielsweise Medizinprodukte [12]. Systeme, die vor diesem Datum auf den Markt gebracht werden, unterliegen dem Bestandsschutz, es sei denn, sie unterliegen einer wesentlichen Designänderung und der Schwellenwert für „erheblich“ ist noch nicht definiert [12]. Für ein Qualitätssystem oder einen Dokumentenassistenten sind die beiden plausiblen Hochrisikofaktoren die Arbeitskräfteverwaltung gemäß Anhang III, beispielsweise wenn das System Aufgaben zuweist oder die Leistung überwacht, und die Tatsache, dass es sich um eine Sicherheitskomponente eines Medizinprodukts gemäß Anhang I handelt [11]. Bei den meisten Qualitätssystemassistenten besteht kein hohes Risiko. Die Einstufung muss jedoch dokumentiert werden und es gelten unabhängig davon die Pflichten zur KI-Kenntnisse nach Artikel 4 und die Transparenzpflichten nach Artikel 50. Teil 5 befasst sich mit der Klassifizierung.

Datenschutz. Indiens Gesetz zum Schutz digitaler personenbezogener Daten von 2023 wurde durch die im November 2025 mitgeteilten DPDP-Regeln in Kraft gesetzt, wobei die Verpflichtungen schrittweise bis 2027 eingeführt werden [13]. Die Organisation, die über den Zweck und die Mittel der Verarbeitung entscheidet, ist ein Datentreuhänder, und dazu gehört auch die Schulung oder der Einsatz von KI für personenbezogene Daten. Die Meldung von Verstößen erfolgt in zwei Schritten: unverzügliche Benachrichtigung des Datenschutzausschusses, anschließende Einreichung eines detaillierten Berichts innerhalb von 72 Stunden und Benachrichtigung betroffener Personen ohne Wesentlichkeitsschwelle [13]. Bei Verstößen gegen angemessene Sicherheitsvorkehrungen drohen Strafen von bis zu ₹250 crore [13]. In Europa tätige Organisationen wenden die DSGVO an, einschließlich ihrer Regeln zu automatisierten Entscheidungen und Folgenabschätzungen. Teil 5 befasst sich mit der Privatsphäre innerhalb der Plattform.

Managementstandards. ISO/IEC 42001:2023 definiert ein KI-Managementsystem, das zertifiziert werden kann und in ISO/IEC 27001 [19] integriert ist. Das AI Risk Management Framework des NIST bietet ein gemeinsames Vokabular mit vier Funktionen: Steuern, Zuordnen, Messen und Verwalten, und sein generatives KI-Profil 2024 fügt spezifische Risiken für generative Systeme hinzu, einschließlich Konfabulation und Informationsintegrität [20][22]. Beides ist keine GxP-Anforderung. Beide sind nützliche Gerüste für die Governance in Teil 5.

Bei all dem fallen zwei Dinge auf.

Erstens stimmen die Frameworks miteinander überein. Sie alle fordern einen definierten Verwendungszweck, risikobasierte Sicherheit, menschliche Verantwortung, dokumentierte Beweise und Kontrolle über Veränderungen. Eine Plattform, die für einen von ihnen gebaut wurde, ist der Weg zu den anderen.

Zweitens ist die stärkste Einschränkung immer noch ein Entwurf. Das ist ein Grund, jetzt dafür zu entwerfen, und kein Grund zu warten. Die Kosten für die Integration menschlicher Überprüfungen und Beweise in die Plattform sind gering. Die Kosten für die Nachrüstung nach einer Inspektion fallen nicht an.

Die Konsequenz, die alles andere prägt

Setzen Sie die Frameworks zusammen und es folgt eine Regel. Jeder KI-Einsatz muss vor dem Bau auf zwei Achsen klassifiziert werden.

1. GxP-Auswirkungen. Beeinträchtigt das Ergebnis die Produktqualität, die Patientensicherheit oder eine regulierte Aufzeichnung? Kritisch oder unkritisch?
2. Einfluss auf die Entscheidung. Beeinflusst die Ausgabe eine menschliche Entscheidung oder trifft sie die Entscheidung? Dies ist die Logik des FDA-Glaubwürdigkeitsrahmens, bei dem das Modellrisiko mit dem Einfluss des Modells und mit der Konsequenz einer falschen Entscheidung steigt [5]. Es ist auch die Logik von ICH Q9(R1), die die Formalität des Risikomanagements an die Wichtigkeit der Entscheidung knüpft und vor Subjektivität bei Risikobewertungen warnt [14].

Zusammen bilden die beiden Achsen vier Quadranten.

Die Plattform ist standardmäßig auf den oberen linken Quadranten eingestellt: Entscheidungsunterstützung, unkritische Nutzung, mit einer benannten Person, die prüft und unterzeichnet. Alles andere ist eine Ausnahme mit eigenem Validierungsfall. Der untere rechte Quadrant ist für generative Modelle vom Tisch, bis die Regulierungsbehörden etwas anderes sagen.

Die FDA hat bereits gezeigt, was ohne dies passiert. Im April 2026 richtete das Unternehmen ein Warnschreiben an einen Hersteller, nachdem bei einer Inspektion festgestellt wurde, dass das Unternehmen einen KI-Agenten eingesetzt hatte, um Spezifikationen und Aufzeichnungen ohne angemessene Überprüfung zu erstellen [7]. Das Unternehmen teilte den Ermittlern mit, dass es keine Prozessvalidierung durchgeführt habe, da der Agent ihm nie mitgeteilt habe, dass eine Validierung erforderlich sei. In dem Schreiben heißt es, dass ein Unternehmen, das KI als Hilfsmittel bei der Dokumentenerstellung einsetzt, die generierten Dokumente auf Richtigkeit und Konformität überprüfen muss. Außerdem wird 21 CFR 211.22(c) zitiert, die Regel, die die Qualitätsabteilung für Verfahren und Spezifikationen verantwortlich macht, und 211.100 zu schriftlichen Produktionskontrollen [7]. Die von der FDA erwartete Abhilfe war einfach: Eine autorisierte Person muss alle Ausgaben eines KI-Agenten überprüfen und freigeben [7]. Die britische MHRA äußerte sich im Juni 2026 ähnlich zu KI-gestützten Reaktionen auf Inspektionsergebnisse: Sie müssen korrekt, technisch überprüft und von einer verantwortlichen Person genehmigt sein [23].

Dieser Brief ist der Entwurfsvorschlag für eine regulierte KI-Plattform. Das System kann einen Entwurf erstellen. Ein Mensch entscheidet. Die Aufzeichnung zeigt, wer.

Die Klassifizierung entscheidet auch über die Validierungstiefe und die Überprüfungsstufe. Unter CSA kann eine unkritische Entscheidungsunterstützungsfunktion durch Tests und Überwachung ohne Skript sichergestellt werden, während für eine kritische Funktion Skriptnachweise pro Nutzungskontext erforderlich sind [3]. Im Rahmen des FDA-Glaubwürdigkeitsrahmens wächst der Glaubwürdigkeitsplan mit dem Modelleinfluss und der Entscheidungskonsequenz [5]. Teil 4 macht daraus eine konkrete Vorgehensweise.

Sechs Designprinzipien

Diese Prinzipien ziehen sich durch jeden weiteren Teil. Bei jedem einzelnen geht es darum, was es in der Praxis bedeutet und was es verhindert.

1. Standardmäßig souverän. Daten, Modelle und Protokolle bleiben innerhalb der Grenzen. In der Praxis: eine genehmigte Liste dessen, was die Grenze überschreiten darf, und sonst nichts. Es verhindert eine versehentliche Offenlegung und ermöglicht die Lieferantenaufsicht, die Anhang 11 und Anhang 22 vorsehen [10].
2. Standardverweigerung, wird vor dem Abruf erzwungen. Die Plattform weiß, wer fragt und welche Dokumente sie möglicherweise sehen, und filtert, bevor Text ein Modell erreicht. Die Isolierung auf Produktebene reicht nicht aus. Zwei Benutzer desselben Produkts können unterschiedliche Rechte an demselben Dokument haben. In der Praxis: Die Identität und Berechtigungen des Anrufers werden mit der Anfrage übertragen und der Retriever filtert sie vor dem Ranking, niemals nach der Generierung. Es verhindert die Leckpfade, die OWASP als Offenlegung sensibler Informationen sowie als Vektor- und Einbettungsschwächen auflistet [21].
3. Beweise zuerst. In jeder Antwort werden das Quelldokument, die Version und der verwendete Abschnitt zitiert. Wenn die Beweise dünn sind, sagt das System dies, anstatt zu raten. In der Praxis: Zitate enthalten Dokumentidentität, Version, Datum des Inkrafttretens und Abschnitt, und das System enthält sich unterhalb einer Beweisschwelle. Es liefert die Art von Beweisen, die das Glaubwürdigkeitsrahmenwerk der FDA verlangt [5].
4. Menschliche Verantwortung von Natur aus. Ergebnisse dienen der Entscheidungsunterstützung. Eine qualifizierte Person überprüft alles, was in einen GxP-Datensatz oder eine GxP-Entscheidung einfließt, und die Überprüfung selbst ist ein Datensatz. In der Praxis: eine Bewertungsstufe pro Quadrant und eine erfasste Aufzeichnung darüber, wer wann was überprüft hat. Dies ist die Regel im Abmahnungsschreiben vom April 2026 und im Entwurf des Anhangs 22 [7][10].
5. Risikobasierte Validierung und Änderungskontrolle. Der Verwendungszweck wird pro Funktion definiert. Änderungen an einem Modell, einer Eingabeaufforderung, einer Abrufeinstellung oder einem Einbettungsmodell sind kontrollierte Änderungen mit Beweisen, keine Konfigurationsänderungen. In der Praxis: eine Evaluierungssuite, die bei jeder Änderung ausgeführt wird, und eine Registrierung, die genau aufzeichnet, was bereitgestellt wird. Es steht im Einklang mit CSA und GAMP und schützt den Bestandsschutz gemäß dem AI Act, indem es „wesentliche Änderungen“ zu einer dokumentierten Entscheidung und nicht zu einem Unfall macht [2][3][12].
6. Aufzeichnungen, keine Protokolle. Prüfprotokolle erfüllen die Erwartungen von 21 CFR Teil 11 und Anhang 11: sicher, mit Zeitstempel versehen, zuordenbar, unveränderlich und für die gesamte Lebensdauer der Aufzeichnungen aufbewahrt [8][10]. In der Praxis: Audit-Ereignisse werden mit den gleichen Kontrollen wie andere GxP-Datensätze in einen Speicher geschrieben und ihre Aufbewahrung richtet sich nach dem Datensatz, auf den sie sich beziehen.

Modelle und Lieferanten, kurz

Das Modell ist der instabilste Teil der Plattform. Alle paar Monate erscheinen neue Versionen, Lizenzen ändern sich und Anbieter stellen Modelle ein. Daher darf die Plattform nicht von einem bestimmten Modell abhängig sein, und das Design muss einen Modellaustausch zu einer kontrollierten, nachgewiesenen Änderung und nicht zu einem Neuaufbau machen. Teil 2 stellt den Modellrouter vor, der dies ermöglicht. Zu Beginn zählen vier Punkte.

Open-Weight-Modelle und vom Anbieter unterstützte Modelle können beide lokal ausgeführt werden. Open-Weight-Modelle werden heruntergeladen und selbst gehostet. Vom Anbieter unterstützte Modelle werden unter einer kommerziellen Lizenz verpackt und unterstützt, laufen aber weiterhin auf Ihrer Hardware. Der Unterschied liegt im Support, der Entschädigung, der Verpackung und den Kosten. Es ist keine Souveränität. Jeder Pfad besteht den ausgehenden Test, wenn er korrekt bereitgestellt wird, und einer der beiden besteht ihn nicht, wenn die ihn umgebenden Tools in Ordnung sind.

Lizenzen sind unterschiedlich und ändern sich. Ab September 2026 verwenden mehrere starke Modellfamilien freizügige Lizenzen. Qwen3 Open-Weight-Releases und IBM Granite 4-Releases sind Apache 2.0, DeepSeek-Releases verwenden MIT und einige Mistral-Modelle sind Apache 2.0, andere nicht [18]. Die Llama 4 Community-Lizenz ist für weniger als 700 Millionen monatlich aktive Benutzer kostenlos, enthält jedoch Benennungs- und Zuordnungsregeln für abgeleitete Modelle [18]. Einige Anbieter verwenden benutzerdefinierte Bedingungen, die restriktiver sind als Apache 2.0. Überprüfen Sie die Lizenz auf der Modellkarte auf die genaue Version, die Sie bereitstellen, und tragen Sie sie in die in Teil 5 beschriebene Modellregistrierung ein. Dasselbe gilt für das Einbetten und Neuranking von Modellen, die oft vergessen werden. Sie verfügen auch über Lizenzen und Versionen, und eine Änderung des Einbettungsmodells macht jeden mit dem alten erstellten Vektor ungültig.

Sie können Trainingsdaten nicht vollständig verifizieren, also qualifizieren Sie stattdessen den Lieferanten. Modellkarten unterscheiden sich stark darin, was sie über Trainingsdaten und Wissensgrenzen offenlegen. Es gibt keine praktische Möglichkeit, ein Trainingskorpus von außen zu prüfen. Zwei Hebel helfen. Das EU-KI-Gesetz verpflichtet Anbieter von Allzweck-KI-Modellen zur Führung einer technischen Dokumentation, einschließlich einer Zusammenfassung der für die Schulung verwendeten Inhalte [11]. Und der GAMP AI Guide enthält einen Anhang zum Lieferantenmanagement, während der Entwurf von Anhang 22 ausdrücklich besagt, dass die Verantwortung beim regulierten Unternehmen und nicht beim Lieferanten liegt [1][10]. Die praktische Antwort ist eine Lieferantenqualifizierungsdatei für jedes Modell. Es sollte die Lizenz und die Versionskennung, die dokumentierte Zusammenfassung der Trainingsdaten, veröffentlichte Bewertungs- und Voreingenommenheitsnachweise, bekannte Einschränkungen, den Sicherheitsstatus des Bereitstellungscontainers, die Versions- und Änderungsbenachrichtigungsverpflichtungen des Anbieters, etwaige Support- und Entschädigungsbedingungen sowie Ihre eigenen Bewertungsergebnisse enthalten. Die Assurance Guidance der FDA erlaubt Lieferantennachweisen, Ihre eigenen Tests zu reduzieren, aber nur, wenn Sie über diesen Nachweis verfügen und ihn vorlegen können [3].

Behandeln Sie das Modell wie jede andere qualifizierte Komponente. Ein validiertes System ändert seine Datenbank-Engine nicht ohne eine Änderungsanforderung. Es sollte sein Sprachmodell auch nicht ohne eines ändern. Das bedeutet, dass das Register das Modell, seine Version, seine Lizenz, seine Evaluierungsergebnisse und die Produkte, die es verwenden, aufzeichnet und ein Austausch dasselbe Tor durchläuft wie jede andere kontrollierte Änderung.

Was als nächstes kommt

Alle Teile sind über den Serienindex in Teil 0 verlinkt. Teil 2 gibt die Referenzarchitektur an: die Steuerebene, die acht Ausführungsebenen und den Anforderungspfad, der Identität und Autorisierung in den Abruf überträgt, bevor Text ein Modell erreicht. Teil 3 behandelt Dokumente als geregelte Daten. Teil 4 beantwortet die Frage, die sich jeder Qualitätsmanager zuerst stellt: Wie validiert man ein System, das nicht deterministisch ist? Teil 5 behandelt Sicherheit, Datenschutz und Governance. Teil 6 behandelt Hosting, Kosten, Betrieb, das Team und eine Checkliste für die Produktionsbereitschaft.

Quellen für Teil 1

Mit (bestätigen) gekennzeichnete Links wurden für diesen Entwurf nicht erneut überprüft und müssen vor der Veröffentlichung überprüft werden.

1. ISPE. ISPE GAMP Guide: Künstliche Intelligenz. Juli 2025. Endgültig. https://ispe.org/publications/guidance-documents/gamp-guide-artificial-intelligence
2. ISPE. ISPE GAMP 5: Ein risikobasierter Ansatz für konforme GxP-Computersysteme, zweite Auflage. 2022. Endgültig. https://ispe.org/topics/gamp
3. FDA. Computersoftwaresicherung für Produktions- und Qualitätssystemsoftware. Leitfaden für Industrie und FDA-Mitarbeiter. September 2025. Endgültig. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-produktion-and-quality-system-software
4. Bundesregister. Hinweis zur Verfügbarkeit der CSA-Leitlinien. 24. September 2025. https://www.federalregister.gov/documents/2025/09/24/2025-18468/computer-software-assurance-for-produktion-and-quality-system-software-guidance-for-industry-and
5. FDA. Überlegungen zum Einsatz künstlicher Intelligenz zur Unterstützung der regulatorischen Entscheidungsfindung für Arzneimittel und biologische Produkte. Leitlinienentwurf, Januar 2025. Entwurf, nicht zur Umsetzung, Stand September 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological
6. FDA und EMA. Leitprinzipien guter KI-Praxis in der Arzneimittelentwicklung. Januar 2026. Unverbindlich. https://www.fda.gov/media/189581/download
7. FDA. Warning Letter, Referenz 722591, vom 2. April 2026, unter Berufung auf 21 CFR 211.22(c) und 211.100. Datenbank der FDA-Warnschreiben. https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/compliance-actions-and-activities/warning-letters (direkter Brieflink: bestätigen)
8. 21 CFR Teil 11, Elektronische Aufzeichnungen; Elektronische Signaturen, Abschnitt 11.10(e). eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
9. FDA. Datenintegrität und Compliance mit Drug CGMP: Fragen und Antworten. Leitfaden, Dezember 2018. Endgültig. (bestätigen)
10. Europäische Kommission. Konsultation der Interessenträger zu EudraLex Band 4: überarbeitetes Kapitel 4, überarbeiteter Anhang 11 und neuer Anhang 22, Künstliche Intelligenz. Konsultation 7. Juli bis 7. Oktober 2025. Entwurf, nicht angenommen, Stand September 2026. (Konsultationsseite: bestätigen)
11. Verordnung (EU) 2024/1689, das Gesetz über künstliche Intelligenz. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
12. Verordnung (EU) 2026/1744, der digitale Omnibus zur KI. Veröffentlicht am 24. Juli 2026, in Kraft getreten am 27. Juli 2026. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2026/1744/oj
13. Ministerium für Elektronik und Informationstechnologie, Indien. Digital Personal Data Protection Act, 2023, und Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13. November 2025, Amtsblatt vom 14. November 2025. (Link zum Amtsblatt: bestätigen)
14. ICH. Q9(R1) Qualitätsrisikomanagement. Schritt 4, Januar 2023. https://database.ich.org/sites/default/files/ICH_Q9(R1)_Guideline_Step4_2022_1219.pdf
15. EMA. Reflexionspapier zum Einsatz künstlicher Intelligenz im Lebenszyklus von Arzneimitteln, EMA/CHMP/CVMP/83833/2023. Angenommen im September 2024. https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline
16. MIT NANDA. Die GenAI-Kluft: Stand der KI in der Wirtschaft 2025. Juli 2025. (Link zum Bericht: bestätigen)
17. RAND Corporation. Ryseff, De Brühl, Newberry. Die Hauptursachen für das Scheitern von Projekten im Bereich der künstlichen Intelligenz und wie sie erfolgreich sein können. 2024. RRA2680-1. https://www.rand.org/pubs/research_reports/RRA2680-1.html (bestätigen)
18. Modelllizenzen: Meta Llama 4 Commu

nity-Lizenz; Qwen3-Modellkarten; IBM Granite 4-Modellkarten; DeepSeek-Modellkarten; Mistral-Modellkarten. Die Lizenzbedingungen sind auf jeder Modellkarte angegeben und variieren je nach Version. (Links: bei Veröffentlichung bestätigen, um die genauen bereitgestellten Versionen zu erfahren) 19. ISO. ISO/IEC 42001:2023, Managementsystem für künstliche Intelligenz. Dezember 2023. https://www.iso.org/standard/42001 20. NIST. Risikomanagement-Framework für künstliche Intelligenz (AI RMF 1.0), NIST AI 100-1. Januar 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (bestätigen) 21. OWASP GenAI-Sicherheitsprojekt. OWASP Top 10 für LLM-Anwendungen 2025. https://owasp.org/www-project-top-10-for-large-lingual-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf 22. NIST. Risikomanagement-Framework für künstliche Intelligenz: Profil für generative künstliche Intelligenz, NIST AI 600-1. Juli 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf (bestätigen) 23. MHRA-Inspektion. Blogbeitrag zum Einsatz von KI als Reaktion auf GxP-Inspektionsergebnisse. 29. Juni 2026. (bestätigen) 24. PIC/S. PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. In Kraft 1. Juli 2021. https://picscheme.org (Dokumentlink: bestätigen)