Coding Agents in Pharma und Medizintechnik: Welche Nachweise zählen

Ein Coding Agent soll Code für ein LIMS oder für die Software eines Medizinprodukts schreiben. Vor dem ersten Einsatz stellt die Qualitätssicherung eine berechtigte Frage: Welche Nachweise brauchen wir für dieses Werkzeug?

Zunächst ist der Agent von der Software zu unterscheiden, die er erzeugt. Hinzu kommt der Einsatzbereich: Geht es um ein GMP-IT-System oder um Medizinproduktesoftware? Die jeweiligen Regelwerke richten sich an unterschiedliche Adressaten. Dass der Agent nicht mit ausgeliefert wird, beantwortet noch nicht, welche Anforderungen für seinen Einsatz gelten.

Untersucht wird hier der Agent als Werkzeug im Entwicklungsprozess. Nicht untersucht wird KI, die im Produkt selbst steckt oder im validierten System mitläuft. Alle Angaben beziehen sich auf den Stand 10. September 2026. Dieser Text ersetzt keine Rechtsberatung und nimmt die Bewertung des konkreten Einsatzes bei einer Inspektion nicht vorweg.

Zwei Regelwerke, zwei Adressaten: Medizinprodukt oder GMP-IT-System

GxP ist der Sammelbegriff für die Anforderungen an die gute Praxis in regulierten Bereichen. Dazu gehören GMP für die Herstellung, GCP für klinische Prüfungen und GLP für das Labor. Validiert wird darin ein System im Produktivbetrieb, die Anlagensteuerung, das LIMS oder das elektronische Chargenprotokoll. Was in diesen Unternehmen seit Jahrzehnten CSV heißt, ausgeschrieben Computerised System Validation, zielt auf genau dieses System.

Ein Coding Agent läuft dort nie mit. Er sitzt davor, im Entwicklungsprozess. Damit ist er kein Bestandteil des validierten Systems, und damit ist noch nichts darüber gesagt, welche Nachweise sein Einsatz verlangt. Die beiden Sätze werden in der Debatte regelmäßig zusammengezogen, obwohl sie verschiedene Fragen beantworten.

Welche Nachweise erforderlich sind, hängt zunächst davon ab, wen die Pflicht trifft. Dafür kommen zwei Regelwerke in Betracht. Entscheidend ist dabei nicht, wie detailliert sie sind, sondern an wen sie sich richten. Danach richtet sich auch, wo Validierungsfragen in die Agent-Strategie gehören.

Im Medizinproduktfall gilt die MDR, Verordnung (EU) 2017/745. Adressat ist der Hersteller nach Art. 2 Nr. 30, und die Definition erfasst auch denjenigen, der ein Produkt entwerfen lässt und unter eigenem Namen in Verkehr bringt. Wer Softwareentwicklung in der Medizintechnik an einen Dienstleister vergibt, verschiebt damit die Tastatur, nicht die Pflicht.

Was die MDR zu Software verlangt, steht in Anhang I Kapitel II Nummer 17.2: Entwicklung und Herstellung nach dem Stand der Technik, unter Berücksichtigung des Entwicklungszyklus, des Risikomanagements einschließlich Informationssicherheit sowie von Verifizierung und Validierung. Geregelt wird der Lebenszyklus. Eine ausdrückliche Pflicht, die eingesetzten Werkzeuge zu qualifizieren, enthält die Klausel nicht. Sie steht anderswo.

Im GxP-IT-Fall wechselt der Adressat. EU-GMP Annex 11 in der Fassung Revision 1 vom Januar 2011 richtet sich an den regulierten Anwender, den Betrieb mit der Herstellungserlaubnis, nicht an den Softwarelieferanten. Den Lieferanten erreicht das Regelwerk mittelbar: über förmliche Vereinbarungen (§3.1), die Prüfung mitgelieferter Dokumentation (§3.3), den Inspektorenzugang zu Qualitätssystem- und Auditinformationen (§3.4) und die Lieferantenbewertung (§4.5). Ein Coding Agent in der Pipeline eines Zulieferers wird damit zum Gegenstand eines Lieferantenaudits, ein ähnliches Muster wie in der Bankenaufsicht nach MaRisk.

Wer beide Märkte bedient, kann einzelne Nachweise wiederverwenden, soweit Anforderung und Adressat sich decken. Zuordnung und Begründung fallen trotzdem für jedes Regelwerk getrennt an.

Was der Agent tut, entscheidet mehr als sein Name

Die Bezeichnung „Coding Agent“ ist keine regulatorische Kategorie. Für die Einordnung zählt, welche Aufgabe das Werkzeug übernimmt, und dabei sind vier zu unterscheiden:

• Er schreibt Produktcode oder Code für ein GxP-IT-System.
• Er entwirft Tests.
• Er führt Prüfungen aus, deren Ergebnis in einen Nachweis eingeht.
• Er bearbeitet freigaberelevante Unterlagen, Spezifikationen, Verfahrensanweisungen und Prüfprotokolle.

Für diese Tätigkeiten sind jeweils andere Bestimmungen einschlägig. Automatisierte Testwerkzeuge sind in Annex 11 ausdrücklich geregelt, freigaberelevante Unterlagen waren bereits Gegenstand einer Beanstandung, und für den Produktcode ist die Beleglage die dünnste von allen.

Der dokumentierte Behördenfall betrifft die vierte Tätigkeit. Am 2. April 2026 schickte die FDA einen Warning Letter an Purolea Cosmetics Lab, MARCS-CMS 722591, mit einer eigenen Abschnittsüberschrift: „Inappropriate Use of Artificial Intelligence in Pharmaceutical Manufacturing“. Beanstandet wird, dass die Firma KI-Agenten einsetzte, um Produktspezifikationen, Verfahren und Herstellungsanweisungen zu erzeugen, ohne die erforderliche fachliche Prüfung sicherzustellen. Zur fehlenden Prozessvalidierung antwortete die Firma, ihr sei die gesetzliche Anforderung nicht bekannt gewesen, da der eingesetzte KI-Agent sie nie erwähnt habe.

Gegenstand der Beanstandung ist Papier, keine Zeile Quellcode. Für die im Schreiben beschriebenen CGMP-Tätigkeiten fordert die FDA Prüfung und Freigabe der Agentenausgaben durch eine dazu befugte Person aus der Qualitätseinheit. Das ist ein Befund zu einem Arzneimittelhersteller und dessen CGMP-Pflichten. Wer daraus ein allgemeines Freigabemodell für jede Agentenausgabe in jedem Entwicklungsprozess macht, überträgt den Fall, ohne die Übertragung zu begründen.

Dasselbe Muster in Großbritannien: Das MHRA Inspectorate berichtete am 29. Juni 2026 von Stellungnahmen zu Inspektionsbefunden, die erfundene Verweise auf Leitlinien enthielten, und erwartet Antworten, die sachlich richtig, überprüfbar, fachlich geprüft und von einer dazu befugten Person freigegeben sind. Beide dokumentierten Behördenfälle des Jahres 2026 sind Dokumentenfälle. Ein öffentlicher Fall zu KI-Werkzeugen in der Codeentwicklung ist mir zum 10. September 2026 nicht bekannt.

Werkzeuganforderungen: benennen, bewerten, validieren

Drei Stufen kommen in den Regelwerken vor, und sie meinen nicht dasselbe.

Benennen. IEC 62304 verlangt, Standards, Methoden und Werkzeuge im Softwareentwicklungsplan festzuhalten, Klausel 5.1.4. Den kostenpflichtigen Normtext habe ich nicht gelesen. Wie weit die Klausel reicht, lässt sich dennoch anhand öffentlicher Quellen nachvollziehen. Ihr Anwendungsbereich ist enger, als die verbreitete Lesart vermuten lässt. In der geltenden Ausgabe gilt 5.1.4 für Software der Sicherheitsklasse C. Die Begründung der geplanten Änderungen durch das IEC-Gremium SC 62A/MT 49 beschreibt für die zweite Ausgabe die Streichung des Zusatzes „of class C“. Eine Streichung setzt voraus, dass die Beschränkung im geltenden Wortlaut steht. Gemeint ist die Klasse der entwickelten Software, nicht eine Klasse des Werkzeugs.

Unterhalb Klasse C lässt sich die Benennungspflicht also nicht ungeprüft aus 5.1.4 ableiten. Zur Beweiskraft des Dokuments gehört dabei eine Unterscheidung. Für den geplanten Stand der zweiten Ausgabe ist es ein unmittelbarer Beleg. Für den geltenden Wortlaut ist es nur ein mittelbarer Hinweis, denn es benennt die Beschränkung, um ihre Streichung zu begründen. Hinzu kommt, dass die Änderungsbegründung einen frühen Committee Draft begleitet, den das Gremium selbst als technisch unvollständig bezeichnet. Belegen lässt sich die Klassenbeschränkung im geltenden Text deshalb nur an der Norm selbst.

Bewerten. Annex 11 §4.7 verlangt dokumentierte Bewertungen der Eignung für automatisierte Testwerkzeuge und Testumgebungen. Verlangt ist eine Eignungsbewertung, die noch keine Validierung ist, und der Wortlaut bleibt eng bei Testwerkzeugen. Entwicklungswerkzeuge allgemein nennt er nicht. Für einen Agenten, der Tests entwirft oder ausführt, gilt diese Bestimmung unmittelbar. Wer einen Agenten Produktcode schreiben lässt, muss die Anforderung anderswo herleiten.

Validieren. Die FAQ des Verbands Benannter Stellen zu EN 62304 ist hier deutlicher, als die Werkzeugdebatte sie meist wiedergibt. Werkzeuge für Entwicklung, Auslieferung und Wartung erben die Sicherheitsklasse des Produkts nicht, sie sind klassenlos, und Entwicklungsplattformen sind keine Medizinproduktesoftware. Im selben Atemzug hält die FAQ fest, dass die Norm die Beherrschung von Werkzeugen verlangt, wenn diese mit Softwareeinheiten der Klassen B oder C eingesetzt werden, und dass der Hersteller die Verwendung eines Werkzeugs für den vorgesehenen Zweck zu validieren hat. Die Validierung selbst liegt außerhalb des Anwendungsbereichs der Norm. Außerhalb des Anwendungsbereichs heißt hier nicht, dass die Pflicht entfällt. Sie steht woanders.

Die FAQ verweist dafür auf Klausel 7.5.2.1 der damals geltenden Ausgabe von ISO 13485. Die Ausgabe 2016 führt die Pflicht für Software im Qualitätsmanagementsystem in Klausel 4.1.6: dokumentierte Verfahren zur Validierung vor der ersten Nutzung und nach Änderungen, mit risikoproportionalem Aufwand. Die Zuordnung zur Ausgabe von 2016 stammt von mir. Die FAQ stellt diesen Bezug nicht her. Gelesen habe ich keine der beiden Klauseln im Original. Beide sind kostenpflichtig, und ich stütze mich hier auf Darstellungen Dritter.

Ob ein Coding Agent unter „im Qualitätsmanagementsystem eingesetzt“ fällt, entscheidet die vorgesehene Nutzung. Reviews und Tests entscheiden es nicht. Sie kommen einen Schritt später zum Tragen, bei der Risikobewertung und bei der Begründung des Nachweisumfangs. Wer die Reihenfolge umdreht, argumentiert sich mit den eigenen Kontrollen aus einem Anwendungsbereich heraus, in dem er steht.

SOUP nach IEC 62304: warum das Werkzeug nicht darunter fällt

Solange der Agent nicht mit ausgeliefert wird, fällt er nicht unter die Definition. Die Anmerkung 2 zum Anwendungsbereich der Norm bindet die SOUP-Anforderungen an Software, die auf dem Prozessor des Produkts läuft. Eine Einschränkung bleibt: Was aus der Werkzeugkette mit ins Produkt wandert, etwa Laufzeitbibliotheken des Compilers, ist sehr wohl SOUP. Genau diesen Fall nennt die Team-NB-FAQ ausdrücklich.

Das „provenance“ in der Definition (Klausel 3.29) meint nicht Autorschaft. Ein Element wird zu SOUP, wenn keine angemessenen Aufzeichnungen seiner Entwicklungsprozesse verfügbar sind. Gefragt ist die Verfügbarkeit der Aufzeichnungen, nicht, wer die Zeilen getippt hat.

GAMP 5: Kategorie 5, und warum D9 der Werkzeuganhang ist

Für den GMP-IT-Fall führt das Kategorienschema der Branche zum selben Ergebnis. Kategorie 5 umfasst Individualsoftware. Die Einteilung ist in Anhang M4 von GAMP 5 Second Edition beschrieben. Mir ist keine veröffentlichte Aussage der ISPE dazu bekannt, ob die Codeherkunft diese Zuordnung beeinflusst. Meine Schlussfolgerung lautet: Die Herkunft des Codes ändert daran nichts. Die Kategorie fragt, was die Software ist und wie weit sie konfigurierbar ist, nicht, ob der erste Entwurf aus einem Agenten kam oder aus einem Kopf. Wem KI-generierter Code urheberrechtlich gehört, ist eine andere Frage und steht in einem eigenen Text: Urheberrecht bei KI-generiertem Code.

Der für die Frage nach Entwicklungswerkzeugen relevante Anhang ist nicht der mit KI im Titel. Nach dem öffentlichen Inhaltsverzeichnis ist D11 der Anhang zu künstlicher Intelligenz und maschinellem Lernen, der Werkzeuganhang ist D9 „Software Tools“. Ausschlaggebend ist, welche Aufgabe das Werkzeug im Prozess übernimmt, und ein Coding Agent ist ein Lebenszykluswerkzeug. Was D9 an Aufwand verlangt, weiß ich nicht: Der Leitfaden ist kostenpflichtig, ich habe ihn nicht eingesehen. Im Audit lässt sich die Einordnung ohne das Original nicht belastbar begründen.

Annex 11 ist dagegen offen nachlesbar und knüpft die Rückverfolgbarkeit an die Benutzeranforderungen. Nach §4.4 müssen diese über den Lebenszyklus hinweg nachverfolgbar bleiben. §4.5 verlangt vom regulierten Anwender angemessene Maßnahmen, um sicherzustellen, dass das System nach einem geeigneten Qualitätsmanagementsystem entwickelt wurde. Dazu gehört die Lieferantenbewertung. Von der Autorschaft einer Codezeile ist in keiner der beiden Bestimmungen die Rede.

FDA und CSA: Wie sich der Prüfaufwand risikobasiert begründen lässt

Auf der US-Seite hat die Aufsicht diese Begründung ausbuchstabiert. Die FDA hat am 3. Februar 2026 die Leitlinie „Computer Software Assurance for Production and Quality Management System Software“ neu herausgegeben, Docket FDA-2022-D-0795, und damit Abschnitt 6 der älteren Validierungsleitlinie abgelöst.

Der verbreitete Gegensatz „CSA statt CSV“ trägt dabei nicht. Die Leitlinie hält selbst fest, dass bereits die ältere Validierungsleitlinie einen risikobasierten Ansatz empfiehlt. CSA konkretisiert diesen Ansatz für Produktions- und Qualitätsmanagementsoftware von Medizinprodukteherstellern. Die Konkretisierung gilt allerdings für einen bestimmten Anwendungsbereich und löst die Validierung nicht allgemein ab.

Wo Entwicklungswerkzeuge darin auftauchen, ist genau umrissen. Die Leitlinie ordnet Software nach ihrem Verwendungszweck, und in die unterstützende Software fallen Werkzeuge, die Softwaresysteme testen oder überwachen oder Testtätigkeiten automatisieren, sofern die betroffene Software zur Produktion oder zum Qualitätsmanagementsystem gehört. Maßgeblich ist auch hier die Testtätigkeit.

Die Grenze steht im Dokument selbst: Die Entwicklungs- und Validierungsanforderungen für Gerätesoftwarefunktionen nimmt die Leitlinie aus ihrem Anwendungsbereich aus, und damit liegt ein Agent, der Code für ein Medizinprodukt schreibt, außerhalb.

Für diesen Fall gelten weiter die General Principles of Software Validation vom 11. Januar 2002, von denen nur Abschnitt 6 ersetzt wurde. Deren §5.2.5 verlangt, dass ein Werkzeug eine Qualität aufweist, die der des damit entwickelten Softwareprodukts nicht nachsteht, und dass eine Dokumentation die Validierung für den Verwendungszweck belegt. Die Passage steht im Zusammenhang mit Softwaretestwerkzeugen. Sie auf einen Codegenerator zu übertragen, ist eine Ableitung und keine Vorschrift. Ich halte sie für tragfähig, weil das Argument der Klausel, dass ein Werkzeug die Qualität des Ergebnisses mitbestimmt, für einen Codegenerator mindestens so stark gilt wie für einen Testtreiber. Im Auditgespräch gehört sie als Analogie gekennzeichnet, nicht als Zitat.

Zum Status dieser Dokumente gehört ein Hinweis der FDA selbst: Ihre Leitlinien beschreiben Empfehlungen und begründen keine rechtlich durchsetzbaren Pflichten. Wer sie in einem Auditbericht als Pflicht zitiert, zitiert sie falsch.

21 CFR Part 11 gilt nicht aus eigener Kraft

21 CFR Part 11 hängt an anderen Vorschriften. §11.1(b) erfasst elektronische Aufzeichnungen, die unter den Aufzeichnungspflichten anderer Behördenvorschriften entstehen, geändert, gepflegt oder übermittelt werden. Erst eine solche andere Vorschrift, im Fachjargon eine Predicate Rule, macht die Aufzeichnung zur Pflicht. Diese Abhängigkeit heißt akzessorisch. Commit-Historie, Agenten-Transkripte und Review-Threads fallen also dort hinein, wo eine Predicate Rule sie verlangt, und sonst nicht. Was in Projektplänen als CFR-Part-11-Compliance geführt wird, greift von sich aus nicht auf Entwicklungsartefakte durch. Der eCFR-Stand für Titel 21 ist der 4. September 2026.

Die Nachweiskette am Beispiel: eine Änderung am LIMS

Fünf Glieder tauchen in allen bisher betrachteten Regelwerken in irgendeiner Form auf: eine freigegebene Anforderung, ein Design, das sie umsetzt, Code, ein Test gegen die Anforderung und eine Freigabe durch einen verantwortlichen Menschen. Diese Fünferkette ist ein Arbeitsmodell, mit dem ich Nachweise sortiere, und keine wortgleiche Anforderung aller genannten Regelwerke.

Wie sie aussieht, zeigt ein erfundener, aber alltäglicher Fall. Ein Labor betreibt ein LIMS im GMP-Umfeld. Die Haltbarkeitsfrist eines Prüfmusters soll künftig auf volle Tage abgerundet werden statt kaufmännisch gerundet. Ein Agent schlägt die Änderung vor.

1. Anforderung. Die Änderung beginnt im Änderungsverfahren als Antrag mit Bezug auf die betroffene Benutzeranforderung. Annex 11 §4.4 verlangt, Benutzeranforderungen über den Lebenszyklus nachverfolgbar zu halten. Ohne diesen Bezug hat der spätere Test nichts, wogegen er prüfen könnte, und dass ein Agent den Vorschlag gemacht hat, ersetzt den Schritt nicht.
2. Design. Die Designspezifikation hält fest, wie abgerundet wird und welche Regel um genau Mitternacht gilt. Dass ich diese Zwischenstufe eigens ausweise, gehört zu meinem Arbeitsmodell. §6.5 des Annex-11-Revisionsentwurfs würde die dokumentierte Nachverfolgbarkeit zwischen Anforderung, Designspezifikation und Testfall ausdrücklich verlangen. Er ist Entwurf und heute keine Vorgabe.
3. Code. Der Merge Request dokumentiert die Änderung, und die geänderte Softwareversion ist eindeutig bezeichnet. Im Softwareentwicklungsplan beziehungsweise in der Eignungsbewertung ist benannt, dass ein Agent im Prozess eingesetzt wird und in welcher Rolle.
4. Test. Hier entscheidet sich, ob die Kette hält. Schreibt der Agent Code und Test, stammen Prüfling und Prüfmaßstab aus derselben Quelle, und ein Test, der die implementierte Rundung nachbaut, ist immer grün. Der Sollwert muss deshalb von jemand anderem aus der freigegebenen Anforderung abgeleitet werden: Probenahme am 1. März um 23:30 Uhr, Frist 14 Tage, erwartetes Haltbarkeitsdatum der 15. März und nicht der 16. Ein solcher unabhängig festgelegter Grenzfall ist aussagekräftiger als zwanzig generierte Testfälle (Muster der Testgenerierung).
5. Freigabe. Die Änderung wird nach dem festgelegten Änderungsverfahren geprüft und freigegeben, Annex 11 §10. Der Änderungsnachweis verbindet die betroffene Softwareversion mit den Prüfergebnissen und der Freigabe. Davon getrennt läuft der Audit Trail der produktiven Anwendung nach §9, der die Änderungen an GMP-relevanten Daten im Betrieb festhält.

Sichtbar wird in einer Inspektion davon dreierlei: der Name, das Datum und das freigegebene Dokument. Der Agent kann in dieser Kette mehrere Schritte unterstützen. Die Freigabe durch eine verantwortliche Person ersetzt er jedoch nicht.

Für den benachbarten Dokumentenfall hat die EMA das Verfahren schon beschrieben. Ihr Reflection Paper vom September 2024 verlangt in §2.3.5 für generative KI, die Produktinformationsdokumente entwirft oder prüft, enge menschliche Aufsicht und Prüfverfahren, die vor der Einreichung die sachliche Richtigkeit jedes modellgenerierten Textes sicherstellen. Geprüft wird das Ergebnis.

Hier lohnt es sich, einen häufigen Reflex genauer zu fassen. PIC/S PI 041-1 vom 1. Juli 2021 begrenzt seinen Anwendungsbereich in §4.1 auf Vor-Ort-Inspektionen, und Code oder Repositories kommen im Dokument nicht vor. Ein Ausschluss von Entwicklungsnachweisen folgt daraus nicht: §6.6.4 hält fest, dass gute Datenmanagementpraktiken für alle Funktionsbereiche gelten, die an GMP und GDP mitwirken, IT und Engineering eingeschlossen. Die belastbare Frage lautet deshalb nicht Produktlebenszyklus gegen Softwarelebenszyklus, sondern: Enthält ein Repository nur Entwicklungsarbeit, oder führt es zugleich Prüf- und Freigabenachweise? Im zweiten Fall ist ALCOA+ keine fremde Analogie mehr.

Schwieriger wird die Lieferantenbewertung nach §4.5, wenn der Anbieter sein Modell monatlich ändert. Die Grundlage der Bewertung verändert sich dann laufend. Belastbare Ergebnisse liefern eigene, wiederholte Messungen mit einem internen Evaluationsset. Und weil die gesamte Kette auf der Anforderung aufbaut, ist die Spezifikation die entscheidende Größe (Spec-driven Development). Bei echten Patientendaten in Testfixtures stellt sich eine eigene Frage: was der Agent überhaupt sehen darf.

Annex 22, und was offen bleibt

Wer mit validierten Systemen arbeitet, hat hier einen gut belegten Einwand parat: Eine regulatorische Determinismusforderung existiert. Der Entwurf zu Annex 22 „Artificial Intelligence“, am 7. Juli 2025 zur Konsultation veröffentlicht, lässt nur Modelle mit deterministischer Ausgabe zu, also solche, die bei identischer Eingabe identisch antworten. Generative KI und Large Language Models nimmt er aus seinem Anwendungsbereich aus und rät von ihnen in kritischen GMP-Anwendungen ab. Für nicht-kritische erlaubt er den Einsatz unter menschlicher Verantwortung, im Text Human-in-the-Loop genannt.

Diese Forderung bezieht sich jedoch auf einen anderen Einsatzfall. Der Anhang gilt für computergestützte Systeme in der Herstellung von Arzneimitteln und Wirkstoffen, in die KI-Modelle eingebettet sind. Er bezeichnet sich selbst als zusätzliche Leitlinie zu Annex 11 und verweist bei den Akzeptanzkriterien auf dessen Abschnitt 2.7. Geregelt wird das Modell im validierten System, nicht das Werkzeug, das den Code dafür mitgeschrieben hat.

Eine ausdrückliche Regelung für das Entwicklungswerkzeug habe ich im Entwurf nicht gefunden, die einschlägigen Begriffe beziehen sich dort ausschließlich auf Modellentwicklung und Modelltraining. Damit ist nur belegt, was ich gefunden habe. Ob allgemein formulierte Anforderungen auf den Fall anwendbar wären, ist damit nicht entschieden.

Dazu kommt der Status: Annex 22 ist am 10. September 2026 nicht in Kraft und fehlt auf der EudraLex-Band-4-Annexliste. Der Dreijahresplan der GMP/GDP-Inspectors-Working-Group nennt Q4 2026 als Zieltermin für die Übergabe eines finalen Texts an die Kommission, und ein Übergabetermin ist kein Inkrafttreten. In die andere Richtung fehlt der Bezug: Im geprüften Annex-11-Revisionsentwurf aus demselben Konsultationspaket findet sich kein Verweis auf Annex 22. Daraus folgt zunächst nur, dass die Rückverweisung fehlt. Über den Zusammenhang beider Dokumente ist damit nichts gesagt.

Auch die KI-Verordnung beantwortet die Werkzeugfrage nicht. Wer einen Agenten intern einsetzt, ist Betreiber nach Art. 3 Nr. 4, und für Anhang-I-Produkte greifen die Hochrisikopflichten seit der Verordnung (EU) 2026/1744 erst ab dem 2. August 2028. Rolle und Risikokategorie sind dabei getrennt zu betrachten.

Eine Stelle war bis zuletzt offen, und sie liegt nah an der Frage dieses Textes. IEC 62304 verlangt in Klausel 5.8.5, zu dokumentieren, wie die freigegebene Software entstanden ist. Das klingt zunächst nach einer Autorenhistorie. Dieselbe IEC-Änderungsbegründung ordnet die Klausel anders ein: Sie gilt heute für die Sicherheitsklassen B und C, an der Anforderung selbst ändert die zweite Ausgabe nichts, und die benachbarte Klarstellung zu 5.8.6 zielt auf Reproduzierbarkeit, Identifizierbarkeit, Integrität und Auslieferung. Gemeint ist der Build-Prozess. Den Normtext selbst habe ich nicht gelesen.

Belastbare branchenspezifische Zahlen zur Verbreitung von Coding Agents, zu ihren Fehlerraten oder zum Aufwand für Reviews in regulierten Unternehmen habe ich nicht gefunden. Deshalb stehen in diesem Text keine.

Wer unterschreibt, und was Sie vor dem ersten Agenten-Commit klären

Die Kette bleibt, die Menge ändert sich. Mehr generierter Code kann mehr Prüfaufwand mit sich bringen, und deshalb gehört die verfügbare Review-Kapazität in die Einsatzplanung. Was die freigebende Person bestätigt, ist die Übereinstimmung des Artefakts mit der Anforderung. Sie braucht dafür eine belastbare Entscheidungsgrundlage aus den vorgesehenen Reviews, Tests und Nachweisen. Wie sich die Prüfarbeit zwischen Mensch und Agent verteilt, steht in Code-Review mit Coding Agents: wer prüft wen.

Vor dem ersten Agenten-Commit, in dieser Reihenfolge. In Klammern steht, woher der Punkt kommt:

1. Adressat klären. (beide Regelwerke) Hersteller nach MDR Art. 2 Nr. 30 oder regulierter Anwender nach Annex 11. Davon hängt ab, ob der Agent in Ihrer technischen Dokumentation auftaucht oder im Lieferantenaudit Ihres Kunden.
2. Tätigkeit einordnen. (beide Regelwerke) Schreibt der Agent Produktcode, entwirft er Tests, führt er Prüfungen aus oder bearbeitet er freigaberelevante Unterlagen? Davon hängt ab, welche Klausel überhaupt einschlägig ist.
3. Fehlerbild aufschreiben. (eigene Prozessempfehlung) Welche Fehler kann der Agent verursachen, welche Folgen hätten sie, und wodurch würden sie erkannt? Ohne diese drei Antworten lässt sich kein Nachweisumfang risikobasiert begründen, weder nach CSA noch nach ISO 13485.
4. Werkzeug benennen. (Medizinprodukt) Erfassen Sie es im Softwareentwicklungsplan nach IEC 62304 5.1.4. Halten Sie dabei die zugrunde gelegte Normfassung und die Sicherheitsklasse der entwickelten Software fest: In der geltenden Ausgabe ist die Klausel auf Klasse C beschränkt, und die Beherrschung von Werkzeugen erwartet die Auslegung der Benannten Stellen ab Klasse B.
5. Werkzeug bewerten. (GMP-IT) Dokumentieren Sie die Eignungsbewertung automatisierter Testwerkzeuge und Testumgebungen nach Annex 11 §4.7. Für einen Agenten, der Produktcode schreibt, greift diese Klausel nicht unmittelbar.
6. Einsatz im Qualitätsmanagementsystem prüfen. (Medizinprodukt) Wird der Agent nach seiner vorgesehenen Nutzung im Qualitätsmanagementsystem eingesetzt, greift ISO 13485 4.1.6. Risikoproportional ist dann der Aufwand, nicht die Pflicht.
7. Rückverfolgbarkeit an den Anforderungen ausrichten. (GMP-IT) Nach Annex 11 §4.4, nicht an der Autorschaft der Zeile.
8. Freigabe festschreiben. (eigene Prozessempfehlung) Benannte Person, Befugnis, Datum. Dass die Freigabe vor dem Merge liegt, empfehle ich. Eine einheitliche regulatorische Vorgabe ist es nicht.

Kurzum, die Frage der Qualitätssicherung lässt sich nicht mit einem Ja oder Nein zur Validierung beantworten. Es kommt darauf an, wen die Pflicht trifft und was das Werkzeug im Prozess tut. Beides lässt sich vor dem ersten Commit begründet festlegen, und genau das erwartet eine Inspektion.

Häufige Fragen

Muss ein Coding Agent nach GAMP 5 validiert werden?

Er ist zunächst als Entwicklungswerkzeug einzuordnen und nicht als computergestütztes System im GxP-Betrieb, weil er nicht ausgeliefert wird und im validierten System nicht mitläuft. Damit ist noch nicht beantwortet, welche Nachweise sein Einsatz verlangt: Das hängt von der vorgesehenen Nutzung und vom einschlägigen Regelwerk ab. Welche Anforderungen GAMP 5 an Entwicklungswerkzeuge stellt, steht in Anhang D9 „Software Tools“. Dieser Text ist kostenpflichtig, und ich habe ihn nicht eingesehen. Bestehen bleiben in jedem Fall die Nachweise für die Software, die dabei entsteht.

In welche GAMP-5-Kategorie fällt Code, den ein Coding Agent geschrieben hat?

In dieselbe wie handgeschriebener Code. Die Zuordnung folgt der Konfigurierbarkeit und dem Individualisierungsgrad der Software, nicht der Herkunft des Quelltexts. Eine veröffentlichte Aussage der ISPE zur Codeherkunft ist mir zum 10. September 2026 nicht bekannt, das ist meine Schlussfolgerung und keine Vorgabe des Leitfadens. Die Codeherkunft hebt die Anforderungen an die entwickelte Software nicht auf.

Was ist der Unterschied zwischen CSV und CSA?

CSA ist keine Ablösung von CSV, sondern eine Konkretisierung des risikobasierten Ansatzes für Produktions- und Qualitätsmanagementsoftware von Medizinprodukteherstellern. Die FDA-Leitlinie vom 3. Februar 2026 hält selbst fest, dass bereits die ältere Validierungsleitlinie einen risikobasierten Ansatz empfiehlt. Entwicklungswerkzeuge, die testen oder überwachen, ordnet sie als unterstützende Software ein, deren Prüfaufwand sich risikobasiert reduzieren lässt. Die Entwicklung von Gerätesoftware nimmt sie ausdrücklich aus. FDA-Leitlinien beschreiben Empfehlungen und begründen keine rechtlich durchsetzbaren Pflichten.

Ist ein Coding Agent SOUP nach IEC 62304?

Ein Entwicklungswerkzeug, das nicht in das ausgelieferte Produkt gelangt, fällt nicht unter die SOUP-Definition der Norm. Eine mitausgelieferte Laufzeitbibliothek fällt darunter, unabhängig davon, wer sie eingebunden hat. Dass ein Werkzeug kein SOUP ist, bedeutet jedoch nicht, dass keine Nachweise für seinen Einsatz erforderlich sind. IEC 62304 verlangt in Klausel 5.1.4 die Benennung im Softwareentwicklungsplan. In der geltenden Ausgabe gilt diese Klausel für Software der Sicherheitsklasse C. Für die Validierung zum vorgesehenen Zweck verweist die Auslegung der Benannten Stellen auf ISO 13485.

Was ist EU-GMP Annex 22?

Ein Entwurf vom 7. Juli 2025 für eine zusätzliche Leitlinie zu Annex 11, gerichtet auf computergestützte Systeme mit eingebetteten KI-Modellen. Er ist zum 10. September 2026 nicht in Kraft und steht nicht auf der EudraLex-Liste, die EMA nennt Q4 2026 als Zielmarke für die Textübergabe. Generative KI und LLMs schließt der Entwurf aus seinem Anwendungsbereich aus. Eine ausdrückliche Regelung für Werkzeuge im Entwicklungsprozess enthält er nicht.